Vanliga AEM
Dokumentet beskriver vanliga loggposter och deras betydelse samt hur de ska behandlas.
Beskrivning description
Miljö
Adobe Experience Manager
Problem/symtom
Vad är vanliga loggposter, vad de betyder och hur du hanterar dem.
Mer information finns i handboken för Adobe Managed Services Dispatcher i handboken för AEM Tutorials.
Upplösning resolution
GLOB-varning
Exempelloggpost:
[ 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.
Sedan dispatchermodell 4.2.x började de avskräcka personer från att använda följande typ av matchningar i sina filterfiler:
/0041 { /type "allow" /glob "* *.css *" } ## enable css
I stället är det bättre att använda den nya syntaxen som:
/0041 { /type "allow" /url "*.css" } ## enable css
Eller ännu bättre för att inte matcha mot en jokerteckensmatchare:
/0041 { /type "allow" /extension "css" } ## enable css
Om du gör någon av de föreslagna metoderna tas felmeddelandet bort från loggarna.
Filter avvisar
Obs!
De här posterna visas inte alltid, även om det uppstår avslag om loggnivån är för låg. Ställ in den på Info eller debug för att kontrollera om filtren avvisar förfrågningarna.
Exempel på loggpost:
[ Fri Jul 20 17:25:48 2018] [ D] [ pid 25939 (tid 139937517123328)] Filter rejects: GET /libs/granite/core/content/login.html HTTP/1.1
eller:
[ Fri Jul 20 22:16:55 2018] [ I] [ pid 128803] "GET /system/console/" ! - 8ms [ publishfarm/-]
Varning:
Förstå att dispatcherns regler har ställts in för att filtrera bort den begäran. I det här fallet avvisades sidan med avsikt, och vi skulle inte vilja göra något med det.
Om loggen ser ut så här:
[ 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
Vi får veta att vår designfil .eot blockeras och vi vill åtgärda det.
Så vi bör titta på vår filterfil och lägga till följande rad för att tillåta .eot-filer genom
/0011 { /type "allow" /method "GET" /extension 'eot' /path "/etc/designs/*" }
Detta gör att filen kan loggas igenom och förhindrar att den loggas.
Om du vill se vad som filtreras ut kan du köra det här kommandot i loggfilen:
$ grep "Filter rejects\|\!" /var/log/httpd/dispatcher.log | awk 'match($0, /\/.*\//, m){ print m[ 0] }' | awk '{ print $1 }'| sort | uniq -c | sort -rn
Timeout från rendering
Loggpost för Socket-timeout-exempel:
[ 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
Detta inträffar när du har konfigurerat fel IP-adress i återgivningsavsnittet i servergruppen. Den eller den AEM instansen slutade svara eller lyssna, och dispatchern kunde inte nå den.
Kontrollera brandväggsreglerna och att AEM körs och är felfri.
Exempelloggposter 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/-]
Det innebär att AEM hade en öppen socket som den kunde nå och nådde en tidsgräns med svaret. Det innebär att AEM var för långsam eller ohälsosam och att dispatchern nådde sina konfigurerade timeoutinställningar i renderingssektionen i servergruppen. Öka timeoutinställningen eller få AEM felfri.
Cachenivå
Exempel på loggpost:
[ Fri Jul 20 23:00:19 2018] [ I] [ pid 16004 (tid 140134145820416)] Current cache hit ratio: 87.94 %
Det innebär att hämtningen från renderingsnivån kontra från cacheminnet mäts. Du vill uppnå 80+ procent från cacheminnet och du bör följa hjälpen här:
För att få så många siffror som möjligt.
Obs!
Även om du har cacheinställningarna i servergruppsfilen för att cachelagra allt, kanske du tömmer för ofta eller för aggressivt, vilket kan göra att en lägre procentandel av cacheträffen inträffar
Katalog saknas
Exempel på loggpost:
[ 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
Detta visas vanligtvis när ett objekt hämtas samtidigt som en cacherensning sker.
Det eller dokumentets rotkatalog har felaktiga behörigheter eller fel SELinux-filkontext i mappen som nekar apache att skapa de nya underkatalogerna som behövs.
Om du har problem med behörighet tittar du på behörigheterna för dokumentroten och ser till att de ser ut ungefär så här:
dispatcher$ ls -la
Vanity URL not found
Exempel på loggpost:
[ 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
Det här felet inträffar när du har konfigurerat din dispatcher till att använda det dynamiska autofiltret för att tillåta URL:er för innehåll, men inte har slutfört installationen genom att installera paketet på AEM renderare.
Du åtgärdar detta genom att installera funktionspaketet för fågel-URL på AEM och tillåta att det är klart av den anonyma användaren. Information här
En fungerande URL-konfiguration ser ut så här:
[ 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
Grupp saknas
Exempel på loggpost:
[ Wed Nov 13 17:17:26 2019] [ W] [ pid 19173:tid 140542738364160] No farm matches host 'we-retail.com', selected last farm 'publishfarm'
Detta fel indikerar att det inte gick att hitta en matchande post från /virtualhost-avsnittet från alla servergruppsfiler som är tillgängliga i /etc/httpd/conf.dispatcher.d/enabled_farm/.
Servergruppsfilerna matchar trafik baserat på det domännamn eller den sökväg som förfrågan kom in med. Den använder matchning av glob, och om den inte matchar, har du antingen inte konfigurerat din servergrupp korrekt, skrivit in posten i servergruppen eller skrivit in posten helt. När servergruppen inte matchar några poster används som standard den senaste servergruppen som ingår i gruppen med servergruppsfiler. I det här exemplet var det 999_ams_publish_farm.any, som heter det generiska namnet för publiceringsgruppen.
Här är ett exempel på servergruppsfilen /etc/httpd/conf.dispatcher.d/enabled_farms/300_weretail_publish_farm.any som har reducerats för att markera relevanta delar.
Objektet har betjänats från
Exempel på loggpost:
[ Tue Nov 26 16:41:34 2019] [ I] [ pid 9208 (tid 140112092391168)] "GET /content/we-retail/us/en.html" - + 24034ms [ publishfarm/0]
Sidan hämtades via GETENS http-metod för innehållet /content/we-retail/us/en.html, vilket tog 24034 millisekunder. Den del som vi vill uppmärksamma finns i slutet av [ publishfarm/0] . Du kommer att se att det riktade in sig på och matchade publiceringsgruppen. Begäran hämtades från rendering 0, vilket innebär att sidan måste begäras från AEM och sedan cachelagras. Nu ska vi begära den här sidan igen och se vad som händer med loggen