Blueprint Canary für mehrere Checks erstellen

Der Amazon CloudWatch Synthetics Multi Checks Blueprint hilft Ihnen dabei, einen Synthetics-Canary zu erstellen, indem es eine einfache JSON-Konfiguration bereitstellt. Sie können Kosten sparen, indem Sie bis zu 10 verschiedene Arten von HTTP/DNS/SSL/TCP Prüfungen schrittweise nacheinander bündeln. Jede Prüfung enthält Behauptungen, die eine grundlegende Überprüfung anhand eines Prüfergebnisses ermöglichen.

Multi Checks Canaries sind für einfache Anwendungsfälle konzipiert, die nur grundlegende Prüfungen ohne einen Headless-Browser erfordern. Für komplexere Anwendungsfälle schauen Sie sich die anderen Canary-Typen an, die Amazon CloudWatch Synthetics anbietet.

Voraussetzungen

• Muss syn-nodejs-3.0+ verwenden, um einen Multi-Check-Canary zu erstellen

• Wenn Sie die Authentication and Secrets Manager Manager-Konfiguration verwenden, müssen Sie sicherstellen, dass der Canary ExecutionRoleArndie Berechtigungen für den Zugriff auf diese Geheimnisse gewährt

• Wenn Sie die Authentifizierung für Sigv4 verwenden, müssen Sie sicherstellen, dass der Canary ExecutionRoleArndie Berechtigungen für den Zugriff auf die entsprechende Rolle gewährt

Einschränkungen

• Die Größe der HTTP-Antwort darf nicht größer als 1 MB sein

• Maximal 10 definierte Variablen.

• Bei Verwendung des JSON-RFC kann das Checks JSON doppelte Felder enthalten, sofern jedoch nur das letzte sequentielle Feld verwendet wird

• In einem Canary mit mehreren Prüfungen werden standardmäßig Metriken mit mehreren Prüfschritten angezeigt, um die Verfügbarkeit der einzelnen Prüfungen leicht zu ermitteln. AWS-Managementkonsole Wenn Schecks entfernt werden, zeigt dieses Diagramm die Checks möglicherweise immer noch im Verfügbarkeitsdiagramm an, bis die Metrik für mindestens 3 Stunden nicht mehr aktiv ist

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 Node.js Multi Checks.

Komprimieren Sie die Datei blueprint-config.json in eine ZIP-Datei und stellen Sie sie in einem der folgenden Erstellungs-Workflows bereit. Wenn es eine synthetics.json Konfiguration gibt, wird sie auch 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
    

Einen Multi-Check-Canary in erstellen AWS-Managementkonsole

1. Öffnen Sie die Amazon CloudWatch Synthetics-Konsole.

2. Wählen Sie Canary erstellen aus.

3. Wählen Sie unter Blueprint verwenden die Option Mehrfachprüfungen aus.

   Unter Checks konfigurieren findest du zwei Tabs: Checks und Canary-Konfiguration.

4. Wählen Sie die Laufzeitversion syn-nodejs-3.0 oder höher aus.

5. Gehen Sie wie unten beschrieben vor, um die Prüfung Schreiben einer JSON-Konfiguration für den Blueprint Node.js Multi Checks zu beschreiben, die Sie durchführen möchten. Alternativ bietet Ihnen die Konsole eine Standard-JSON-Konfiguration, auf der Sie aufbauen können.

6. Wählen Sie Canary erstellen aus.

Mit AWS Synthetics einen Multi-Check-Kanarienvogel erstellen APIs

Verwenden Sie die CreateCanary API und geben Sie im Code Parameter field/value BlueprintTypes="multi-checks" anstelle von das an. Handler Wenn BlueprintTypes sowohl als auch angegeben Handler sind, ValidationException wird a angezeigt. Die bereitgestellte Runtime-Version muss seinsyn-nodejs-3.0 or later.

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 Check-Ins erstellen CloudFormation

Geben Sie in Ihrer CloudFormation Vorlage für einen Canary mit mehreren Checks innerhalb des Code Parameters das field/value BlueprintTypes="multi-checks" anstelle von an. Handler Wenn BlueprintTypes sowohl als auch angegeben Handler sind, ValidationException wird a angezeigt. Die bereitgestellte Runtime-Version muss seinsyn-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 dein Canary HTTP-Anfragen an einen authentifizierten Endpunkt sendet, kannst du die Schritte deines Blueprint Canary so konfigurieren, dass er einen von vier Authentifizierungstypen verwendet: Basic, API Key, OAuth Client Credentials und SigV4. Anstatt selbst Anforderungsheader einzurichten, können Sie in Ihrer Blueprint-Definition einen Authentifizierungstyp angeben, und 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, 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 Secret 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 und bewahrt Ihre Geheimnisse gleichzeitig sicher auf, ohne sie in Ihrer Blueprint-Konfiguration im Klartext anzugeben.

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

Standardauthentifizierung

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

• Ein Paar aus Benutzername und Passwort wird aus der Blueprint-Konfiguration bereitgestellt.

• Der Benutzerpass wird durch die Verkettung des Benutzernamens, eines einzelnen Doppelpunkts („:“) und des Kennworts erstellt.

• Der Benutzerpass ist UTF-8-kodiert und wird dann in eine Base64-kodierte Zeichenfolge umgewandelt.

• Dieser Base64-kodierte Benutzerpass wird im Header „Authorization“ mit dem folgenden Format bereitgestellt: Authorization: Basic {base64-} encoded-user-pass

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

Beispielkonfiguration:

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

API-Schlüsselauthentifizierung

Sie können einen API-Schlüssel zur 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ügen soll.

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-authentifizierte Anfrage zu stellen, müssen Sie die Region und den Dienst angeben, an den Sie Anfragen stellen, sowie einen ARN (AWS Ressourcenname) angeben, der eine IAM-Rolle identifiziert, die der Canary bei dieser SigV4-Anfrage übernehmen soll. Synthetics übernimmt die im roleArn bereitgestellte IAM-Rolle und verwendet sie, um Ihre API-Anfrage zu authentifizieren. 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 übernimmt, die Sie im Abschnitt zur SigV4-Authentifizierung angegeben haben, muss die dieser Rolle zugeordnete Vertrauensrichtlinie so konfiguriert sein, dass der Canary das bereitgestellte roleArn übernehmen kann. Der AWS Principal, 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 beispielsweise ein Canary unter dem Konto 0123456789012 mit dem Namen test-canary läuft und die Rolle, die er angenommen hat, benannt wurde, muss die Vertrauensrichtlinie diese Anweisung enthalten canary-assume-role, damit der Canary die Rolearn-Authentifizierung für SigV4-Authentifizierung korrekt übernimmt:

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

OAuth Kundenanmeldedaten

Synthetics implementiert den Grant-Typ OAuth Client Credentials, wie in RFC 6479 Abschnitt 4.4 definiert. Wenn Sie eine HTTP-Anfrage an einen Endpunkt stellen möchten, der mit einem von einem Token-Endpunkt ausgegebenen Bearer-Token authentifiziert wurde, kann Synthetics in Ihrem Namen ein Bearer-Token anfordern und verwalten. OAuth Wenn Sie das OAuth Schema verwenden, führt Synthetics die folgenden Schritte aus:

• Verwendet das Standardauthentifizierungsschema mit clientId und ClientSecret, um eine Anfrage an die TokenUrl zu authentifizieren, den Endpunkt, der Inhabertoken ausgibt

• Wenn Sie die optionalen Parameter Scope, Audience und Resource angeben, sind diese in der Token-Anfrage enthalten

• Verwendet das von der TokenUrl zurückgegebene Zugriffstoken, um Ihre HTTP-Anfrage zu authentifizieren

• Speichert das von der TokenURL zurückgegebene Aktualisierungstoken sicher für future Token-Anfragen

Beispielkonfiguration:

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

OAuth Überlegungen

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 mit dem Format ${aws_SECRET:<secret_name>} auf einen gesamten geheimen Wert in Ihrer Blueprint-Konfiguration verweisen oder auf einen bestimmten Schlüssel verweisen. ${aws_SECRET:<secret_name>:<secret_key>}

Wenn Sie beispielsweise ein Geheimnis namens login/ habenbasic-auth-credentials, das einen Benutzernamen und ein Passwort mit der folgenden JSON-Struktur speichert:

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

Sie können den Benutzernamen und das Passwort in Ihrer Blueprint-Konfiguration wie folgt referenzieren, 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 die vom Canary übernommene Rolle ARN über SecretsManager: -Berechtigungen verfügen. GetSecretValue Wenn das Geheimnis mit einem vom Kunden verwalteten Schlüssel anstelle des verwalteten Schlüssels AWS/secretsmanager verschlüsselt AWS wird, benötigen Sie auch Decrypt-Berechtigungen für diesen Schlüssel. kms:

Beispielberechtigungen:

{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "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 Fehlerbehebung

Der zugrunde liegende Code für den Multi-Check-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 der Konfiguration

Wenn es irgendwelche syntaktischen Fehler im Zusammenhang mit der JSON-Prüfkonfiguration des Canary gibt, AWS-Managementkonsole erhalten Sie eine Fehlerursache, wenn Sie versuchen, den Canary zu erstellen. 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 Workflow für sichere Canary-Updates für Multi Check Canary zu verwenden. Weitere Informationen findest du unter Sichere Canary-Updates durchführen.

Netzwerk- oder Timeout-Fehler

Bei sporadisch auftretenden oder andauernden Ausfällen im Zusammenhang mit Timeouts oder Netzwerkverbindungsfehlern (z. B. ENOTFOUND, ECONNRESET) sollten Sie in Erwägung ziehen, DEBUG Protokolle zu aktivieren, sodass der folgende Rechenlauf weitere Informationen darüber liefert, 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 sich an den AWS Support wenden oder prüfen, ob einer der anderen von CloudWatch Synthetics bereitgestellten Canary-Typen besser zu Ihrem Anwendungsfall passt.