Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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 Canaries sind als Lambda-Funktionen in Ihrem Konto implementiert. Diese Lambda-Funktionen unterliegen regelmäßigen Lambda-Runtime-Updates, die Sicherheitsupdates, Bugfixes und andere Verbesserungen enthalten. Lambda ist bestrebt, Runtime-Updates bereitzustellen, die mit bestehenden 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 glauben, dass Ihr Canary von einem Lambda-Runtime-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 Störungen werden minimiert, sodass Sie Zeit haben, die Inkompatibilität zu beheben, bevor Sie zur neuesten Runtime-Version zurückkehren.

Wenn dein Canary nach einem Lambda-Runtime-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-Laufzeitmanagement-Steuerelemente verfügbar sind, einen Canary auf eine ältere von Lambda verwaltete Laufzeit zurücksetzen, indem Sie den manuellen Modus für die Laufzeitverwaltungssteuerung verwenden. Sie können den manuellen Modus entweder mithilfe der AWS CLI oder mithilfe der Lambda-Konsole einrichten, indem Sie die folgenden Schritte in den folgenden Abschnitten ausführen.

Voraussetzungen

Schritt 1: Rufen Sie die Lambda-Funktion ARN ab

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

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

Beispielausgabe vonEngingArn:

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

Schritt 2: Besorgen Sie sich den ARN der letzten guten Lambda-Laufzeitversion

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

Wenn Ihr Canary von einem Lambda-Runtime-Update betroffen ist, müssen Sie den ARN der funktionierenden Lambda-Runtime-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 Runtime-Version und fahren Sie mit Schritt 3 fort, um die Runtime-Management-Konfiguration 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 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 vonRuntimeVersionArn:

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

Schritt 3: Aktualisierung der Lambda Runtime Management-Konfiguration

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

Um den manuellen Modus für die Konfiguration des Lambda-Laufzeitmanagements einzustellen, verwenden Sie den AWS CLI

Geben Sie den folgenden Befehl ein, um das Laufzeitmanagement der Lambda-Funktion in den manuellen Modus zu ändern. Achten Sie darauf, function-name und qualifier durch die Versionsnummer der Lambda-Funktion ARN bzw. Lambda-Funktion zu ersetzen, indem Sie die Werte verwenden, die Sie in Schritt 1 gefunden haben. Ersetzen Sie auch die runtime-version-arn durch die Version ARN, die Sie in Schritt 2 gefunden 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 ist blockiert von AWS WAF

Um Canary-Verkehr durchzulassen AWS WAF, erstellen Sie eine Bedingung für die Übereinstimmung mit AWS WAF Zeichenketten, 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 Zeichenketten.

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

Gehen Sie wie folgt vor, um eine benutzerdefinierte User-Agent-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.

Bei Problemen mit Puppetteer finden Sie auf der Seite von Puppeteer oder in den Internetforen. GitHub

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

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 am unteren Bildschirmrand befindet, passen Sie außerdem Ihr Darstellungsfenster an. CloudWatch Synthetics verwendet standardmäßig einen Viewport von 1920 * 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

Wenn Ihr Canary aufgrund eines Amazon S3 S3-Fehlers ausfällt, konnte CloudWatch Synthetics aufgrund von Berechtigungsproblemen keine Screenshots, Protokolle oder Berichte hochladen, 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. Nach der Ausführung Ihres Skripts 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 Canary-Ausführung wurde gestoppt, bevor CloudWatch Synthetics CloudWatch Erfolgsmetriken in Prozent veröffentlichen oder Artefakte wie HAR-Dateien, Logs 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 Timeout-Wert 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 in der CloudWatch Synthetics-Konsole nicht angezeigt werden, wenn dieser Fehler auftritt. Du kannst CloudWatch Logs verwenden, um die Logs von Canary einzusehen.

Versuch, auf einen internen Endpunkt zuzugreifen

Wenn du möchtest, dass dein Canary auf einen Endpunkt in deinem internen Netzwerk zugreift, empfehlen wir dir, 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 Runtime-Version heruntergestuft haben, stellen Sie sicher, dass die CloudWatch Synthetics-Funktionen, die Sie verwenden, in der älteren Runtime-Version verfügbar sind, auf die Sie das Downgrade durchgeführt 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. Wenn Sie die Anforderungsheader ändern, indem Sie einen Trace-Header hinzufügen oder zusätzliche Header mithilfe von Puppeteer hinzufügen, page.setExtraHTTPHeaders führt dies zu einer CORS-Prüfung auf Anfragen (XHR). XMLHttp

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.

Mit der Synthetics-Startfunktion können Sie die von CloudWatch Synthetics verwendeten Startparameter überschreiben und zusätzliche disable-web-security CloudWatch Flag-Parameter übergeben. Weitere Informationen finden Sie unter Verfügbare Bibliotheksfunktionen für kanarische Skripte von Node.js mit Puppeteer.

Probleme mit den Bedingungen des Canary-Rennens

Um die beste Erfahrung mit CloudWatch Synthetics zu erzielen, stellen Sie sicher, dass der für die Kanaren geschriebene Code idempotent ist. Andernfalls kann es in seltenen Fällen bei Canary-Runs zu Rennbedingungen kommen, wenn der Canary bei verschiedenen Durchläufen 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 den neuen Canary zu erstellen, wählen Sie unter Zugriffsberechtigungen die Option Neue Rolle erstellen aus. 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 auto Wiederholung

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