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. # Utilisation des modèles de scripts Canary Cette section fournit des détails sur chacun des modèles de scripts Canary et les tâches auxquelles chaque modèle est le mieux adapté. Des plans sont fournis pour les types de scripts Canary suivants : **Topics** + [Surveillance des pulsations](#CloudWatch_Synthetics_Canaries_Blueprints_Heartbeat) + [Script Canary d'API](#CloudWatch_Synthetics_Canaries_Blueprints_API) + [Vérificateur des liens cassés](#CloudWatch_Synthetics_Canaries_Blueprints_Broken_Links) + [Modèle de surveillance visuelle](#CloudWatch_Synthetics_Canaries_Blueprints_VisualTesting) + [Enregistreur de scripts Canary](#CloudWatch_Synthetics_Canaries_Blueprints_Recorder) + [Générateur de flux de travail GUI](#CloudWatch_Synthetics_Canaries_Blueprints_GUI_Workflow) + [Plan multi-chèques](#CloudWatch_Synthetics_Canaries_Blueprints_Multichecks_Blueprint) + [Création d'un canari à plusieurs vérifications](CloudWatch_Synthetics_Canaries_MultiCheck_Blueprint.md) Lorsque vous utilisez un modèle pour créer un script canari, lorsque vous renseignez les champs de la console CloudWatch, la zone **Script editor (Éditeur de script)** de la page affiche le script canari que vous créez en tant que script Node.js. Vous pouvez également modifier votre script Canary dans cette zone pour le personnaliser davantage. ## Surveillance des pulsations Les scripts de pulsations chargent l'URL spécifiée et stockent une capture d'écran de la page et un fichier d'archive HTTP (fichier HAR). Ils stockent également les journaux des accès URLs. Vous pouvez utiliser les fichiers HAR pour afficher des données de performances détaillées sur les pages web. Vous pouvez analyser la liste des demandes web et détecter des problèmes liés aux performances, notamment le temps de chargement d'un élément. Si votre Canary utilise la version d'exécution `syn-nodejs-puppeteer-3.1` ou une version ultérieure, vous pouvez utiliser le plan de surveillance du rythme cardiaque pour en surveiller plusieurs URLs et voir le statut, la durée, les captures d'écran associées et la raison de l'échec de chaque URL dans le résumé des étapes du rapport Canary Run. ## Script Canary d'API Les scripts Canary d'API peuvent tester les fonctions de base de lecture et d'écriture d'une API REST. REST, qui signifie *transfert d'état représentatif*, est un ensemble de règles que les développeurs suivent lors de la création d'une API. L'une de ces règles stipule qu'un lien vers une URL spécifique doit renvoyer un élément de données. Les Canaries peuvent travailler avec n'importe qui APIs et tester tous les types de fonctionnalités. Chaque script Canary peut effectuer plusieurs appels d'API. Dans les canaris qui utilisent une version d'exécution `syn-nodejs-2.2` ou ultérieure, le plan API Canary prend en charge les canaris en plusieurs étapes qui vous APIs surveillent sous forme d'étapes HTTP. Vous pouvez en tester plusieurs APIs dans un seul canari. Chaque étape est une demande distincte qui peut accéder à des URL différentes, utiliser des en-têtes différents et des règles différentes pour déterminer si les en-têtes et les corps de réponse sont capturés. En ne capturant pas les en-têtes et le corps de la réponse, vous pouvez empêcher l'enregistrement de données sensibles. Chaque demande dans un script Canary d'API comprend les informations suivantes : + Le *point de terminaison*, qui est l'URL que vous demandez. + La *méthode*, qui est le type de demande envoyé au serveur. REST APIs prend en charge les opérations GET (lecture), POST (écriture), PUT (mise à jour), PATCH (mise à jour) et DELETE (suppression). + Les *en-têtes*, qui fournissent des informations à la fois au client et au serveur. Ils sont utilisés pour l'authentification et fournir des informations sur le contenu du corps. Pour une liste d'en-têtes valides, consultez [En-têtes HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers). + Les *données* (ou le *corps*) qui contiennent des informations à envoyer au serveur. Utilisées uniquement pour les demandes POST, PUT, PATCH ou DELETE. **Note** Les plans de script Canary API ne sont pas pris en charge par les exécutions Playwright. Le modèle de script Canary d'API prend en charge les méthodes GET et POST. Lorsque vous utilisez ce modèle, vous devez spécifier des en-têtes. Par exemple, vous pouvez spécifier **Authorization** en tant que **clé** et spécifier les données d'autorisation nécessaires en tant que **valeur** pour cette clé. Si vous testez une requête POST, vous spécifiez également le contenu à publier dans le champ **Données**. **Intégration à API Gateway** Le modèle d'API est intégré à Amazon API Gateway. Cela vous permet de sélectionner une API API Gateway et un stage à partir du même AWS compte et de la même région que le Canary, ou de télécharger un modèle Swagger depuis API Gateway pour la surveillance des API entre comptes et entre régions. Vous pouvez ensuite choisir le reste des détails dans la console pour créer le script Canary, au lieu de les saisir à partir de zéro. Pour plus d'informations sur API Gateway, consultez [Qu'est-ce qu'Amazon API Gateway ?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html). **Utilisation d'une API privée** Vous pouvez créer un script canary utilisant une API privée dans Amazon API Gateway. Pour de plus amples informations, veuillez consulter [Création d'une API privée dans Amazon API Gateway ?](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) ## Vérificateur des liens cassés Le vérificateur de liens rompus collecte tous les liens à l'intérieur de l'URL que vous testez en utilisant `document.getElementsByTagName('a')`. Il teste uniquement le nombre de liens que vous spécifiez et l'URL elle-même est considérée comme le premier lien. Par exemple, si vous voulez vérifier tous les liens d'une page qui en contient cinq, vous devez spécifier que le script Canary doit suivre six liens. Les scripts Canary du vérificateur de liens rompus créés à l'aide de l'exécution `syn-nodejs-2.0-beta` ou version ultérieure prennent en charge les fonctions supplémentaires suivantes : + Fourniture d'un rapport qui inclut les liens qui ont été vérifiés, le code d'état, la raison de l'échec (le cas échéant) et les captures d'écran des pages source et de destination. + Lors de l'affichage des résultats de scripts Canary, vous pouvez utiliser un filtre pour afficher uniquement les liens rompus, puis réparer ces liens en fonction de la raison de l'échec. + Cette version effectue pour chaque lien des captures d'écran annotées de la page source et met en surbrillance l'ancre où le lien a été trouvé. Les composants masqués ne sont pas annotés. + Vous pouvez configurer cette version pour effectuer des captures d'écran des pages source et de destination, des pages source uniquement ou des pages de destination uniquement. + Cette version résout un problème dans la version précédente qui provoquait l'arrêt du script Canary après le premier lien rompu, même lorsque d'autres liens sont récupérés à partir de la première page. **Note** Les plans de vérification de liens brisés ne sont pas pris en charge par les exécutions Playwright. Pour mettre à jour un script Canary existant à l’aide de `syn-1.0` afin d’utiliser une nouvelle exécution, vous devez supprimer le script Canary existant et en créer un nouveau. La mise à jour d'un script Canary existant vers la nouvelle exécution ne rend pas ces fonctions disponibles. Un script Canary de vérification des liens rompus détecte les types d'erreurs de liens suivants : + 404 Page introuvable + Nom d'hôte non valide + URL incorrecte. Par exemple, il manque un crochet dans l'URL, elle a des barres obliques supplémentaires ou elle utilise le mauvais protocole. + Code de réponse HTTP non valide. + Le serveur hôte renvoie des réponses vides sans contenu ni code de réponse. + Les requêtes HTTP expirent constamment pendant l'exécution du script Canary. + L'hôte coupe systématiquement les connexions parce qu'il est mal configuré ou trop occupé. ## Modèle de surveillance visuelle Le modèle de surveillance visuelle inclut un code permettant de comparer les captures d'écran prises lors de l'exécution d'un script Canary aux captures d'écran prises lors de l'exécution d'un script Canary de référence. Si l'écart entre les deux captures d'écran dépasse un pourcentage de seuil, le script Canary échoue. La surveillance visuelle est prise en charge dans les canaris utilisant **syn-puppeteer-node-3.2 et versions ultérieures**. Cette fonctionnalité n’est actuellement pas prise en charge pour les scripts Canary utilisant Python et Selenium, ni pour ceux utilisant l’exécution Playwright. Le modèle de surveillance visuelle inclut la ligne de code suivante dans le script Canary de modèle par défaut, cette ligne activant la surveillance visuelle. ``` syntheticsConfiguration.withVisualCompareWithBaseRun(true); ``` La première fois que le script Canary s'exécute avec succès après l'ajout de cette ligne au script, il utilise les captures d'écran prises au cours de cette exécution comme référence pour les comparaisons. Après cette première exécution de Canary, vous pouvez utiliser la CloudWatch console pour modifier le Canary afin d'effectuer l'une des opérations suivantes : + Définir la prochaine exécution du script Canary comme nouvelle référence. + Dessiner des limites sur la capture d'écran de référence actuelle pour désigner les zones de la capture d'écran à ignorer lors des comparaisons visuelles. + Empêcher une capture d'écran d'être utilisée pour la surveillance visuelle. Pour plus d'informations sur l'utilisation de la CloudWatch console pour modifier un canari, consultez[Modification ou suppression d'un canary](synthetics_canaries_deletion.md). Vous pouvez également modifier le canary run utilisé comme référence en utilisant les `lastrun` paramètres ` nextrun` or ou en spécifiant un identifiant Canary Run dans l'[UpdateCanary](https://docs.aws.amazon.com/AmazonSynthetics/latest/APIReference/API_UpdateCanary.html)API. Lorsque vous utilisez le modèle de surveillance visuelle, vous saisissez l'URL à laquelle vous souhaitez effectuer la capture d'écran et vous spécifiez un seuil de différence sous forme de pourcentage. Après l'exécution de référence, les futures exécutions du script Canary qui détectent une différence visuelle supérieure à ce seuil déclenchent un échec du script Canary. Après l'exécution de référence, vous pouvez également modifier le script Canary pour « dessiner » des limites sur la capture d'écran de référence afin d'ignorer des zones pendant la surveillance visuelle. La fonction de surveillance visuelle est alimentée par la boîte à outils logicielle ImageMagick open source. Pour plus d'informations, consultez [ ImageMagick](https://imagemagick.org/index.php). ## Enregistreur de scripts Canary Avec le plan Canary Recorder, vous pouvez utiliser le CloudWatch Synthetics Recorder pour enregistrer vos actions de clic et de saisie sur un site Web et générer automatiquement un script Node.js qui peut être utilisé pour créer un Canary suivant les mêmes étapes. Le CloudWatch Synthetics Recorder est une extension Google Chrome fournie par Amazon. L’enregistreur Canary n’est pas pris en charge pour les scripts Canary utilisant l’exécution Playwright. **Crédits** [: The CloudWatch Synthetics Recorder est basé sur l'enregistreur Headless.](https://github.com/checkly/headless-recorder) Pour de plus amples informations, veuillez consulter [Utilisation de l' CloudWatch enregistreur Synthetics pour Google Chrome](CloudWatch_Synthetics_Canaries_Recorder.md). ## Générateur de flux de travail GUI Le modèle de générateur de flux de travail GUI vérifie que des actions peuvent être effectuées sur votre page web. Par exemple, si vous avez une page web avec un formulaire de connexion, le script Canary peut remplir les champs utilisateur et mot de passe et envoyer le formulaire pour vérifier le bon fonctionnement de la page web. Lorsque vous utilisez un modèle pour créer ce type de script Canary, vous spécifiez les actions que ce dernier doit effectuer sur la page web. Les actions que vous pouvez utiliser sont les suivantes : + **Click (Cliquer)** : sélectionne l'élément que vous spécifiez et simule un utilisateur qui clique sur l'élément ou le choisit. Pour spécifier l'élément dans un script Node.js, utilisez `[id=]` ou ` a[class=]`. Pour spécifier l'élément dans un script Python, utilisez `xpath //*[@id=]` ou ` //*[@class=]`. + **Verify selector (Vérifier le sélecteur)** : vérifie que l'élément spécifié existe sur la page web. Ce test est utile pour vérifier qu'une action précédente a conduit les éléments corrects à remplir la page. Pour spécifier l'élément à vérifier dans un script Node.js, utilisez `[id=]` ou ` a[class=]`. Pour spécifier l'élément à vérifier dans un script Python, utilisez `xpath //*[@id=]` ou `//*[class=]`. + **Verify text (Vérifier le texte)** : vérifie que la chaîne spécifiée est contenue dans l'élément cible. Ce test est utile pour vérifier qu'une action précédente a provoqué l'affichage du bon texte. Pour spécifier l'élément dans un script Node.js, utilisez un format tel que ` div[@id=]//h1`, parce que cette action utilise la fonction `waitForXPath` dans Puppeteer. Pour spécifier l'élément dans un script Python, utilisez un format xpath tel que` //*[@id=] ` ou //\$1[@class=], parce que cette action utilise la fonction `implicitly_wait` dans Selenium. + **Input text (Saisir du texte)** : écrit le texte spécifié dans l'élément cible. Pour spécifier l'élément à vérifier dans un script Node.js, utilisez `[id=]` ou ` a[class=]`. Pour spécifier l'élément à vérifier dans un script Python, utilisez `xpath //*[@id=]` ou `//*[@class=]`. + **Click with navigation (Cliquer avec la navigation)** : attend que la page soit entièrement chargée après avoir choisi l'élément spécifié. Cela s'avère très utile lorsque vous devez recharger la page. Pour spécifier l'élément dans un script Node.js, utilisez `[id=]` ou ` a[class=]`. Pour spécifier l'élément dans un script Python, utilisez `xpath //*[@id=]` ou ` //*[@class=]`. Par exemple, le modèle suivant utilise Node.js. Il clique sur le **firstButton** dans l'URL spécifiée, il vérifie que le sélecteur attendu s'affiche avec le texte attendu, il saisit le nom `Test_Customer` dans le champ **Name** (Nom), il clique sur le bouton **Login** (Connexion) et il vérifie ensuite que la connexion a réussi en recherchant le texte **Welcome** (Bienvenue) sur la page suivante. ![\[Page de création d'un script Canary dans la console, avec des champs remplis pour le modèle de flux de travail GUI.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/canary_create_gui_workflow.PNG) Les scripts Canary du flux de travail GUI qui utilisent les exécutions suivantes fournissent également un résumé des étapes exécutées pour chaque exécution de script Canary. Vous pouvez utiliser les captures d'écran et le message d'erreur associés à chaque étape pour trouver la cause racine de l'échec. + `syn-nodejs-2.0` ou version ultérieure + `syn-python-selenium-1.0` ou version ultérieure ## Plan multi-chèques Le plan Multi check simplifie la création de canaris. Il réduit les coûts en utilisant une configuration JSON simple qui fournit des out-of-the-box fonctionnalités permettant d'effectuer des vérifications HTTP, DNS, SSL et TCP. Vous pouvez configurer jusqu'à 10 contrôles. Configurez chaque vérification comme une étape numérique exécutée de manière séquentielle, afin de permettre une compréhension claire du Canary Flow. Les plans à vérifications multiples sont compatibles avec : + Requêtes HTTP de base, requêtes TCP, validation des enregistrements DNS et surveillance des certificats SSL + Méthodes d'authentification HTTP telles que Basic, API Key et Sigv4 intégrées à Secrets Manager OAuth + Assertions pour chaque vérification Pour de plus amples informations, veuillez consulter [Création d'un Canary](CloudWatch_Synthetics_Canaries_Create.md). # Création d'un canari à plusieurs vérifications 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. **Topics** + [Conditions préalables](#CloudWatch_Synthetics_MultiCheck_Prerequisites) + [Limitations](#CloudWatch_Synthetics_MultiCheck_Limitations) + [Structure d'emballage, schéma JSON et paramètres de configuration](#CloudWatch_Synthetics_MultiCheck_Packaging) + [Création d'un canari à vérifications multiples dans AWS Management Console](#CloudWatch_Synthetics_MultiCheck_Console) + [Création d'un canari à contrôles multiples à l'aide de AWS Synthetics APIs](#CloudWatch_Synthetics_MultiCheck_API) + [Création d'un canari à vérifications multiples dans CloudFormation](#CloudWatch_Synthetics_MultiCheck_CloudFormation) + [Configuration de l’authentification](#CloudWatch_Synthetics_MultiCheck_Authentication) + [Résolution des problèmes](#CloudWatch_Synthetics_MultiCheck_Troubleshooting) ## Conditions préalables + Vous devez utiliser syn-nodejs-3.0\$1 pour créer un canari à vérifications multiples + Lorsque vous utilisez la configuration d'Authentication and Secrets Manager, vous devez vous assurer que Canary [ ExecutionRoleArn](https://docs.aws.amazon.com/AmazonSynthetics/latest/APIReference/API_CreateCanary.html)autorise l'accès à ces secrets + Lorsque vous utilisez l'authentification pour Sigv4, vous devez vous assurer que le Canary [ ExecutionRoleArn](https://docs.aws.amazon.com/AmazonSynthetics/latest/APIReference/API_CreateCanary.html)autorise les autorisations d'accès au rôle correspondant ## Limitations + La taille des réponses HTTP ne peut pas dépasser 1 Mo + Maximum de 10 variables définies. + Lors de l'utilisation de la RFC JSON, le Checks JSON peut contenir des champs dupliqués, mais seul le dernier champ séquentiel sera utilisé. + Dans le AWS Management Console, un canari à vérifications multiples affichera par défaut les mesures relatives aux étapes de vérification multiples afin d'identifier facilement la disponibilité de chaque vérification. Lorsque les chèques sont supprimés, ce graphique peut toujours afficher les contrôles dans le graphique de disponibilité jusqu'à ce que la métrique cesse d'être active pendant au moins 3 heures ## 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ée` blueprint-config.json`. La configuration doit suivre le [schéma](https://github.com/aws-samples/synthetics-canary-local-debugging-sample/tree/main) et suivre les instructions ci-dessous[Écrire une configuration JSON pour le plan Node.js Multi Checks](CloudWatch_Synthetics_WritingCanary_Multichecks.md). 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 1. Ouvrez la console Amazon CloudWatch Synthetics. 1. Choisissez **Create Canary** (Créer un script Canary). 1. Sous **Utiliser un plan**, choisissez **plusieurs vérifications**. Sous **Configurer les vérifications**, vous verrez deux onglets, **Checks** et **Configuration Canary**. 1. Sélectionnez la version d'exécution **syn-nodejs-3.0** ou ultérieure. 1. Suivez la procédure ci-dessous [Écrire une configuration JSON pour le plan Node.js Multi Checks](CloudWatch_Synthetics_WritingCanary_Multichecks.md) pour décrire la vérification que vous souhaitez effectuer. La console vous fournit également une configuration JSON par défaut sur laquelle vous pouvez vous appuyer. 1. Choisissez **Create Canary** (Créer un script Canary). ## Création d'un canari à contrôles multiples à l'aide de AWS Synthetics APIs Utilisez l'`CreateCanary`API et, dans le `Code` paramètre, indiquez le field/value `BlueprintTypes="multi-checks"` au lieu de` Handler`. Lorsque les deux `BlueprintTypes` et `Handler` sont spécifiés, un `ValidationException` est affiché. La version d'exécution fournie doit être `syn-nodejs-3.0` ou ultérieure. ``` 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 de` Handler`. Lorsque les deux `BlueprintTypes` et `Handler` sont spécifiés, un `ValidationException` est affiché. La version d'exécution fournie doit être`syn-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 ?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) ### Authentification basique Synthetics implémente le schéma d'authentification HTTP de base défini dans la RFC 7617. Le processus fonctionne comme suit : + Une paire de nom d'utilisateur et de mot de passe est fournie à partir de la configuration du plan. + Le mot de passe utilisateur est créé en concaténant le nom d'utilisateur, un caractère deux-points (« : ») et le mot de passe. + Le passe utilisateur est codé en UTF-8, puis converti en une chaîne codée en base64. + Ce pass utilisateur codé en base64 est fourni dans l'en-tête « Authorization » au format suivant : Authorization : Basic \$1base64-\$1 encoded-user-pass 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//` 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 : + Utilise le schéma d'authentification de base avec ClientID et ClientSecret pour authentifier une demande auprès du TokenURL, le point de terminaison qui émet les jetons porteurs + Si vous fournissez les paramètres optionnels de portée, d'audience et de ressource, ils sont inclus dans la demande de jeton + Utilise le jeton d'accès renvoyé par le tokenURL pour authentifier votre requête HTTP + Stocke en toute sécurité le jeton d'actualisation renvoyé par le tokenURL pour les futures demandes de jetons 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:}` ou pour faire référence à une clé ` ${aws_SECRET::}` 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 du 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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Troubleshoot.html). ### 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, voir [Exécution de mises à jour sécurisées de Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/performing-safe-canary-upgrades.html). ### 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\$1SYNTHETICS\$1LOG\$1LEVEL : « 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 de Canary fournis par CloudWatch Synthetics correspond mieux à votre cas d'utilisation.