Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Creazione di controlli multipli blueprint canary

Il blueprint a più controlli di Amazon CloudWatch Synthetics ti aiuta a creare un canarino Synthetics fornendo una semplice configurazione JSON. Puoi risparmiare sui costi raggruppando fino a 10 diversi tipi di controlli in modo sequenziale e graduale. HTTP/DNS/SSL/TCP Ogni controllo include asserzioni che forniscono una verifica di base rispetto al risultato del controllo.

I Multi Checks Canaries sono progettati per casi d'uso semplici che richiedono solo controlli di base senza un browser headless. Per casi d'uso più complessi, consulta gli altri tipi di canary forniti da Amazon Synthetics. CloudWatch

Prerequisiti

Limitazioni

Struttura del pacchetto, schema JSON e impostazioni di configurazione

La configurazione JSON Checks che verrà utilizzata per il canary deve essere denominata. blueprint-config.json La configurazione deve seguire lo schema e seguire le istruzioni riportate di seguito. Scrittura di una configurazione JSON per il blueprint Multi Checks Node.js

Comprimetelo blueprint-config.json in un file ZIP e inseritelo in uno dei seguenti flussi di lavoro di creazione. Quando c'è una synthetics.json configurazione, anche questa viene compressa nello stesso file ZIP. Di seguito è riportato un esempio di file zip chiamatomulti-checks.zip.

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

Creazione di un canary con controllo multiplo in Console di gestione AWS

Creazione di un canarino a controllo multiplo utilizzando AWS API Synthetics

Usa l'CreateCanaryAPI e, all'interno del Code parametro, fornisci invece di field/value BlueprintTypes="multi-checks". Handler Quando Handler vengono specificati entrambi BlueprintTypes e, ValidationException viene visualizzato un. La versione di runtime fornita deve essere syn-nodejs-3.0 o successiva.

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

Creazione di un canary con check-in multiplo CloudFormation

Nel CloudFormation modello per un canarino a controllo multiplo, all'interno del Code parametro, fornisci invece di. field/value BlueprintTypes="multi-checks" Handler Quando Handler vengono specificati entrambi BlueprintTypes e, ValidationException viene visualizzato un. La versione di runtime fornita deve esseresyn-nodejs-3.0 or later.

Un modello di esempio:

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

Configurazione di autenticazione

Quando il tuo canary effettua richieste HTTP a un endpoint autenticato, puoi configurare i passaggi del tuo blueprint canary per utilizzare uno dei quattro tipi di autenticazione: Basic, API Key, OAuth Client Credentials e SIGv4. Anziché configurare tu stesso le intestazioni delle richieste, puoi specificare un tipo di autenticazione nella definizione del blueprint. Synthetics segue il tipo di autenticazione specificato per popolare i componenti della richiesta HTTP con le informazioni di autenticazione fornite.

Specificate un tipo di autenticazione nella fase del progetto nella sezione Autenticazione. Si specifica lo schema di autenticazione da utilizzare, le proprietà richieste per lo schema di autenticazione scelto e Synthetics utilizza le informazioni fornite per creare un'intestazione di autenticazione per la richiesta HTTP.

Poiché l'archiviazione dei segreti (come password o chiavi API) in testo normale è un problema di sicurezza, Synthetics supporta l'integrazione con. AWS Secrets Manager Quando desideri autenticare una richiesta HTTP in un blueprint canary di Synthetics, puoi fare riferimento al segreto che memorizza le tue informazioni di autenticazione e Synthetics si occuperà del recupero del segreto e della memorizzazione nella cache del tuo canarino. Questo approccio fornisce i segreti a Synthetics mantenendo i segreti archiviati in modo sicuro, senza specificarli in testo normale nella configurazione del blueprint.

Per ulteriori informazioni su AWS Secrets Manager, vedi Che cos'è? AWS Secrets Manager

Autenticazione di base

Synthetics implementa lo schema di autenticazione HTTP di base definito in RFC 7617. Di seguito è riportato il procedimento:

Ad esempio, se lo user agent desidera inviare l'ID utente «Aladdin» e la password «open sesame», utilizza il seguente campo di intestazione: Authorization: Basic == QWxhZGRpbjpvcGVuIHNlc2FtZQ

Configurazione di esempio:

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

Autenticazione con chiave API

Puoi fornire una chiave API per autenticare le tue richieste HTTP. Quando utilizzi l'autenticazione con chiave API, la chiave API fornita viene inserita nell'intestazione "X-API-Key" HTTP. Se hai una risorsa personalizzata che cerca le intestazioni delle chiavi API in un'intestazione oltre a questa, puoi facoltativamente specificare un nome di intestazione diverso in cui Synthetics inserisca la chiave API.

Configurazione di esempio:

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

Autenticazione SIGv4

AWS Sigv4 (Signature Version 4) è il protocollo di AWS firma per aggiungere informazioni di autenticazione alle richieste API. AWS Per effettuare una SigV4-authenticated richiesta, è necessario specificare la regione e il servizio a cui si stanno effettuando le richieste, nonché un ARN (AWS Resource Name) che identifichi il ruolo IAM che si desidera che il canarino assuma quando si effettua questa richiesta SIGv4. Synthetics assume il ruolo IAM fornito nel ROLearn e lo utilizza per autenticare la richiesta API. AWS

Configurazione di esempio:

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

Considerazioni sul SIGv4

Affinché Synthetics assuma il ruolo fornito nella sezione sull'autenticazione Sigv4, la politica di fiducia associata a quel ruolo deve essere configurata per consentire al canarino di assumere il ROLearn fornito. Il AWS principio di cui ti devi fidare è il ruolo che il tuo canarino ha assunto. AWS STS Prende il formato aws:sts::{account_running_the_canary}:assumed-role/<canary_name>/<assumed_role_name> arn:.

Ad esempio, se hai un canary in esecuzione nell'account 0123456789012, denominato test-canary, e il ruolo che ha assunto è stato denominato canary-assume-role, allora la policy di fiducia deve includere questa dichiarazione affinché il canarino assuma correttamente l'autenticazione ROLearn per Sigv4:

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

Credenziali del client OAuth

Synthetics implementa il tipo di concessione OAuth Client Credentials come definito nella Sezione 4.4 della RFC 6479. Se desideri effettuare una richiesta HTTP a un endpoint autenticato con un token al portatore emesso da un endpoint con token OAuth, Synthetics può richiedere e gestire un token al portatore per tuo conto. Quando si utilizza lo schema OAuth, Synthetics esegue i seguenti passaggi:

Configurazione di esempio:

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

Considerazioni su OAuth

Synthetics aggiorna i token OAuth quando viene restituita una risposta 401 o 407.

AWS Secrets Manager integrazione

Per evitare di archiviare valori segreti (come password o chiavi API) in testo semplice, Synthetics fornisce un'integrazione con. AWS Secrets Manager Puoi fare riferimento a un intero valore segreto nella configurazione del tuo blueprint con il formato ${AWS_SECRET:<secret_name>} o fare riferimento a una chiave particolare. ${AWS_SECRET:<secret_name>:<secret_key>}

Ad esempio, se disponi di un segreto denominato login/basic -auth-credentials, memorizza un nome utente e una password con la seguente struttura JSON:

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

Puoi fare riferimento al nome utente e alla password nella configurazione del blueprint come segue e Synthetics si occupa del recupero del valore segreto e dell'utilizzo delle relative chiavi per autenticare la tua richiesta:

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

Per consentire a Synthetics di recuperare il segreto specificato, il ruolo ARN assunto dal canarino deve disporre di entrambe le autorizzazioni. secretsmanager:GetSecretValue secretsmanager:DescribeSecret Se il segreto è crittografato utilizzando una chiave gestita dal cliente anziché la chiave gestita AWS/secretsmanager, sono necessarie anche le AWS autorizzazioni KMS:Decrypt per quella chiave.

Autorizzazioni di esempio:

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

Risoluzione dei problemi

Errori comuni nella risoluzione dei problemi

Il codice sottostante per Multi Check Blueprint è scritto in Typescript. Consulta la pagina di risoluzione dei problemi di Canary per gli errori più comuni: Risoluzione dei problemi di un canary fallito. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Troubleshoot.html

Errori di sintassi di configurazione JSON Check

In caso di errori sintattici relativi alla configurazione del controllo JSON di Canary, Console di gestione AWS verrà fornito un motivo dell'errore quando si tenta di creare il canary. Se state creando un canary usando un'API o CloudFormation, vedrete l'errore quando il canary viene eseguito per la prima volta. Si consiglia di utilizzare il flusso di lavoro Safe Canary Updates per il controllo multiplo di canary. Per ulteriori informazioni, consulta Esecuzione degli aggiornamenti sicuri di Canary.

Errori di rete o di timeout

Per qualsiasi errore intermittente o costante legato ai timeout, agli errori della connessione di rete (ad esempio, ENOTFOUND, ECONNRESET), valuta la possibilità di attivare i DEBUG log in modo che la seguente esecuzione fornisca ulteriori dettagli sul motivo per cui i controlli non riescono. A tale scopo, fornisci la variabile di ambiente CW_SYNTHETICS_LOG_LEVEL: «DEBUG».

Se ci sono ancora errori di cui non riesci a eseguire il debug, valuta la possibilità di contattare l' AWS assistenza o di verificare se uno degli altri tipi di Canary forniti da Synthetics corrisponde maggiormente al tuo caso d'uso. CloudWatch