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 ab ARN

Führen Sie den folgenden Befehl aus, um das EngineArn Feld aus der Antwort abzurufen. Dies EngineArn ist die ARN Lambda-Funktion, die dem Kanarienvogel zugeordnet ist. Sie werden sie 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 die letzte gute Lambda-Laufzeitversion ARN

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 die 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 die ARN funktionierende Lambda-Runtime-Version identifizieren, die Sie zuvor verwendet haben. Folgen Sie den Anweisungen unter Identifizieren von Laufzeitversionsänderungen, um die Änderungen ARN der vorherigen Runtime zu ermitteln. Notieren Sie die Runtime-Version und fahren Sie mit Schritt 3 fortARN, um die Runtime-Management-Konfiguration festzulegen.

Wenn Ihr Canary noch nicht von einem Lambda-Umgebungsupdate betroffen ist, können Sie die ARN 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, das zu ersetzen function-name and qualifier mit der Versionsnummer der Lambda-Funktion ARN bzw. der Lambda-Funktion unter Verwendung der Werte, die Sie in Schritt 1 ermittelt haben. Ersetzen Sie auch die runtime-version-arn mit der VersionARN, 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 zu AWS WAF verhindern, dass dein Canary blockiert wird, richte eine Bedingung für den AWS WAF Zeichenkettenabgleich ein, die die Zeichenfolge erlaubtCloudWatchSynthetics. Weitere Informationen findest du in der AWS WAF Dokumentation unter Mit Bedingungen für den Abgleich von Zeichenketten arbeiten.

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 VPC einzurichten. Weitere Informationen finden Sie unter Einen Canary auf einem laufen lassen VPC.

Probleme beim Upgrade und Downgrade der Canary-Laufzeitversion

Wenn du den Canary kürzlich von einer Runtime-Version auf eine neuere Version aktualisiert hast, könnte es sich syn-1.0 um ein ursprungsübergreifendes Problem beim Teilen von Anfragen (CORS) handeln. Weitere Informationen finden Sie unter Problem beim ursprungsübergreifenden Teilen von Anfragen () 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 beim ursprungsübergreifenden Teilen von Anfragen () 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. Falls ja, könnten die fehlgeschlagenen Netzwerkanfragen durch Einschränkungen beim ursprungsübergreifenden Teilen von Anfragen (CORS) verursacht werden. Sie können überprüfen, ob dies der Fall ist, indem Sie die aktive Ablaufverfolgung deaktivieren oder die zusätzlichen Header entfernen. HTTP

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's hinzufügen, wird nach () -Anfragen gesuchtpage.setExtraHTTPHeaders. CORS XMLHttpRequest XHR

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 Für Node.js-Canary-Skripte verfügbare Bibliotheksfunktionen.

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.