Protokollweiterleitung log-forwarding

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

Die Protokollweiterleitung wird auf Self-Service-Weise konfiguriert, indem eine Konfiguration in Git deklariert und über die Cloud Manager-Konfigurationspipeline in Produktionsprogrammen (nicht Sandbox) für RDE-, Entwicklungs-, Staging- und Produktionsumgebungstypen bereitgestellt wird.

Es gibt eine Option, mit der die AEM- und Apache/Dispatcher-Protokolle über AEM erweiterte Netzwerkinfrastruktur, wie z. B. dedizierte Egress-IP, weitergeleitet werden können.

Beachten Sie, dass die Netzwerkbandbreite, die mit an das Protokollierungsziel gesendeten Protokollen verknüpft ist, als Teil der Netzwerk-I/O-Nutzung Ihres Unternehmens betrachtet wird.

Wie dieser Artikel organisiert ist how-organized

Dieser Artikel ist wie folgt organisiert:

Einrichtung setup

Token in der Konfiguration (z. B. ${{SPLUNK_TOKEN}}) stellen Geheimnisse dar, die nicht in Git gespeichert werden sollten. Deklarieren Sie sie stattdessen als Cloud Manager Secret Environment Variables. Stellen Sie sicher, dass Sie "Alle"als Dropdown-Wert für das Feld "Dienst angewendet"auswählen, damit Protokolle an die Ebenen "Autor", "Veröffentlichen"und "Vorschau"weitergeleitet werden können.

Es ist möglich, verschiedene Werte zwischen CDN-Protokollen und AEM-Protokollen (einschließlich Apache/Dispatcher) festzulegen, indem ein zusätzlicher Block cdn und/oder aem nach dem Block default eingefügt wird, in dem Eigenschaften die im Block default definierten überschreiben können. Es ist nur die aktivierte Eigenschaft erforderlich. Ein möglicher Anwendungsfall könnte die Verwendung eines anderen Splunk-Index für CDN-Protokolle sein, wie im folgenden Beispiel gezeigt wird.

   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

Konfiguration des Protokollierungsziels logging-destinations

Die Konfigurationen für die unterstützten Protokollierungsziele sind unten aufgeführt, zusammen mit allen spezifischen Überlegungen.

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}}

Für die Authentifizierung sollte ein SAS-Token verwendet werden. Sie sollte nicht auf der Seite Freigegebener Zugriffstoken, sondern auf der Signaturseite Freigegebener Zugriff erstellt und mit den folgenden Einstellungen konfiguriert werden:

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

Wenn die Protokolle nach der ordnungsgemäßen Funktionsweise nicht mehr bereitgestellt werden, ü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 Protokollierungsserver erzeugt alle paar Sekunden eine neue Datei im Ordner "aemcdn". Nach der Erstellung wird die Datei nicht mehr an angehängt. Das Format des Dateinamens ist YYY-MM-DDThhs.sss-uniqueid.log. Beispiel: 2024-03-04T10:00:00.000-WnFWYN9BpOUs2aOVn4ee.log.

Beispiel:

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

Und 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 jeweils in einer separaten Zeile stehen. Die Protokolleintragsformate werden unter Protokollierung für AEM as a Cloud Service beschrieben und jeder Protokolleintrag enthält auch die zusätzlichen Eigenschaften, die im Abschnitt Protokolleintragsformate unten erwähnt werden.

Azure Blob Storage-AEM 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 und an diese angehängt. Kunden sind für die Verarbeitung und Verwaltung dieser Datei verantwortlich, sodass sie nicht zu groß wird.

Siehe Protokolleintragsformate unter Protokollierung 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

Zu beachten:

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"

Zu beachten:

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}}"

Zu beachten:

HTTPS-CDN-Protokolle https-cdn

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

Es gibt auch eine Eigenschaft mit dem Namen sourcetype, die auf den Wert aemcdn festgelegt ist.

HTTPS-AEM https-aem

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

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

Splunk splunk

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

Zu beachten:

Protokolleintragsformate log-formats

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

Da Protokolle aus mehreren Programmen und Umgebungen an dasselbe Protokollierungsziel weitergeleitet werden können, werden zusätzlich zur im Protokollartikel beschriebenen Ausgabe die folgenden Eigenschaften in jeden Protokolleintrag aufgenommen:

Beispielsweise könnten die Eigenschaften die folgenden Werte aufweisen:

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

Erweiterte Netzwerkfunktionen advanced-networking

Einige Unternehmen beschränken, welcher Traffic von den Protokollierungszielen empfangen werden kann.

Für das CDN-Protokoll können Sie die IP-Adressen auf die Zulassungsliste setzen, wie in der Schnelldokumentation - Öffentliche IP-Liste beschrieben. Wenn die Liste der freigegebenen IP-Adressen zu groß ist, sollten Sie Traffic an einen HTTPS-Server oder (Nicht-Adobe) Azure Blob Store senden, wo Logik geschrieben werden kann, um die Protokolle von einer bekannten IP an ihr ultimatives Ziel zu senden.

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

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

Migration von der alten Protokollweiterleitung legacy-migration

Bevor die Konfiguration der Protokollweiterleitung über ein Self-Service-Modell erreicht wurde, wurden die Kunden aufgefordert, Support-Tickets zu öffnen, wo Adobe die Integration starten würde.

Kunden, die auf diese Weise von Adobe eingerichtet wurden, können sich gerne an das Self-Service-Modell anpassen. Es gibt mehrere Gründe für diese Umstellung:

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

Es wird empfohlen, jedoch nicht erforderlich, eine Konfiguration für alle Umgebungen bereitzustellen, damit sie alle von selbst gesteuert werden. Wenn nicht, vergessen Sie möglicherweise, welche Umgebungen von Adobe konfiguriert wurden, im Vergleich zu den auf Self-Service-Art konfigurierten Umgebungen.