In diesem Dokument werden häufige Protokolleinträge beschrieben, was sie bedeuten und wie sie zu beheben sind.
🔙Frühere Dispatcher-Vanity-URLs
GLOB-Warnung
Beispiel für einen Protokolleintrag:
[Fri Jul 20 03:35:09 2018] [W] [pid 8300 (tid 139937910880384)] /etc/httpd/conf/publish-filters.any:5: Allowing requests with globs is considered unsafe. Please consult the documentation at 'https://www.adobe.com/go/docs_dispatcher_config_en' on how to use attributes method/url/query/protocol/path/selectors/extension/suffix instead.
Seit dem Dispatcher-Modul 4.2.x wird davon abgeraten, die folgenden Übereinstimmungstypen in ihrer Filterdatei zu verwenden:
/0041 { /type "allow" /glob "* *.css *" } ## enable css
Stattdessen sollte die neue Syntax wie die folgende verwendet werden:
/0041 { /type "allow" /url "*.css" } ## enable css
Noch besser ist es, zur Übereinstimmung gar keinen Platzhalter zu verwenden:
/0041 { /type "allow" /extension "css" } ## enable css
Wenn Sie eine der vorgeschlagenen Methoden nutzen, erscheint diese Fehlermeldung nicht mehr in den Protokollen.
Ablehnungen durch Filter
Diese Einträge werden nicht immer angezeigt, selbst wenn Ablehnungen auftreten, weil die Protokollebene zu niedrig eingestellt ist. Wählen Sie für die Protokollebene „Info“ oder „debug“, damit Sie sehen können, wenn die Filter die Anfragen ablehnen.
Beispiel für einen Protokolleintrag:
[Fri Jul 20 17:25:48 2018] [D] [pid 25939 (tid 139937517123328)] Filter rejects: GET /libs/granite/core/content/login.html HTTP/1.1
oder:
[Fri Jul 20 22:16:55 2018] [I] [pid 128803] "GET /system/console/" ! - 8ms [publishfarm/-]
Beachten Sie, dass die Dispatcher-Regeln so eingestellt sind, dass diese Anfrage herausgefiltert wird. In diesem Fall wurde die Seite, die aufgerufen werden sollte, absichtlich abgelehnt, und wir möchten dies nicht ändern.
Wenn Ihr Protokoll wie folgt aussieht:
[Fri Jul 20 17:26:47 2018] [D] [pid 20051 (tid 139937517123328)] Filter rejects: GET /etc/designs/exampleco/fonts/montserrat-regular/montserrat-regular-webfont.eot HTTP/1.1
Dadurch wissen wir, dass unsere Designdatei .eot blockiert wird und das möchten wir beheben.
Daher sollten wir in unserer Filterdatei folgende Zeile hinzufügen, um .eot-Dateien passieren zu lassen.
/0011 { /type "allow" /method "GET" /extension 'eot' /path "/etc/designs/*" }
Dadurch kann die Datei passieren und die Protokollierung wird verhindert.
Wenn Sie sehen möchten, was herausgefiltert wird, können Sie diesen Befehl in Ihrer Protokolldatei ausführen:
$ grep "Filter rejects\|\!" /var/log/httpd/dispatcher.log | awk 'match($0, /\/.*\//, m){ print m[0] }' | awk '{ print $1 }'| sort | uniq -c | sort -rn
Timeouts wegen Rendering
Beispiel für einen Protokolleintrag wegen Socket-Timeout:
[Fri Jul 20 22:31:15 2018] [W] [pid 3648] Unable to connect socket to 10.43.3.40:4502: Connection timed out [Fri Jul 20 22:31:15 2018] [W] [pid 3648] Unable to connect to any backend in farm authorfarm
Dies tritt auf, wenn Sie die falsche IP-Adresse im Render-Bereich Ihrer Farm konfiguriert haben. Ein anderer Grund ist, dass die AEM-Instanz nicht mehr reagiert oder hört und der Dispatcher nicht mehr darauf zugreifen kann.
Überprüfen Sie Ihre Firewall-Regeln und ob die AEM-Instanz ausgeführt wird und ordnungsgemäß funktioniert.
Beispiel für die Protokolleinträge für Gateway-Timeout:
[Fri Jul 20 22:32:42 2018] [I] [pid 3648] "GET /favicon.ico" 502 - 54034ms [authorfarm/-] [Fri Jul 20 22:35:45 2018] [I] [pid 3648] "GET /favicon.ico" 503 - 54234ms [authorfarm/-]
Das bedeutet, dass die AEM-Instanz einen offenen Socket hatte, den sie erreichen konnte, und bei der Antwort eine Zeitüberschreitung auftrat. Das heißt wiederum, dass Ihre AEM-Instanz zu langsam war oder nicht ordnungsgemäß funktionierte und der Dispatcher das im Render-Abschnitt der Farm konfigurierte Timeout erreichte. Erhöhen Sie entweder die Timeout-Einstellung oder beheben Sie Fehler in Ihrer AEM-Instanz.
Caching-Ebene
Beispiel für einen Protokolleintrag:
[Fri Jul 20 23:00:19 2018] [I] [pid 16004 (tid 140134145820416)] Current cache hit ratio: 87.94 %
Dies bedeutet, dass Ihr Abruf von der Render-Ebene im Vergleich zum Cache gemessen wird. Wenn Sie mehr als 80 Prozent aus dem Cache erreichen möchten, folgen Sie der Hilfe hier:
https://helpx.adobe.com/de/experience-manager/kb/optimizing-the-dispatcher-cache.html
Dadurch können Sie sicherstellen, dass diese Zahl möglichst hoch ist.
Auch wenn Sie Ihre Cache-Einstellungen in der Farm-Datei so festgelegt haben, dass alles zwischengespeichert wird, könnte es sein, dass der Speicher zu oft oder zu aggressiv geleert wird, sodass die Trefferrate des Cache einen niedrigeren Prozentsatz aufweist.
Fehlendes Verzeichnis
Beispiel für einen Protokolleintrag:
[Fri Jul 20 14:02:43 2018] [E] [pid 4728 (tid 140662586435328)] Unable to create parent directory /mnt/var/www/author/libs/dam/content/asseteditors/formitems.overlay.infinity.json/application: Not a directory
Dies wird normalerweise angezeigt, wenn ein Element abgerufen wird, während gleichzeitig ein Cache-Löschvorgang stattfindet.
Es könnte auch sein, dass das Dokumentenstammverzeichnis keine Berechtigungen dafür oder den falschen SELinux-Dateikontext im Ordner hat, der Apache daran hindert, die neuen erforderlichen Unterverzeichnisse zu erstellen.
Prüfen Sie bei Berechtigungsproblemen die Berechtigungen des documentroot-Verzeichnisses und stellen Sie sicher, dass diese in etwa so aussehen:
dispatcher$ ls -la
Vanity-URL nicht gefunden
Beispiel für einen Protokolleintrag:
[Thu Sep 27 17:35:11 2018] [D] [pid 18936] Checking vanity URLs [Thu Sep 27 17:35:11 2018] [D] [pid 18936] Vanity URL file (/tmp/vanity_urls) not found, fetching... [Thu Sep 27 17:35:11 2018] [W] [pid 18936] Unable to fetch vanity URLs from 10.43.0.42:4503/libs/granite/dispatcher/content/vanityUrls.html: remote server returned: HTTP/1.1 404 Not Found
Dieser Fehler tritt auf, wenn Sie Ihren Dispatcher so konfiguriert haben, dass der dynamische automatische Filter Vanity-URLs zulässt, die Einrichtung jedoch nicht abgeschlossen wurde, indem das Package auf dem AEM-Renderer installiert wurde.
Um dies zu beheben, installieren Sie das Feature Pack „vanityurl“ auf der AEM-Instanz und lassen Sie es von einem anonymen Benutzer bereitstellen. Weitere Details finden Sie hier
Eine funktionierende Vanity-URL sieht in etwa wie folgt aus:
[Thu Sep 27 17:40:29 2018] [D] [pid 21844] Checking vanity URLs [Thu Sep 27 17:40:29 2018] [D] [pid 21844] Vanity URL file (/tmp/vanity_urls) not found, fetching... [Thu Sep 27 17:40:29 2018] [D] [pid 21844] Loaded 18 vanity URLs from file /tmp/vanity_urls
Fehlende Farm-Datei
Beispiel für einen Protokolleintrag:
[Wed Nov 13 17:17:26 2019] [W] [pid 19173:tid 140542738364160] No farm matches host 'we-retail.com', selected last farm 'publishfarm'
Dieser Fehler weist darauf hin, dass aus allen in /etc/httpd/conf.dispatcher.d/enabled_farm/ verfügbaren Farm-Dateien kein entsprechender Eintrag im Abschnitt /virtualhost gefunden werden konnte.
Die Farm-Dateien entsprechen dem Traffic auf Basis des Domänennamens oder des Pfads, in dem die Anfrage einging. Dabei wird globales Matching verwendet. Wenn keine Übereinstimmung gefunden wird, haben Sie entweder Ihre Farm nicht richtig konfiguriert, einen falschen Eintrag in die Farm eingegeben oder einen fehlenden Eintrag. Wenn die Farm keinen Einträgen entspricht, wird standardmäßig die letzte Farm im Stack der Farm-Dateien herangezogen. In diesem Beispiel war das 999_ams_publish_farm.any, die den generischen Namen von publishfarm hat.
Dies ist ein Beispiel für eine Farm-Datei /etc/httpd/conf.dispatcher.d/enabled_farms/300_weretail_publish_farm.any. Sie wurde reduziert, um die relevanten Teile hervorzuheben.
Element bereitgestellt von
Beispiel für einen Protokolleintrag:
[Tue Nov 26 16:41:34 2019] [I] [pid 9208 (tid 140112092391168)] "GET /content/we-retail/us/en.html" - + 24034ms [publishfarm/0]
Die Seite wurde über die GET-HTTP-Methode für den Inhalt /content/we-retail/us/en.html in 24034 Millisekunden abgerufen. Der Teil am Ende soll dabei hervorgehoben werden: [publishfarm/0]. Daraus ist ersichtlich, dass dieser Teil auf publishfarm ausgerichtet war und damit übereinstimmte. Die Anfrage wurde vom Render 0 abgerufen. Das bedeutet, dass diese Seite aus AEM angefordert und dann zwischengespeichert werden musste. Nun fordern wir diese Seite erneut an und sehen uns an, was mit dem Protokoll passiert.
Beispiel für einen Protokolleintrag:
[Tue Nov 26 16:42:16 2019] [I] [pid 9207 (tid 140112321234688)] "GET /content/we-retail/us/en.html" - - 1ms [publishfarm/-]
Das Element wurde erneut angefordert und, wie Sie sehen können, war es auf dieselbe publishfarm ausgerichtet wie die vorherige Anfrage. Diesmal lautet der Eintrag [publishfarm/-]. Der Bindestrich am Ende weist darauf hin, dass er aus dem Cache bereitgestellt wurde und nicht vom AEM-Renderer abgerufen werden musste.
Als Nächstes ➡ Schreibgeschützte Dateien
Bei Ihrem Konto anmelden