Problembehandlung bei fehlgeschlagenem Canary

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

Allgemeine Problembehebung

• Verwenden Sie die Canarydetailseite, um weitere Informationen zu erhalten. Wählen Sie in der CloudWatch Konsole im Navigationsbereich Canaries und dann den Namen des Canaries aus, um die Canary-Detailseite zu öffnen. Prüfen Sie auf der Registerkarte „Verfügbarkeit“ anhand der SuccessPercentMetrik, ob das Problem ständig oder nur sporadisch auftritt.

  Wählen Sie auf der Registerkarte Verfügbarkeit einen fehlgeschlagenen Datenpunkt aus, um Screenshots, Protokolle und Schrittberichte (sofern verfügbar) für diese fehlgeschlagene Ausführung anzuzeigen.

  Wenn ein Schrittbericht verfügbar ist, weil Schritte Teil des Skripts sind, überprüfen Sie, welcher Schritt fehlgeschlagen ist, und sehen Sie sich die zugehörigen Screenshots an, um das Problem anzuzeigen, das Ihren Kunden auftritt.

  Sie können die HAR Dateien auch überprüfen, um festzustellen, ob eine oder mehrere Anfragen fehlschlagen. Sie können tiefer graben, indem Sie Protokolle verwenden, um fehlgeschlagene Anforderungen und Fehler anzuzeigen. Schließlich können Sie diese Artefakte mit den Artefakten eines erfolgreichen Canary-Laufs vergleichen, um das Problem zu ermitteln.

  Standardmäßig erfasst CloudWatch Synthetics Screenshots für jeden Schritt in einem UI-Kanarium. Ihr Skript ist jedoch möglicherweise so konfiguriert, dass Screenshots deaktiviert werden. Während des Debuggings möchten Sie möglicherweise Screenshots erneut aktivieren. In ähnlicher Weise möchten Sie bei API Canaries beim Debuggen möglicherweise die Header und den Hauptteil der HTTP Anfrage und Antwort sehen. Informationen zum Einschließen dieser Daten in den Bericht finden Sie unter executeHttpStep(stepName,requestOptions, [Rückruf], []) stepConfig.

• Wenn Sie eine kürzlich bereitgestellte Anwendung hatten, rollen Sie sie zurück und debuggen Sie sie später.

• Stellen Sie manuell eine Verbindung zu Ihrem Endpunkt her, um zu sehen, ob Sie das gleiche Problem reproduzieren können.

Themen

• Canary schlägt nach dem Update der Lambda-Umgebung fehl
• Mein Canary ist blockiert von AWS WAF
• Warten auf das Erscheinen eines Elements
• Der Knoten ist entweder nicht sichtbar oder nicht für page.click () geeignet HTMLElement
• Artifacts können nicht in S3 hochgeladen werden, Ausnahme: S3-Bucket-Speicherort kann nicht abgerufen werden: Zugriff verweigert
• Fehler: Protokollfehler (Runtime). callFunctionOn): Ziel geschlossen.
• Canary ist fehlgeschlagen. Fehler: Kein Datenpunkt – Canary zeigt Timeout-Fehler
• Versuch, auf einen internen Endpunkt zuzugreifen
• Probleme beim Upgrade und Downgrade der Canary-Laufzeitversion
• Problem beim ursprungsübergreifenden Teilen von Anfragen () CORS
• Probleme mit den Bedingungen des Canary-Rennens
• Fehlerbehebung bei einem Canary auf einem VPC

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.

Warnung

Wenn Sie die Laufzeiteinstellungen in den manuellen Modus ändern, erhält Ihre Lambda-Funktion keine automatischen Sicherheitsupdates, bis sie wieder in den automatischen Modus zurückversetzt wird. Während dieses Zeitraums kann Ihre Lambda-Funktion anfällig für Sicherheitslücken sein.

Voraussetzungen

• Installieren Sie jq

• Installieren Sie die neueste Version von. AWS CLI Weitere Informationen finden Sie in den AWS CLI Installations- und Aktualisierungsanweisungen.

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 Änderungen an der Runtime-Version, um die Version 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"

Um einen Canary mithilfe der Lambda-Konsole in den manuellen Modus zu versetzen

1. Öffnen Sie die AWS Lambda Konsole unter. https://console.aws.amazon.com/lambda/

2. Wählen Sie die Registerkarte Versionen, wählen Sie den Link mit der Versionsnummer, der Ihrem entsprichtARN, und wählen Sie den Tab Code.

3. Scrollen Sie nach unten zu Runtime-Einstellungen, erweitern Sie Runtime Management-Konfiguration und kopieren Sie die Runtime-Version ARN.

   

4. Wählen Sie Runtime-Management-Konfiguration bearbeiten, wählen Sie Manuell und fügen Sie die Runtime-VersionARN, die Sie zuvor kopiert haben, in das ARN Feld Runtime-Version ein. Wählen Sie dann Speichern.

   

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:

• Vergewissern Sie sich, dass die IAM Rolle des Canary die s3:ListAllMyBuckets Berechtigung hat, die s3:GetBucketLocation Berechtigung für den richtigen Amazon S3 S3-Bucket und die s3:PutObject Berechtigung für den Bucket, in dem der Canary seine Artefakte speichert. Wenn der Canary eine visuelle Überwachung durchführt, benötigt die Rolle auch die s3:GetObject-Berechtigung für den Bucket. Dieselben Berechtigungen sind auch in der Amazon VPC S3 Gateway Endpoint Policy erforderlich, wenn der Canary in einem VPC mit einem VPC Endpunkt bereitgestellt wird.

• Wenn der Canary anstelle des standardmäßigen verwalteten Schlüssels (Standard) einen vom AWS KMS Kunden AWS verwalteten Schlüssel für die Verschlüsselung verwendet, ist die IAM Rolle des Canary möglicherweise nicht berechtigt, mit diesem Schlüssel zu verschlüsseln oder zu entschlüsseln. Weitere Informationen finden Sie unter Verschlüsseln von Canary-Artefakten.

• Ihre Bucket-Richtlinie lässt möglicherweise den Verschlüsselungsmechanismus nicht zu, den der Canary verwendet. Wenn deine Bucket-Richtlinie zum Beispiel die Verwendung eines bestimmten Verschlüsselungsmechanismus oder KMS Schlüssels vorschreibt, musst du denselben Verschlüsselungsmodus für deinen Canary wählen.

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.

Um CloudWatch Logs zu verwenden, um die Logs eines Kanarienvogels einzusehen

1. Öffnen Sie die CloudWatch Konsole unter https://console.aws.amazon.com/cloudwatch/.

2. Wählen Sie im linken Navigationsbereich Log groups (Protokollgruppen) aus.

3. Suchen Sie die Protokollgruppe, indem Sie den Canary-Namen in das Filterfeld eingeben. Protokollgruppen für Kanaren haben den Namen /aws/lambda/cwsyn-canaryName-randomId.

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.

Anmerkung

Wenn Sie ein Upgrade oder Downgrade der Runtime-Version für einen Canary planen, empfehlen wir Ihnen, zuerst den Canary zu klonen und die Runtime-Version auf dem geklonten Canary zu aktualisieren. Nachdem Sie überprüft haben, dass der Klon mit der neuen Laufzeitversion funktioniert, können Sie die Laufzeitversion Ihres ursprünglichen Canary aktualisieren und den Klon löschen.

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.

Anmerkung

Sie können die von CloudWatch Synthetics verwendeten Startparameter überschreiben, wenn Sie die Laufzeitversion syn-nodejs-2.1 oder höher verwenden.

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.