Protokollweiterleitung log-forwarding

Kundschaften, die eine Lizenz bei einem Logging-Anbieter besitzen oder ein Logging-Produkt hosten, können AEM-Protokolle (einschließlich Apache/Dispatcher) und CDN-Protokolle an das zugehörige Logging-Ziel 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"
   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"
   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 Logging-Konfiguration 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.

Für AEM-Protokolle (einschließlich Apache/Dispatcher) können Sie, wenn Sie Erweiterte Netzwerke konfiguriert haben, die aem.advancedNetworking-Eigenschaft verwenden, um sie von einer dedizierten Ausgangs-IP-Adresse weiterzuleiten.

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

kind: "LogForwarding"
version: "1"
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.

Gegenseitige TLS-Authentifizierung (TLS) mtls

Splunk-, Elasticsearch/OpenSearch- und HTTPS-Ziele unterstützen gegenseitiges TLS (mTLS). Bei mTLS stellt AEM as a Cloud Service ein Client-Zertifikat bereit, wenn es eine Verbindung zu Ihrem Protokollierungsziel herstellt, sodass das Ziel überprüfen kann, ob die Protokolle aus Ihrer Umgebung stammen. mTLS gilt für AEM-Protokolle (einschließlich Apache/Dispatcher) und für CDN-Protokolle.

mTLS arbeitet mit der vorhandenen Authentifizierung des Ziels zusammen. Behalten Sie die vorhandenen Authentifizierungseigenschaften des Ziels bei, z. B. token (Splunk) oder user und password (Elasticsearch/OpenSearch). Für HTTPS-Ziele, die CDN-Protokolle weiterleiten, sind authHeaderName und authHeaderValue erforderlich.

Konfiguration mtls-configuration

Fügen Sie einen mtls Block neben den anderen Eigenschaften des Ziels hinzu:

Im folgenden Beispiel werden AEM- und CDN-Protokolle mithilfe von mTLS an Splunk weitergeleitet:

kind: "LogForwarding"
version: "1"
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"
      mtls:
        cert: "${{SPLUNK_MTLS_CERT}}"
        key: "${{SPLUNK_MTLS_KEY}}"
        ca: "${{SPLUNK_MTLS_CA}}"

Es gelten folgende Regeln:

Unterstützte Schlüsselformate mtls-key-formats

Die erste Zeile des PEM-Texts des Schlüssels zeigt sein Format an:

Legen Sie für einen verschlüsselten Schlüssel auch keyPasswd auf sein Kennwort fest.

Verschlüsselte PKCS#8 wird für verschlüsselte Schlüssel empfohlen. Um einen Schlüssel im älteren Format zu konvertieren, verwenden Sie den folgenden Befehl, der nach dem aktuellen Kennwort und dann nach dem Kennwort des neuen Schlüssels fragt:

openssl pkcs8 -topk8 -v2 aes-256-cbc -in client.key -out client-pkcs8.key

Speichern Sie den Inhalt von client-pkcs8.key in den geheimen Daten, auf die von key verwiesen wird, und das zugehörige Kennwort in den geheimen Daten, auf die von keyPasswd verwiesen wird.

CDN-Protokolle mtls-cdn

Wie andere Eigenschaften gilt ein mtls unter default sowohl für AEM-Protokolle als auch für CDN-Protokolle. Um ein anderes Zertifikat für CDN-Protokolle zu verwenden, legen Sie die mtls in einem cdn fest. Um mTLS nur für AEM-Protokolle oder nur CDN-Protokolle zu verwenden, platzieren Sie den mtls in den aem- oder cdn-Block anstelle von default.

Nachdem Sie eine Konfiguration bereitgestellt haben, die die CDN-Protokollweiterleitung an ein Ziel ermöglicht, kann es mehrere Minuten dauern, bis die ersten CDN-Protokolle eintreffen. Bei HTTPS-Zielen beginnt die CDN-Protokollbereitstellung auch erst, nachdem Ihr Server die unter „HTTPS​ beschriebene einmalige Herausforderung abgeschlossen ​. Die Challenge-Anfrage wird mit demselben Client-Zertifikat gesendet, sodass Ihr Server dieses Zertifikat auch auf dem Challenge-Pfad akzeptieren muss.

Rotation und Ablauf von Zertifikaten mtls-rotation

Um ein Zertifikat zu rotieren, aktualisieren Sie die Cloud Manager Secret-Umgebungsvariablen, die das Zertifikat (und den Schlüssel, falls er geändert wurde) enthalten, und führen Sie die Konfigurations-Pipeline erneut aus. Wenn die Konfigurationsdatei für die Protokollweiterleitung selbst unverändert ist, nehmen Sie auch eine Änderung daran vor, damit die Konfiguration erneut angewendet wird. Speichern Sie beispielsweise die neuen Werte in neuen geheimen Umgebungsvariablen und verweisen Sie auf diese Namen im mtls.

Möglicherweise erhalten Sie auch eine proaktive Aktionscenter-Benachrichtigung etwa 21 Tage vor Ablauf eines Client-Zertifikats. Verfolgen Sie die Ablaufdaten von Zertifikaten selbst, anstatt sich auf diese Benachrichtigung zu verlassen.

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"
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"
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 bereitgestellt wurden, ü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"
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"
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"
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"
  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"
  data:
    dynatrace:
      default:
        enabled: true
        environmentId: "${{DYNATRACE_ENVID}}"
        token: "${{DYNATRACE_TOKEN}}"

Splunk splunk

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

Überlegungen

Sumo Logic sumologic

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"
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 Logging-Ziel weitergeleitet werden können, sind zusätzlich zum im Logging-Artikel 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.