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.

Erstellen von Blueprint Canary mit mehreren Checks

Der Amazon CloudWatch Synthetics Multi Checks Blueprint hilft Ihnen bei der Erstellung eines Synthetics Canary, indem er eine einfache JSON-Konfiguration bereitstellt. Sie können Kosten sparen, indem Sie bis zu 10 verschiedene Arten von HTTP/DNS/SSL/TCP Schecks schrittweise nacheinander bündeln. Jede Prüfung umfasst Assertionen, die eine grundlegende Überprüfung anhand eines Prüfergebnisses ermöglichen.

Die Kanarien für Mehrfachprüfungen sind für einfache Anwendungsfälle konzipiert, in denen nur grundlegende Prüfungen ohne einen Headless-Browser erforderlich sind. Für komplexere Anwendungsfälle schauen Sie sich die anderen Canary-Typen an, die Amazon CloudWatch Synthetics anbietet.

Voraussetzungen

Einschränkungen

Verpackungsstruktur, JSON-Schema und Konfigurationseinstellungen

Die JSON-Checks-Konfiguration, die für den Canary verwendet wird, muss benannt blueprint-config.json werden. Die Konfiguration muss dem Schema und den Anweisungen unter folgenSchreiben einer JSON-Konfiguration für den Blueprint mit Node.js mehreren Checks.

Komprimieren Sie das blueprint-config.json in eine ZIP-Datei und stellen Sie sie in einem der folgenden Erstellungsworkflows bereit. Wenn eine synthetics.json Konfiguration vorhanden ist, wird sie ebenfalls in derselben ZIP-Datei komprimiert. Im Folgenden finden Sie ein Beispiel für eine Zip-Datei mit dem Namenmulti-checks.zip.

multi-checks.zip
├── blueprint-config.json
└── synthetics.json
    

Erstellen eines Canary-In mit mehreren Checks AWS-Managementkonsole

Erstellen Sie einen Multi Check Canary mit AWS APIs für Kunststoffe

Verwenden Sie die CreateCanary API und geben Sie im Code Parameter field/value BlueprintTypes="multi-checks" statt von an. Handler Wenn beide BlueprintTypes und angegeben Handler sind, ValidationException wird a angezeigt. Die angegebene Laufzeitversion muss mindestens eine syn-nodejs-3.0 neuere Version sein.

aws synthetics create-canary \
    --name my-multi-check-canary \
    --code ZipFile="ZIP_BLOB",BlueprintTypes="multi-checks" \
    --runtime-version syn-nodejs-3.0 \
    ...

// Or if you wanted to use S3 to provide your code.

aws synthetics create-canary \
    --name my-multi-check-canary \
    --code S3Bucket="my-code-bucket",S3Key="my-zip-code-key",BlueprintTypes="multi-checks" \
    ...
    

Einen Canary-In mit mehreren Checks erstellen CloudFormation

Geben Sie in Ihrer CloudFormation Vorlage für einen Canary mit Mehrfachcheck innerhalb des Code Parameters field/value BlueprintTypes="multi-checks" statt von an. Handler Wenn beide BlueprintTypes und angegeben Handler sind, ValidationException wird a angezeigt. Die bereitgestellte Runtime-Version muss syn-nodejs-3.0 or later

Eine Beispielvorlage:

SyntheticsCanary:
    Type: 'AWS::Synthetics::Canary'
    Properties:
      Name: MyCanary
      RuntimeVersion: syn-nodejs-3.0
      Schedule: {Expression: 'rate(5 minutes)', DurationInSeconds: 3600}
      ...
      Code:
        S3Bucket: "my-code-bucket"
        S3Key: "my-zip-code-key"
        BlueprintTypes: ["multi-checks"]
      ...
    

Authentifizierungs-Konfiguration

Wenn Ihr Canary HTTP-Anfragen an einen authentifizierten Endpunkt stellt, können Sie die Schritte Ihres Blueprint-Canary so konfigurieren, dass sie einen von vier Authentifizierungstypen verwenden: Basic, API Key, OAuth Client Credentials und Sigv4. Anstatt die Anforderungsheader selbst einzurichten, können Sie in Ihrer Blueprint-Definition einen Authentifizierungstyp angeben. Synthetics folgt dem angegebenen Authentifizierungstyp, um die Komponenten Ihrer HTTP-Anfrage mit den bereitgestellten Authentifizierungsinformationen zu füllen.

Sie geben in Ihrem Blueprint-Schritt im Abschnitt Authentifizierung einen Authentifizierungstyp an. Sie geben das Authentifizierungsschema an, das Sie verwenden möchten, und die Eigenschaften, die für das von Ihnen gewählte Authentifizierungsschema erforderlich sind, und Synthetics verwendet die bereitgestellten Informationen, um einen Authentifizierungsheader für Ihre HTTP-Anfrage zu erstellen.

Da das Speichern von Geheimnissen (wie Passwörtern oder API-Schlüsseln) im Klartext ein Sicherheitsproblem darstellt, unterstützt Synthetics die Integration mit. AWS Secrets Manager Wenn Sie eine HTTP-Anfrage in einem Synthetics Blueprint Canary authentifizieren möchten, können Sie auf das Geheimnis verweisen, in dem Ihre Authentifizierungsinformationen gespeichert sind, und Synthetics kümmert sich darum, das Geheimnis abzurufen und in Ihrem Canary zwischenzuspeichern. Dieser Ansatz stellt Synthetics Geheimnisse zur Verfügung, während deine Geheimnisse sicher gespeichert werden, ohne sie in deiner Blueprint-Konfiguration im Klartext angeben zu müssen.

Weitere Informationen zu finden Sie AWS Secrets Manager unter Was ist? AWS Secrets Manager

Grundlegende Authentifizierung

Synthetics implementiert das in RFC 7617 definierte grundlegende HTTP-Authentifizierungsschema. Das Verfahren funktioniert folgendermaßen:

Wenn der Benutzeragent beispielsweise die Benutzer-ID „Aladdin“ und das Passwort „open sesame“ senden möchte, verwendet er das folgende Header-Feld: Authorization: Basic == QWxhZGRpbjpvcGVuIHNlc2FtZQ

Beispielkonfiguration:

"Authentication": {
    "type": "BASIC",
    "username": MY_USERNAME, // Required
    "password": MY_PASSWORD // Required
}
      

API-Schlüssel-Authentifizierung

Sie können einen API-Schlüssel für die Authentifizierung Ihrer HTTP-Anfragen angeben. Wenn Sie die API-Schlüsselauthentifizierung verwenden, wird Ihr bereitgestellter API-Schlüssel in den HTTP-Header X-API-Key "" eingefügt. Wenn Sie eine benutzerdefinierte Ressource haben, die in einem anderen Header nach API-Schlüssel-Headern sucht, können Sie optional einen anderen Header-Namen angeben, in den Synthetics den API-Schlüssel einfügt.

Beispielkonfiguration:

"Authentication": {
    "type": "API_KEY",
    "apiKey": S0A1M2P3L4E5, // Required
    "header": X-Specific-Header // Optional, defaults to "X-API-Key"
}
      

SigV4-Authentifizierung

AWS SigV4 (Signature Version 4) ist das AWS Signaturprotokoll zum Hinzufügen von Authentifizierungsinformationen zu API-Anfragen. AWS Um eine SigV4-authenticated Anfrage zu stellen, müssen Sie die Region und den Dienst angeben, an den Sie Anfragen stellen, sowie einen ARN (AWS Resource Name), der eine IAM-Rolle identifiziert, die der Canary bei dieser SigV4-Anfrage übernehmen soll. Synthetics übernimmt die in RolEarn bereitgestellte IAM-Rolle und verwendet sie zur Authentifizierung Ihrer API-Anfrage. AWS

Beispielkonfiguration:

"Authentication": {
    "type": "SIGV4",
    "region": us-west-2, // Required
    "service": s3, // Required
    "roleArn": arn:AWS:iam:12345678912:role/SampleRole // Required
}
      

Überlegungen zu SigV4

Damit Synthetics die Rolle übernehmen kann, die Sie im Abschnitt zur SigV4-Authentifizierung angegeben haben, muss die dieser Rolle zugeordnete Vertrauensrichtlinie so konfiguriert werden, dass der Canary die bereitgestellte RoleArn übernehmen kann. Dem AWS Prinzipal, dem Sie vertrauen müssen, ist die Rolle, die Ihr Canary übernommen hat. AWS STS Es hat das Format aws:sts::{account_running_the_canary}:assumed-role/<canary_name>/<assumed_role_name> arn:.

Wenn auf Ihrem Konto 0123456789012 beispielsweise ein Canary mit dem Namen test-canary läuft und die Rolle, die er übernommen hat, den Namen canary-assume-role trägt, dann muss die Vertrauensrichtlinie diese Anweisung enthalten, damit der Canary die RoleArn-Funktion für die SigV4-Authentifizierung korrekt übernimmt:

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:AWS:sts::123456789012:assumed-role/test-canary/"
    },
    "Action": "sts:AssumeRole"
}
        

OAuth-Client-Anmeldeinformationen

Synthetics implementiert den in RFC 6479 Abschnitt 4.4 definierten Gewährungstyp für OAuth-Client-Anmeldeinformationen. Wenn Sie eine HTTP-Anfrage an einen Endpunkt stellen möchten, der mit einem Bearer-Token authentifiziert ist, das von einem OAuth-Token-Endpunkt ausgestellt wurde, kann Synthetics in Ihrem Namen ein Bearer-Token anfordern und verwalten. Wenn Sie das OAuth-Schema verwenden, führt Synthetics die folgenden Schritte aus:

Beispielkonfiguration:

"Authentication": {
    "type": "OAUTH_CLIENT_CREDENTIALS",
    "tokenUrl": ..., // Required
    "clientId": ..., // Required
    "clientSecret": ..., // Required
    "scope": ..., // Optional
    "audience": ..., // Optional
    "resource": ..., // Optional
}
      

Überlegungen zu OAuth

Synthetics aktualisiert OAuth-Token, wenn eine 401- oder 407-Antwort zurückgegeben wird.

AWS Secrets Manager Integration

Um zu vermeiden, dass geheime Werte (wie Passwörter oder API-Schlüssel) im Klartext gespeichert werden, bietet Synthetics eine Integration mit AWS Secrets Manager. Sie können in Ihrer Blueprint-Konfiguration mit dem Format ${AWS_SECRET:<secret_name>} auf einen ganzen geheimen Wert verweisen oder auf einen bestimmten Schlüssel verweisen. ${AWS_SECRET:<secret_name>:<secret_key>}

Wenn Sie beispielsweise ein Geheimnis mit dem Namen login/basic -auth-credentials haben, speichern Sie einen Benutzernamen und ein Passwort mit der folgenden JSON-Struktur:

{
    "username": "Aladdin",
    "password": "open sesame"
}
      

Sie können in Ihrer Blueprint-Konfiguration wie folgt auf den Benutzernamen und das Passwort verweisen, und Synthetics übernimmt das Abrufen des geheimen Werts und die Verwendung seiner Schlüssel zur Authentifizierung Ihrer Anfrage:

"Authentication": {
    "type": "BASIC",
    "username": ${AWS_SECRET:login/basic-auth-credentials:username},
    "password": ${AWS_SECRET:login/basic-auth-credentials:password}
}
      

Damit Synthetics das angegebene Geheimnis abrufen kann, muss der vom Canary übernommene Rollen-ARN sowohl über Berechtigungen als auch über Berechtigungen verfügen. secretsmanager:GetSecretValue secretsmanager:DescribeSecret Wenn das Geheimnis mit einem vom Kunden verwalteten Schlüssel anstelle des verwalteten Schlüssels AWS/secretsmanager verschlüsselt AWS wird, benötigen Sie für diesen Schlüssel auch die Berechtigungen kms:decrypt.

Beispiele für Berechtigungen:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": "arn:AWS:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
        },
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:AWS:kms:us-east-1:123456789012:key/key-id"
        }
    ]
}
      

Fehlerbehebung

Häufige Fehler bei der Problembehandlung

Der zugrunde liegende Code für den Multicheck-Blueprint ist in Typescript geschrieben. Auf der Seite zur Fehlerbehebung bei Canary finden Sie häufig auftretende Fehler: Fehlerbehebung bei einem ausgefallenen Canary.

Syntaxfehler bei der JSON-Überprüfung

Wenn syntaktische Fehler im Zusammenhang mit der JSON-Checkkonfiguration des Canary auftreten, AWS-Managementkonsole wird dir beim Versuch, den Canary zu erstellen, eine Fehlerursache angezeigt. Wenn du einen Canary mithilfe einer API oder erstellst CloudFormation, wirst du den Fehler sehen, wenn der Canary zum ersten Mal ausgeführt wird. Es wird empfohlen, den sicheren Canary-Aktualisierungs-Workflow für Multi Check Canary zu verwenden. Weitere Informationen findest du unter Sichere Canary-Updates durchführen.

Netzwerk- oder Timeout-Fehler

Bei zeitweiligen oder konsistenten Ausfällen im Zusammenhang mit Timeouts oder Netzwerkverbindungsausfällen (z. B. ENOTFOUND, ECONNRESET) sollten Sie erwägen, die DEBUG Protokolle so zu aktivieren, dass Sie im folgenden Durchlauf weitere Informationen darüber erhalten, warum die Prüfungen fehlschlagen. Geben Sie dazu die Umgebungsvariable CW_SYNTHETICS_LOG_LEVEL: „DEBUG“ an.

Wenn es immer noch Fehler gibt, die Sie nicht debuggen können, sollten Sie erwägen, sich an den AWS Support zu wenden oder zu überprüfen, ob einer der anderen von Synthetics bereitgestellten Canary-Typen Ihrem Anwendungsfall besser entspricht. CloudWatch