AEM as a Cloud Service ist eine Plattform, auf der Kunden benutzerdefinierten Code einbinden können, um einzigartige Erlebnisse für ihre Kunden zu erstellen. Vor diesem Hintergrund ist der Protokollierungsdienst eine wichtige Funktion, um die Codeausführung in lokalen Entwicklungs- und Cloud-Umgebungen, insbesondere in den Entwicklungsumgebungen des AEM as a Cloud Service, zu debuggen und zu verstehen.
Die Protokollierung und Protokollierungsebenen in AEM as a Cloud Service werden in Konfigurationsdateien verwaltet, die als Teil des AEM-Projekts in Git gespeichert und als Teil des AEM-Projekts über Cloud Manager bereitgestellt werden. Die Protokollierung in AEM as a Cloud Service kann in zwei logische Gruppen unterteilt werden:
Die Protokollierung auf der AEM-Programmebene erfolgt über drei Protokolle:
HTTP-Anfragen, die aus dem Dispatcher-Cache der Veröffentlichungsstufe oder dem vorgelagerten CDN bedient werden, werden in diesen Protokollen nicht berücksichtigt.
AEM as a Cloud Service bietet Zugriff auf Java-Protokolleinträge. Entwickler von Programmen für AEM sollten sich an die allgemeinen Best Practices für die Java-Protokollierung halten und relevante Einträge zur Ausführung von benutzerdefiniertem Code auf den folgenden Protokollebenen protokollieren:
AEM-Umgebung | Protokollebene | Beschreibung | Verfügbarkeit der Protokolleinträge |
Entwicklung | DEBUG |
Beschreibt, was im Programm geschieht. Wenn die DEBUG-Protokollierung aktiv ist, werden Einträge protokolliert, die ein klares Bild davon vermitteln, welche Aktivitäten stattfinden und welche Schlüsselparameter die Verarbeitung beeinflussen. |
|
Staging | WARN |
Beschreibt Bedingungen, bei denen Fehler auftreten können. Wenn die WARN-Protokollierung aktiv ist, werden nur Einträge protokolliert, die auf Zustände hinweisen, die sich einer Suboptimalität nähern. |
|
Produktion | ERROR |
Beschreibt Bedingungen, die auf einen Fehler hinweisen und gelöst werden müssen. Wenn die ERROR-Protokollierung aktiv ist, werden nur Einträge protokolliert, die auf Fehler hinweisen. ERROR-Protokolleinträge weisen auf ein ernstes Problem hin, das so schnell wie möglich behoben werden sollte. |
|
Während die Java-Protokollierung mehrere andere Ebenen der Protokollierungsgranularität unterstützt, empfiehlt AEM as a Cloud Service die Verwendung der drei oben beschriebenen Ebenen.
Die AEM-Protokollstufen werden pro Umgebungstyp über die OSGi-Konfiguration festgelegt, die wiederum an Git gebunden sind, und über den Cloud Manager an AEM as a Cloud Service bereitgestellt. Aus diesem Grund ist es am besten, Protokolleinträge konsistent und für Umgebungstypen bekannt zu halten, um sicherzustellen, dass die über AEM verfügbaren Protokolle auf der optimalen Protokollebene verfügbar sind, ohne dass eine erneute Bereitstellung der Anwendung mit der aktualisierten Protokollebenenkonfiguration erforderlich ist.
Beispiel einer Protokollausgabe
22.06.2020 18:33:30.120 [cm-p12345-e6789-aem-author-86657cbb55-xrnzq] *ERROR* [qtp501076283-1809] io.prometheus.client.dropwizard.DropwizardExports Failed to get value from Gauge
22.06.2020 18:33:30.229 [cm-p12345-e6789-aem-author-86657cbb55-xrnzq] *INFO* [qtp501076283-1805] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials
22.06.2020 18:33:30.370 [cm-p12345-e6789-aem-author-86657cbb55-xrnzq] *INFO* [73.91.59.34 [1592850810364] GET /libs/granite/core/content/login.html HTTP/1.1] org.apache.sling.i18n.impl.JcrResourceBundle Finished loading 0 entries for 'en_US' (basename: <none>) in 4ms
22.06.2020 18:33:30.372 [cm-p12345-e6789-aem-author-86657cbb55-xrnzq] *INFO* [FelixLogListener] org.apache.sling.i18n Service [5126, [java.util.ResourceBundle]] ServiceEvent REGISTERED
22.06.2020 18:33:30.372 [cm-p12345-e6789-aem-author-86657cbb55-xrnzq] *WARN* [73.91.59.34 [1592850810364] GET /libs/granite/core/content/login.html HTTP/1.1] libs.granite.core.components.login.login$jsp j_reason param value 'unknown' cannot be mapped to a valid reason message: ignoring
Protokollformat
Datum und Uhrzeit | 29.04.2020 21:50:13.398 |
AEM as a Cloud Service-Knoten-ID | [cm-p1234-e5678-aem-author-59555cb5b8-q7l9s] |
Protokollebene | DEBUG |
Thread | qtp2130572036-1472 |
Java-Klasse | com.example.approval.workflow.impl.CustomApprovalWorkflow |
Protokolleintrag | Kein angegebener Genehmigender, standardmäßig [Creative Genehmigende-Benutzergruppe] |
AEM-Java-Protokolle werden als OSGi-Konfiguration definiert und zielen daher mithilfe von Ordnern im Ausführungsmodus auf bestimmte AEM as a Cloud Service-Umgebungen ab.
Konfigurieren Sie die Java-Protokollierung für benutzerdefinierte Java-Pakete über OSGi-Konfigurationen für die Sling LogManager-Factory. Es werden zwei Konfigurationseigenschaften unterstützt:
OSGi-Konfigurationseigenschaft | Beschreibung |
---|---|
org.apache.sling.commons.log.names | Die Java-Pakete, für die Protokolleinträge gesammelt werden sollen. |
org.apache.sling.commons.log.level | Die Protokollebene, auf der die Java-Pakete protokolliert werden sollen, angegeben durch org.apache.sling.commons.log.names |
Das Ändern anderer LogManager OSGi-Konfigurationseigenschaften kann zu Verfügbarkeitsproblemen in AEM as a Cloud Service führen.
Im Folgenden finden Sie Beispiele für die empfohlenen Protokollierungskonfigurationen (unter Verwendung des Platzhalter-Java-Pakets com.example
) für die drei Umgebungstypen von AEM as a Cloud Service.
/apps/my-app/config/org.apache.sling.commons.log.LogManager.factory.config-example.cfg.json
{
"org.apache.sling.commons.log.names": ["com.example"],
"org.apache.sling.commons.log.level": "debug"
}
/apps/my-app/config.stage/org.apache.sling.commons.log.LogManager.factory.config-example.cfg.json
{
"org.apache.sling.commons.log.names": ["com.example"],
"org.apache.sling.commons.log.level": "warn"
}
/apps/my-app/config.prod/org.apache.sling.commons.log.LogManager.factory.config-example.cfg.json
{
"org.apache.sling.commons.log.names": ["com.example"],
"org.apache.sling.commons.log.level": "error"
}
Die HTTP-Anfrageprotokollierung von AEM as a Cloud Service bietet Einblick in die an AEM gesendeten HTTP-Anfragen und deren HTTP-Antworten in zeitlicher Reihenfolge. Dieses Protokoll ist hilfreich, um die HTTP-Anfragen an AEM und die Reihenfolge zu verstehen, in der sie verarbeitet und beantwortet werden.
Der Schlüssel zum Verständnis dieses Protokolls liegt in der Zuordnung der HTTP-Anfrage- und Antwortpaare anhand ihrer Kennungen, die durch den numerischen Wert in den Klammern angegeben werden. Beachten Sie, dass zwischen Anfragen und den zugehörigen Antworten häufig andere HTTP-Anfragen und -Antworten im Protokoll stehen.
Beispielprotokoll
29/Apr/2020:19:14:21 +0000 [137] -> POST /conf/global/settings/dam/adminui-extension/metadataprofile/ HTTP/1.1 [cm-p1234-e5678-aem-author-59555cb5b8-q7l9s]
...
29/Apr/2020:19:14:22 +0000 [139] -> GET /mnt/overlay/dam/gui/content/processingprofilepage/metadataprofiles/editor.html/conf/global/settings/dam/adminui-extension/metadataprofile/main HTTP/1.1 [cm-p1234-e5678-aem-author-59555cb5b8-q7l9s]
...
29/Apr/2020:19:14:21 +0000 [137] <- 201 text/html 111ms [cm-p1234-e5678-aem-author-59555cb5b8-q7l9s]
...
29/Apr/2020:19:14:22 +0000 [139] <- 200 text/html;charset=utf-8 637ms [cm-p1234-e5678-aem-author-59555cb5b8-q7l9s]
Protokollformat
Datum und Uhrzeit | 29. April 2020:19:14:21 +0000 |
Kennung des Anfrage-/Antwortpaares | [137] |
HTTP-Methode | POST |
URL | /conf/global/settings/dam/adminui-extension/metadataprofile/ |
Protokoll | HTTP/1.1 |
AEM as a Cloud Service-Knoten-ID | [cm-p1234-e5678-aem-author-59555cb5b8-q7l9s] |
Das AEM-Protokoll für HTTP-Anfragen kann in AEM as a Cloud Service nicht konfiguriert werden.
Die Protokollierung von HTTP-Zugriffen in AEM as a Cloud Service zeigt HTTP-Anfragen in zeitlicher Reihenfolge an. Jeder Protokolleintrag stellt die HTTP-Anfrage dar, die auf AEM zugreift.
Dieses Protokoll ist hilfreich, um schnell zu verstehen, welche HTTP-Anfragen an AEM gesendet werden, ob sie erfolgreich sind, indem man sich den zugehörigen Status-Code der HTTP-Antwort ansieht, und wie lange es dauerte, bis die HTTP-Anfrage abgeschlossen war. Dieses Protokoll kann auch hilfreich sein, um die Aktivität eines bestimmten Benutzers zu debuggen, indem die Protokolleinträge nach Benutzern gefiltert werden.
Beispiel einer Protokollausgabe
cm-p1234-e26813-aem-author-59555cb5b8-8kgr2 - example@adobe.com 30/Apr/2020:17:37:14 +0000 "GET /libs/granite/ui/references/clientlibs/references.lc-5188e85840c529149e6cd29d94e74ad5-lc.min.css HTTP/1.1" 200 1141 "https://author-p10711-e26813.adobeaemcloud.com/mnt/overlay/dam/gui/content/assets/metadataeditor.external.html?item=/content/dam/en/images/example.jpeg&_charset_=utf8" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36"
cm-p1234-e26813-aem-author-59555cb5b8-8kgr2 - example@adobe.com 30/Apr/2020:17:37:14 +0000 "GET /libs/dam/gui/coral/components/admin/customthumb/clientlibs.lc-60e4443805c37afa0c74b674b141f1df-lc.min.css HTTP/1.1" 200 809 "https://author-p10711-e26813.adobeaemcloud.com/mnt/overlay/dam/gui/content/assets/metadataeditor.external.html?item=/content/dam/en/images/example.jpeg&_charset_=utf8" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36"
cm-p1234-e26813-aem-author-59555cb5b8-8kgr2 - example@adobe.com 30/Apr/2020:17:37:14 +0000 "GET /libs/dam/gui/coral/components/admin/metadataeditor/clientlibs/metadataeditor.lc-4a2226d8232f8b7ab27d24820b9ddd64-lc.min.js HTTP/1.1" 200 7965 "https://author-p10711-e26813.adobeaemcloud.com/mnt/overlay/dam/gui/content/assets/metadataeditor.external.html?item=/content/dam/en/images/example.jpeg&_charset_=utf8" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36"
AEM as a Cloud Service-Knoten-ID | cm-p1235-e2644-aem-author-59555cb5b8-8kgr2 |
---|---|
IP-Adresse des Clients | - |
User | myuser@adobe.com |
Datum und Uhrzeit | 30. April 2020:17:37:14 +0000 |
HTTP-Methode | GET |
URL | /libs/granite/ui/references/clientlibs/references.lc-5188e85840c529149e6cd29d94e74ad5-lc.min.css |
Protokoll | HTTP/1.1 |
HTTP-Antwortstatus | 200 |
Größe des Antworttextes in Byte | 1141 |
Referrer | "https://author-p1234-e4444.adobeaemcloud.com/mnt/overlay/dam/gui/content/assets/metadataeditor.external.html?item=/content/dam/wknd/en/adventures/surf-camp-in-costa-rica/adobestock_266405335.jpeg&_charset_=utf8" |
Benutzeragent | "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36" |
Das HTTP-Zugriffsprotokoll kann in AEM as a Cloud Service nicht konfiguriert werden.
AEM as a Cloud Service stellt drei Protokolle für die Apache-Webserver- und Dispatcher-Schicht der Veröffentlichungsebene bereit:
Beachten Sie, dass diese Protokolle nur für die Veröffentlichungsstufe verfügbar sind.
Dieser Satz an Protokollen bietet Einblicke in HTTP-Anfragen an die Veröffentlichungsstufe von AEM as a Cloud Service, bevor diese Anfragen das AEM-Programm erreichen. Dies ist wichtig, da im Idealfall die meisten HTTP-Anfragen an die Server der Veröffentlichungsstufe von Inhalten bereitgestellt werden, die von Apache HTTPD Web Server und AEM Dispatcher zwischengespeichert werden und niemals das AEM-Programm selbst erreichen. Daher gibt es keine Protokolleinträge für diese Anfragen in Java-, Anfrage- oder Zugriffsprotokollen in AEM.
Das Apache HTTP Web Server-Zugriffsprotokoll enthält Einträge für jede HTTP-Anfrage, die den Webserver/Dispatcher der Veröffentlichungsstufe erreicht. Beachten Sie, dass Anfragen, die von einem vorgelagerten CDN bereitgestellt werden, in diesen Protokollen nicht berücksichtigt werden.
Informationen zum Fehlerprotokollformat finden Sie in der offiziellen Dokumentation von Apache.
Beispiel einer Protokollausgabe
cm-p1234-e5678-aem-publish-b86c6b466-qpfvp - - 17/Jul/2020:09:14:41 +0000 "GET /etc.clientlibs/wknd/clientlibs/clientlib-site/resources/images/favicons/favicon-32.png HTTP/1.1" 200 715 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0"
cm-p1234-e5678-aem-publish-b86c6b466-qpfvp - - 17/Jul/2020:09:14:41 +0000 "GET /etc.clientlibs/wknd/clientlibs/clientlib-site/resources/images/favicons/favicon-512.png HTTP/1.1" 200 9631 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0"
cm-p1234-e5678-aem-publish-b86c6b466-qpfvp - - 17/Jul/2020:09:14:42 +0000 "GET /etc.clientlibs/wknd/clientlibs/clientlib-site/resources/images/country-flags/US.svg HTTP/1.1" 200 810 "https://publish-p6902-e30226.adobeaemcloud.com/content/wknd/us/en.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0"
Protokollformat
AEM as a Cloud Service-Knoten-ID | cm-p1234-e26813-aem-publish-5c787687c-lqlxr |
IP-Adresse des Clients | - |
User | - |
Datum und Uhrzeit | 01. Mai 2020:00:09:46 +0000 |
HTTP-Methode | GET |
URL | /content/example.html |
Protokoll | HTTP/1.1 |
HTTP-Antwortstatus | 200 |
Größe | 310 |
Referenz | - |
Benutzeragent | „Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/81.0.4044.122 Safari/537.36“ |
Dieses Protokoll kann in AEM as a Cloud Service nicht konfiguriert werden.
Das Apache HTTP Web Server-Fehlerprotokoll enthält Einträge für jeden Fehler im Webserver/Dispatcher der Veröffentlichungsstufe.
Informationen zum Fehlerprotokollformat finden Sie in der offiziellen Dokumentation von Apache.
Beispiel einer Protokollausgabe
Fri Jul 17 02:19:48.093820 2020 [mpm_worker:notice] [pid 1:tid 140272153361288] [cm-p1234-e30226-aem-publish-b86c6b466-b9427] AH00292: Apache/2.4.43 (Unix) Communique/4.3.4-20200424 mod_qos/11.63 configured -- resuming normal operations
Fri Jul 17 02:19:48.093874 2020 [core:notice] [pid 1:tid 140272153361288] [cm-p1234-e30226-aem-publish-b86c6b466-b9427] AH00094: Command line: 'httpd -d /etc/httpd -f /etc/httpd/conf/httpd.conf -D FOREGROUND -D ENVIRONMENT_PROD'
Fri Jul 17 02:29:34.517189 2020 [mpm_worker:notice] [pid 1:tid 140293638175624] [cm-p1234-e30226-aem-publish-b496f64bf-5vckp] AH00295: caught SIGTERM, shutting down
Protokollformat
Datum und Uhrzeit | Freitag, 17. Juli 02:16:42.608913 2020 |
Ereignisebene | [mpm_worker:notice] |
Prozess-ID | [pid 1:tid 140715149343624] |
Pod-Name | [cm-p1234-e56789-aem-publish-b86c6b466-qpfvp] |
Nachricht | AH00094: Befehlszeile: 'httpd -d /etc/httpd -f /etc/httpd/conf/httpd.conf -D FOREGROUND -D |
Die Protokollierungsebenen „mod_rewrite“ werden durch die Variable „REWRITE_LOG_LEVEL“ in der Datei conf.d/variables/global.var
definiert.
Sie kann auf „Error“, „Warn“, „Info“, „Debug“ und „Trace1“ bis „Trace8“ eingestellt werden, wobei der Standardwert „Warn“ ist. Zum Debugging Ihrer „RewriteRules“ wird empfohlen, die Protokollebene auf „Trace2“ zu erhöhen.
Weitere Informationen finden Sie in der Dokumentation zum mod_rewrite-Modul.
Verwenden Sie zum Festlegen der Protokollstufe pro Umgebung den entsprechenden bedingten Zweig in der Datei „global.var“, wie unten beschrieben:
Define REWRITE_LOG_LEVEL debug
<IfDefine ENVIRONMENT_STAGE>
...
Define REWRITE_LOG_LEVEL warn
...
</IfDefine>
<IfDefine ENVIRONMENT_PROD>
...
Define REWRITE_LOG_LEVEL error
...
</IfDefine>
Beispiel
[17/Jul/2020:23:48:06 +0000] [I] [cm-p12904-e25628-aem-publish-6c5f7c9dbd-mzcvr] "GET /content/wknd/us/en/adventures.html" - 475ms [publishfarm/0] [action miss] "publish-p12904-e25628.adobeaemcloud.com"
[17/Jul/2020:23:48:07 +0000] [I] [cm-p12904-e25628-aem-publish-6c5f7c9dbd-mzcvr] "GET /content/wknd/us/en/adventures/climbing-new-zealand/_jcr_content/root/responsivegrid/carousel/item_1571266094599.coreimg.jpeg/1473680817282/sport-climbing.jpeg" 302 10ms [publishfarm/0] [action none] "publish-p12904-e25628.adobeaemcloud.com"
[17/Jul/2020:23:48:07 +0000] [I] [cm-p12904-e25628-aem-publish-6c5f7c9dbd-mzcvr] "GET /content/wknd/us/en/adventures/ski-touring-mont-blanc/_jcr_content/root/responsivegrid/carousel/item_1571168419252.coreimg.jpeg/1572047288089/adobestock-238230356.jpeg" 302 11ms [publishfarm/0] [action none] "publish-p12904-e25628.adobeaemcloud.com"
Protokollformat
Datum und Uhrzeit | [17. Juli 2020:23:48:16 +0000] |
Pod-Name | [cm-p12904-e25628-aem-publish-6c5f7c9dbd-mzcvr] |
Protokoll | GET |
URL | /content/experience-fragments/wknd/language-masters/en/contributors/sofia-sjoeberg/master/_jcr_content/root/responsivegrid/image.coreimg.100.500.jpeg/1572236359031/ayo-ogunseinde-237739.jpeg |
Status-Code der Dispatcher-Antwort | /content/experience-fragments/wknd/language-masters/en/contributors/sofia-sjoeberg/master/_jcr_content/root/responsivegrid/image.coreimg.100.500.jpeg/1572236359031/ayo-ogunseinde-237739.jpeg |
Dauer | 1949ms |
Farm | [publishfarm/0] |
Cache-Status | [action miss] |
Host | "publish-p12904-e25628.adobeaemcloud.com" |
Die Dispatcher-Protokollebenen werden durch die Variable „DISP_LOG_LEVEL“ in der Datei conf.d/variables/global.var
definiert.
Sie kann auf „Error“, „Warn“, „Info“, „Debug“ und „Trace1“ eingestellt werden, wobei der Standardwert „Warn“ ist.
Während die Dispatcher-Protokollierung mehrere andere Ebenen der Protokollierungsgranularität unterstützt, empfiehlt AEM as a Cloud Service die Verwendung der unten beschriebenen Ebenen.
Verwenden Sie zum Festlegen der Protokollstufe pro Umgebung den entsprechenden bedingten Zweig in der Datei global.var
, wie unten beschrieben:
Define DISP_LOG_LEVEL debug
<IfDefine ENVIRONMENT_STAGE>
...
Define DISP_LOG_LEVEL warn
...
</IfDefine>
<IfDefine ENVIRONMENT_PROD>
...
Define DISP_LOG_LEVEL error
...
</IfDefine>
Bei AEM as a Cloud Service-Umgebungen ist „debug“ die maximale Ausführlichkeitsstufe. Die Trace-Protokollebene wird nicht unterstützt. Daher sollten Sie beim Arbeiten in Cloud-Umgebungen vermeiden, sie festzulegen.
Diese Funktion wird Anfang September schrittweise für Kunden eingeführt.
AEM as a Cloud Service bietet Zugriff auf CDN-Protokolle, die für Anwendungsfälle nützlich sind, einschließlich der Optimierung der Cache-Trefferquote. Das CDN-Protokollformat kann nicht angepasst werden und es gibt kein Konzept, es auf verschiedene Modi wie Info, Warn oder Fehler festzulegen.
Beachten Sie, dass die Funktion Splunk-Weiterleitung CDN-Protokolle noch nicht unterstützt.
Beispiel
{
"timestamp": "2023-05-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"rid": "974e67f6",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"host": "example.com",
"url": "/content/hello.png",
"method": "GET",
"res_ctype": "image/png",
"cache": "PASS",
"status": 200,
"res_age": 0,
"pop": "PAR"
}
Protokollformat
Die CDN-Protokolle unterscheiden sich von den anderen Protokollen insofern, als sie einem JSON-Format entsprechen.
Feldname | Beschreibung |
---|---|
timestamp | Der Zeitpunkt, zu dem die Anfrage nach TLS-Beendigung gestartet wurde |
ttfb | Abkürzung für Zeit bis zum ersten Byte. Das Zeitintervall zwischen der Anfrage begann bis zu dem Punkt, an dem der Antworttext mit dem Streaming begann. |
cli_ip | Die Client-IP-Adresse. |
cli_country | Zweibuchstaben ISO 3166-1 Alpha-2-Ländercode für das Client-Land. |
rid | Der -Wert des Anforderungsheaders, der zur eindeutigen Identifizierung der Anfrage verwendet wird. |
req_ua | Der Benutzeragent, der für die Ausführung einer bestimmten HTTP-Anforderung verantwortlich ist. |
host | Die Behörde, für die der Antrag bestimmt ist. |
url | Der vollständige Pfad, einschließlich Abfrageparametern. |
method | Vom Client gesendete HTTP-Methode, z. B. "GET"oder "POST". |
res_ctype | Der Content-Type, der den ursprünglichen Medientyp der Ressource angibt. |
cache | Status des Caches. Mögliche Werte sind HIT, MISS oder PASS |
status | Der HTTP-Statuscode als ganzzahliger Wert. |
res_age | Die Zeit (in Sekunden), die eine Antwort zwischengespeichert wurde (in allen Knoten). |
pop | Rechenzentrum des CDN-Cache-Servers |
Auf die Protokolle in AEM as a Cloud Service für Cloud-Services kann entweder durch Herunterladen über die Cloud Manager-Oberfläche oder durch Nachverfolgung der Protokolle über die Befehlszeile mithilfe der Adobe I/O-Befehlszeilenschnittstelle zugegriffen werden. Weitere Informationen finden Sie in der Dokumentation zur Cloud Manager-Protokollierung.
Das AEM as a Cloud Service SDK stellt Protokolldateien zur Unterstützung der lokalen Entwicklung bereit.
AEM-Protokolle befinden sich im Ordner crx-quickstart/logs
, in dem die folgenden Protokolle eingesehen werden können:
error.log
request.log
access.log
Apache-Ebenenprotokolle, einschließlich Dispatcher, befinden sich im Docker-Container, in dem sich der Dispatcher befindet. Informationen zum Starten des Dispatchers finden Sie in der Dispatcher-Dokumentation.
Abrufen der Protokolle:
docker ps
ein, um Ihre Container aufzulisten.docker exec -it <container> /bin/sh
“ ein, um sich beim Container anzumelden, wobei <container>
die Dispatcher-Container-ID aus dem vorherigen Schritt ist./mnt/var/www/html
./etc/httpd/logs
httpd_access.log
httpd_error.log
dispatcher.log
Die Protokolle werden auch direkt an die Terminalausgabe gedruckt. Meistens sollten diese Protokolle DEBUG sein, was bei Ausführung von Docker durch Übergabe in der Debug-Ebene als Parameter erreicht werden kann. Beispiel:
DISP_LOG_LEVEL=Debug ./bin/docker_run.sh out docker.for.mac.localhost:4503 8080
In Ausnahmefällen müssen die Protokollebenen geändert werden, um in Staging- oder Produktionsumgebungen mit einer feineren Granularität zu protokollieren.
Dies ist zwar möglich, erfordert jedoch Änderungen der Protokollebenen in den Konfigurationsdateien in Git von „Warn“ und „Error“ auf „Debug“ sowie eine Bereitstellung von AEM as a Cloud Service, um diese Konfigurationsänderungen in den Umgebungen zu registrieren.
Je nach Traffic und der Menge der von Debug geschriebenen Protokolleinträge kann dies zu Leistungsbeeinträchtigungen in der Umgebung führen. Daher wird empfohlen, Änderungen an den Debug-Ebenen für Staging- und Produktionsumgebungen wie folgt vorzunehmen:
Kunden mit Splunk-Konten können über das Kunden-Support-Ticket anfordern, dass ihre AEM Cloud Service-Protokolle an den entsprechenden Index weitergeleitet werden. Die Protokolldaten entsprechen denen, die über die Cloud Manager-Protokolldownloads verfügbar sind. Kunden können es jedoch praktisch finden, die im Splunk-Produkt verfügbaren Abfragefunktionen zu verwenden.
Die Netzwerkbandbreite, die mit an Splunk gesendeten Protokollen verknüpft ist, wird als Teil der Netzwerk-E/A-Nutzung des Kunden betrachtet.
Beachten Sie, dass die Splunk-Weiterleitung CDN-Protokolle noch nicht unterstützt.
In der Support-Anfrage sollten Kunden Folgendes angeben:
Die obigen Eigenschaften sollten für jede relevante Kombination aus Programm und Umgebungstyp angegeben werden. Wenn ein Kunde beispielsweise Entwicklungs-, Staging- und Produktionsumgebungen wünscht, sollte er drei Informationssätze bereitstellen, wie unten angegeben.
Die Splunk-Weiterleitung für Sandbox-Programmumgebungen wird nicht unterstützt.
Die Splunk-Weiterleitungsfunktion ist über eine dedizierte Ausgangs-IP-Adresse nicht möglich.
Sie sollten sicherstellen, dass die anfängliche Anfrage zusätzlich zur Staging-/Produktionsumgebung alle Entwicklungsumgebungen enthält, die aktiviert werden sollen. Splunk muss über ein SSL-Zertifikat verfügen und öffentlich zugänglich sein.
Wenn neue Entwicklungsumgebungen, die nach der ersten Anfrage erstellt wurden, die Splunk-Weiterleitung verwenden sollen, diese aber nicht aktiviert haben, sollte eine zusätzliche Anfrage gestellt werden.
Beachten Sie außerdem, dass in anderen Entwicklungsumgebungen, die nicht in der Anfrage enthalten sind, oder sogar in Sandbox-Umgebungen die Splunk-Weiterleitung aktiviert ist und einen Splunk-Index gemeinsam nutzt, wenn Entwicklungsumgebungen angefordert wurden. Kunden können anhand des Felds aem_env_id
zwischen diesen Umgebung unterscheiden.
Unten finden Sie ein Beispiel für eine Support-Anfrage:
Programm 123, Produktionsumgebung
splunk-hec-ext.acme.com
Programm 123, Staging-Umgebung
splunk-hec-ext.acme.com
Programm 123, Entwicklungsumgebung
splunk-hec-ext.acme.com
Es kann ausreichen, für jede Umgebung denselben Splunk-Index zu verwenden. In diesem Fall kann das aem_env_type
-Feld zur Differenzierung auf der Grundlage der Werte „dev“, „stage“ und „prod“ verwendet werden. Wenn mehrere Entwicklungsumgebungen vorhanden sind, kann auch das aem_env_id
-Feld verwendet werden. Einige Organisationen wählen möglicherweise einen separaten Index für die Protokolle der Produktionsumgebung, wenn der zugehörige Index den Zugriff auf eine reduzierte Gruppe von Splunk-Benutzern beschränkt.
Im Folgenden finden Sie einen Beispielprotokolleintrag:
aem_env_id: 1242
aem_env_type: dev
aem_program_id: 12314
aem_tier: author
file_path: /var/log/aem/error.log
host: 172.34.200.12
level: INFO
msg: [FelixLogListener] com.adobe.granite.repository Service [5091, [org.apache.jackrabbit.oak.api.jmx.SessionMBean]] ServiceEvent REGISTERED
orig_time: 16.07.2020 08:35:32.346
pod_name: aemloggingall-aem-author-77797d55d4-74zvt
splunk_customer: true