Problembehandlung bei fehlgeschlagenem Canary

Wenn Ihr Canary fehlschlägt, gehen Sie wie folgt vor:

Allgemeine Problembehebung

Canary schlägt nach dem Update der Lambda-Umgebung fehl

CloudWatch-Synthetics-Canarys sind als Lambda-Funktionen in Ihrem Konto implementiert. Diese Lambda-Funktionen unterliegen regelmäßigen Lambda-Laufzeit-Updates, die Sicherheitsupdates, Fehlerbehebungen und andere Verbesserungen enthalten. Lambda ist bestrebt, Laufzeitaktualisierungen bereitzustellen, die mit vorhandenen Funktionen abwärtskompatibel sind. Wie beim Software-Patching gibt es jedoch seltene Fälle, in denen sich eine Laufzeitaktualisierung negativ auf eine vorhandene Funktion auswirken kann. Wenn Sie denken, dass Ihr Canary von einem Lambda-Laufzeit-Update betroffen ist, können Sie den manuellen Modus für Lambda-Laufzeitmanagement (in unterstützten Regionen) verwenden, um die Lambda-Laufzeitversion vorübergehend zurückzusetzen. Dadurch bleibt Ihre Canary-Funktion funktionsfähig und die Unterbrechung wird minimiert. Gleichzeitig wird Zeit bereitgestellt, um die Inkompatibilität zu beheben, bevor Sie zur neuesten Laufzeitversion zurückkehren.

Wenn Ihr Canary nach einem Lambda-Laufzeit-Update ausfällt, ist die beste Lösung ein Upgrade auf eine der neuesten Synthetics-Laufzeiten. Weitere Informationen zu den neuesten Laufzeiten finden Sie unter Synthetics Laufzeitversionen.

Als alternative Lösung können Sie in Regionen, in denen Lambda-Laufzeitverwaltungskontrollen verfügbar sind, einen Canary auf eine ältere von Lambda verwaltete Laufzeit zurücksetzen, indem Sie den manuellen Modus für die Laufzeitverwaltungskontrollen verwenden. Sie können den manuellen Modus entweder mithilfe der AWS CLI oder mithilfe der Lambda-Konsole einrichten, indem Sie die unteren Schritte in den folgenden Abschnitten ausführen.

Voraussetzungen

Schritt 1: Die Lambda-Funktion ARN abrufen

Führen Sie den folgenden Befehl aus, um das EngineArn-Feld aus der Antwort abzurufen. Dieser EngineArn ist der ARN der Lambda-Funktion, die dem Canary zugeordnet ist. Sie verwenden diesen ARN in den folgenden Schritten.

aws synthetics get-canary --name my-canary | jq '.Canary.EngineArn'

Beispielausgabe für EngingArn:

"arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8"

Schritt 2: Die letzte gute Lambda-Laufzeitversion ARN abrufen

Um zu verstehen, ob Ihr Canary von einem Lambda-Laufzeit-Update betroffen war, überprüfen Sie, ob Datum und Uhrzeit der ARN-Änderungen der Lambda-Laufzeit-Version in Ihren Protokollen dem Datum und der Uhrzeit entsprechen, zu der Sie Auswirkungen auf Ihren Canary festgestellt haben. Wenn sie nicht übereinstimmen, verursacht Ihr Problem wahrscheinlich kein Lambda-Laufzeit-Update.

Wenn Ihr Canary von einem Lambda-Laufzeit-Update betroffen ist, müssen Sie den ARN der funktionierenden Lambda-Laufzeit-Version identifizieren, die Sie zuvor verwendet haben. Folgen Sie den Anweisungen unter Identifizieren von Laufzeitversionsänderungen, um den ARN der vorherigen Laufzeit zu ermitteln. Notieren Sie den ARN der Laufzeitversion und fahren Sie mit Schritt 3 fort, um die Laufzeitverwaltungskonfiguration festzulegen.

Wenn Ihr Canary noch nicht von einem Lambda-Umgebungsupdate betroffen ist, können Sie den ARN der Lambda-Laufzeitversion finden, die Sie derzeit verwenden. Führen Sie den folgenden Befehl aus, um die RuntimeVersionArn der Lambda-Funktion aus der Antwort abzurufen.

aws lambda get-function-configuration \
--function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8" | jq '.RuntimeVersionConfig.RuntimeVersionArn'

Beispielausgabe für RuntimeVersionArn:

"arn:aws:lambda:us-west-2::runtime:EXAMPLE647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Schritt 3: Aktualisierung der Lambda-Laufzeitverwaltungskonfiguration

Sie können entweder die AWS CLI oder die Lambda-Konsole verwenden, um die Laufzeitverwaltungskonfiguration zu aktualisieren.

So stellen Sie den manuellen Modus für die Konfiguration der Lambda-Laufzeitverwaltung mit dem AWS CLI ein

Geben Sie den folgenden Befehl ein, um die Laufzeitverwaltung der Lambda-Funktion in den manuellen Modus zu ändern. Achten Sie darauf, den Funktionsnamen und den Qualifier durch den ARN der Lambda-Funktion bzw. die Versionsnummer der Lambda-Funktion zu ersetzen, indem Sie die in Schritt 1 ermittelten Werte verwenden. Ersetzen Sie auch die Runtime-Version-ARN durch den Versions-ARN, den Sie in Schritt 2 ermittelt haben.

aws lambda put-runtime-management-config \
    --function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991" \
    --qualifier 8 \
    --update-runtime-on "Manual" \
    --runtime-version-arn "arn:aws:lambda:us-west-2::runtime:a993d90ea43647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Mein Canary wird blockiert von AWS WAF

Um Canary-Verkehr durch AWS WAF zuzulassen, erstellen Sie eine Bedingung für den Abgleich von AWS WAF-Zeichenfolgen, die eine von Ihnen angegebene benutzerdefinierte Zeichenfolge zulässt. Weitere Informationen finden Sie in der AWS WAF-Dokumentation unter Arbeiten mit Bedingungen für den Abgleich von Zeichenfolgen.

Es wird dringend empfohlen, anstelle von Standardwerten Ihre eigene benutzerdefinierte Benutzeragent-Zeichenfolge zu verwenden. Das bietet eine bessere Kontrolle über das AWS WAF-Filtern und erhöht die Sicherheit.

Gehen Sie wie folgt vor, um eine benutzerdefinierte Benutzeragent-Zeichenfolge festzulegen:

Warten auf das Erscheinen eines Elements

Wenn Sie nach der Analyse Ihrer Protokolle und Screenshots sehen, dass Ihr Skript darauf wartet, dass ein Element auf dem Bildschirm angezeigt wird und eine Zeitüberschreitung auftritt, überprüfen Sie den entsprechenden Screenshot, um zu sehen, ob das Element auf der Seite angezeigt wird. Überprüfen Sie Ihren xpath, um sicherzustellen, dass er richtig ist.

Informationen zu Puppetteer-bezogenen Problemen finden Sie auf der GitHub-Seite von Puppeteer oder in den Internetforen.

Knoten ist entweder nicht sichtbar oder kein HTMLElement für page.click()

Wenn ein Knoten nicht sichtbar ist oder kein HTMLElement für page.click() ist, überprüfen Sie zuerst den xpath, den Sie zum Klicken auf das Element verwenden. Wenn sich Ihr Element unten auf dem Bildschirm befindet, passen Sie das Ansichtsfenster an. CloudWatch Synthetics verwendet standardmäßig ein Ansichtsfenster von 1920 x 1080. Sie können beim Starten des Browsers oder mithilfe der Puppeteer-Funktion page.setViewport ein anderes Ansichtsfenster festlegen.

Artifacts können nicht in S3 hochgeladen werden, Ausnahme: S3-Bucket-Speicherort kann nicht abgerufen werden: Zugriff verweigert

Sollte Ihr Canary aufgrund eines Amazon-S3-Fehlers ausfallen, bedeutet dies, dass CloudWatch Synthetics aufgrund von Berechtigungsproblemen keine Screenshots, Protokolle oder Berichte hochladen konnte, die für den Canary erstellt wurden. Überprüfen Sie, ob Folgendes der Fall ist:

Führt der Canary eine visuelle Überwachung durch, finden Sie unter Aktualisieren des Artefaktspeicherortes und der Verschlüsselung bei Verwendung der visuellen Überwachung weitere Informationen dazu.

Fehler: Protokollfehler (Runtime.CallFunctionOn): Ziel geschlossen.

Dieser Fehler wird angezeigt, wenn nach dem Schließen der Seite oder des Browsers einige Netzwerkanforderungen vorhanden sind. Möglicherweise haben Sie vergessen, auf einen asynchronen Vorgang zu warten. Nachdem Sie Ihr Skript ausgeführt haben, schließt CloudWatch Synthetics den Browser. Die Ausführung eines asynchronen Vorgangs nach dem Schließen des Browsers kann dazu führen, dass target closed error.

Canary ist fehlgeschlagen. Fehler: Kein Datenpunkt – Canary zeigt Timeout-Fehler

Dies bedeutet, dass Ihr Canarylauf das Timeout überschritten hat. Die Ausführung von Canary wurde gestoppt, bevor CloudWatch Synthetics erfolgreich prozentuale CloudWatch-Metriken veröffentlichen oder Artefakte wie HAR-Dateien, Protokolle und Screenshots aktualisieren konnte. Wenn Ihr Timeout zu niedrig ist, können Sie es erhöhen.

Standardmäßig ist ein Canary-Timeout-Wert gleich seiner Häufigkeit. Sie können den Timeout-Wert manuell so einstellen, dass er kleiner oder gleich der Canary-Frequenz ist. Wenn Ihre Canaryfrequenz niedrig ist, müssen Sie die Frequenz erhöhen, um das Timeout zu erhöhen. Sie können sowohl die Häufigkeit als auch den Timeoutschreitungswert unter Zeitplan anpassen, wenn Sie einen Canary mithilfe der CloudWatch-Synthetics-Konsole erstellen oder aktualisieren.

Stellen Sie sicher, dass Ihr canary-Timeout-Wert nicht kürzer als 15 Sekunden ist, um Lambda-Kaltstarts und die Zeit zu ermöglichen, die zum Hochfahren der canary-Instrumentierung benötigt wird.

Canary-Artefakte können nicht in der CloudWatch-Synthetics-Konsole angezeigt werden, wenn dieser Fehler auftritt. Sie können CloudWatch Logs verwenden, um die Protokolle des Canary anzuzeigen.

Versuch, auf einen internen Endpunkt zuzugreifen

Wenn Sie möchten, dass Ihr Canary auf einen Endpunkt in Ihrem internen Netzwerk zugreifen kann, empfehlen wir, CloudWatch Synthetics für die Verwendung von VPC einzurichten. Weitere Informationen finden Sie unter Ausführen eines Canarys in einer VPC.

Probleme beim Upgrade und Downgrade der Canary-Laufzeitversion

Wenn Sie den Canary kürzlich von der Laufzeitversion syn-1.0 auf eine neuere Version aktualisiert haben, liegt möglicherweise ein Problem mit der ursprungsübergreifenden Anforderungsfreigabe (CORS) vor. Weitere Informationen finden Sie unter Problem mit Cross-Origin Request Sharing (CORS).

Wenn Sie den Canary kürzlich auf eine ältere Laufzeitversion herabgestuft haben, stellen Sie sicher, dass die von Ihnen verwendeten CloudWatch-Synthetics-Funktionen in der älteren Laufzeitversion verfügbar sind, auf die Sie herabgestuft haben. Die Funktion executeHttpStep ist beispielsweise ab der Laufzeitversion syn-nodejs-2.2 verfügbar. Informationen zur Verfügbarkeit von Funktionen finden Sie unter Ein Canary-Skript schreiben.

Problem mit Cross-Origin Request Sharing (CORS)

Wenn in einem UI-Canary einige Netzwerkanforderungen mit 403 oder net::ERR_FAILED fehlschlagen, prüfen Sie, ob für den Canary die aktive Ablaufverfolgung aktiviert ist, und verwendet auch die Puppeteer-Funktion page.setExtraHTTPHeaders, um Header hinzuzufügen. Wenn dies der Fall ist, können die fehlgeschlagenen Netzwerkanforderungen durch Cross-Origin Request Sharing (CORS) Einschränkungen verursacht werden. Sie können bestätigen, ob dies der Fall ist, indem Sie die aktive Ablaufverfolgung deaktivieren oder die zusätzlichen HTTP-Header entfernen.

Warum passiert das?

Wenn aktive Ablaufverfolgung verwendet wird, wird allen ausgehenden Anforderungen ein zusätzlicher Header hinzugefügt, um den Aufruf zu verfolgen. Das Ändern der Anforderungsheader durch Hinzufügen eines Ablaufverfolgungs-Headers oder das Hinzufügen zusätzlicher Header mithilfe von Puppeteer page.setExtraHTTPHeaders führt zu einer CORS-Prüfung für XMLHttpRequest (XHR)-Anfragen.

Wenn Sie das aktive Tracing nicht deaktivieren oder die zusätzlichen Header entfernen möchten, können Sie Ihre Webanwendung aktualisieren, um den ursprungsübergreifenden Zugriff zu ermöglichen, oder Sie können die Websicherheit deaktivieren, indem Sie das Flag disable-web-security beim Starten des Chrome-Browsers in Ihrem Skript verwenden.

Sie können von CloudWatch Synthetics verwendete Startparameter überschreiben und zusätzliche disable-web-security-Flag-Parameter übergeben, indem Sie die Startfunktion von CloudWatch Synthetics verwenden. Weitere Informationen finden Sie unter Für Node.js-Canary-Skripte verfügbare Bibliotheksfunktionen, die Puppeteer verwenden.

Probleme mit der Race-Bedingung des Canary

Um die beste Erfahrung mit CloudWatch Synthetics zu erzielen, stellen Sie sicher, dass der für die Canarys geschriebene Code idempotent ist. Andernfalls kann es in seltenen Fällen bei Canary-Ausführungen zu Race-Bedingungen kommen, wenn der Canary bei verschiedenen Ausführungen mit derselben Ressource interagiert.

Fehlerbehebung für ein Canary in einer VPC

Wenn nach dem Erstellen oder Aktualisieren eines Canarys auf einem VPC Probleme auftreten, kann einer der folgenden Abschnitte Ihnen helfen, das Problem zu beheben.

Neues Canary im Fehlerzustand oder Canary kann nicht aktualisiert werden

Wenn Sie ein Canary zur Ausführung in einer VPC erstellen und dieses sofort in einen Fehlerzustand geht oder Sie ein Canary nicht so aktualisieren können, dass es in einer VPC ausgeführt wird, verfügt die Rolle des Canarys möglicherweise nicht über die korrekten Berechtigungen. Um auf einer VPC ausgeführt werden zu können, muss ein Canary über die Berechtigungen ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces und ec2:DeleteNetworkInterface verfügen. Diese Berechtigungen sind alle in der von AWSLambdaVPCAccessExecutionRole verwalteten Richtlinie enthalten. Weitere Informationen finden Sie unter Ausführungsrolle und Benutzerberechtigungen.

Wenn dieses Problem beim Erstellen eines Canarys aufgetreten ist, müssen Sie das Canary löschen und ein neues erstellen. Wenn Sie die CloudWatch-Konsole verwenden, um das neue Canary zu erstellen, wählen Sie unter Access Permissions (Zugriffsberechtigungen) die Option Create a new role (Neue Rolle erstellen). Es wird eine neue Rolle erstellt, die alle für die Ausführung des Canary erforderlichen Berechtigungen enthält.

Wenn dieses Problem auftritt, wenn Sie ein Canary aktualisieren, können Sie das Canary erneut aktualisieren und eine neue Rolle bereitstellen, die über die erforderlichen Berechtigungen verfügt.

Fehler „No test result returned“ (Kein Testergebnis zurückgegeben)

Wenn ein Canary den Fehler „No test result returned (Kein Testergebnis zurückgegeben)“ anzeigt, kann eines der folgenden Probleme die Ursache sein:

Informationen zur Behebung dieser Probleme finden Sie in den Protokollen für das Canary.

Fehlerbehebung bei Canary mit automatischer Wiederholung

Um zu verstehen, warum Ihr Canary ausfällt, oder um bestimmte fehlgeschlagene Versuche zu analysieren, befolgen Sie diese Schritte zur Fehlerbehebung.