# Usar esquemas de canaries Esta seção fornece detalhes sobre cada um dos esquemas de canaries e as tarefas para as quais cada um é mais adequado. Os esquemas são fornecidos pelos seguintes tipos de canaries: **Topics** + [Monitorar pulsação](#CloudWatch_Synthetics_Canaries_Blueprints_Heartbeat) + [Canário da API](#CloudWatch_Synthetics_Canaries_Blueprints_API) + [Verificador de link quebrado](#CloudWatch_Synthetics_Canaries_Blueprints_Broken_Links) + [Esquema de monitoramento visual](#CloudWatch_Synthetics_Canaries_Blueprints_VisualTesting) + [Gravador do canário](#CloudWatch_Synthetics_Canaries_Blueprints_Recorder) + [Criador de fluxos de trabalho da GUI](#CloudWatch_Synthetics_Canaries_Blueprints_GUI_Workflow) + [Esquema de múltiplas verificações](#CloudWatch_Synthetics_Canaries_Blueprints_Multichecks_Blueprint) + [Criar um canário com esquema de múltiplas verificações](CloudWatch_Synthetics_Canaries_MultiCheck_Blueprint.md) Ao usar um esquema para criar um canário, conforme você preenche os campos no console do CloudWatch, a área **Script editor** (Editor de scripts) da página exibe o canário que você está criando como um script Node.js. Também é possível editar o canário nessa área para personalizá-lo ainda mais. ## Monitorar pulsação Os scripts de pulsação carregam a URL especificada e armazenam uma captura de tela da página e um arquivo HTTP (arquivo HAR). Eles também armazenam logs de URLs acessados. É possível usar os arquivos HAR para visualizar dados de performance detalhados sobre as páginas da web. Você pode analisar a lista de solicitações da web e detectar problemas de performance, como tempo de carregamento de um item. Se o canário usar a versão de runtime `syn-nodejs-puppeteer-3.1` ou posterior, você poderá usar o esquema de monitoramento de pulsação para monitorar várias URLs e ver o status, a duração, as capturas de telas associadas e o motivo da falha de cada URL no resumo de etapas do relatório de execução do canário. ## Canário da API Canaries de API podem testar as funções básicas de leitura e gravação de uma API REST. REST significa *representational state transfer* (transferência de estado representacional) e é um conjunto de regras que os desenvolvedores seguem ao criar uma API. Uma dessas regras determina que um link para um URL específico deve retornar uma parte dos dados. O canaries podem trabalhar com qualquer APIs e testar todos os tipos de funcionalidade. Cada canário pode fazer várias chamadas de API. Em canários que usam a versão de runtime `syn-nodejs-2.2` ou posterior, o esquema do canário da API é compatível com canários de várias etapas que monitoram suas APIs como etapas HTTP. É possível testar várias APIs em um único canário. Cada etapa é uma solicitação separada que pode acessar uma URL diferente, usar cabeçalhos diferentes e usar regras diferentes para definir se os cabeçalhos e os corpos das respostas serão capturados. Não capturarando cabeçalhos e corpo de resposta, você pode impedir que dados sigilosos sejam registrados. Cada solicitação de um canário da API consiste nas seguintes informações: + O *endpoint*, que é o URL solicitado. + O *método*, que é o tipo da solicitação enviada para o servidor. APIs REST oferecem suporte a operações GET (leitura), POST (gravação), PUT (atualização), PATCH (atualização) e DELETE (exclusão). + Os *cabeçalhos*, que fornecem informações para o cliente e o servidor. Eles são usados para autenticação e para fornecer informações sobre o conteúdo do corpo. Para obter uma lista de cabeçalhos válidos, consulte [Cabeçalhos HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers). + Os *dados* (ou o *corpo*) que contêm informações a serem enviadas para o servidor. Isso é usado somente para solicitações POST, PUT, PATCH ou DELETE. **nota** Os esquemas canários da API não são compatíveis com os runtimes do Playwright. O esquema do canário de API é compatível com os métodos GET e POST. Ao usar esse esquema, é necessário especificar cabeçalhos. Por exemplo, você pode especificar **Authorization** como uma **Chave** e os dados de autorização necessários como o **Valor** para essa chave. Se você estiver testando uma solicitação POST, especifique também o conteúdo a ser publicado no campo **Dados**. **Integração com o API Gateway** O esquema de API é integrado ao Amazon API Gateway. Isso permite selecionar uma API do API Gateway e um estágio da mesma conta e região da AWS como o canário ou carregar um modelo do Swagger do API Gateway para monitoramento de API entre contas e regiões. Então é possível escolher os detalhes restantes no console para criar o canário, em vez de inseri-los do zero. Para obter mais informações sobre o API Gateway, consulte [O que é o Amazon API Gateway?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) **Usar uma API privada** Você pode criar um canário que use uma API privada no Amazon API Gateway. Para obter mais informações, consulte [Como criar uma API privada no Amazon API Gateway?](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) ## Verificador de link quebrado O verificador de links quebrados coleta todos os links dentro da URL que você está testando usando `document.getElementsByTagName('a')`. Ele testa apenas até o número de links especificado, e a URL em si é considerada o primeiro link. Por exemplo, se você quiser verificar todos os links em uma página que contenha cinco links, deverá especificar para o canário seguir seis links. Os canários que verificam links quebrados criados usando o runtime `syn-nodejs-2.0-beta` ou posterior oferecem suporte aos seguintes recursos adicionais: + Fornece um relatório contendo os links verificados, o código de status, o motivo da falha (se houver) e as capturas de tela da página de origem e de destino. + Ao visualizar os resultados do canário, é possível filtrar para ver apenas os links quebrados e corrigir o link de acordo com o motivo da falha. + Essa versão obtém capturas de tela da página de origem anotada para cada link e destaca a âncora onde o link foi encontrado. Os componentes ocultos não são anotados. + É possível configurar essa versão para obter capturas de tela de páginas de origem e de destino, apenas páginas de origem ou apenas páginas de destino. + Essa versão corrige um problema na versão anterior em que o script do canário é interrompido após o primeiro link quebrado mesmo quando mais links são extraídos da primeira página. **nota** Os esquemas do verificador de links quebrados não são compatíveis com os runtimes do Playwright. Para atualizar um canário existente com `syn-1.0` para usar o novo runtime, é necessário excluir e recriar o canário. Atualizar um canário existente para o novo runtime não disponibiliza esses recursos. Um canário do verificador de links quebrados detecta os seguintes tipos de erros de link: + 404 Page Not Found (404 Página não encontrada) + Invalid Host Name (Nome de host inválido) + Bad URL (URL incorreto). Por exemplo, a URL não contém um colchete, tem barras extras ou usa um protocolo incorreto. + Invalid HTTP response code (Código de resposta HTTP inválido). + O servidor host gera respostas vazias sem conteúdo e sem código de resposta. + As solicitações HTTP constantemente atingem o tempo limite durante a execução do canário. + O host elimina conexões consistentemente porque ele está configurado incorretamente ou está muito ocupado. ## Esquema de monitoramento visual O esquema de monitoramento visual inclui código para comparar capturas de tela feitas durante uma execução do canário com capturas de tela feitas durante uma execução do canário de linha de base. Se a discrepância entre as duas capturas de tela estiver além de uma porcentagem limite, o canário falhará. O monitoramento visual é compatível com canaries que executam **syn-puppeteer-node-3.2** e posterior. Atualmente, não é compatível com canários que executam Python e Selenium, ou que usam runtimes do Playwright. O esquema de monitoramento visual inclui a seguinte linha de código no script do canário do esquema padrão, que permite o monitoramento visual. ``` syntheticsConfiguration.withVisualCompareWithBaseRun(true); ``` A primeira vez que o canário é executado corretamente após essa linha ser adicionada ao script, ele usa as capturas de tela obtidas durante a execução como linha de base para comparação. Após a primeira execução do canário, é possível usar o console do CloudWatch para editar o canário para fazer qualquer um destes procedimentos: + Defina a próxima execução do canário como a nova linha de base. + Estabeleça limites na captura de tela de linha de base atual para designar as áreas da captura de tela que deverão ser ignoradas durante comparações visuais. + Remova uma captura de tela que não será usada para monitoramento visual. Para obter mais informações sobre como usar o console do CloudWatch para editar um canário, consulte [Editar ou excluir um canário](synthetics_canaries_deletion.md). Também é possível alterar a execução do canário que é usada como linha de base usando os parâmetros ` nextrun` ou `lastrun` ou especificando um ID de execução do canário na API [UpdateCanary](https://docs.aws.amazon.com/AmazonSynthetics/latest/APIReference/API_UpdateCanary.html). Ao usar o esquema de monitoramento visual, insira a URL onde deseja que a captura de tela seja feita e especifique um limite de diferença em porcentagem. Após a execução da linha de base, as execuções futuras do canário que detectam uma diferença visual maior do que esse limite desencadeiam uma falha do canário. Após a execução da linha de base, também é possível editar o canário para “traçar” limites na captura de tela da linha de base que deseja ignorar durante o monitoramento visual. O recurso de monitoramento visual é desenvolvido pelo toolkit de software de código aberto ImageMagick. Para obter mais informações, consulte [ImageMagick](https://imagemagick.org/index.php). ## Gravador do canário Com o esquema do gravador do canário, é possível usar o CloudWatch Synthetics Recorder para registrar suas ações de clicar e digitar em um site e gerar automaticamente um script Node.js que pode ser usado para criar um canário que segue as mesmas etapas. O CloudWatch Synthetics Recorder é uma extensão do Google Chrome fornecida pela Amazon. O gravador de canários não é compatível com canários que usam o runtime do Playwright. **Créditos**: o CloudWatch Synthetics Recorder é baseado no [ Headless recorder ](https://github.com/checkly/headless-recorder). Para obter mais informações, consulte [Usar o CloudWatch Synthetics Recorder para Google Chrome](CloudWatch_Synthetics_Canaries_Recorder.md). ## Criador de fluxos de trabalho da GUI O esquema criador de fluxos de trabalho da GUI verifica se as ações podem ser executadas em sua página da Web. Por exemplo, se você tiver uma página da Web com um formulário de login, o canário poderá preencher os campos de usuário e senha e enviá-lo para verificar se a página da Web está funcionando corretamente. Ao usar um esquema para criar esse tipo de canário, especifique as ações a serem executadas pelo canário na página da Web. As ações que podem ser utilizadas são as seguintes: + **Clicar**: seleciona o elemento especificado e simula um usuário clicando ou escolhendo o elemento. Para especificar o elemento em um script Node.js, use `[id=]` ou ` a[class=]`. Para especificar o elemento em um script Python .js, use `xpath //*[@id=]` ou ` //*[@class=]`. + **Verificar seletor**: verifica se o elemento especificado existe na página da Web. Esse teste é útil para verificar se uma ação anterior faz com que os elementos corretos preencham a página. Para especificar o elemento a ser verificado em um script Node.js, use `[id=]` ou ` a[class=]`. Para especificar o elemento a ser verificado em um script Python .js, use `xpath //*[@id=]` ou `//*[class=]`. + **Verificar texto**: verifica se a string especificada está contida no elemento de destino. Esse teste é útil para verificar se uma ação anterior fez o texto correto ser exibido. Para especificar o elemento em um script do Node.js, use um formato como ` div[@id=]//h1` porque essa ação usa a função `waitForXPath` no Puppeteer. Para especificar o elemento em um script Python, use o formato xpath como ` //*[@id=] ` ou //\$1[@class=] porque esta ação usa a função `implicitly_wait` no Selenium. + **Texto de entrada**: grava o texto especificado no elemento de destino. Para especificar o elemento a ser verificado em um script Node.js, use `[id=]` ou ` a[class=]`. Para especificar o elemento a ser verificado em um script Python .js, use `xpath //*[@id=]` ou `//*[@class=]`. + **Clicar com a navegação**: aguarda a página inteira ser carregada depois de escolher o elemento especificado. Isso é mais útil quando é necessário recarregar a página. Para especificar o elemento em um script Node.js, use `[id=]` ou ` a[class=]`. Para especificar o elemento em um script Python .js, use `xpath //*[@id=]` ou ` //*[@class=]`. Por exemplo, o esquema a seguir usa Node.js. Ele clica em **firstButton** no URL especificado, verifica se o seletor esperado com o texto esperado é exibido, insere o nome `Test_Customer` no campo **Nome**, clica no botão **Login** e confirma se o login foi bem-sucedido verificando o texto de **Boas-vindas** na página seguinte. ![\[A página de criação do canário no console, com campos preenchidos para o esquema de fluxo de trabalho da GUI.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/canary_create_gui_workflow.PNG) Os canários de fluxo de trabalho GUI que usam os tempos de execução a seguir também fornecem um resumo das etapas executadas para cada execução do canário. É possível usar as capturas de tela e a mensagem de erro associadas a cada etapa para encontrar a causa raiz da falha. + `syn-nodejs-2.0` ou posterior + `syn-python-selenium-1.0` ou posterior ## Esquema de múltiplas verificações O esquema de múltiplas verificações simplifica a criação de canários. Ele reduz custos porque usa uma configuração JSON simples que fornece funcionalidade imediata para a execução de verificações HTTP, DNS, SSL e TCP. Você pode configurar até 10 verificações. Configure cada verificação como uma etapa numerada, executada em sequência, o que permite uma compreensão clara do fluxo canário. Compatível com esquemas de múltiplas verificações: + Solicitações Basic HTTP, solicitações TCP, validação de registros DNS e monitoramento de certificados SSL + Métodos de autenticação HTTP, como Basic, API Key, OAuth e Sigv4 integrados ao Secrets Manager + Asserções para cada verificação Para obter mais informações, consulte [Criar um canário](CloudWatch_Synthetics_Canaries_Create.md). # Criar um canário com esquema de múltiplas verificações O esquema de múltiplas verificações do Amazon CloudWatch Synthetics ajuda a criar um canário do Synthetics por meio de uma configuração JSON simples. Você pode economizar custos empacotando até 10 tipos diferentes de verificações HTTP/DNS/SSL/TCP feitas em etapas sequenciais. Cada verificação inclui asserções que fornecem uma validação básica em relação ao resultado da verificação. Os canários de múltiplas verificações são projetados para casos de uso simples que exigem apenas verificações básicas sem usar um navegador sem periféricos/sem interface gráfica. Para casos de uso mais complexos, revise os outros tipos de canários que o Amazon CloudWatch Synthetics oferece. **Topics** + [Pré-requisitos](#CloudWatch_Synthetics_MultiCheck_Prerequisites) + [Limitações](#CloudWatch_Synthetics_MultiCheck_Limitations) + [Estrutura de empacotamento, esquema JSON e definições de configuração](#CloudWatch_Synthetics_MultiCheck_Packaging) + [Criar um canário de múltiplas verificações no Console de gerenciamento da AWS](#CloudWatch_Synthetics_MultiCheck_Console) + [Criar um canário de múltiplas verificações usando as APIs do AWS Synthetics](#CloudWatch_Synthetics_MultiCheck_API) + [Criar um canário de múltiplas verificações no CloudFormation](#CloudWatch_Synthetics_MultiCheck_CloudFormation) + [Configuração da autenticação](#CloudWatch_Synthetics_MultiCheck_Authentication) + [Solução de problemas](#CloudWatch_Synthetics_MultiCheck_Troubleshooting) ## Pré-requisitos + É necessário usar o syn-nodejs-3.0\$1 para criar um canários de múltiplas verificações + Ao usar a configuração do Authentication e do Secrets Manager, você deve garantir que o canário [ExecutionRoleArn](https://docs.aws.amazon.com/AmazonSynthetics/latest/APIReference/API_CreateCanary.html) tenha as permissões de acesso a esses segredos + Ao usar o Authentication para Sigv4, você deve garantir que o canário [ExecutionRoleArn](https://docs.aws.amazon.com/AmazonSynthetics/latest/APIReference/API_CreateCanary.html) tenha as permissões de acesso ao perfil correspondente ## Limitações + As respostas HTTP não podem ter mais de 1 MB + Máximo de 10 variáveis definidas. + Ao usar o JSON RFC, o Checks JSON pode ter campos duplicados, porém apenas o último campo sequencial será usado + No Console de gerenciamento da AWS, um canário de múltiplas verificações exibirá, por padrão, métricas de etapa de múltiplas verificações para identificar prontamente a disponibilidade de cada verificação. Quando as verificações são removidas, elas podem continuar a ser mostradas no gráfico de disponibilidade até estarem inativas por, pelo menos, 3 horas ## Estrutura de empacotamento, esquema JSON e definições de configuração A configuração do JSON Checks que será usada para o canário deve será denominada ` blueprint-config.json`. A configuração deve seguir o [esquema](https://github.com/aws-samples/synthetics-canary-local-debugging-sample/tree/main) e as instruções em [Escrever uma configuração JSON para o esquema de múltiplas verificações do Node.js](CloudWatch_Synthetics_WritingCanary_Multichecks.md). Compacte o `blueprint-config.json` em um arquivo ZIP e forneça-o em um dos seguintes fluxos de trabalho de criação. Quando existe uma configuração `synthetics.json`, ela também é compactada no mesmo arquivo ZIP. O exemplo a seguir é de arquivo denominado `multi-checks.zip`. ``` multi-checks.zip ├── blueprint-config.json └── synthetics.json ``` ## Criar um canário de múltiplas verificações no Console de gerenciamento da AWS 1. Abra o console do Amazon CloudWatch Synthetics. 1. Selecione **Create Canary** (Criar canário). 1. Em **Usar um esquema**, escolha **múltiplas verificações**. Em **Configurar verificações**, você verá duas guias: **Verificações** e **Configuração do canário**. 1. Selecione a versão do runtime **syn-nodejs-3.0** ou posterior. 1. Siga o procedimento em [Escrever uma configuração JSON para o esquema de múltiplas verificações do Node.js](CloudWatch_Synthetics_WritingCanary_Multichecks.md) para descrever a verificação que você deseja realizar. Como alternativa, o console fornece uma configuração JSON padrão que pode servir de base. 1. Selecione **Create Canary** (Criar canário). ## Criar um canário de múltiplas verificações usando as APIs do AWS Synthetics Use a API `CreateCanary` e, no parâmetro `Code`, forneça o campo/valor `BlueprintTypes="multi-checks"` em vez de ` Handler`. Quando ambos `BlueprintTypes` e `Handler` são especificados, uma `ValidationException` é exibida. A versão do runtime fornecido deve ser `syn-nodejs-3.0` ou posterior. ``` 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" \ ... ``` ## Criar um canário de múltiplas verificações no CloudFormation No modelo CloudFormation de um canário de múltiplas verificações, no `Code` parâmetro, forneça o campo/valor `BlueprintTypes="multi-checks"` em vez de ` Handler`. Quando ambos `BlueprintTypes` e `Handler` são especificados, uma `ValidationException` é exibida. A versão do runtime deve ser `syn-nodejs-3.0 or later`. Um exemplo de modelo: ``` 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"] ... ``` ## Configuração da autenticação Quando o canário faz solicitações HTTP a um endpoint autenticado, você pode configurar as etapas do canário do esquema para usar um dos quatro tipos de autenticação: Basic, API Key, OAuth Client Credentials e SigV4. Em vez de configurar você mesmo os cabeçalhos de solicitação, é possível especificar um tipo de autenticação na definição do esquema, e o Synthetics seguirá o tipo de autenticação especificado para preencher os componentes da solicitação HTTP com as informações de autenticação fornecidas. Você especifica um tipo de autenticação na etapa do esquema com a seção Autenticação. Você especifica o esquema de autenticação que quer usar, as propriedades requeridas para o esquema de autenticação escolhido, e o Synthetics usa as informações fornecidas para criar um cabeçalho de autenticação para a solicitação HTTP. Como manter segredos (como senhas ou chaves de API) armazenados em texto simples é um problema de segurança, o Synthetics é compatível com a integração com o AWS Secrets Manager. Quando quiser autenticar uma solicitação HTTP em um canário de esquema do Synthetics, consulte o segredo que contém suas informações de autenticação, e o Synthetics recuperará o segredo e o colocará em cache no canário. Essa abordagem fornece segredos ao Synthetics e, ao mesmo tempo, os mantém armazenados com segurança, sem especificá-los em texto simples na configuração do esquema. Para obter mais informações sobre o AWS Secrets Manager, consulte [O que é AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) ### Autenticação básica O Synthetics implementa o esquema de autenticação Basic HTTP definido na RFC 7617. O processo funciona da seguinte maneira: + Um par nome de usuário e senha é fornecido a partir da configuração do esquema. + A senha de usuário é criada concatenando o nome de usuário, um único caractere dois pontos (“:”) e a senha. + O par usuário/senha é em uma string codificada em UTF-8, depois convertida em base64. + Esse usuário/senha codificado em base64 é fornecido no cabeçalho “Autorização” com o seguinte formato: Autorização: Basic \$1base64-encoded-user-pass\$1 Por exemplo, se o agente do usuário quiser enviar o ID de usuário “Aladin” e a senha “abra-te sésamo”, ele usará o seguinte campo de cabeçalho: Autorização: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Exemplo de configuração: ``` "Authentication": { "type": "BASIC", "username": MY_USERNAME, // Required "password": MY_PASSWORD // Required } ``` ### Autenticação de chave de API Você pode fornecer uma chave de API para autenticar as solicitações HTTP. Quando você usa a autenticação de chave de API, a chave de API fornecida é colocada no cabeçalho HTTP “X-API-Key”. Se você tiver um recurso personalizado que procura cabeçalhos de chave de API em outro cabeçalho, terá a opção de especificar outro nome de cabeçalho no qual o Synthetics deverá colocar a chave de API. Exemplo de configuração: ``` "Authentication": { "type": "API_KEY", "apiKey": S0A1M2P3L4E5, // Required "header": X-Specific-Header // Optional, defaults to "X-API-Key" } ``` ### Autenticação SigV4 AWS SigV4 (Signature Version 4) é o protocolo de assinatura da AWS para adição de informações de autenticação às solicitações de API da AWS. Para fazer uma solicitação autenticada por SigV4, especifique a região e o serviço aos quais as solicitações são feitas, bem como um ARN (nome do recurso da AWS) do perfil do IAM que você deseja que o canário assuma ao fazer essa solicitação do SigV4. O Synthetics assume o perfil do IAM fornecido no roleArn e usa-o para autenticar a solicitação de API da AWS. Exemplo de configuração: ``` "Authentication": { "type": "SIGV4", "region": us-west-2, // Required "service": s3, // Required "roleArn": arn:AWS:iam:12345678912:role/SampleRole // Required } ``` #### Considerações sobre a autenticação SigV4 Para que o Synthetics assuma o perfil fornecido na seção de autenticação do SigV4, a política de confiança anexada a esse perfil deve ser configurada para permitir que o canário assuma o roleArn fornecido. A entidade principal da AWS em que você precisa confiar é o perfil que o canário assumiu por meio do AWS STS. O formato utilizado é o do ARN ` aws:sts::{account_running_the_canary}:assumed-role//`: Por exemplo, se você tiver um canário em execução na conta 0123456789012, denominado test-canary, e o perfil que ele assumiu for denominado canary-assume-role, a política de confiança precisará incluir essa instrução para que o canário assuma corretamente o roleArn para a autenticação SigV4: ``` { "Effect": "Allow", "Principal": { "AWS": "arn:AWS:sts::123456789012:assumed-role/test-canary/" }, "Action": "sts:AssumeRole" } ``` ### Credenciais de cliente OAuth O Synthetics implementa o tipo de concessão OAuth Client Credentials conforme definido na seção 4.4 da RFC 6479. Se quiser fazer uma solicitação HTTP a um endpoint autenticado com um token ao portador emitido por um endpoint de token OAuth, o Synthetics pode solicitar e gerenciar um token de portador para você. Quando você usa o esquema OAuth, o Synthetics executa as seguintes etapas: + Usa o esquema de autenticação Basic com clientId e clientSecret para autenticar uma solicitação à tokenUrl, o endpoint que emite tokens ao portador + Se você fornecer os parâmetros opcionais de escopo, público e recurso, eles serão incluídos na solicitação de token + Usa o token de acesso retornado pela tokenUrl para autenticar a solicitação HTTP + Armazena com segurança o token de atualização retornado da tokenUrl para futuras solicitações de token Exemplo de configuração: ``` "Authentication": { "type": "OAUTH_CLIENT_CREDENTIALS", "tokenUrl": ..., // Required "clientId": ..., // Required "clientSecret": ..., // Required "scope": ..., // Optional "audience": ..., // Optional "resource": ..., // Optional } ``` #### Considerações sobre o OAuth O Synthetics atualiza os tokens OAuth quando uma resposta 401 ou 407 é retornada. ### AWS Secrets ManagerIntegração do Para evitar o armazenamento de valores secretos (como senhas ou chaves de API) em texto simples, o Synthetics fornece uma integração com o AWS Secrets Manager. Você pode referenciar um valor secreto inteiro na configuração do esquema com o formato ` ${aws_SECRET:}` ou referenciar uma chave ` ${aws_SECRET::}` específica. Por exemplo, se você tiver um segredo denominado login/basic-auth-credentials, o armazenamento de um nome de usuário e senha com a seguinte estrutura JSON: ``` { "username": "Aladdin", "password": "open sesame" } ``` Você pode referenciar o nome de usuário e senha na configuração do esquema do seguinte modo, e o Synthetics recuperará o valor do segredo e usará suas chaves para autenticar a solicitação: ``` "Authentication": { "type": "BASIC", "username": ${AWS_SECRET:login/basic-auth-credentials:username}, "password": ${AWS_SECRET:login/basic-auth-credentials:password} } ``` Para permitir que o Synthetics recupere o segredo especificado, o ARN do perfil assumido pelo canário precisa ter as permissões secretsManager:GetSecretValue. Se o segredo for criptografado com uma chave gerenciada pelo cliente em vez da chave gerenciada pela AWS AWS/secretsmanager, o perfil também precisará das permissões kms:Decrypt para essa chave. Exemplo de permissões: ``` { "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" } ] } ``` ## Solução de problemas ### Falhas comuns da solução de problemas O código subjacente do esquema de múltiplas verificações é escrito em Typescript. Consulte a página de solução de problemas do canário para ver as falhas comuns: [Solução de problemas de um canário com falha](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Troubleshoot.html). ### Erros de sintaxe de configuração de verificação JSON Quando houver algum erro de sintaxe relacionado à configuração da verificação JSON do canário, o Console de gerenciamento da AWS apresentará um motivo de falha quando você tentar criar o canário. Se você criar um canário usando uma API ou o CloudFormation, verá a falha quando o canário for executado a primeira vez. Para um canário de múltiplas verificações, é recomendável usar o fluxo de trabalho de atualizações seguras do canário. Para saber mais, consulte [Execução de atualizações seguras para o canário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/performing-safe-canary-upgrades.html). ### Falhas de rede ou de tempo limite esgotado Para falhas intermitentes ou consistentes relacionadas a tempos limite esgotados, falhas de conexão de rede (por exemplo, ENOTFOUND, ECONNRESET), considere ativar os logs ` DEBUG` para que a próxima execução forneça mais detalhes sobre por que as verificações estão apresentando falhas. Para isso, forneça a variável de ambiente CW\$1SYNTHETICS\$1LOG\$1LEVEL: “DEBUG”. Se ainda houver falhas que você não consegue depurar, considere entrar em contato com o AWS Support ou verificar se algum dos outros tipos de canário fornecidos pelo CloudWatch Synthetics é mais adequado ao seu caso de uso.