Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Création d'un canari de plans à vérifications multiples

Le plan multi-contrôles Amazon CloudWatch Synthetics vous aide à créer un canari Synthetics en fournissant une configuration JSON simple. Vous pouvez réduire les coûts en regroupant jusqu'à 10 types de HTTP/DNS/SSL/TCP chèques différents de manière séquentielle par étapes. Chaque vérification inclut des assertions qui fournissent une vérification de base par rapport à un résultat de vérification.

Les canaris à vérifications multiples sont conçus pour des cas d'utilisation simples qui ne nécessitent que des vérifications de base, sans navigateur headless. Pour des cas d'utilisation plus complexes, consultez les autres types de canaris proposés par Amazon CloudWatch Synthetics.

Conditions préalables

Limitations

Structure d'emballage, schéma JSON et paramètres de configuration

La configuration JSON Checks qui sera utilisée pour le canary doit être nomméeblueprint-config.json. La configuration doit suivre le schéma et suivre les instructions ci-dessousÉcrire une configuration JSON pour le plan Node.js Multi Checks.

Compressez-le blueprint-config.json dans un fichier ZIP et insérez-le dans l'un des flux de travail de création suivants. Lorsqu'il existe une synthetics.json configuration, elle est également compressée dans le même fichier ZIP. Voici un exemple de fichier zip appelémulti-checks.zip.

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

Création d'un canari à vérifications multiples dans AWS Management Console

Création d'un canari à contrôles multiples à l'aide de AWS Synthetics APIs

Utilisez l'CreateCanaryAPI et, dans le Code paramètre, indiquez le field/value BlueprintTypes="multi-checks" au lieu deHandler. Lorsque les deux BlueprintTypes et Handler sont spécifiés, un ValidationException est affiché. La version d'exécution fournie doit êtresyn-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" \
    ...
    

Création d'un canari à vérifications multiples dans CloudFormation

Dans votre CloudFormation modèle pour un canari à vérifications multiples, dans le Code paramètre, indiquez le field/value BlueprintTypes="multi-checks" au lieu deHandler. Lorsque les deux BlueprintTypes et Handler sont spécifiés, un ValidationException est affiché. La version d'exécution fournie doit êtresyn-nodejs-3.0 or later.

Exemple de modèle :

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"]
      ...
    

Configuration de l’authentification

Lorsque votre Canary envoie des requêtes HTTP à un point de terminaison authentifié, vous pouvez configurer les étapes de votre Blueprint Canary pour utiliser l'un des quatre types d'authentification suivants : Basic, API Key, OAuth Client Credentials et SigV4. Plutôt que de configurer vous-même les en-têtes de demande, vous pouvez spécifier un type d'authentification dans la définition de votre plan, et Synthetics suit le type d'authentification spécifié pour renseigner les composants de votre requête HTTP avec les informations d'authentification fournies.

Vous spécifiez un type d'authentification dans l'étape de votre plan dans la section Authentification. Vous spécifiez le schéma d'authentification que vous souhaitez utiliser, les propriétés requises pour le schéma d'authentification que vous avez choisi, et Synthetics utilise les informations fournies pour créer un en-tête d'authentification pour votre requête HTTP.

Étant donné que le stockage de secrets (tels que des mots de passe ou des clés d'API) en texte brut constitue un problème de sécurité, Synthetics prend en charge l'intégration avec. AWS Secrets Manager Lorsque vous souhaitez authentifier une requête HTTP dans un canari de plans Synthetics, vous pouvez vous référer au secret qui stocke vos informations d'authentification. Synthetics se charge de récupérer le secret et de le mettre en cache dans votre canari. Cette approche fournit des secrets à Synthetics tout en les stockant en toute sécurité, sans les spécifier en texte brut dans la configuration de votre plan.

Pour plus d'informations AWS Secrets Manager, voir Qu'est-ce que c'est AWS Secrets Manager ?

Authentification basique

Synthetics implémente le schéma d'authentification HTTP de base défini dans la RFC 7617. Le processus fonctionne comme suit :

Par exemple, si l'agent utilisateur souhaite envoyer le nom d'utilisateur « Aladdin » et le mot de passe « open sesame », il utilise le champ d'en-tête suivant : Authorization : Basic FTzQ== QWxh ZGRpbjpvc GVu IHNlc2

Exemple de configuration :

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

Authentification par clé d'API

Vous pouvez fournir une clé d'API pour authentifier vos requêtes HTTP. Lorsque vous utilisez l'authentification par clé d'API, la clé d'API que vous avez fournie est placée dans l'en-tête HTTP « X-api-key ». Si vous avez une ressource personnalisée qui recherche des en-têtes de clé d'API dans un en-tête autre que celui-ci, vous pouvez éventuellement spécifier un autre nom d'en-tête dans lequel Synthetics insère la clé d'API.

Exemple de configuration :

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

Authentification SigV4

AWS SigV4 (Signature Version 4) est le protocole de AWS signature permettant d'ajouter des informations d'authentification aux demandes d' AWS API. Pour effectuer une demande authentifiée SIGv4, vous devez spécifier la région et le service auxquels vous envoyez des demandes, ainsi qu'un ARN (nom de AWS ressource) identifiant le rôle IAM que vous souhaitez que le canari assume lors de cette demande Sigv4. Synthetics assume le rôle IAM fourni dans le ROLearn et l'utilise pour authentifier votre demande d'API. AWS

Exemple de configuration :

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

Considérations relatives au SigV4

Pour que Synthetics assume le rôle que vous avez indiqué dans la section d'authentification SigV4, la politique de confiance associée à ce rôle doit être configurée pour permettre au Canary d'assumer le ROLearn fourni. Le AWS principe auquel vous devez faire confiance est le rôle que votre canari a assumé AWS STS. Il prend le format aws:sts::{account_running_the_canary}:assumed-role/<canary_name>/<assumed_role_name> arn :.

Par exemple, si un canari s'exécute sur le compte 0123456789012, nommé test-canary, et que le rôle qu'il a assumé a été nommé canary-assume-role, la politique de confiance doit inclure cette déclaration pour que le canari assume correctement l'authentification ROLearn for SIGv4 :

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

OAuth informations d'identification du client

Synthetics implémente le type d'autorisation des informations d'identification OAuth du client tel que défini dans la section 4.4 de la RFC 6479. Si vous souhaitez envoyer une requête HTTP à un point de terminaison authentifié à l'aide d'un jeton porteur émis par un point de terminaison de OAuth jeton, Synthetics peut demander et gérer un jeton porteur en votre nom. Lorsque vous utilisez le OAuth schéma, Synthetics exécute les étapes suivantes :

Exemple de configuration :

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

OAuth considérations

Synthetics OAuth actualise les jetons lorsqu'une réponse 401 ou 407 est renvoyée.

AWS Secrets Manager intégration

Pour éviter de stocker des valeurs secrètes (telles que des mots de passe ou des clés d'API) en texte brut, Synthetics propose une intégration avec. AWS Secrets Manager Vous pouvez référencer une valeur secrète complète dans la configuration de votre plan à l'aide du format${aws_SECRET:<secret_name>}, ou pour faire référence à une clé ${aws_SECRET:<secret_name>:<secret_key>} particulière.

Par exemple, si vous avez un secret nommé login/basic-auth-credentials, vous stockez un nom d'utilisateur et un mot de passe avec la structure JSON suivante :

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

Vous pouvez référencer le nom d'utilisateur et le mot de passe dans la configuration de votre plan comme suit, et Synthetics se charge de récupérer la valeur secrète et d'utiliser ses clés pour authentifier votre demande :

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

Pour permettre à Synthetics de récupérer le secret spécifié, le rôle ARN assumé par le canari doit disposer des autorisations SecretsManager :. GetSecretValue Si le secret est chiffré à l'aide d'une clé gérée par le client au lieu de la clé AWS gérée AWS/secretsmanager, vous devez également disposer des autorisations de kms: déchiffrement pour cette clé.

Exemples d'autorisations :

{
    "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"
        }
    ]
}
      

Résolution des problèmes

Défaillances de dépannage courantes

Le code sous-jacent pour le plan à vérifications multiples est écrit en Typescript. Consultez la page de résolution des problèmes courants de Canary : Résolution des problèmes liés à un Canary défaillant.

Erreurs de syntaxe de configuration de vérification JSON

En cas d'erreurs syntaxiques liées à la configuration de vérification JSON du canari, vous AWS Management Console indiquerez la raison de l'échec lorsque vous tenterez de créer le canari. Si vous créez un canari à l'aide d'une API CloudFormation, vous constaterez l'échec lorsque le canari sera exécuté pour la première fois. Il est recommandé d'utiliser le flux de travail sécurisé de Canary Updates pour Multi Check Canary. Pour plus d'informations, consultez la section Exécution de mises à jour sécurisées de Canary.

Défaillances de mise en réseau ou de temporisation

En cas de défaillance intermittente ou constante liée à des délais d'expiration ou à des défaillances de connexion réseau (par exemple, ENOTFOUND, ECONNRESET), envisagez d'activer les DEBUG journaux afin que l'exécution suivante fournisse plus de détails supplémentaires sur les raisons de l'échec des vérifications. Pour ce faire, fournissez la variable d'environnement CW_SYNTHETICS_LOG_LEVEL : « DEBUG ».

Si vous ne parvenez toujours pas à corriger des défaillances, pensez à contacter le AWS Support ou à vérifier si l'un des autres types Canary fournis par CloudWatch Synthetics correspond mieux à votre cas d'utilisation.