As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Defina e configure alarmes em Detecção e Resposta a Incidentes
AWS trabalha com você para definir métricas e alarmes para fornecer visibilidade do desempenho de seus aplicativos e de sua AWS infraestrutura subjacente. Solicitamos que os alarmes sigam os seguintes critérios ao definir e configurar limites:
+ Os alarmes só entram no estado “Alarme” quando há um impacto crítico na carga de trabalho monitorada (perda de receita ou degradação da experiência do cliente que reduz significativamente o desempenho) que requer atenção imediata do operador.
+ Os alarmes também devem envolver seus resolvedores especificados para a carga de trabalho ao mesmo tempo ou antes de engajar a equipe de gerenciamento de incidentes. Os engenheiros de gerenciamento de incidentes devem colaborar com seus solucionadores específicos no processo de mitigação, não servir como respondedores de primeira linha e depois encaminhar até você.
+ Os limites de alarme devem ser definidos com um limite e uma duração apropriados para que, sempre que um alarme disparar, uma investigação ocorra. Se um alarme estiver oscilando entre o estado “Alarme” e “OK”, um impacto suficiente está ocorrendo para garantir a resposta e a atenção do operador.
**Tipos de alarmes**:
+ Alarmes que retratam o nível de impacto nos negócios e transmitem informações relevantes para uma simples detecção de falhas.
+ CloudWatch Canários da Amazônia. [Para obter mais informações, consulte [Canaries and X-Ray tracing e X-Ray](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html).](https://aws.amazon.com/xray/)
+ Alarme agregado (monitoramento de dependências)
A tabela a seguir fornece exemplos de alarmes, todos usando o sistema de CloudWatch monitoramento.
****
| Nome da métrica//Limite de alarme | ARN do alarme ou ID do recurso | Se esse alarme disparar | Se contratado, crie um Premium Support Case para esses serviços |
| --- | --- | --- | --- |
| Erros de API/ Nº de erros >= 10 para 10 pontos de dados | arn:aws:cloudwatch:us-west- 2:000000000000:alarm:E2 Lambda - Erros MPmim | Redução de tíquetes para a equipe de administradores de banco de dados (DBA) | Lambda, API Gateway |
| ServiceUnavailable (Código de status Http 503) Nº de erros >=3 para 10 pontos de dados (clientes diferentes) em uma janela de 5 minutos | arn: aws: cloudwatch: us-west-2: xxxxx: alarme: código de erro http 503 | Tíquete reduzido para a equipe de serviço | Lambda, API Gateway |
| ThrottlingException (Código de status Http 400) Nº de erros >=3 para 10 pontos de dados (clientes diferentes) em uma janela de 5 minutos | arn: aws: cloudwatch: us-west-2: xxxxx: alarme: código de erro http 400 | Tíquete reduzido para a equipe de serviço | EC2, Amazon Aurora |
Consulte mais detalhes em [Monitoramento e observabilidade do AWS Incident Detection and Response](observe-idr.md).
Se você preferir usar ferramentas de automação para integrar alarmes, a Interface de Linha de Comando (CLI) de Detecção e Resposta a Incidentes ajuda você a implantar e integrar seus alarmes. Consulte mais detalhes em [CLI de detecção e resposta a incidentes da AWS](idr-cli.md).
**Principais saídas:**
+ Definição e configuração de alarmes em suas cargas de trabalho.
+ Preenchimento dos detalhes do alarme no questionário de integração.
**Topics**
+ [Crie CloudWatch alarmes](idr-alarms-fit-purpose.md)
+ [Crie CloudWatch alarmes com modelos CloudFormation](idr-create-alarms-with-cfn.md)
+ [Exemplos de casos de uso para CloudWatch alarmes](idr-ex-alarm-use-cases.md)
# Crie CloudWatch alarmes que atendam às necessidades de sua empresa em Detecção e Resposta a Incidentes
Quando você cria CloudWatch alarmes da Amazon, há várias etapas que você pode seguir para garantir que seus alarmes atendam melhor às necessidades da sua empresa.
**nota**
Para exemplos de CloudWatch alarmes recomendados para integração Serviços da AWS com a Detecção e Resposta a Incidentes, consulte [Melhores práticas de detecção e resposta a incidentes](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr) em. AWS re:Post
## Revise seus CloudWatch alarmes propostos
Analise os alarmes propostos para garantir que eles só entrem no estado “Alarme” quando houver um impacto crítico na carga de trabalho monitorada (perda de receita ou degradação da experiência do cliente, o que reduz significativamente o desempenho). Por exemplo, você considera esse alarme crítico o suficiente para reagir imediatamente se ele entrar no estado “Alarme”?
A seguir estão sugestões de métricas que podem representar um impacto crítico nos negócios, como afetar a experiência dos usuários finais com um aplicativo:
+ **CloudFront:** Para obter mais informações, consulte [Visualização CloudFront e métricas da função de borda](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html).
+ **Balanceadores de carga de aplicativos:** é uma prática recomendada criar os seguintes alarmes para balanceadores de carga de aplicativos, se possível:
+ HTTPCode\$1ELB\$15xx\$1Contagem
+ HTTPCode\$1Target\$15xx\$1count
Os alarmes anteriores permitem monitorar as respostas de alvos que estão por trás do Application Load Balancer ou por trás de outros recursos. Isso facilita a identificação da origem dos erros 5XX. Para obter mais informações, consulte [CloudWatch as métricas do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ **Amazon API Gateway:** Se você usa a WebSocket API no Elastic Beanstalk, considere usar as seguintes métricas:
+ Taxas de erro de integração (filtradas para erros 5XX)
+ Latência de integração
+ Erros de execução
Para obter mais informações, consulte [Monitoramento WebSocket da execução da API com CloudWatch métricas](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html).
+ **Amazon Route 53:** monitore a **EndPointUnhealthyENICount**métrica. Essa métrica é o número de interfaces de rede elásticas no status de **recuperação automática**. Esse status indica tentativas do resolvedor de recuperar uma ou mais das interfaces de rede da Amazon Virtual Private Cloud associadas ao endpoint (especificado por **EndpointId**). No processo de recuperação, o endpoint funciona com capacidade limitada. O endpoint não pode processar consultas de DNS até que seja totalmente recuperado. Para obter mais informações, consulte [Monitoramento de endpoints do Amazon Route 53 Resolver com a Amazon CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html).
## Valide suas configurações de alarme
Depois de confirmar que os alarmes propostos atendem às suas necessidades comerciais, valide a configuração e o histórico dos alarmes:
+ Valide o **limite** da métrica para entrar no estado de “Alarme” em relação à tendência gráfica da métrica.
+ Valide o **período** usado para pontos de dados de pesquisa. A pesquisa de pontos de dados em 60 segundos ajuda na detecção precoce de incidentes.
+ Valide a **DatapointToAlarm**configuração. Na maioria dos casos, é uma prática recomendada definir isso como 3 de 3 ou 5 de 5. Em um incidente, o alarme é acionado após 3 minutos quando definido como [métrica de 60 segundos com 3 de 3 DatapointToAlarm] ou 5 minutos quando definido como [métrica de 60 segundos com 5 de 5 DatapointToAlarm]. Use essa combinação para eliminar alarmes ruidosos.
**nota**
As recomendações anteriores podem variar dependendo de como você usa um serviço. Cada AWS serviço opera de forma diferente dentro de uma carga de trabalho. Além disso, o mesmo serviço pode operar de forma diferente quando usado em vários lugares. Você deve ter certeza de que entendeu como sua carga de trabalho utiliza os recursos que alimentam o alarme, bem como os efeitos a montante e a jusante.
## Valide como seus alarmes lidam com dados perdidos
Algumas fontes métricas não enviam dados CloudWatch em intervalos regulares. Para essas métricas, é uma prática recomendada tratar os dados perdidos como **não violadores**. Para obter mais informações, consulte [Configurando como CloudWatch os alarmes tratam dados perdidos e Como](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) [evitar transições prematuras para](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition) o estado de alarme.
Por exemplo, se uma métrica monitora uma taxa de erro e não há erros, a métrica não relata pontos de dados (nulos). Se você configurar o alarme para tratar os dados ausentes como **ausentes**, um único ponto de dados de violação seguido por dois pontos de dados sem dados (nulos) fará com que a métrica entre no estado “Alarme” (para 3 dos 3 pontos de dados). Isso ocorre porque a configuração de dados ausentes avalia o último ponto de dados conhecido no período de avaliação.
Nos casos em que as métricas monitoram uma taxa de erro, na ausência de degradação do serviço, você pode presumir que nenhum dado é bom. É uma prática recomendada tratar os dados ausentes como **NotBreach, para que** os dados ausentes sejam tratados como “OK” e a métrica não entre no estado “Alarme” em um único ponto de dados.
## Revise o histórico de cada alarme
Se o histórico de um alarme mostrar que ele entra frequentemente no estado “Alarme” e depois se recupera rapidamente, o alarme pode se tornar um problema para você. Certifique-se de ajustar o alarme para evitar ruídos ou alarmes falsos.
## Valide métricas para recursos subjacentes
Certifique-se de que suas métricas analisem recursos subjacentes válidos e usem as estatísticas corretas. Se um alarme estiver configurado para revisar nomes de recursos inválidos, talvez o alarme não consiga rastrear os dados subjacentes. Isso pode fazer com que o alarme entre no estado “Alarme”.
## Crie alarmes compostos
Se você fornecer às operações de Detecção e Resposta a Incidentes um grande número de alarmes para integração, talvez seja necessário criar alarmes compostos. Os alarmes compostos reduzem o número total de alarmes que precisam ser integrados.
# Crie CloudWatch alarmes em Detecção e Resposta a Incidentes com modelos CloudFormation
Para acelerar a integração com o AWS Incident Detection and Response e reduzir o esforço necessário para criar alarmes, AWS fornece CloudFormation modelos. Esses modelos incluem configurações de alarme otimizadas para serviços comumente integrados, como Application Load Balancer, Network Load Balancer e Amazon. CloudFront
**Crie CloudWatch alarmes com modelos CloudFormation**
1. Faça o download de um modelo usando os links fornecidos:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/idr-create-alarms-with-cfn.html)
1. Revise o arquivo JSON baixado para garantir que ele atenda aos processos operacionais e de segurança da sua organização.
1. Crie uma CloudFormation pilha:
**nota**
As etapas a seguir usam o processo padrão de criação de CloudFormation pilhas. Para obter etapas detalhadas, consulte [Criação de uma pilha no CloudFormation console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html).
1. Abra o AWS CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Selecione **Criar pilha**.
1. Escolha **O modelo está pronto** e, em seguida, carregue o arquivo de modelo da sua pasta local.
Veja a seguir um exemplo da tela **Criar pilha**.
![\[Exemplo de arquivo de modelo de upload de pilha\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/images/create-cfn-stack1.png)
1. Escolha **Próximo**.
1. Insira as seguintes informações obrigatórias:
+ **AlarmNameConfig**e **AlarmDescriptionConfig**: Insira um nome e uma descrição para seu alarme.
+ **ThresholdConfig**: revise o valor limite para atender aos requisitos do seu aplicativo.
+ **Distribuição IDConfig**: certifique-se de que o ID de distribuição aponte para os recursos corretos na conta em que você está criando a CloudFormation pilha.
1. Escolha **Próximo**.
1. Revise os valores padrão **DatapointsToAlarmConfig**nos campos **PeriodConfig**EvalutionPeriodConfig****, e. É uma prática recomendada usar os valores padrão para esses campos. Você pode fazer ajustes, se necessário, para atender aos requisitos do seu aplicativo.
1. Opcionalmente, insira tags e informações de notificação do SNS conforme necessário. É uma prática recomendada ativar a **Proteção de rescisão** para evitar a exclusão acidental do alarme. Para ativar a proteção contra terminação, selecione o botão de rádio **Ativado**, conforme mostrado no exemplo a seguir:
![\[Exemplo de criação de pilha, ativação de rescisão\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/images/create-cfn-stack2.png)
1. Escolha **Próximo**.
1. Revise as configurações da pilha e escolha **Criar pilha**.
1. Depois de criar a pilha, você vê o alarme listado na lista de CloudWatch **alarmes** da Amazon, conforme mostrado no exemplo a seguir:
![\[Exemplo de lista CloudWatch de alarmes\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/images/create-cfn-stack3.png)
1. Depois de criar todos os seus alarmes na conta e na AWS região corretas, notifique seu gerente técnico de contas (TAM). A equipe de Detecção e Resposta de Incidentes da AWS analisa o status dos seus novos alarmes e, em seguida, continua sua integração.
# Exemplos de casos de uso de CloudWatch alarmes em Detecção e Resposta a Incidentes
Os casos de uso a seguir fornecem exemplos de como você pode usar os CloudWatch alarmes da Amazon em Detecção e Resposta a Incidentes. Esses exemplos demonstram como CloudWatch os alarmes podem ser configurados para monitorar as principais métricas e limites em vários AWS serviços, permitindo que você identifique e responda a possíveis problemas que podem afetar a disponibilidade e o desempenho de seus aplicativos e cargas de trabalho.
## Exemplo de caso de uso A: Application Load Balancer
Você pode criar o seguinte CloudWatch alarme que sinaliza um possível impacto na carga de trabalho. Para fazer isso, você cria uma métrica matemática que alerta quando conexões bem-sucedidas caem abaixo de um determinado limite. Para ver as CloudWatch métricas disponíveis, consulte as [CloudWatch métricas do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)
**Métrica:** `HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`
**NameSpace: AWS/Aplicação** ELB
**ComparisonOperator(Limite):** Menos de x (x = limite do cliente).
**Período:** 60 segundos
**DatapointsToAlarm:** 3 de 3
**Tratamento de dados perdidos:** trate os dados perdidos como [violação](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Estatística:** soma
O diagrama a seguir mostra o fluxo para o caso de uso A:
![\[Exemplo de caso de uso do Application Load Balancer\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/images/UseCaseAALB.png)
## Exemplo de caso de uso B: Amazon API Gateway
Você pode criar o seguinte CloudWatch alarme que sinaliza um possível impacto na carga de trabalho. Para fazer isso, você cria uma métrica composta que alerta quando há alta latência ou um número médio alto de erros 4XX no API Gateway. Para ver as métricas disponíveis, consulte as [dimensões e métricas do Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)
**Métrica:** `compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`
**NameSpace:** AWS/API Gateway
**ComparisonOperator(Limite):** Maior que (limites x ou y do cliente)
**Período:** 60 segundos
**DatapointsToAlarm:** 1 de 1
**Tratamento de dados perdidos:** trate os dados perdidos como [se não fossem uma violação](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Estatística:**
O diagrama a seguir mostra o fluxo para o caso de uso B:
![\[Exemplo de caso de uso do API Gateway\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/images/UseCaseBAPIGW.png)
## Exemplo de caso de uso C: Amazon Route 53
Você pode monitorar seus recursos criando verificações de saúde do Route 53 que são usadas CloudWatch para coletar e processar dados brutos em métricas legíveis e quase em tempo real. Você pode criar o seguinte CloudWatch alarme que sinaliza um possível impacto na carga de trabalho. Você pode usar as CloudWatch métricas para criar um alarme que é acionado quando ultrapassa o limite estabelecido. Para ver as CloudWatch métricas disponíveis, consulte [CloudWatch métricas para verificações de saúde do Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)
**Métrica:** `R53-HC-Success`
**NameSpace:** AWS/Rota 53
**Limite HealthCheckStatus:** HealthCheckStatus < x para 3 pontos de dados em 3 minutos (sendo x limite do cliente)
**Período:** 1 minuto
**DatapointsToAlarm:** 3 de 3
**Tratamento de dados perdidos:** trate os dados perdidos como [violação](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Estatística:** mínima
O diagrama a seguir mostra o fluxo para o caso de uso C:
![\[Exemplo de caso de uso do Route 53\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/images/UseCaseCR53.png)
## Exemplo de caso de uso D: monitore uma carga de trabalho com um aplicativo personalizado
É fundamental que você reserve um tempo para definir uma verificação de saúde apropriada nesse cenário. Se você verificar apenas se a porta de um aplicativo está aberta, então você não verificou se o aplicativo está funcionando. Além disso, fazer uma chamada para a página inicial de um aplicativo não é necessariamente a maneira correta de determinar se o aplicativo está funcionando. Por exemplo, se um aplicativo depende tanto de um banco de dados quanto do Amazon Simple Storage Service (Amazon S3), a verificação de saúde deve validar todos os elementos. Uma maneira de fazer isso é criar uma página da web de monitoramento, como **/monitor**. A página de monitoramento faz uma chamada para o banco de dados para garantir que ele possa se conectar e obter dados. E a página de monitoramento faz uma chamada para o Amazon S3. Em seguida, você aponta a verificação de integridade do balanceador de carga para a página **/monitor.**
O diagrama a seguir mostra o fluxo para o caso de uso D:
![\[Exemplo de caso de uso para monitoramento com um aplicativo personalizado\]](http://docs.aws.amazon.com/pt_br/IDR/latest/userguide/images/CustomAlarm.png)