Protokollweiterleitung log-forwarding

Kundinnen und Kunden, die eine Lizenz bei einem Protokollierungsanbieter besitzen oder ein Protokollierungsprodukt hosten, können AEM-Protokolle (einschließlich Apache/Dispatcher) und CDN-Protokolle an das zugehörige Protokollierungsziel weiterleiten lassen. AEM as a Cloud Service unterstützt die folgenden Protokollierungsziele:

Die Protokollweiterleitung wird im Self-Service-Modus konfiguriert, indem eine Konfiguration in Git deklariert wird, und kann über Cloud Manager-Konfigurations-Pipelines für Entwicklungs-, Staging- und Produktionsumgebungstypen bereitgestellt werden. Die Konfigurationsdatei kann mithilfe von Befehlszeilenprogrammen in schnellen Entwicklungsumgebungen (Rapid Development Environments, RDEs) bereitgestellt werden.

Es gibt eine Option für die Weiterleitung der AEM- und Apache/Dispatcher-Protokolle über die erweiterte Netzwerkinfrastruktur von AEM, z. B. eine dedizierte Egress-IP.

Die Netzwerkbandbreite, die mit an Splunk gesendeten Protokollen verknüpft ist, wird als Teil der kundenseitigen Netzwerk-E/A-Nutzung betrachtet.

Wie dieser Artikel organisiert ist how-organized

Dieser Artikel ist wie folgt aufgebaut:

Setup setup

Token in der Konfiguration (z. B. ${{SPLUNK_TOKEN}}) stellen geheime Daten dar, die nicht in Git gespeichert werden sollten. Deklarieren Sie sie stattdessen als Geheime Umgebungsvariablen von Cloud Manager. Wählen Sie Alle als Dropdown-Wert für das Feld „Angewendeter Service“ aus, damit Protokolle an die Autoren-, Veröffentlichungs- und Vorschauebenen weitergeleitet werden können.

Es ist möglich, für CDN-Protokolle und AEM-Protokolle (einschließlich Apache/Dispatcher) unterschiedliche Werte festzulegen, indem nach dem Block default ein zusätzlicher Block cdn und/oder aem eingefügt wird. Dabei können Eigenschaften die im Block default definierten Werte überschreiben. Nur die Eigenschaft „enabled“ ist erforderlich. Ein möglicher Anwendungsfall könnte die Verwendung eines abweichenden Splunk-Index für CDN-Protokolle sein, wie im folgenden Beispiel veranschaulicht.

   kind: "LogForwarding"
   version: "1"
   metadata:
     envTypes: ["dev"]
   data:
     splunk:
       default:
         enabled: true
         host: "splunk-host.example.com"
         token: "${{SPLUNK_TOKEN}}"
         index: "AEMaaCS"
       cdn:
         enabled: true
         token: "${{SPLUNK_TOKEN_CDN}}"
         index: "AEMaaCS_CDN"

Ein weiteres Szenario besteht darin, die Weiterleitung der CDN-Protokolle oder AEM-Protokolle (einschließlich Apache/Dispatcher) zu deaktivieren. Um beispielsweise nur die CDN-Protokolle weiterzuleiten, können Sie Folgendes konfigurieren:

   kind: "LogForwarding"
   version: "1"
   metadata:
     envTypes: ["dev"]
   data:
     splunk:
       default:
         enabled: true
         host: "splunk-host.example.com"
         token: "${{SPLUNK_TOKEN}}"
         index: "AEMaaCS"
       aem:
         enabled: false

Transport und erweiterte Netzwerkfunktionen transport-advancednetworking

Einige Organisationen möchten einschränken, welcher Traffic von den Protokollierungszielen empfangen werden kann. Andere benötigen möglicherweise andere Ports als HTTPS (443). In diesem Fall müssen vor der Implementierung der Protokollweiterleitungskonfiguration Erweiterte Netzwerkfunktionen konfiguriert werden.

In der folgenden Tabelle sehen Sie, welche Anforderungen an die erweiterte Netzwerk- und Protokollierungskonfiguration gestellt werden, je nachdem, ob Sie Port 443 verwenden oder nicht und ob Ihre Protokolle über eine feste IP-Adresse angezeigt werden müssen oder nicht.

Wenn Sie Erweiterte Netzwerkfunktionen konfiguriert haben, können Sie für AEM-Protokolle (einschließlich Apache/Dispatcher) die aem.advancedNetworking-Eigenschaft verwenden, um sie von einer dedizierten Egress-IP-Adresse oder über ein VPN weiterzuleiten.

Das folgende Beispiel zeigt, wie die Protokollierung an einem Standard-HTTPS-Port mit erweiterten Netzwerkfunktionen konfiguriert wird.

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      port: 443
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"
    aem:
      advancedNetworking: true

Für CDN-Protokolle können Sie die IP-Adressen auf die Zulassungsliste setzen, wie unter Fastly-Dokumentation – Öffentliche IP-Liste beschrieben. Wenn diese Liste der freigegebenen IP-Adressen zu groß ist, sollten Sie Traffic an einen HTTPS-Server oder Azure Blob Store (außer Adobe) senden, in den Logik erstellt werden kann, mit der die Protokolle von einer bekannten IP an ihr endgültiges Ziel gesendet werden.

Konfiguration des Protokollierungsziels logging-destinations

Im Folgenden sind die Konfigurationen sowie ggf. spezifische Überlegungen für die unterstützten Protokollierungsziele aufgeführt.

Amazon S3 amazons3

Die Protokollweiterleitung an Amazon S3 unterstützt AEM- und Dispatcher-Protokolle. CDN-Protokolle werden noch nicht unterstützt.

kind: "LogForwarding"
version: "1.0"
metadata:
  envTypes: ["dev"]
data:
  awsS3:
    default:
      enabled: true
      region: "your-bucket-region"
      bucket: "your_bucket_name"
      accessKey: "${{AWS_S3_ACCESS_KEY}}"
      secretAccessKey: "${{AWS_S3_SECRET_ACCESS_KEY}}"

Um die S3-Protokollweiterleitung zu verwenden, müssen Sie einen AWS IAM-Benutzenden mit der entsprechenden Richtlinie für den Zugriff auf Ihren S3-Bucket vorkonfigurieren. Wie Sie IAM-Benutzeranmeldeinformationen erstellen, erfahren Sie in der AWS IAM-Benutzerdokumentation.

Die IAM-Richtlinie sollte dem Benutzenden die Verwendung von s3:putObject ermöglichen. Beispiel:

 {
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "s3:PutObject"
        ],
        "Resource": "arn:aws:s3:::your_bucket_name/*"
    }]
}

Weitere Informationen zur Implementierung finden Sie in der Dokumentation zur AWS-Bucket-Richtlinie.

Azure Blob Storage azureblob

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  azureBlob:
    default:
      enabled: true
      storageAccountName: "example_acc"
      container: "aem_logs"
      sasToken: "${{AZURE_BLOB_SAS_TOKEN}}

Zur Authentifizierung sollte ein SAS-Token verwendet werden. Erstellen Sie das Token auf der Seite „Shared Access Signature“ und nicht auf der Seite „Shared Access Token“. Verwenden Sie die folgenden Einstellungen für die Konfiguration:

Im Folgenden finden Sie einen Screenshot einer Beispiel-SAS-Token-Konfiguration:

Wenn Protokolle nicht mehr bereitgestellt werden, nachdem sie zuvor korrekt funktioniert haben, überprüfen Sie, ob das von Ihnen konfigurierte SAS-Token weiterhin gültig ist, da es möglicherweise abgelaufen ist.

Azure Blob Storage-CDN-Protokolle azureblob-cdn

Jeder der global verteilten Protokollierungs-Server erzeugt alle paar Sekunden eine neue Datei im Ordner aemcdn. Nach der Erstellung wird nichts mehr an die Datei angehängt. Das Dateinamenformat ist JJJJ-MM-DDThhss.sss-uniqueid.log. Beispielsweise 2024-03-04T10:00:00.000-WnFWYN9BpOUs2aOVn4ee.log.

Beispielsweise zu einem bestimmten Zeitpunkt:

aemcdn/
   2024-03-04T10:00:00.000-abc.log
   2024-03-04T10:00:00.000-def.log

Und dann 30 Sekunden später:

aemcdn/
   2024-03-04T10:00:00.000-abc.log
   2024-03-04T10:00:00.000-def.log
   2024-03-04T10:00:30.000-ghi.log
   2024-03-04T10:00:30.000-jkl.log
   2024-03-04T10:00:30.000-mno.log

Jede Datei enthält mehrere JSON-Protokolleinträge, die sich jeweils in einer separaten Zeile befinden. Die Protokolleintragsformate werden unter Protokollierung für AEM as a Cloud Service beschrieben. Jeder Protokolleintrag enthält auch die zusätzlichen Eigenschaften, die im Abschnitt Protokolleintragsformate unten erwähnt werden.

Azure Blob Storage-AEM-Protokolle azureblob-aem

AEM-Protokolle (einschließlich Apache/Dispatcher) werden unter einem Ordner mit der folgenden Namenskonvention angezeigt:

Unter jedem Ordner wird eine einzelne Datei erstellt, an die angehängt wird. Kundinnen und Kunden sind für die Verarbeitung und Verwaltung dieser Datei verantwortlich, damit sie nicht zu groß wird.

Weitere Informationen finden Sie in den Protokolleintragsformaten unter Protolkollierung für AEM as a Cloud Service. Die Protokolleinträge enthalten auch die zusätzlichen Eigenschaften, die im Abschnitt Protokolleintragsformate unten erwähnt werden.

Datadog datadog

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  datadog:
    default:
      enabled: true
      host: "http-intake.logs.datadoghq.eu"
      token: "${{DATADOG_API_KEY}}"
      tags:
         tag1: value1
         tag2: value2

Überlegungen

Elasticsearch und OpenSearch elastic

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  elasticsearch:
    default:
      enabled: true
      host: "example.com"
      user: "${{ELASTICSEARCH_USER}}"
      password: "${{ELASTICSEARCH_PASSWORD}}"
      pipeline: "ingest pipeline name"

Überlegungen

def envType = ctx.aem_env_type != null ? ctx.aem_env_type : 'unknown';
def sourceType = ctx._index;
def date = new SimpleDateFormat('dd_MM_yyyy').format(new Date());
ctx._index = sourceType + "_" + envType + "_" + date;

HTTPS https

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  https:
    default:
      enabled: true
      url: "https://example.com/aem_logs/aem"
      authHeaderName: "X-AEMaaCS-Log-Forwarding-Token"
      authHeaderValue: "${{HTTPS_LOG_FORWARDING_TOKEN}}"

Überlegungen

HTTPS-CDN-Protokolle https-cdn

Web-Anfragen (POSTs) werden kontinuierlich mit einer JSON-Payload gesendet, die ein Array von Protokolleinträgen ist, wobei das unter Protokollierung für AEM as a Cloud Service beschriebene Protokolleintragsformat verwendet wird. Weitere Eigenschaften werden im Abschnitt Protokolleintragsformate unten beschrieben.

Es gibt auch eine Eigenschaft mit dem Namen sourcetype, für die der Wert aemcdn festgelegt ist.

HTTPS-AEM-Protokolle https-aem

Bei AEM-Protokollen (einschließlich Apache/Dispatcher) werden Web-Anfragen (POSTs) kontinuierlich mit einer JSON-Payload gesendet, die ein Array von Protokolleinträgen mit den verschiedenen Protokolleintragsformaten ist, wie unter Protokollierung für AEM as a Cloud Service beschrieben. Weitere Eigenschaften werden im Abschnitt Protokolleintragsformate unten beschrieben.

Es gibt auch eine Eigenschaft mit dem Namen Source-Type, die auf einen der folgenden Werte eingestellt ist:

New Relic-Protokoll-API newrelic-https

Die Protokollweiterleitung an New Relic nutzt die New Relic-HTTPS-API für die Aufnahme. Derzeit werden nur Protokolle von AEM und Dispatcher unterstützt. CDN-Protokolle werden noch nicht unterstützt.

  kind: "LogForwarding"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    newRelic:
      default:
        enabled: true
        uri: "https://log-api.newrelic.com/log/v1"
        apiKey: "${{NR_API_KEY}}"

Dynatrace-Protokoll-API dynatrace-https

Die Protokollweiterleitung an Dynatrace nutzt die Dynatrace-HTTPS-API für die Aufnahme. Derzeit werden nur Protokolle von AEM und Dispatcher unterstützt. CDN-Protokolle werden noch nicht unterstützt.

Das Umfangsattribut „Ingest Logs“ ist für das Token erforderlich.

  kind: "LogForwarding"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    dynatrace:
      default:
        enabled: true
        environmentId: "${{DYNATRACE_ENVID}}"
        token: "${{DYNATRACE_TOKEN}}"

Splunk splunk

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"

Überlegungen

Sumo Logic sumologic

Die Protokollweiterleitung an Sumo Logic unterstützt AEM- und Dispatcher-Protokolle; CDN-Protokolle werden noch nicht unterstützt.

Bei der Konfiguration der Sumo-Logik für die Datenaufnahme erhalten Sie eine „HTTP Source Address“, die den Host, den Receiver-URI und den privaten Schlüssel in einer einzigen Zeichenfolge bereitstellt. Beispiel:

https://collectors.de.sumologic.com/receiver/v1/http/ZaVnC...

Sie müssen den letzten Abschnitt der URL (ohne den vorhergehenden /) kopieren und als Cloud Manager-Geheimnis-Umgebungsvariable hinzufügen, wie oben im Abschnitt Setup beschrieben, und dann in Ihrer Konfiguration auf diese Variable verweisen. Ein Beispiel wird unten angezeigt.

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  sumoLogic:
    default:
      enabled: true
      collectorURL: "https://collectors.de.sumologic.com/receiver/v1/http"
      privateKey: "${{SUMOLOGIC_PRIVATE_KEY}}"
      index: "aem-logs"

Protokolleintragsformate log-formats

Unter Protokollierung für AEM as a Cloud Service finden Sie das Format der jeweiligen Protokolltypen (CDN-Protokolle und AEM-Protokolle, einschließlich Apache/Dispatcher).

Da Protokolle aus mehreren Programmen und Umgebungen an dasselbe Protokollierungsziel weitergeleitet werden können, sind zusätzlich zum im Protokollierungsartikel beschriebenen Output die folgenden Eigenschaften in jedem Protokolleintrag enthalten:

Beispielsweise könnten die Eigenschaften die folgenden Werte aufweisen:

aem_env_id: 1242
aem_env_type: dev
aem_program_id: 12314
aem_tier: author

Migration von der alten Protokollweiterleitung legacy-migration

Bevor die Konfiguration der Protokollweiterleitung über ein Self-Service-Modell erfolgte, wurden Kundinnen und Kunden aufgefordert, Support-Tickets zu öffnen, damit Adobe die Integration initiierte.

Kundinnen und Kunden, deren Setup von Adobe auf diese Weise erstellt wurde, können jederzeit zum Self-Service-Modell wechseln. Es gibt mehrere Gründe für diesen Umstieg:

Wenn Sie zur Migration bereit sind, konfigurieren Sie einfach die YAML-Datei wie in den vorherigen Abschnitten beschrieben. Verwenden Sie die Cloud Manager-Konfigurations-Pipeline, um sie in jeder Umgebung zu implementieren, in der die Konfiguration angewendet werden soll.

Es wird empfohlen, ist aber nicht erforderlich, dass eine Konfiguration in allen Umgebungen implementiert wird, damit sie alle per Self-Service gesteuert werden. Anderenfalls könnten Sie vielleicht vergessen, welche Umgebungen von Adobe und welche Umgebungen eigenständig konfiguriert wurden.