AEM as a Cloud Service: Hur isolerar man 503 fel?

Om alla sidor returnerar en 503-felsökning för en pågående incident. Om en sida returnerar ett 503-fel kontrollerar du molnloggarna.

Beskrivning description

Miljö

Adobe Experience Manager as a Cloud Service

Problem/symtom

I den här artikeln beskrivs hur du isolerar var problemet finns när du stöter på 503 fel i AEM as a Cloud Service.

Upplösning resolution

Leveransflödet i AEM as a Cloud Service är följande:

Browser" CDN" Dispatcher" Publish

Om det skulle uppstå en incident som spänner över hela tjänsten returnerar alla sidor felet 503. Om det är något problem mellan CDN - Dispatcher eller Dispatcher - Publish för begäranden med ett visst villkor returnerar bara vissa sidor felet 503.

Fall A - Alla sidor returnerar felet

När alla sidor returnerar felet kan det finnas en incident som spänner över hela tjänsten. Kontrollera om det finns en pågående incident eller ett planerat underhåll på Adobe System Status" Experience Cloud" Adobe Experience Manager as a Cloud Service.

Adobe systemstatus
https://status.adobe.com/

Fall B - Endast vissa sidor returnerar felet

När felet bara inträffar på vissa sidor kan det bero på ett inbyggt problem som förhindrar normalt svar vid någon tidpunkt i innehållsleveransflödet. I det här fallet kan du försöka komma åt sidan och se felet 503 en gång till. Isolera sedan problemet med loggarna som laddats ned från Cloud Manager.

Dispatcher httpdaccess och Publish aemrequest är särskilt viktiga. Om du kontrollerar om varje logg innehåller motsvarande åtkomstpost blir det lättare att isolera var problemet finns.

Här är ett loggexempel för jämförelse, där både Dispatcher och Publish returnerade normala svar för åtkomst till /us/en.html.

Dispatcher httpdaccess:logged svarar

cm-p12345-e67890-aem-publish-55cf6bcc5-vxfcf - - 18/Oct/2022:10:20:11 +0000 "GET /us/en.html HTTP/1.1" 200 16263 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36"

Publish aemrequest: loggad på att ta emot och svara

18/Oct/2022:10:20:11 +0000 [1063] -> GET /content/wknd/us/en.html HTTP/1.1 cm-p12345-e67890-aem-publish-55cf6bcc5-vxfcf
18/Oct/2022:10:20:14 +0000 &#91;1063&#93; <- 200 text/html 3355ms cm-p12345-e67890-aem-publish-55cf6bcc5-vxfcf

Mer information om loggningsinformation finns i handboken.
https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/developing/logging.html?lang=sv-SE

Följande fyra fall kan isoleras från en kombination av närvaro/frånvaro av åtkomstposter.

Fall B-1 - Både Dispatcher och Publish har åtkomstposten

CDN kan ha överskridit tidsgränsen på grund av en lång svarstid på Publish. Kontrollera om det finns en svarspost i Publish aemrequest och hur länge svarstiden var. Om svarstiden var längre, till exempel över flera minuter, kan du leta efter relaterade meddelanden i Publish aemerror.

Fall B-2 - Dispatcher har åtkomstposten, men det gör inte Publish

Antingen svarade Dispatcher ensam eller så kom förfrågan till Publish, men något fel kan inträffa innan posten loggas. Kontrollera om det finns relaterade meddelanden i Dispatcher httpderror, aemdispatcher och Publish aemerror.

Fall B-3 - Dispatcher har inte åtkomstposten, men det gör Publish

Publish har accepterat begäran men har ännu inte svarat. Kontrollera om det finns en svarspost i Publish aemrequest. Om det inte finns någon svarspost söker du efter relaterade meddelanden i Publish aemerror.

Fall B-4 - Varken Dispatcher eller Publish har åtkomstposten

Dispatcher kunde inte godkänna förfrågningarna på grund av ett problem. Kontrollera om det finns relaterade meddelanden i Dispatcher httpderror och Dispatcher aemdispatcher.

Dessutom är följande användbara när vissa sidor returnerar felet.