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 un blueprint con controlli multipli canary

Il blueprint multi check di Amazon CloudWatch Synthetics ti aiuta a creare un canary Synthetics fornendo una semplice configurazione JSON. Puoi risparmiare sui costi raggruppando fino a 10 diversi tipi di controlli in modo sequenziale basato su fasi. HTTP/DNS/SSL/TCP Ogni controllo include asserzioni che forniscono una verifica di base rispetto al risultato di un controllo.

Multi check canaries è progettato 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 canarino forniti da Amazon CloudWatch Synthetics.

Prerequisiti

Limitazioni

Struttura del pacchetto, schema JSON e impostazioni di configurazione

La configurazione JSON Checks che verrà utilizzata per il canarino 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 Node.js multi Checks

Comprimili blueprint-config.json in un file ZIP e inseriscili in uno dei seguenti flussi di lavoro di creazione. Quando esiste 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 canarino a controllo multiplo in Console di gestione AWS

Creazione di un canarino a controllo multiplo usando Synthetics AWS APIs

Usa l'CreateCanaryAPI e, all'interno del Code parametro, fornisci field/value BlueprintTypes="multi-checks" invece di. Handler Quando Handler vengono specificati entrambi BlueprintTypes e, ValidationException viene visualizzato un. La versione di runtime fornita deve esseresyn-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" \
    ...
    

Creazione di un canarino a controllo multiplo in CloudFormation

Nel tuo 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 invia richieste HTTP a un endpoint autenticato, puoi configurare i passaggi del tuo blueprint canary in modo da utilizzare uno dei quattro tipi di autenticazione: Basic, API Key, Client Credentials e SigV4. OAuth Invece di impostare personalmente le intestazioni delle richieste, è possibile specificare un tipo di autenticazione nella definizione del blueprint e Synthetics segue il tipo di autenticazione specificato per popolare i componenti della richiesta HTTP con le informazioni di autenticazione fornite.

È possibile specificare un tipo di autenticazione nella fase del progetto con la sezione Autenticazione. Specificate lo schema di autenticazione che desiderate utilizzare, le proprietà richieste per lo schema di autenticazione scelto e Synthetics utilizza le informazioni fornite per costruire un'intestazione di autenticazione per la vostra richiesta HTTP.

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

Per ulteriori informazioni su Gestione dei segreti AWS, consulta What is? Gestione dei segreti AWS

Autenticazione Base

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

Ad esempio, se l'agente utente desidera inviare l'ID utente «Aladdin» e la password «open sesame», utilizza il seguente campo di intestazione: Authorization: Basic ftZq== QWxh ZGRpbjpvc GVu IHNlc2

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 tramite chiave API, la chiave API fornita viene inserita nell'intestazione HTTP «X-API-Key». Se disponi di una risorsa personalizzata che cerca le intestazioni delle chiavi API in un'intestazione diversa da 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 richiesta autenticata con SigV4, devi specificare la regione e il servizio a cui stai effettuando le richieste, oltre a un ARN (AWS Resource Name) che identifichi un ruolo IAM che desideri che il canarino assuma quando effettua questa richiesta SigV4. Synthetics assume il ruolo IAM fornito in 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 su SIGv4

Affinché Synthetics assuma il ruolo che hai fornito nella sezione di autenticazione SigV4, la politica di fiducia allegata a quel ruolo deve essere configurata per consentire al canarino di assumere il ROLearn fornito. Il AWS principale 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 canarino in esecuzione nell'account 0123456789012, chiamato test-canary, e il ruolo che ha assunto è stato nominato canary-assume-role, la policy di fiducia deve includere questa dichiarazione affinché il canary assuma correttamente l'autenticazione ROLearn for SigV4:

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

OAuth credenziali del client

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

Configurazione di esempio:

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

OAuth considerazioni

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

Gestione dei segreti AWS integrazione

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

Ad esempio, se hai un segreto chiamato login/basic-auth-credentials, memorizzi un nome utente e una password con la seguente struttura JSON:

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

È possibile fare riferimento al nome utente e alla password nella configurazione del blueprint come segue e Synthetics gestisce il recupero del valore segreto e l'utilizzo delle sue chiavi per autenticare la 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 avere SecretsManager: permessi. GetSecretValue Se il segreto viene crittografato utilizzando una chiave gestita dal cliente anziché la chiave gestita AWS/secretsmanager, sono necessarie anche le autorizzazioni di AWS decriptazione per quella chiave. kms:

Autorizzazioni di esempio:

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

Risoluzione dei problemi

Errori comuni di risoluzione dei problemi

Il codice sottostante per il blueprint a controllo multiplo è scritto in Typescript. Consulta la pagina di risoluzione dei problemi di Canary per gli errori più comuni: Risoluzione dei problemi di un canarino fallito.

Errori di sintassi di configurazione di JSON check

In caso di errori sintattici relativi alla configurazione di controllo JSON di Canary, Console di gestione AWS verrà fornito un motivo di errore quando si tenta di creare il canarino. Se state creando un canarino utilizzando un'API oppure CloudFormation, vedrete l'errore quando il canarino viene eseguito per la prima volta. Si consiglia di utilizzare il flusso di lavoro Safe Canary Updates per Multi-Check Canary. Per ulteriori informazioni, vedere Esecuzione degli aggiornamenti di safe canary.

Errori di rete o di timeout

Per eventuali errori intermittenti o costanti legati ai timeout e alle connessioni di rete (ad esempio, ENOTFOUND, ECONNRESET), valuta la possibilità di attivare i DEBUG log in modo che l'esecuzione seguente fornisca maggiori dettagli aggiuntivi sul motivo dell'esito negativo dei controlli. A tale scopo, fornite la variabile d'ambiente CW_SYNTHETICS_LOG_LEVEL: «DEBUG».

Se ci sono ancora errori di cui non riesci a eseguire il debug, prova a contattare AWS Support o a verificare se uno degli altri tipi di Canary forniti da Synthetics si avvicina di più al tuo caso d' CloudWatch uso.