# Usar alarmes do Amazon CloudWatch
É possível criar alarmes que observem métricas e enviem notificações ou façam alterações automaticamente nos recursos que você está monitorando quando um limite é violado. Por exemplo, você pode monitorar o uso de CPU e de leituras e gravações de disco de suas instâncias do Amazon EC2 e usar esses dados para determinar se deve iniciar instâncias adicionais para lidar com o aumento de carga. Você também pode usar esses dados para interromper instâncias subutilizados para economizar dinheiro.
No Amazon CloudWatch, você pode configurar alarmes *de métricas* e *compostos*.
Você pode criar alarmes em consultas do Metrics Insights que usam tags de recurso da AWS para filtrar e agrupar métricas. Para usar tags com alarmes, em [https://console.aws.amazon.com/connect/](https://console.aws.amazon.com/connect/), escolha **Configurações**. Na página **Configurações do CloudWatch**, em **Habilitar tags de recurso em telemetria**, escolha **Habilitar**. Para ter um monitoramento contextual que se adapte automaticamente à sua estratégia de marcação, crie alarmes nas consultas ao Metrics Insights usando tags de recurso da AWS. Isso permite monitorar todos os recursos marcados com aplicações ou ambientes específicos.
+ Um *alarme de métrica* observa uma única métrica do CloudWatch ou o resultado de uma expressão matemática baseada em métricas do CloudWatch. O alarme executa uma ou mais ações com base no valor da métrica ou na expressão em relação a um limite em alguns períodos. A ação pode ser enviar uma notificação para um tópico do Amazon SNS, executar uma ação do Amazon EC2 ou uma ação do Amazon EC2 Auto Scaling, iniciar uma investigação nas investigações operacionais do CloudWatch ou criar um OpsItem ou incidente no Systems Manager.
+ Um *alarme do PromQL* monitora as métricas usando uma consulta instantânea do Prometheus Query Language (PromQL) em métricas ingeridas por meio do endpoint do OTLP do CloudWatch. O alarme rastreia séries temporais individuais em violação como contribuidores e usa períodos pendentes e de recuperação baseados na duração para controlar as transições de estado. Para obter mais informações, consulte [Alarmes do PromQL](alarm-promql.md).
+ Um *alarme composto* inclui uma expressão de regra que leva em conta os estados de outros alarmes que você criou. O alarme composto entrará no estado ALARM somente se todas as condições da regra forem atendidas. Os alarmes especificados na expressão de regra de um alarme composto podem incluir alarmes de métrica e outros alarmes compostos.
O uso de alarmes compostos pode reduzir o ruído do alarme. Você pode criar vários alarmes de métrica e também criar um alarme composto e configurar alertas apenas para o alarme composto. Por exemplo, um alarme composto poderá entrar no estado ALARM somente quando todos os alarmes de métrica subjacentes estiverem no estado ALARM.
Os alarmes compostos podem enviar notificações do Amazon SNS quando mudam de estado e podem criar investigações, OpsItems ou incidentes do Systems Manager quando entram no estado ALARM, mas não podem executar ações do EC2 ou ações do Auto Scaling.
**nota**
Você pode criar quantos alarmes quiser em sua conta da AWS.
É possível adicionar alarmes aos painéis, para monitorar e receber alertas sobre seus recursos da AWS e aplicações em várias regiões. Após ser adicionado a um painel, o alarme ficará cinza quando estiver no estado `INSUFFICIENT_DATA` e vermelho quando estiver no estado `ALARM`. O alarme é mostrado sem cor quando está no estado `OK`.
Também é possível adicionar como favoritos alarmes recém-visitados via opção *Favorites and recents* (Favoritos e recentes) no painel de navegação do console do CloudWatch. A opção *Favorites and recents* (Favoritos e recentes) contém colunas para seus alarmes favoritos e alarmes visitados recentemente.
Um alarme invoca ações somente quando muda de estado. A exceção se aplica a alarmes com ações do Auto Scaling. Para ações do Auto Scaling, o alarme continuará invocando a ação para cada período que ele permanecer no novo estado.
Um alarme pode observar uma métrica da mesma conta. Se você habilitou a funcionalidade entre contas no console do CloudWatch, também poderá criar alarmes que observem métricas em outras contas da AWS. Não há suporte para a criação de alarmes compostos entre contas. A criação de alarmes entre contas que usam expressões matemáticas é compatível, exceto as funções `ANOMALY_DETECTION_BAND`, `INSIGHT_RULE` e `SERVICE_QUOTA` que não são compatíveis com alarmes entre contas.
**nota**
O CloudWatch não testa nem valida as ações especificadas nem detecta erros do Amazon EC2 Auto Scaling ou do Amazon SNS resultantes de uma tentativa de invocar ações não existentes. Verifique se as ações de alarme existem.
# Conceitos
Os alarmes do CloudWatch monitoram métricas e acionam ações quando os limites são violados. Noções básicas sobre como os alarmes avaliam os dados e respondem às condições é essencial para um monitoramento eficaz.
**Topics**
+ [
# Consultas de dados de alarmes
](alarm-data-queries.md)
+ [
# Avaliação de alarme
](alarm-evaluation.md)
+ [
# Alarmes do PromQL
](alarm-promql.md)
+ [
# Alarmes compostos
](alarm-combining.md)
+ [
# Ações de alarme
](alarm-actions.md)
+ [
# Regras de silenciamento de alarmes
](alarm-mute-rules.md)
+ [
# Limites
](alarm-limits.md)
# Consultas de dados de alarmes
Os alarmes do CloudWatch podem monitorar várias fontes de dados. Escolha o tipo de consulta adequado com base nas suas necessidades de monitoramento.
## Métricas
Monitorar uma única métrica do CloudWatch. Esse é o tipo de alarme mais comum para monitorar a performance de recursos. Para obter mais informações sobre métricas, consulte [Conceitos das métricas do CloudWatch](cloudwatch_concepts.md).
Para obter mais informações, consulte [Criar um alarme do CloudWatch com base em um limite estático](ConsoleAlarms.md).
## Matemática de métricas
Defina um alarme com base no resultado de uma expressão matemática baseada em uma ou mais métricas do CloudWatch. Uma expressão matemática usada para um alarme pode incluir até 10 métricas. Toda métrica deve estar usando o mesmo período.
Para um alarme baseado em uma expressão matemática, é possível especificar como você deseja que o CloudWatch trate pontos de dados ausentes. Nesse caso, o ponto de dados é considerado ausente se a expressão matemática não retornar um valor para esse ponto de dados.
Os alarmes baseados em expressões matemáticas não poderão realizar ações do Amazon EC2.
Para obter mais informações sobre expressões matemáticas e sintaxe de métrica, consulte [Uso de expressões matemáticas com as métricas do CloudWatch](using-metric-math.md).
Para obter mais informações, consulte [Criar um alarme do Cloudwatch com base em uma expressão matemática de métrica](Create-alarm-on-metric-math-expression.md).
## Insights de métricas
Uma consulta do CloudWatch Metrics Insights ajuda você a consultar métricas em grande escala usando uma sintaxe semelhante à SQL. Você pode criar um alarme em qualquer consulta do Metrics Insights, incluindo consultas que retornam várias séries temporais. Esse recurso expande significativamente suas opções de monitoramento. Quando você cria um alarme baseado em uma consulta do Metrics Insights, o alarme se ajusta automaticamente à medida que recursos são adicionados ou removidos do grupo monitorado. Crie o alarme uma vez, e qualquer recurso que corresponda à definição e aos filtros da consulta se associará ao escopo de monitoramento de alarmes quando a métrica correspondente estiver disponível. Para consultas de várias séries temporais, cada série temporal retornada contribui para o alarme, permitindo um monitoramento mais granular e dinâmico.
Confira abaixo dois casos de uso principais dos alarmes do CloudWatch Metrics Insights:
+ Detecção de anomalias e monitoramento agregado
Crie um alarme em uma consulta do Metrics Insights que retorne uma única série temporal agregada. Essa abordagem funciona bem para alarmes dinâmicos que monitoram métricas agregadas em sua infraestrutura ou aplicações. Por exemplo, você pode monitorar a utilização máxima da CPU em todas as suas instâncias, com o alarme se ajustando automaticamente à medida que você escala sua frota.
Para criar um alarme de monitoramento agregado, use esta estrutura de consulta:
```
SELECT FUNCTION(metricName)
FROM SCHEMA(...)
WHERE condition;
```
+ Monitoramento de frota por recurso
Crie um alarme que monitore várias séries temporais, em que cada série temporal funcione como um colaborador com seu próprio estado. O alarme é ativado quando qualquer colaborador entra no estado ALARM, acionando ações específicas do recurso. Por exemplo, monitore as conexões do banco de dados em várias instâncias do RDS para evitar rejeições de conexão.
Para monitorar várias séries temporais, use esta estrutura de consulta:
```
SELECT AVG(DatabaseConnections)
FROM AWS/RDS
WHERE condition
GROUP BY DBInstanceIdentifier
ORDER BY AVG() DESC;
```
Ao criar alarmes de várias séries temporais, você deve incluir duas cláusulas principais em sua consulta:
+ Uma cláusula `GROUP BY` que define como estruturar a série temporal e determina quantas séries temporais a consulta produzirá.
+ Uma cláusula `ORDER BY` que estabelece uma classificação determinística de suas métricas, permitindo que o alarme avalie os sinais mais importantes primeiro.
Essas cláusulas são essenciais para uma avaliação adequada do alarme. A cláusula `GROUP BY` divide seus dados em séries temporais separadas (por exemplo, por ID da instância), enquanto a cláusula `ORDER BY` garante o processamento consistente e priorizado dessas séries temporais durante a avaliação do alarme.
Para obter mais informações sobre como criar um alarme de várias séries temporais, consulte [Crie um alarme baseado em uma consulta ao Metrics Insights de várias séries temporais](multi-time-series-alarm.md).
## Filtros de métricas do grupo de logs
É possível criar um alarme com base em um filtro de métricas de grupo de logs Com filtros de métrica, você pode procurar termos e padrões em dados de log à medida que os dados são enviados ao CloudWatch Logs. Para obter mais informações, consulte [Criar métricas de eventos de logs usando filtros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) no *Guia do usuário do Amazon CloudWatch Logs*.
Para obter mais informações sobre como criar um alarme baseado em um filtro de métricas de grupo de logs, consulte [Alarmes nos logs](Alarm-On-Logs.md).
## PromQL
Você pode criar um alarme que usa uma consulta instantânea do Prometheus Query Language (PromQL) para monitorar métricas ingeridas por meio do endpoint do OTLP do CloudWatch.
Para obter mais informações sobre como os alarmes do PromQL funcionam, consulte [Alarmes do PromQL](alarm-promql.md).
Para obter mais informações sobre como criar um alarme do PromQL, consulte [Criar um alarme usando uma consulta em PromQL](Create_PromQL_Alarm.md).
## Fonte de dados externa
É possível criar alarmes que monitorem métricas de fontes de dados que não estejam no CloudWatch. Para obter mais informações sobre como criar conexões com essas outras fontes de dados, consulte [Métricas de consulta de outras fontes de dados](MultiDataSourceQuerying.md).
Para obter mais informações sobre como criar um alarme com base em uma fonte de dados conectada, consulte [Criação de um alarme com base em uma fonte de dados conectada](Create_MultiSource_Alarm.md).
# Avaliação de alarme
## Estados de alarme de métrica
Um alarme de métrica tem estes estados possíveis:
+ `OK`: a métrica ou a expressão está dentro do limite definido.
+ `ALARM`: a métrica ou a expressão está fora do limite definido.
+ `INSUFFICIENT_DATA`: o alarme acabou de ser acionado, a métrica não está disponível ou não há dados suficientes para a métrica determinar o estado do alarme.
## Estado de avaliação do alarme
Além do estado do alarme, cada alarme tem um estado de avaliação que fornece informações sobre o processo de avaliação do alarme. Os estados a seguir podem ocorrer:
+ `PARTIAL_DATA`: indica que nem todos os dados disponíveis puderam ser recuperados devido a limitações de cota. Para obter mais informações, consulte [Como dados parciais são tratados](cloudwatch-metrics-insights-alarms-partial-data.md).
+ `EVALUATION_ERROR`: indica erros de configuração na definição do alarme que exigem revisão e correção. Consulte o campo StateReason do alarme para obter mais detalhes.
+ `EVALUATION_FAILURE`: indica problemas temporários do CloudWatch. Recomendamos o monitoramento manual até que o problema seja resolvido
É possível visualizar o estado da avaliação nos detalhes do alarme no console ou usando o comando `describe-alarms` da CLI ou a API `DescribeAlarms`.
## Configurações de avaliação do alarme
Ao criar um alarme, você especifica três configurações para habilitar o CloudWatch e avaliar quando alterar o estado do alarme:
+ **Período** é o intervalo de tempo para avaliar a métrica ou a expressão e criar cada ponto de dados de um alarme. Ele é expresso em segundos.
+ **Evaluation Periods** (Períodos de avaliação) é o número de períodos mais recentes, ou pontos de dados, para avaliar quando determinar o estado do alarme.
+ **Datapoints to Alarm** (Pontos de dados para alarme) é o número de pontos de dados dentro dos períodos de avaliação que devem estar violando para fazer com que o alarme passe para o estado `ALARM`. Os pontos de dados de violação não precisam ser consecutivos, mas eles devem estar dentro do último número de pontos de dados igual ao **Evaluation Period** (Período de avaliação).
Para qualquer período de um minuto ou mais, um alarme é avaliado a cada minuto, e a avaliação é baseada na janela de tempo definida pelo **Período** epelos **Períodos de Avaliação**. Por exemplo, se o **Período** for de 5 minutos (300 segundos) e os **Períodos de Avaliação** forem de 1, no final do minuto 5 o alarme será avaliado com base nos dados dos minutos 1 a 5. Então, no final do minuto 6, o alarme será avaliado com base nos dados dos minutos 2 a 6.
Se o período do alarme for de 10, 20 ou 30 segundos, o alarme será avaliado a cada 10 segundos. Para obter mais informações, consulte [Alarmes de alta resolução](#high-resolution-alarms).
Se o número de períodos de avaliação multiplicado pela duração de cada período de avaliação exceder um dia, o alarme será avaliado uma vez por hora. Para obter mais detalhes sobre como esses alarmes de vários dias são avaliados, consulte [Exemplo de avaliação de um alarme de vários dias](#evaluate-multiday-alarm).
Na figura a seguir, o limite para um alarme de métrica é definido como três unidades. Tanto o **Evaluation Period** (Período de avaliação) como os **Datapoints to Alarm** (Pontos de Dados para Alarme) são 3. Ou seja, quando todos os pontos de dados nos três períodos consecutivos mais recentes estiverem acima do limite, o alarme passará para o estado `ALARM`. Na figura, isso acontece do terceiro ao quinto períodos de tempo. No período seis, o valor fica abaixo do limite. Portanto, um dos períodos que estão sendo avaliados não é violado, e o estado do alarme volta para `OK`. Durante o nono período, o limite é violado novamente, mas somente em um período. Consequentemente, o estado do alarme permanece `OK`.
![\[Alarme de acionamento do limite de alarme\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm_graph.png)
Ao configurar **Evaluation Periods** (Períodos de avaliação) e **Datapoints to Alarm** (Pontos de dados para alarme) como valores diferentes, você está configurando um alarme “M de N”. **Pontos de dados para alarme** é (“M”) e **Períodos de avaliação** é (“N”). O intervalo de avaliação é o número de períodos de avaliação multiplicado pela duração do período. Por exemplo, se você configurar 4 de 5 pontos de dados com um período de 1 minuto, o intervalo de avaliação será de 5 minutos. Se você configurar 3 de 3 pontos de dados com um período de 10 minutos, o intervalo de avaliação será de 30 minutos.
**nota**
Se os pontos de dados estiverem ausentes logo depois que você criar um alarme, e se a métrica estava sendo relatada para o CloudWatch antes da criação do alarme, ao avaliá-lo, o CloudWatch recuperará os pontos de dados mais recentes, de antes de o alarme ter sido criado.
## Alarmes de alta resolução
Se você configurar um alarme com base em uma métrica de alta resolução, poderá especificar um alarme de alta resolução com um período de 10 segundos, 20 segundos ou 30 segundos. Há um custo maior para alarmes de alta resolução. Para obter mais informações sobre as métricas de alta resolução, consulte [Publicar métricas personalizadas](publishingMetrics.md).
## Exemplo de avaliação de um alarme de vários dias
Um alarme será um alarme de vários dias se o número de períodos de avaliação multiplicado pela duração de cada período de avaliação exceder um dia. Os alarmes de vários dias são avaliados uma vez por hora. Quando os alarmes de vários dias são avaliados, o CloudWatch leva em consideração somente as métricas até a hora atual, no minuto :00, durante a avaliação.
Por exemplo, considere um alarme que monitora um trabalho executado a cada 3 dias às 10h.
1. Às 10h02, o trabalho falha
1. Às 10h03, o alarme é avaliado e permanece no estado `OK`, porque a avaliação considera dados somente até 10h.
1. Às 11h03, o alarme considera dados até 11h e entra no estado `ALARM`.
1. Às 11h43, você corrige o erro e o trabalho agora é executado com êxito.
1. Às 12h03, o alarme é avaliado novamente, identifica o trabalho bem-sucedido e retorna ao estado `OK`.
# Configurar como os alarmes do CloudWatch tratam dados ausentes
Às vezes, nem todos os pontos de dados esperados para uma métrica são relatados ao CloudWatch. Por exemplo, isso pode ocorrer quando uma conexão é perdida, um servidor é desativado, ou quando uma métrica informa apenas dados de forma intermitente por padrão.
O CloudWatch permite que você especifique como tratar pontos de dados ausentes ao avaliar um alarme. Isso pode ajudar a configurar seu alarme para passar ao estado `ALARM` quando for apropriado para o tipo de dados que está sendo monitorado. Você pode evitar falsos positivos quando os dados ausentes não indicam um problema.
Assim como cada alarme está sempre em um dos três estados, cada ponto de dados específico relatado do CloudWatch se insere em uma destas três categorias:
+ Não violar (dentro do limite)
+ Violar (violando o limite)
+ Ausente
Para cada alarme, é possível especificar o CloudWatch para tratar pontos de dados ausentes como qualquer uma destas opções:
+ `notBreaching`: os pontos de dados ausentes são tratados como "bons" e dentro do limite
+ `breaching`: os pontos de dados ausentes são tratados como “ruins” e violando o limite
+ `ignore`: o estado do alarme atual é mantido
+ `missing`: se todos os pontos de dados no intervalo de avaliação do alarme estiverem ausentes, o alarme passará para INSUFFICIENT\$1DATA.
A melhor opção depende do tipo de métrica e da finalidade do alarme. Por exemplo, se você estiver criando um alarme de reversão de aplicações usando uma métrica que relata dados continuamente, pode desejar tratar os pontos de dados ausentes como uma violação, pois isso pode indicar que há algo de errado. No entanto, para uma métrica que gera pontos de dados somente quando ocorre um erro, como `ThrottledRequests` no Amazon DynamoDB, é possível tratar dados ausentes como `notBreaching`. O comportamento padrão é `missing`.
**Importante**
Os alarmes configurados nas métricas do Amazon EC2 podem entrar temporariamente no estado INSUFFICIENT\$1DATA se houver pontos de dados de métricas ausentes. Isso é raro, mas pode acontecer quando o relatório de métricas é interrompido, mesmo quando a instância do Amazon EC2 está íntegra. Para os alarmes nas métricas do Amazon EC2 que estão configurados para executar ações de interrupção, encerramento, reinicialização ou recuperação, recomendamos configurar esses alarmes para tratar os dados ausentes como `missing` e para que esses alarmes sejam acionados somente quando estiverem no estado ALARM.
Escolher a melhor opção para seu alarme evita alterações desnecessárias e enganosas e também indica com mais precisão a integridade do seu sistema.
**Importante**
Os alarmes que avaliam as métricas no namespace `AWS/DynamoDB` ignoram por padrão os dados ausentes. É possível substituir isso se escolher uma opção diferente para como o alarme deve tratar os dados ausentes. Quando uma métrica `AWS/DynamoDB` tem dados ausentes, os alarmes que avaliam essa métrica permanecem no estado em que estiverem na ocasião.
## Como o estado do alarme é avaliado quando há dados ausentes
Sempre que um alarme avalia se é necessário alterar o estado, o CloudWatch tenta recuperar um maior número de pontos de dados do que o número especificado em **Evaluation Periods** (Períodos de avaliação). O número exato de pontos de dados que ele tenta recuperar depende do tamanho do período de alarme e se ele é baseado em uma métrica com resolução padrão ou alta. O período de pontos de dados que ele tenta recuperar é o *intervalo de avaliação*.
Assim que o CloudWatch recupera esses pontos de dados, ocorre o seguinte:
+ Se não houver pontos de dados ausentes no intervalo de avaliação, o CloudWatch avaliará o alarme com base nos pontos de dados mais recentes coletados. O número de pontos de dados avaliados é igual ao valor de **Evaluation Periods** (Períodos de avaliação) do alarme. Os pontos de dados excedentes mais antigos no intervalo de avaliação não são necessários e são ignorados.
+ Se alguns pontos de dados no intervalo de avaliação estiverem ausentes, mas o total de pontos de dados recuperados corretamente for igual ou maior que os **Evaluation Periods** (Períodos de avaliação) do alarme, o CloudWatch avaliará o estado do alarme com base nos pontos de dados reais mais recentes que foram recuperados corretamente, inclusive os pontos de dados excedentes necessários mais antigos no período de avaliação. Nesse caso, o valor que você define para como tratar dados ausentes não é necessário e é ignorado.
+ Se alguns pontos de dados no intervalo de avaliação estiverem ausentes e o número de pontos de dados reais que foram recuperados for menor do que o número de **Evaluation Periods** (Períodos de avaliação) do alarme, o CloudWatch preencherá os pontos de dados ausentes com o resultado especificado sobre como tratar dados ausentes e avaliará o alarme. Contudo, todos os pontos de dados reais no intervalo de avaliação serão incluídos na avaliação. O CloudWatch usa pontos de dados ausentes o mínimo possível.
**nota**
Um caso específico desse comportamento é que os alarmes do CloudWatch podem reavaliar repetidamente o último conjunto de pontos de dados por um período depois que o fluxo da métrica é interrompido. Essa reavaliação pode fazer com que o estado do alarme mude e as ações sejam executadas novamente, se ele tiver sido alterado imediatamente antes do fluxo de métrica ser interrompido. Para atenuar esse comportamento, use períodos mais curtos.
As tabelas a seguir ilustram exemplos do comportamento de avaliação de alarme. Na primeira tabela, **Datapoints to Alarm** (Pontos de dados para alarme) e **Evaluation Periods** (Períodos de avaliação) são 3. O CloudWatch recupera os cinco pontos de dados mais recentes ao avaliar o alarme, caso algum dos três pontos de dados mais recentes esteja ausente. O intervalo de avaliação do alarme é 5.
A coluna 1 exibe os cinco pontos de dados mais recentes, pois o intervalo de avaliação é 5. Esses pontos de dados são exibidos com o ponto de dados mais recente à direita, em que 0 é um ponto de dados de não violação, X é um ponto de dados violação e - é um ponto de dados ausente.
A coluna 2 mostra quantos dos 3 pontos de dados necessários estão ausentes. Embora os 5 pontos de dados mais recentes sejam avaliados, apenas 3 (a configuração para **Evaluation Periods (Períodos de avaliação)**) são necessárias para avaliar o estado do alarme. O número de pontos de dados na coluna 2 é o número de pontos de dados que devem ser "preenchidos", usando a configuração de como dados ausentes estão sendo tratados.
Nas colunas de 3 a 6, os cabeçalhos de coluna são os valores possíveis para tratar dados ausentes. As linhas dessas colunas mostram o estado do alarme definido para cada uma dessas possíveis formas de tratar dados ausentes.
| Pontos de dados | Número de pontos de dados que deverão ser preenchidos | AUSENTE | IGNORE | VIOLAÇÃO | NÃO VIOLAÇÃO |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `OK` | `OK` | `OK` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `OK` | `OK` |
| - - - - - | 3 | `INSUFFICIENT_DATA` | Reter estado atual | `ALARM` | `OK` |
| 0 X X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| - - X - - | 2 | `ALARM` | Reter estado atual | `ALARM` | `OK` |
Na segunda linha da tabela anterior, o alarme permanece em `OK` mesmo que os dados ausentes sejam tratados como violação, porque um ponto de dados existente não está violando o limite, e isso é avaliado junto com dois pontos de dados ausentes que são tratados como violação. Na próxima vez em que esse alarme for avaliado, se os dados ainda estiverem ausentes, ele passará para `ALARM`, pois esse ponto de dados de não violação não estará mais no intervalo de avaliação.
A terceira linha, onde todos os cinco pontos de dados mais recentes estão ausentes, ilustra como as várias configurações para tratar dados ausentes afetam o estado do alarme. Se os pontos de dados ausentes forem considerados de violação, o alarme entrará no estado ALARM; caso forem considerados de não violação, o alarme entrará no estado OK. Se os pontos de dados ausentes forem ignorados, o alarme reterá o estado atual que tinha antes dos pontos de dados ausentes. E se os pontos de dados ausentes são apenas considerados ausentes, então o alarme não tem dados reais recentes suficientes para fazer uma avaliação e passa para INSUFFICIENT\$1DATA.
Na quarta linha, o alarme passa para o estado `ALARM` em todos os casos porque os três pontos de dados mais recentes estão em violação, e tanto os **Evaluation Periods** (Períodos de avaliação) como os **Datapoints to Alarm** (Pontos de Dados para Alarme) do alarme são ambos definidos como 3. Nesse caso, o ponto de dados que falta é ignorado, e a configuração para como avaliar dados que estão faltando não é necessária, pois há 3 pontos de dados reais para avaliar.
A linha 5 representa um caso especial de avaliação de alarme chamado *estado de alarme prematuro*. Para obter mais informações, consulte [Evitar transições prematuras para o estado do alarme](#CloudWatch-alarms-avoiding-premature-transition).
Na próxima tabela, o **Period (Período)** é novamente definido como 5 minutos, e **Datapoints to Alarm (Pontos de dados para alarme)** é somente 2, enquanto **Evaluation Periods (Períodos de avaliação)** é 3. Esse é um alarme 2 de 3, M de N.
O intervalo de avaliação é 5. Esse é o número máximo de pontos de dados recentes que são recuperados e podem ser usados caso alguns pontos de dados estejam ausentes.
| Pontos de dados | Número de pontos de dados ausentes | AUSENTE | IGNORE | VIOLAÇÃO | NÃO VIOLAÇÃO |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 0 X 0 X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 - X - - | 1 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - X | 2 | `ALARM` | Reter estado atual | `ALARM` | `OK` |
Nas linhas 1 e 2, o alarme sempre passa para o estado ALARM porque dois dos três pontos de dados mais recentes estão em violação. Na linha 2, os dois pontos de dados mais antigos no intervalo de avaliação não são necessários porque nenhum dos três pontos de dados mais recentes está ausente. Portanto, esses dois pontos de dados mais antigos são ignorados.
Nas linhas 3 e 4, o alarme só passará para o estado ALARM se os dados ausentes forem tratados como violação, e nesse caso os dois pontos de dados ausentes mais recentes serão tratados como violação. Na linha 4, esses dois pontos de dados ausentes que são tratados como violação fornecem os dois pontos de dados de violação necessários para acionar o estado ALARM.
A linha 5 representa um caso especial de avaliação de alarme chamado *estado de alarme prematuro*. Para obter mais informações, consulte a seção a seguir:
### Evitar transições prematuras para o estado do alarme
A avaliação de alarmes do CloudWatch inclui lógica para tentar evitar alarmes falsos, nos quais o alarme entra no estado ALARM prematuramente quando os dados são intermitentes. O exemplo da linha 5 nas tabelas da seção anterior ilustra essa lógica. Nessas linhas e nos exemplos a seguir, os **Evaluation Periods** (Períodos de avaliação) são 3, e o intervalo de avaliação é de 5 pontos de dados. Os **Datapoints to Alarm** (Pontos de dados para alarme) são 3, exceto para o exemplo M de N, em que os **Datapoints to Alarm** são 2.
Suponha que os dados mais recentes de um alarme sejam `- - - - X`, com quatro pontos de dados ausentes e um ponto de dados de violação como ponto de dados mais recente. Como o próximo ponto de dados pode não ser violado, o alarme não entra imediatamente no estado ALARM quando os dados são `- - - - X` ou `- - - X -` e **Datapoints to Alarm** (Pontos de dados para alarme) são 3. Desta forma, evitam-se os falsos positivos quando o próximo ponto de dados for de não violação e faz com que os dados sejam `- - - X O` ou `- - X - O`.
Porém, se os últimos pontos de dados forem `- - X - -`, o alarme entra no estado ALARM mesmo se os pontos de dados ausentes forem tratados como ausentes. Isso ocorre porque os alarmes são projetados para sempre entrar no estado ALARM quando o ponto de dados de violação mais antigo disponível durante o número de pontos de dados dos **Evaluation Periods** (Períodos de avaliação) é pelo menos tão antigo quanto o valor dos **Datapoints to Alarm** (Pontos de dados para alarme) e todos os outros pontos de dados mais recentes estão em violação ou ausentes. Neste caso, o alarme entra no estado ALARM mesmo que o número total de pontos de dados disponíveis seja inferior a M **Datapoints to Alarm** (Pontos de dados para alarme).
Essa lógica de alarme também se aplica a alarmes M de N. Se o ponto de dados em violação mais antigo durante o intervalo de avaliação for pelo menos tão antigo quanto o valor de **Datapoints to Alarm** (Pontos de dados para alarme), e todos os pontos de dados mais recentes estiverem em violação ou ausentes, o alarme entrará no estado ALARM para qualquer valor de M **Datapoints to Alarm** (Pontos de dados para alarme).
## Dados ausentes nos alarmes do CloudWatch Metrics Insights
** Alarmes baseados em consultas do Metrics Insights que se agregam em uma única série temporal **
Os cenários de dados ausentes e seus efeitos na avaliação dos alarmes são os mesmos de um alarme de métrica padrão em termos do tratamento configurado de dados perdidos. Consulte , [Configurar como os alarmes do CloudWatch tratam dados ausentes](#alarms-and-missing-data).
** Alarmes baseados em consultas do Metrics Insights que produzem várias séries temporais **
Os cenários de dados ausentes para os alarmes do Metrics Insights ocorrem quando:
+ Pontos de dados individuais dentro de uma série temporal não estão presentes.
+ Uma ou mais séries temporais desaparecem ao avaliar várias séries temporais.
+ Nenhuma série temporal é recuperada pela consulta.
Os cenários de dados ausentes afetam a avaliação do alarme da maneira a seguir:
+ Para a avaliação de uma série temporal, o tratamento de dados ausentes é aplicado a pontos de dados individuais dentro da série temporal. Por exemplo, se 3 pontos de dados fossem consultados para a série temporal, mas somente 1 fosse recebido, 2 pontos de dados seguiriam a configuração de dados ausentes configurada.
+ Se uma série temporal não for mais recuperada pela consulta, ela sofrerá transição para `OK`, não importando o tratamento de dados ausentes. As ações de alarme associadas à transição `OK` no nível do colaborador são executadas, e `StateReason` especifica que o colaborador mencionado acima não foi encontrado com a mensagem “Nenhum dado foi retornado para este colaborador”. O estado do alarme dependerá do estado dos outros contribuidores que forem recuperados pela consulta.
+ No nível do alarme, se a consulta retornar um resultado vazio (sem nenhuma série temporal), o alarme sofrerá transição para `INSUFFICIENT_DATA`, não importando o tratamento de dados ausentes definido.
# Como dados parciais são tratados
## Como os dados parciais de uma consulta do Metrics Insights são avaliados
Se a consulta ao Metrics Insights usada para o alarme corresponder a mais de 10.000 métricas, o alarme será avaliado com base nas primeiras 10.000 métricas encontradas pela consulta. Isso significa que o alarme está sendo avaliado com base em dados parciais.
Você pode usar os métodos a seguir para descobrir se um alarme do Metrics Insights está avaliando seu estado de alarme com base em dados parciais:
+ No console, se você escolher um alarme para ver a página **Details** (Detalhes), a mensagem **Evaluation warning: Not evaluating all data** (Aviso da avaliação: nem todos os dados estão sendo avaliados) será exibida nessa página.
+ Você vê o valor `PARTIAL_DATA` no campo `EvaluationState` quando usa o comando [describe-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/describe-alarms.html?highlight=describe%20alarms) da AWS CLI ou a API [DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html).
Os alarmes também publicam eventos no Amazon EventBridge quando ele entra no estado de dados parciais, para que você possa criar uma regra do EventBridge para observar esses eventos. Nesses eventos, o campo `evaluationState` tem o valor `PARTIAL_DATA`. Veja um exemplo a seguir.
```
{
"version": "0",
"id": "12345678-3bf9-6a09-dc46-12345EXAMPLE",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-11-08T11:26:05Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:my-alarm-name"
],
"detail": {
"alarmName": "my-alarm-name",
"state": {
"value": "ALARM",
"reason": "Threshold Crossed: 3 out of the last 3 datapoints [20000.0 (08/11/22 11:25:00), 20000.0 (08/11/22 11:24:00), 20000.0 (08/11/22 11:23:00)] were greater than the threshold (0.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-11-08T11:26:05.399+0000\",\"startDate\":\"2022-11-08T11:23:00.000+0000\",\"period\":60,\"recentDatapoints\":[20000.0,20000.0,20000.0],\"threshold\":0.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-11-08T11:25:00.000+0000\",\"value\":20000.0}]}",
"timestamp": "2022-11-08T11:26:05.401+0000",
"evaluationState": "PARTIAL_DATA"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2022-11-08T11:25:51.227+0000"
},
"configuration": {
"metrics": [
{
"id": "m2",
"expression": "SELECT SUM(PartialDataTestMetric) FROM partial_data_test",
"returnData": true,
"period": 60
}
]
}
}
}
```
Se a consulta para o alarme incluir uma instrução GROUP BY que retorne inicialmente mais de 500 séries temporais, o alarme será avaliado com base nas primeiras 500 séries temporais encontradas pela consulta. Porém, se você usar uma cláusula ORDER BY, todas as séries temporais que a consulta encontrar serão classificadas, e as 500 com os valores mais altos ou mais baixos, de acordo com sua cláusula ORDER BY, serão usadas para avaliar o alarme.
## Como dados parciais de um alarme com várias fontes de dados são avaliados
Se a função do Lambda retornar dados parciais:
+ O alarme continua a ser avaliado nos pontos de dados retornados.
+ É possível usar os métodos a seguir para descobrir se um alarme em uma função do Lambda está avaliando seu estado de alarme com base em dados parciais:
+ No console, escolha um alarme e escolha a página **Detalhes**. Se você vir a mensagem **Aviso de avaliação: Não avaliando todos os dados** surgir nessa página, ela está avaliando dados parciais.
+ Se você vir o valor `PARTIAL_DATA` no campo `EvaluationState` ao usar o comando `describe-alarms` da AWS CLI ou a API DescribeAlarms, ele está avaliando com base em dados parciais.
+ Um alarme também publica eventos no Amazon EventBridge ao entrar no estado de dados parciais.
# Alarmes baseados em percentil e exemplos de poucos dados
Quando você define um percentil como a estatística para um alarme, você pode especificar o que fazer quando não há dados suficientes para uma boa avaliação estatística. Você pode escolher que o alarme avalie a estatística de qualquer forma e possivelmente altere o estado do alarme. Ou você pode determinar que o alarme ignore a métrica enquanto o tamanho da amostra for baixo e esperar para avaliá-la até que haja dados suficientes para serem estatisticamente significativos.
Para percentis entre 0,5 (inclusive) e 1,00 (exclusive), essa configuração é usada quando há menos de 10/(1 percentil) pontos de dados durante o período de avaliação. Por exemplo, essa configuração seria usada se houvesse menos do que 1.000 amostras para um alarme em um p99 percentil. Para percentis entre 0 e 0,5 (exclusive), a configuração é usada quando há menos de 10/percentil pontos de dados.
# Alarmes do PromQL
Um alarme do PromQL monitora as métricas usando uma consulta instantânea do Prometheus Query Language (PromQL). A consulta seleciona as métricas ingeridas por meio do endpoint do OTLP do CloudWatch, e todas as séries temporais correspondentes retornadas pela consulta são consideradas em violação. O alarme avalia a consulta em um intervalo regular e rastreia cada série temporal em violação de forma independente como um *colaborador*.
Para obter informações sobre como ingerir métricas usando o OpenTelemetry, consulte [OpenTelemetry](CloudWatch-OpenTelemetry-Sections.md).
## Como funcionam os alarmes do PromQL
Um alarme do PromQL avalia uma consulta instantânea do PromQL em uma programação recorrente definida por `EvaluationInterval`. A consulta retorna somente as séries temporais que satisfazem a condição. Cada série temporal retornada é um *colaborador*, identificado por seu conjunto exclusivo de atributos.
O alarme usa transições de estado baseadas na duração:
+ Quando um colaborador é retornado pela consulta, isso é considerado *em violação*. Se o colaborador continuar violando pelo período especificado por `PendingPeriod`, ele fará a transição para o estado `ALARM`.
+ Quando um colaborador deixa de ser retornado pela consulta, ele é considerado *em recuperação*. Se o colaborador permanecer ausente pelo período especificado por `RecoveryPeriod`, ele voltará ao estado `OK`.
O alarme está no estado `ALARM` quando pelo menos um colaborador está em violação há mais tempo do que o período pendente. O alarme voltará ao estado `OK` quando todos os colaboradores tiverem se recuperado.
## Configuração de alarmes do PromQL
Um alarme do PromQL é configurado com os seguintes parâmetros:
+ **PendingPeriod** é a duração em segundos que um colaborador deve violar continuamente antes que ele faça a transição para o estado `ALARM`. Isso é equivalente à duração `for` da regra de alerta do Prometheus.
+ **RecoveryPeriod** é a duração em segundos que um colaborador deve parar de violar antes que ele volte ao estado `OK`. Isso é equivalente à duração `keep_firing_for` da regra de alerta do Prometheus.
+ **EvaluationInterval** é a frequência com que, em segundos, o alarme avalia a consulta do PromQL.
Para criar um alarme do PromQL, consulte [Criar um alarme usando uma consulta em PromQL](Create_PromQL_Alarm.md).
# Alarmes compostos
Com o CloudWatch, você pode combinar vários alarmes em um único *alarme composto* para criar um indicador de integridade resumido e agregado de toda uma aplicação ou grupo de recursos. Os alarmes compostos são alarmes que determinam seu estado monitorando os estados de outros alarmes. Você define regras para combinar o status desses alarmes monitorados usando a lógica booleana.
Você pode usar alarmes compostos para reduzir o ruído do alarme, tomando medidas apenas em um nível agregado. Por exemplo, você pode criar um alarme composto para enviar uma notificação à sua equipe de servidor Web se algum alarme relacionado ao seu servidor Web for acionado. Quando qualquer um desses alarmes entra no estado ALARME, o alarme composto entra no estado ALARME e envia uma notificação à sua equipe. Se outros alarmes relacionados ao seu servidor Web também entrarem no estado ALARME, sua equipe não será sobrecarregada com novas notificações, pois o alarme composto já notificou a equipe sobre a situação existente.
Você também pode usar alarmes compostos para criar condições de alarme complexas e realizar ações somente quando muitas condições diferentes forem atendidas. Por exemplo, é possível criar um alarme composto que combine um alarme de CPU e um alarme de memória e que só notificaria a sua equipe se os alarmes de CPU e de memória fossem acionados.
**Como usar alarmes compostos**
Ao usar alarmes compostos, você tem duas opções:
+ Configure as ações que você deseja executar somente no nível de alarme composto e crie os alarmes monitorados subjacentes sem ações.
+ Configure um conjunto diferente de ações no nível do alarme composto. Por exemplo, as ações de alarme composto podem envolver uma equipe diferente no caso de um problema generalizado.
Os alarmes compostos podem executar apenas as seguintes ações:
+ Notificar tópicos do Amazon SNS
+ Invocar funções do Lambda
+ Criar OpsItems no centro operacional do Systems Manager
+ Criar incidentes no Systems Manager Incident Manager
**nota**
Todos os alarmes subjacentes em seu alarme composto devem estar na mesma conta e na mesma região que seu alarme composto. No entanto, se você configurar um alarme composto em uma conta de monitoramento da observabilidade entre contas do CloudWatch, os alarmes subjacentes poderão observar métricas em contas de origem diferentes e na própria conta de monitoramento. Para obter mais informações, consulte [Observabilidade entre contas do CloudWatch](CloudWatch-Unified-Cross-Account.md).
Um único alarme composto pode monitorar 100 alarmes subjacentes, e 150 alarmes compostos podem monitorar um único alarme subjacente.
**Expressões de regra**
Todos os alarmes compostos contêm expressões de regras. As expressões de regras informam aos alarmes compostos quais outros alarmes devem ser monitorados e determinam seus estados iniciais. Uma expressão de regra pode se referir a alarmes de métrica e a alarmes compostos. Ao fazer referência a um alarme em uma expressão de regra, você designa uma função para o alarme que determina em qual destes três estados o alarme estará:
+ ALARME
ALARM ("alarm-name ou alarm-ARN") será TRUE se o alarme estiver no estado ALARM (ALARME).
+ OK
OK ("alarm-name ou alarm-ARN") será TRUE se o alarme estiver no estado OK.
+ INSUFFICIENT\$1DATA
INSUFFICIENT\$1DATA ("alarm-name ou alarm-ARN") será TRUE se o alarme nomeado estiver no estado INSUFFICIENT\$1DATA (DADOS\$1INSUFICIENTES).
**nota**
TRUE (VERDADEIRO) é sempre avaliado como VERDADEIRO, e FALSE (FALSO) é sempre avaliado como FALSO.
**Referências de alarme**
Ao referenciar um alarme, usando o nome ou o ARN do alarme, a sintaxe da regra pode exigir que a referência ao nome ou ao ARN do alarme seja com ou sem aspas (").
+ Se a especificação for sem aspas, nomes ou ARNs de alarme não deverão conter espaços, parênteses nem vírgulas.
+ Se a especificação for com aspas, os nomes ou ARNs de alarme que *incluírem* aspas duplas (") deverão colocar as aspas entre caracteres de escape de barra invertida (\$1) para que a referência seja interpretada corretamente.
**Sintaxe**
A sintaxe da expressão usada para combinar vários alarmes em um alarme composto usa lógica e funções booleanas. A tabela a seguir descreve os operadores e as funções disponíveis nas expressões de regra:
| Operador/função | Descrição |
| --- | --- |
| AND | Operador lógico AND. Retorna TRUE quando todas as condições especificadas são TRUE. |
| OR | Operador lógico OR. Retorna TRUE quando, pelo menos, uma das condições especificadas é TRUE. |
| NOT | Operador lógico NOT. Retorna TRUE quando a condição especificada é FALSE. |
| AT\$1LEAST | Função que retorna TRUE quando um número ou porcentagem mínima de alarmes especificados está no estado exigido. Formato: AT\$1LEAST(M, STATE\$1CONDITION, (alarm1, alarm2, ...alarmN)) onde M pode ser um número absoluto ou uma porcentagem (por exemplo, 50%) e STATE\$1CONDITION pode ser ALARM, OK, INSUFFICIENT\$1DATA, NOT ALARM, NOT OK ou NOT INSUFFICIENT\$1DATA. |
Você pode usar parênteses para agrupar condições e controlar a ordem de avaliação de expressões complexas.
**Exemplos de expressões**
Como o parâmetro da solicitação `AlarmRule` é compatível com o uso dos operadores lógicos `AND`, `OR` e `NOT`, e com a função `AT_LEAST`, é possível combinar várias funções em uma única expressão. Os exemplos de expressões a seguir mostram como os alarmes subjacentes podem ser configurados no alarme composto:
+ `ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)`
A expressão especifica que o alarme composto só passará a `ALARM` se `CPUUtilizationTooHigh` e `DiskReadOpsTooHigh` estiverem no estado `ALARM`.
+ `AT_LEAST(2, ALARM, (WebServer1CPU, WebServer2CPU, WebServer3CPU, WebServer4CPU))`
A expressão especifica que o alarme composto entre no estado `ALARM` quando, pelo menos, 2 dos 4 alarmes da CPU do servidor Web estiverem no estado de `ALARM`. Isso permite acionar alertas com base em um limite de recursos afetados, em vez de exigir que todos, ou apenas um, estejam em estado de alarme.
+ `AT_LEAST(50%, OK, (DatabaseConnection1, DatabaseConnection2, DatabaseConnection3, DatabaseConnection4))`
A expressão especifica que o alarme composto entre no estado de `ALARM` quando, pelo menos, 50% dos alarmes de conexão do banco de dados estiverem no estado de `OK`. O uso de porcentagens permite que a regra se adapte dinamicamente à medida que você adiciona ou remove alarmes monitorados.
+ `ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)`
A expressão especifica que o alarme composto passará a `ALARM` se `CPUUtilizationTooHigh` estiver no estado `ALARM` e `DeploymentInProgress` não estiver no estado `ALARM`. Este é um exemplo de um alarme composto que reduz o ruído do alarme durante uma janela de implantação.
+ `AT_LEAST(2, ALARM, (AZ1Health, AZ2Health, AZ3Health)) AND NOT ALARM(MaintenanceWindow)`
A expressão especifica que o alarme composto passe para o estado de `ALARM` quando, pelo menos, 2 dos 3 alarmes de integridade da zona de disponibilidade estiverem no estado de `ALARM` e o alarme da janela de manutenção não estiver no estado de `ALARM`. Isso combina a função AT\$1LEAST com outros operadores lógicos em cenários de monitoramento mais complexos.
# Supressão de alarmes
A supressão da ação de alarme composta permite que você desative temporariamente as ações de alarme sem excluir ou modificar a configuração do alarme. Isso é útil durante manutenções planejadas, implantações ou ao investigar problemas conhecidos.
Com a supressão da ação de alarme composto, você define um alarme como supressor. Os alarmes supressores impedem que os alarmes compostos realizem ações. Por exemplo, você pode especificar um alarme supressor que represente o status de um recurso de suporte. Se o recurso de suporte estiver inativo, o alarme supressor impedirá que o alarme composto envie notificações.
## Quando usar a supressão de alarmes
Situações comuns em que a supressão de alarmes é útil:
+ Janelas de manutenção da sua aplicação
+ Implantações de aplicações
+ Investigação de incidentes em andamento
+ Atividades de teste e desenvolvimento
## Como funcionam os alarmes supressores
Você especifica alarmes supressores ao configurar alarmes compostos. Qualquer alarme pode funcionar como um alarme supressor. Quando o estado do alarme supressor muda de `OK` para `ALARM`, o alarme composto para de realizar ações. Quando o estado do alarme supressor muda de `ALARM` para `OK`, o alarme composto volta a realizar ações.
Como os alarmes compostos permitem que você tenha uma visão agregada da sua integridade em vários alarmes, há situações comuns em que é esperado que esses alarmes sejam acionados. Por exemplo, durante uma janela de manutenção da sua aplicação ou quando você investiga um incidente em andamento. Nessas situações, talvez você queira suprimir as ações de seus alarmes compostos para evitar notificações indesejadas ou a criação de novos tíquetes de incidentes.
Com a supressão da ação de alarme composto, você define um alarme como supressor. Os alarmes supressores impedem que os alarmes compostos realizem ações. Por exemplo, você pode especificar um alarme supressor que represente o status de um recurso de suporte. Se o recurso de suporte estiver inativo, o alarme supressor impedirá que o alarme composto envie notificações. A supressão da ação do alarme composto ajuda a reduzir o ruído do alarme. Assim, você leva menos tempo gerenciando alarmes e mais tempo se concentrando em suas operações.
Você especifica alarmes supressores ao configurar alarmes compostos. Qualquer alarme pode funcionar como um alarme supressor. Quando o estado do alarme supressor muda de `OK` para `ALARM`, o alarme composto para de realizar ações. Quando o estado do alarme supressor muda de `ALARM` para `OK`, o alarme composto volta a realizar ações.
### `WaitPeriod` e da `ExtensionPeriod`
Ao especificar um alarme supressor, você define os parâmetros `WaitPeriod` e `ExtensionPeriod`. Esses parâmetros evitam que alarmes compostos realizem ações inesperadamente quando os alarmes supressores mudam de estado. Use o parâmetro `WaitPeriod` para compensar qualquer atraso que possa ocorrer quando um alarme supressor muda de `OK` para `ALARM`. Por exemplo, se um alarme supressor mudar de `OK` para `ALARM` no período de 60 segundos, defina `WaitPeriod` como 60 segundos.
![\[Supressão de ações no WaitPeriod\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/example1border.png)
Na imagem, o alarme composto muda de `OK` para `ALARM` em t2. Um `WaitPeriod` começa em t2 e termina em t8. Isso dá ao alarme supressor tempo para mudar o estado de `OK` para `ALARM` em t4 antes de suprimir as ações do alarme composto quando o `WaitPeriod` termina em t8.
Use o parâmetro `ExtensionPeriod` para compensar qualquer atraso que possa ocorrer quando um alarme composto muda para `OK` depois que um alarme supressor muda para `OK`. Por exemplo, se um alarme composto mudar para `OK` no período de 60 segundos após a mudança de um alarme supressor para `OK`, defina `ExtensionPeriod` como 60 segundos.
![\[Supressão de ações no ExtensionPeriod\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/example2border.png)
Na imagem, o alarme supressor muda de `ALARM` para `OK` em t2. Um `ExtensionPeriod` começa em t2 e termina em t8. Isso dá ao alarme composto tempo para mudar de `ALARM` para `OK` antes do final do `ExtensionPeriod` em t8.
Alarmes compostos não realizam ações quando `WaitPeriod` e `ExtensionPeriod` se tornam ativos. Os alarmes compostos realizam ações baseadas em seus estados atuais quando `ExtensionPeriod` e `WaitPeriod` se tornam inativos. Recomendamos que você defina o valor de cada parâmetro como 60 segundos, pois os alarmes de métricas são avaliados a cada minuto. Você pode definir os parâmetros como qualquer número inteiro em segundos.
Os exemplos a seguir descrevem mais detalhadamente como `WaitPeriod` e `ExtensionPeriod` impedem que alarmes compostos realizem ações inesperadas.
**nota**
Nos exemplos a seguir, `WaitPeriod` está configurado como 2 unidades de tempo e `ExtensionPeriod` está configurado como 3 unidades de tempo.
#### Exemplos
** Exemplo 1: as ações não são suprimidas após o `WaitPeriod` **
![\[primeiro exemplo de supressão de ação\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/example3border.png)
Na imagem, o alarme composto muda do estado de `OK` para `ALARM` em t2. Um `WaitPeriod` começa em t2 e termina em t4, para evitar que o alarme composto realize uma ação. Depois que o `WaitPeriod` termina em t4, o alarme composto realiza as ações porque o alarme supressor ainda está no estado `OK`.
**Exemplo 2: as ações são suprimidas pelo alarme antes no final do `WaitPeriod` **
![\[segundo exemplo de supressão de ação\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/example4border.png)
Na imagem, o alarme composto muda do estado de `OK` para `ALARM` em t2. Um `WaitPeriod` começa em t2 e termina em t4. Isso dá ao alarme supressor tempo para mudar o estado de `OK` para `ALARM` em t3. Como o alarme supressor muda do estado de `OK` para `ALARM` em t3, o `WaitPeriod` que começou em t2 é descartado e o alarme supressor agora impede que o alarme composto realize ações.
** Exemplo 3: transição de estado quando as ações são suprimidas pelo `WaitPeriod` **
![\[terceiro exemplo de supressão de ação\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/example5border.png)
Na imagem, o alarme composto muda do estado de `OK` para `ALARM` em t2. Um `WaitPeriod` começa em t2 e termina em t4. Isso dá ao alarme supressor tempo para mudar de estado. O alarme composto volta para `OK` em t3 e o `WaitPeriod` que começou em t2 é descartado. Um novo `WaitPeriod` começa em t3 e termina em t5. Quando o novo `WaitPeriod` termina em t5, o alarme composto realiza as ações.
** Exemplo 4: transição de estado quando as ações são suprimidas pelo alarme **
![\[quarto exemplo de supressão de ação\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/cwasexamplefourborder.png)
Na imagem, o alarme composto muda do estado de `OK` para `ALARM` em t2. O alarme supressor já está no estado `ALARM`. O alarme supressor impede que o alarme composto realize ações.
** Exemplo 5: as ações não são suprimidas após o `ExtensionPeriod` **
![\[quinto exemplo de supressão de ação\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/example7border.png)
Na imagem, o alarme composto muda do estado de `OK` para `ALARM` em t2. Um `WaitPeriod` começa em t2 e termina em t4. Isso dá ao alarme supressor tempo para mudar o estado de `OK` para `ALARM` em t3 antes de suprimir as ações do alarme composto até t6. Como o alarme supressor muda do estado de `OK` para `ALARM` em t3, o `WaitPeriod` que começou em t2 é descartado. Em t6, o alarme supressor muda para `OK`. Um `ExtensionPeriod` começa em t6 e termina em t9. Depois que o `ExtensionPeriod` termina, o alarme composto realiza as ações.
** Exemplo 6: transição de estado quando as ações são suprimidas pelo `ExtensionPeriod` **
![\[sexto exemplo de supressão de ação\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/cwasexamplesixrborder.png)
Na imagem, o alarme composto muda do estado de `OK` para `ALARM` em t2. Um `WaitPeriod` começa em t2 e termina em t4. Isso dá ao alarme supressor tempo para mudar o estado de `OK` para `ALARM` em t3 antes de suprimir as ações do alarme composto até t6. Como o alarme supressor muda do estado de `OK` para `ALARM` em t3, o `WaitPeriod` que começou em t2 é descartado. Em t6, o alarme supressor volta para `OK`. Um `ExtensionPeriod` começa em t6 e termina em t9. Quando o alarme composto volta para `OK` em t7, o `ExtensionPeriod` é descartado e um novo `WaitPeriod` começa em t7 e termina em t9.
**dica**
Se você substituir o alarme supressor de ação, qualquer `WaitPeriod` ou `ExtensionPeriod` ativo será descartado.
## Supressão de ações e regras de silenciamento
Quando as regras de supressão de ação e silenciamento de alarme estão ativas para um alarme composto, as regras de silenciamento têm precedência e suprimem todas as ações de alarme. Depois que a janela de silenciamento termina, a configuração de supressão de ação do alarme composto determina se as ações são executadas com base no estado do alarme supressor e nos períodos de espera ou extensão configurados. Para obter mais informações sobre regras de silenciamento de alarmes, consulte [Regras de silenciamento de alarmes](alarm-mute-rules.md).
# Ações de alarme
É possível especificar quais ações um alarme realizará ao mudar de estado entre os estados OK, ALARM e INSUFFICIENT\$1DATA.
A maioria das ações pode ser definida para a transição para cada um dos três estados. Com exceção das ações do Auto Scaling, as ações acontecem somente em transições de estado e não serão executadas novamente se a condição persistir por horas ou dias.
As ações apresentadas a seguir têm suporte como ações de alarme:
+ Notificar um ou mais assinantes ao usar um tópico do Amazon Simple Notification Service. Os assinantes podem ser aplicações e também pessoas.
+ Invocar uma função do Lambda. Essa é a maneira mais fácil de automatizar ações personalizadas em alterações de estado de alarme.
+ Os alarmes baseados em métricas do EC2 também podem executar ações do EC2, como interromper, encerrar, reinicializar ou recuperar uma instância do EC2.
+ Os alarmes podem executar ações para escalar um grupo do Auto Scaling.
+ Os alarmes podem criar OpsItems no OpsCenter do Systems Manager ou criar incidentes no AWS Systems Manager Incident Manager. Essas ações são executadas apenas quando o alarme entra no estado ALARM (ALARME).
+ Um alarme pode iniciar uma investigação quando entra no estado ALARM.
Os alarmes também emitem eventos para Amazon EventBridge quando mudam de estado, e você pode configurar o Amazon EventBridge para acionar outras ações para essas mudanças de estado.
## Ações e notificações de alarmes
A tabela a seguir mostra as ações executadas para alarmes junto com seu comportamento para alarmes de várias séries temporais (ou colaboradores):
| Tipo de ação | Compatível com vários alarmes de séries temporais do Metrics Insights | Compatível com alarmes do PromQL | Mais informações |
| --- | --- | --- | --- |
| Notificações do SNS | Nível do colaborador | Nível do colaborador | [Destinos de eventos do Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html) |
| Ações do EC2 (interromper, terminar, reinicializar, recuperar) | Não suportado | Sem compatibilidade | [Interrupção, encerramento, reinício ou recuperação de uma instância do EC2](UsingAlarmActions.md) |
| Ações do Auto Scaling | Não suportado | Sem compatibilidade | [Políticas de escalabilidade simples e em etapas do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) |
| Criação do OpsItem do Systems Manager | Nível do alarme | Não compatível | [Configurar alarmes do CloudWatch para criar OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) |
| Incidentes do Systems Manager Incident Manager | Nível do alarme | Não compatível | [Criação automática de incidentes com alarmes do CloudWatch](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html#incident-tracking-auto-alarms) |
| Invocação da função do Lambda | Nível do colaborador | Nível do colaborador | [Invocar uma função do Lambda de um alarme](alarms-and-actions-Lambda.md) |
| Investigações do CloudWatch | Nível do alarme | Não compatível | [Iniciar uma investigação do CloudWatch em um alarme](Start-Investigation-Alarm.md) |
O conteúdo das notificações de alarme varia de acordo com o tipo de alarme:
+ Os alarmes de métrica única incluem um motivo do estado e dados detalhados do motivo do estado, mostrando os pontos de dados específicos que causaram a alteração de estado.
+ Os alarmes de várias séries temporais do Metrics Insights fornecem um motivo do estado simplificado para cada colaborador, sem o bloco de dados detalhado do motivo do estado.
+ Os alarmes do PromQL não incluem um motivo do estado ou dados do motivo do estado em suas notificações.
**Example Exemplos de conteúdo de notificação**
A notificação de alarme de métrica única inclui dados detalhados:
```
{
"stateReason": "Threshold Crossed: 3 out of the last 3 datapoints [32.6 (03/07/25 08:29:00), 33.8 (03/07/25 08:24:00), 41.0 (03/07/25 08:19:00)] were greater than the threshold (31.0)...",
"stateReasonData": {
"version": "1.0",
"queryDate": "2025-07-03T08:34:06.300+0000",
"startDate": "2025-07-03T08:19:00.000+0000",
"statistic": "Average",
"period": 300,
"recentDatapoints": [41, 33.8, 32.6],
"threshold": 31,
"evaluatedDatapoints": [
{
"timestamp": "2025-07-03T08:29:00.000+0000",
"sampleCount": 5,
"value": 32.6
}
// Additional datapoints...
]
}
}
```
Exemplo de notificação de SNS de alarme do Metrics Insights de várias séries temporais para colaborador:
```
{
"AlarmName": "DynamoDBInsightsAlarm",
"NewStateValue": "ALARM",
"NewStateReason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "6d442278dba546f6",
"AlarmContributorAttributes": {
"TableName": "example-dynamodb-table-name"
}
// Additional information...
}
```
Exemplo de notificação do SNS de alarme do PromQL para colaborador:
```
{
"AlarmName": "HighCPUUsageAlarm",
"NewStateValue": "ALARM",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "1d502278dcd546a1",
"AlarmContributorAttributes": {
"team": "example-team-name"
}
// Additional information...
}
```
## Ações de silenciamento de alarme
As regras de silenciamento do alarme permitem silenciar automaticamente as ações do alarme durante janelas de tempo predefinidas, como períodos de manutenção ou eventos operacionais. O CloudWatch continua monitorando os estados de alarme enquanto evita notificações indesejadas. Para obter mais informações, consulte [Regras de silenciamento de alarmes](alarm-mute-rules.md).
**Regras de silenciamento versus desativação de ações de alarme**
As regras de silenciamento de alarme silenciam temporariamente as ações durante as janelas de horário programadas e restauram o som do alarme automaticamente quando a janela termina. Por outro lado, a API `DisableAlarmActions` desativa permanentemente as ações de alarme até que você chame `EnableAlarmActions` manualmente. A API `EnableAlarmActions` não ativa o som dos alarmes que sejam silenciados por regras ativas de silenciamento.
**nota**
Silenciar um alarme não impede que o CloudWatch envie eventos de alarme para criação, atualização, exclusão e alterações de estado de alarmes para o Amazon EventBridge.
# Regras de silenciamento de alarmes
As regras de silenciamento de alarmes são um atributo do CloudWatch que fornece um mecanismo para silenciar automaticamente as ações de alarme durante intervalos de tempo predefinidos. Ao criar uma regra de silenciamento, você define períodos de tempo específicos e seleciona alarmes cujas ações serão silenciadas. O CloudWatch continuará monitorando e avaliando os estados de alarme, evitando notificações indesejadas ou ações de alarme automatizadas durante eventos operacionais esperados.
As regras de silenciamento de alarmes ajudam você a gerenciar cenários operacionais críticos em que as ações de alarme seriam desnecessárias ou causariam interrupções. Por exemplo, durante as janelas de manutenção planejada, é possível evitar ações de alarme automatizadas enquanto seus sistemas estão intencionalmente off-line ou apresentam problemas esperados, permitindo que você realize a manutenção sem interrupções. Para operações fora do horário comercial, como fins de semana ou feriados, é possível silenciar ações de alarme não críticas quando a resposta imediata não for necessária, reduzindo o ruído do alarme e as notificações desnecessárias para sua equipe de operações. Em ambientes de teste, as regras de silenciamento permitem que você silencie temporariamente as ações de alarme durante cenários como testes de carga, em que o alto uso de recursos ou taxas de erro são esperadas e não exigem atenção imediata. Quando sua equipe está solucionando problemas ativamente, as regras de silenciamento permitem que você evite que ações de alarme duplicadas sejam acionadas, ajudando você a se concentrar na resolução sem se distrair com notificações de alarme redundantes.
## Definição das regras de silenciamento de alarmes
As regras de silenciamento do alarme podem ser definidas usando: **regras** e **destinos**.
+ **Regras**: definem as janelas de tempo em que as ações de alarme devem ser silenciadas. As regras são compostas por três atributos:
+ **Expressão**: define quando o período de silêncio começa e como ele se repete. É possível usar dois tipos de expressões:
+ **Expressões cron**: use a sintaxe padrão do cron para criar janelas de silenciamento recorrentes. Essa abordagem é ideal para programações de manutenção regulares, como atualizações semanais do sistema ou operações diárias de backup. As expressões cron permitem que você especifique padrões recorrentes complexos, incluindo dias específicos da semana, meses ou horários.
*Sintaxe da expressão cron*
```
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12) (or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6) (0 or 7 is Sunday, or MON-SUN)
│ │ │ │ │
│ │ │ │ │
* * * * *
```
+ Os caracteres `*`, `,`, `-` serão aceitos em todos os campos.
+ Nomes em inglês podem ser usados para os campos `month` (JAN-DEC) e `day of week` (SUN-SAT)
+ **Expressões at**: use expressões at para janelas de silenciamento únicas. Essa abordagem funciona bem para eventos operacionais planejados que ocorrem uma vez em um horário conhecido.
```
Syntax: `at(yyyy-MM-ddThh:mm)`
```
+ **Duração**: especifica quanto tempo a regra de silenciamento dura depois de ativada. A duração deve ser especificada no formato ISO-8601 com um mínimo de 1 minuto (PT1M) e máximo de 15 dias (P15D).
+ **Fuso horário**: especifica o fuso horário no qual a janela de silenciamento será aplicada de acordo com as expressões, usando identificadores de fuso horário padrão, como “America/Los\$1Angeles” ou “Europe/London”.
+ **Destinos**: especifica a lista de nomes de alarmes cujas ações serão silenciadas durante as janelas de tempo definidas. É possível incluir alarmes de métrica e alarmes compostos na sua lista de destinos.
Opcionalmente, é possível incluir carimbos de data/hora de início e término para fornecer limites adicionais para suas janelas de silenciamento. Os carimbos de data/hora de início garantem que as regras de silenciamento não sejam ativadas antes de uma data e hora específicas, enquanto os carimbos de data/hora de término evitam que as regras sejam aplicadas além da data e da hora especificadas.
Para obter mais informações sobre como criar regras de silenciamento de alarmes programaticamente, consulte [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html).
**nota**
Os alarmes direcionados devem estar presentes na mesma Conta da AWS e na mesma Região da AWS em que a regra de silenciamento foi criada.
Uma única regra de silenciamento de alarme pode atingir até 100 alarmes por nomes de alarmes.
O console do CloudWatch inclui uma guia dedicada “Regras de silenciamento de alarmes” que fornece gerenciamento centralizado de todas as regras de silenciamento dentro da sua Conta da AWS. É possível pesquisar regras de silenciamento específicas usando os atributos da regra de silenciamento, como nome da regra.
## Status de silenciamento da regra
Uma vez criada, uma regra de silenciamento de alarme pode estar em um dos três status abaixo:
+ **PROGRAMADA**: a regra de silenciamento ficará ativa em algum momento no futuro, de acordo com a expressão de janela de tempo configurada.
+ **ATIVA**: a regra de silenciamento está atualmente ativa de acordo com a expressão da janela de tempo configurada e silencia ativamente as ações de alarme direcionadas.
+ **EXPIRADA**: a regra de silenciamento não estará mais PROGRAMADA/ATIVA no futuro. Isso ocorre para regras de silenciamento únicas após o término da janela de silenciamento ou para regras de silenciamento recorrentes quando um carimbo de data/hora de término é configurado e esse tempo já decorreu.
## Efeitos das regras de silenciamento nos alarmes
Durante uma janela ativa de silenciamento, quando um alarme selecionado muda de estado e tem ações configuradas, o CloudWatch impede que essas ações sejam executadas. Os silenciamentos são aplicados somente às ações de alarme, o que significa que os alarmes continuam sendo avaliados e as mudanças de estado são visíveis no console do CloudWatch, mas as ações configuradas, como notificações do Amazon Simple Notification Service, ações de ajuste de escala automático do Amazon Elastic Compute Cloud ou ações do Amazon EC2, são impedidas de serem executadas. O CloudWatch continua avaliando os estados de alarme normalmente durante o período de silêncio, e é possível visualizar essas informações por meio do histórico de alarmes.
Quando uma janela de silenciamento se encerra, se os alarmes selecionados permanecerem em um estado de alarme (OK/ALARM/INSUFFICIENT\$1DATA), o CloudWatch acionará automaticamente as ações de alarme que foram silenciadas durante a janela. Isso garante que suas ações de alarme sejam executadas para problemas contínuos após o término do período de silenciamento planejado, mantendo a integridade do seu sistema de monitoramento.
**nota**
Quando você silencia um alarme:
Todas as ações associadas aos alarmes selecionados são silenciadas
Ações associadas a todos os estados de alarme (OK, ALARM e INSUFFICIENT\$1DATA) são silenciadas
## Visualização e gerenciamento de alarmes silenciados
Para obter mais informações sobre como visualizar e gerenciar alarmes silenciados, consulte [Visualização e gerenciamento de alarmes silenciados](viewing-managing-muted-alarms.md).
# Como funcionam as regras de silenciamento de alarmes
Os cenários a seguir ilustram como as regras de silenciamento de alarmes afetam os alarmes direcionados e como as ações de alarme são silenciadas ou executadas.
**nota**
O silenciamento de um alarme silenciará as ações associadas a todos os estados do alarme, incluindo OK, ALARM e INSUFFICIENT\$1DATA. Os comportamentos ilustrados abaixo se aplicam às ações associadas a todos os estados de alarme.
Quando você silencia um alarme do Metrics Insights, todas as séries métricas do colaborador desse alarme também são automaticamente silenciadas.
## Cenário: as ações de alarme são silenciadas quando uma regra de silenciamento está ativa
Considere que,
+ Um alarme tem ações configuradas para seu estado ALARME
+ Uma regra de silenciamento de alarme está programada para estar ativa de t1 a t5 que tem como destino o alarme
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-1.png)
+ Em **t0**: o alarme está no estado OK, o status da regra de silenciamento é PROGRAMADA
+ Em **t1**: o status da regra de silenciamento se torna ATIVA
+ Em **t2**: o alarme passa para o estado ALARME, a ação é silenciada, pois o alarme é efetivamente silenciado pela regra de silenciamento.
+ Em **t4**: o alarme retorna ao estado OK enquanto a regra de silenciamento ainda está ativa
+ Em **t5**: a regra de silenciamento fica inativa, mas nenhuma ação de ALARM é executada porque o alarme agora está no estado OK
## Cenário: a ação do alarme é silenciada quando a regra de silenciamento está ativa e é reativada após a janela de silenciamento
Considere que,
+ Um alarme tem ações configuradas para seu estado ALARME
+ Uma regra de silenciamento de alarme está programada para estar ativa de t1 a t5 que tem como destino o alarme
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-2.png)
+ Em **t0**: o alarme está no estado OK, o status da regra de silenciamento é PROGRAMADA
+ Em **t1**: o status da regra de silenciamento se torna ATIVA
+ Em **t2**: o alarme passa para o estado ALARME, a ação é silenciada, pois o alarme é efetivamente silenciado pela regra de silenciamento.
+ Em **t4**: a janela de silenciamento fica inativa, o alarme ainda está no estado ALARME
+ Em **t5**: a ação do alarme é executada porque a janela de silenciamento terminou e o alarme permanece no mesmo estado (ALARME) em que foi originalmente silenciado
## Cenário: várias regras de silenciamento de alarme sobrepostas
Considere que,
+ Um alarme tem ações configuradas para seu estado ALARME
Considere que existem duas regras de silenciamento,
+ Regra 1 de silenciamento de alarme: silencia o alarme de t1 para t5
+ Regra 2 de silenciamento de alarme: silencia o alarme de t3 para t9
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-3.png)
+ Em **t0**: o alarme está no estado OK, ambas as regras de silenciamento estão PROGRAMADAS
+ Em **t1**: a primeira regra de silenciamento se torna ATIVA
+ Em **t2**: o alarme sofre transição para o estado ALARM, a ação é silenciada
+ Em **t3**: a segunda regra de silenciamento se torna ATIVA
+ Em **t5**: a primeira regra de silenciamento fica inativa, mas a ação de alarme permanece silenciada porque a segunda regra de silenciamento ainda está ativa
+ Em **t8**: a ação do alarme é executada porque a segunda janela de silenciamento terminou e o alarme permanece no mesmo estado (ALARME) em que foi originalmente silenciado
## Cenário: ações de alarme silenciadas são executadas quando a atualização da regra de silenciar encerra a janela de silenciamento
Considere que,
+ Um alarme tem ações configuradas para seu estado ALARME
+ Uma regra de silenciamento de alarme está programada para estar ativa de t1 a t8 que tem como destino o alarme
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-4.png)
+ Em **t0**: o alarme está no estado OK, a regra de silenciamento está PROGRAMADA
+ Em **t1**: a regra de silenciamento se torna ATIVA
+ Em **t2**: o alarme sofre transição para o estado ALARME, as ações são silenciadas
+ Em **t6**: a configuração da regra de silenciamento é atualizada de forma que a janela de horário termine em t6. As ações de alarme são executadas imediatamente em t6 porque a regra de silenciamento não está mais ativa.
**nota**
O mesmo comportamento se aplica,
Se a regra de silenciamento for excluída em t6. A exclusão da regra de silenciamento remove imediatamente o silenciamento do alarme.
Se o alarme for removido dos destinos da regra de silenciamento (em t6), o alarme terá o silenciamento removido imediatamente.
## Cenário: novas ações são executadas se as ações de alarme forem atualizadas durante a janela de silenciamento
Considere que,
+ Um alarme tem ações configuradas para seu estado ALARME
+ Uma regra de silenciamento de alarme está programada para estar ativa de t1 a t8 que tem como destino o alarme
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-5.png)
+ Em **t0**: o alarme está no estado OK, a regra de silenciamento está PROGRAMADA. Uma ação do SNS é configurada com o estado de alarme ALARME.
+ Em **t1**: a regra de silenciamento se torna ATIVA
+ Em **t2**: o alarme sofre transição para o estado ALARME, a ação do SNS configurada é silenciada
+ Em **t6**: a configuração do alarme é atualizada para remover a ação do SNS e adicionar a ação do Lambda
+ Em **t8**: a ação do Lambda configurada para o alarme é executada porque a janela de silenciamento terminou e o alarme permanece no mesmo estado (ALARME) em que foi originalmente silenciado
**nota**
Se todas as ações de alarme forem removidas durante a janela de silenciamento (em t6 no exemplo acima), nenhuma ação será executada no final da janela de silenciamento (em t8 acima)
## Exemplos de programações para casos de uso comuns
Os exemplos a seguir mostram como configurar expressões de janela de tempo para casos de uso comuns.
**Cenário 1: silenciamento de ações de alarme durante janelas de manutenção programada**: atividades de manutenção regulares que ocorrem em um cronograma previsível, como atualizações do sistema ou do banco de dados quando os serviços estão intencionalmente indisponíveis ou operam em modo degradado.
+ Expressão cron `0 2 * * SUN` com duração `PT4H`: silencia os alarmes todos os domingos, das 2h às 6h, para manutenção semanal do sistema.
+ Expressão cron `0 1 1 * *` com duração `PT6H`: silencia os alarmes no primeiro dia de cada mês, das 1h às 7h, para manutenção mensal do banco de dados.
**Cenário 2: silenciamento de alarmes não críticos fora do horário comercial**: reduzir a fadiga de alertas durante fins de semana ou feriados, quando não é necessária atenção imediata.
+ Expressão cron `0 18 * * FRI` com duração `P2DT12H`: silencia os alarmes todo fim de semana, de sexta-feira às 18h até segunda-feira às 6h.
**Cenário 3: silenciamento de alarmes de performance durante as operações diárias de backup**: processos diários de backup automatizados que aumentam temporariamente a utilização dos recursos e podem acionar alarmes relacionados à performance durante intervalos de tempo previsíveis.
+ Expressão cron `0 23 * * *` com duração `PT2H`: silencia os alarmes todos os dias, das 23h à 1h, durante operações noturnas de backup que aumentam temporariamente a E/S do disco e a utilização da CPU.
**Cenário 4: silenciamento de alarmes duplicados durante sessões ativas de solução de problemas**: silenciamento temporário das ações de alarme enquanto as equipes investigam e resolvem problemas ativamente, evitando ruídos de notificação e permitindo uma resolução focada do problema.
+ Expressão at `at(2024-05-10T14:00)` com duração `PT4H`: silencia os alarmes em 10 de maio de 2024, das 14h às 18h, durante uma sessão ativa de resposta a incidentes.
**Cenário 5: silenciamento das ações de alarme durante as paralisações planejadas da empresa**: períodos de manutenção prolongados únicos ou desligamentos em toda a empresa em que todos os sistemas ficam intencionalmente off-line por longos períodos.
+ Expressão at `at(2024-12-23T00:00)` com duração `P7D`: silencia os alarmes durante toda a semana de 23 a 29 de dezembro de 2024 durante a paralisação anual da empresa.
# Limites
## Cotas gerais do CloudWatch
Para obter informações sobre as cotas de serviço gerais do CloudWatch que se aplicam aos alarmes, consulte [Cotas de serviço do CloudWatch](cloudwatch_limits.md).
## Limites que se aplicam a alarmes baseados em consultas do Metrics Insights
Ao trabalhar com os alarmes do CloudWatch Metrics Insights, esteja ciente destes limites funcionais:
+ Um padrão de 200 alarmes usando a consulta do Metrics Insights por conta por região
+ Somente as últimas três horas de dados podem ser usadas para avaliar as condições do alarme. No entanto, você pode visualizar até duas semanas de dados no grafo da página de detalhes do alarme.
+ Os alarmes que avaliam várias séries temporais limitarão o número de colaboradores em ALARM a 100
+ Supondo que a consulta recupere 150 séries temporais:
+ Se houver menos de 100 colaboradores em ALARME (por exemplo, 95), o `StateReason` será “95 de 150 séries temporais avaliadas para ALARME”
+ Se houver mais de 100 colaboradores em ALARM (por exemplo 105), o `StateReason` será “mais de 100 séries temporais avaliadas para ALARM”
+ Além disso, se o volume de atributos for muito grande, o número de colaboradores em ALARM poderá ser limitado a menos de 100.
+ Os limites do Metrics Insights quanto ao número máximo de séries temporais analisadas ou retornadas se aplicam.
+ Durante a avaliação do alarme, o `EvaluationState` será definido como `PARTIAL_DATA` para os limites a seguir:
+ Se a consulta do Metrics Insights retornar mais de 500 séries temporais.
+ Se a consulta do Metrics Insights corresponder a mais de 10.000 métricas.
Para obter mais informações sobre cotas de serviço do CloudWatch, consulte [Cotas de serviço do Metrics Insights do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html).
## Limites que se aplicam a alarmes baseados em consultas do PromQL
Ao trabalhar com os alarmes do PromQL do CloudWatch, esteja ciente destes limites funcionais:
+ Os alarmes que avaliam várias séries temporais limitarão o número de colaboradores em ALARM a 100
+ Se houver menos de 100 colaboradores em ALARM (por exemplo, 95), o `StateReason` será “95 séries temporais avaliadas para ALARM”
+ Se houver mais de 100 colaboradores em ALARM (por exemplo 105), o `StateReason` será “mais de 100 séries temporais avaliadas para ALARM”
+ Além disso, se o volume de atributos for muito grande, o número de colaboradores em ALARM poderá ser limitado a menos de 100.
+ Os limites do PromQL quanto ao número máximo de séries temporais analisadas ou retornadas se aplicam
+ Durante a avaliação do alarme, `EvaluationState` será definido como `PARTIAL_DATA` se a consulta do PromQL retornar mais de 500 séries temporais.
## Limites que se aplicam a alarmes baseados em fontes de dados conectadas
+ Quando o CloudWatch avalia um alarme, ele o faz a cada minuto, mesmo que o período para o alarme seja superior a um minuto. Para que o alarme funcione, a função do Lambda deve ser capaz de retornar uma lista de carimbos de data/hora começando em qualquer minuto, e não somente em múltiplos da duração do período. Esses carimbos de data/hora devem ser espaçados por uma duração do período.
Portanto, se a fonte de dados consultada pelo Lambda puder retornar somente carimbos de data/hora que sejam múltiplos da duração do período, a função deverá disponibilizar uma “nova amostragem” dos dados buscados para corresponder aos carimbos de data/hora esperados pela solicitação `GetMetricData`.
Por exemplo, um alarme com um período de cinco minutos é avaliado a cada minuto usando janelas de cinco minutos que mudam um minuto de cada vez. Neste caso:
+ Para a avaliação do alarme às 12:15:00, o CloudWatch espera pontos de dados com carimbos de data/hora de `12:00:00`, `12:05:00` e `12:10:00`.
+ Então, para a avaliação do alarme às 12:16:00, o CloudWatch espera pontos de dados com carimbos de data/hora de `12:01:00`, `12:06:00` e `12:11:00`.
+ Quando o CloudWatch avalia um alarme, todos os pontos de dados retornados pela função do Lambda que não estão alinhados com os carimbos de data/hora esperados são descartados, e o alarme é avaliado usando os pontos de dados esperados restantes. Por exemplo, quando o alarme é avaliado às `12:15:00`, ele espera dados com carimbos de data/hora de `12:00:00`, `12:05:00` e `12:10:00`. Se ele receber dados com carimbos de data/hora de `12:00:00`, `12:05:00`, `12:06:00` e `12:10:00`, os dados de `12:06:00` serão descartados e o CloudWatch avaliará o alarme usando os outros carimbos de data/hora.
Então, para a próxima avaliação às `12:16:00`, ele espera dados com carimbos de data/hora de `12:01:00`, `12:06:00` e `12:11:00`. Se tiver somente os dados com carimbos de data/hora de `12:00:00`, `12:05:00` e `12:10:00`, todos esses pontos de dados serão ignorados às 12:16:00, e o alarme realizará a transição para o estado de acordo com a forma como você o especificou para tratar dados ausentes. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
+ Recomendamos criar esses alarmes para executar ações quando eles realizarem a transição para o estado `INSUFFICIENT_DATA`, porque diversos casos de uso de falha da função do Lambda realizarão a transição do alarme para `INSUFFICIENT_DATA`, independentemente da forma como você o configurou para tratar dados ausentes.
+ Se a função do Lambda retornar um erro:
+ Se houver um problema de permissão ao chamar a função do Lambda, o alarme começará a realizar transições de dados ausentes de acordo com a forma como você o especificou para tratar dados ausentes quando o criou.
+ Qualquer outro erro proveniente da função do Lambda faz com que o alarme realize a transição para `INSUFFICIENT_DATA`.
+ Se a métrica solicitada pela função do Lambda tiver algum atraso de modo que o último ponto de dados esteja sempre ausente, você deverá usar uma solução alternativa. É possível criar um alarme “M out of N” ou aumentar o período de avaliação do alarme. Para obter mais informações sobre alarmes “M out of N”, consulte [Avaliação de alarme](alarm-evaluation.md).
# Introdução
**Topics**
+ [
# Criar alarmes
](Create-Alarms.md)
+ [
# Atuação em mudanças de alarmes
](Acting_Alarm_Changes.md)
+ [
# Configurar regras de silenciamento de alarme
](alarm-mute-rules-configure.md)
# Criar alarmes
**Topics**
+ [
# Criar um alarme do CloudWatch com base em um limite estático
](ConsoleAlarms.md)
+ [
# Criar um alarme do Cloudwatch com base em uma expressão matemática de métrica
](Create-alarm-on-metric-math-expression.md)
+ [
# Criar um alarme do CloudWatch com base na detecção de anomalias
](Create_Anomaly_Detection_Alarm.md)
+ [
# Crie um alarme baseado em uma consulta ao Metrics Insights de várias séries temporais
](multi-time-series-alarm.md)
+ [
# Criação de um alarme com base em uma fonte de dados conectada
](Create_MultiSource_Alarm.md)
+ [
# Criar um alarme usando uma consulta em PromQL
](Create_PromQL_Alarm.md)
+ [
# Alarmes nos logs
](Alarm-On-Logs.md)
+ [
# Criar um alarme composto
](Create_Composite_Alarm.md)
# Criar um alarme do CloudWatch com base em um limite estático
Escolha uma métrica do CloudWatch a ser observada pelo alarme e o limite dessa métrica. O alarme passará para o estado `ALARM` quando a métrica atingir o limite de um número especificado de períodos de avaliação.
Se você estiver criando um alarme em uma conta configurada como uma conta de monitoramento na observabilidade entre contas do CloudWatch, será possível configurar o alarme para observar uma métrica em uma conta de origem vinculada a essa conta de monitoramento. Para obter mais informações, consulte [Observabilidade entre contas do CloudWatch](CloudWatch-Unified-Cross-Account.md).
**Para criar um alarme com base em uma única métrica**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Select metric** (Selecionar métrica).
1. Execute um destes procedimentos:
+ Escolha o namespace do serviço que contém a métrica desejada. Continue escolhendo as opções à medida que elas são exibidas para restringir as escolhas. Quando uma lista de métricas for exibida, marque a caixa de seleção ao lado da métrica que você deseja.
+ Na caixa de pesquisa, insira o nome de uma métrica, ID de conta, rótulo de conta, dimensão ou ID de recurso. Escolha um dos resultados e continue até uma lista de métricas ser exibida. Marque a caixa de seleção ao lado da métrica que você deseja.
1. Escolha a guia **Graphed metrics (Métricas em gráfico)**.
1. Em **Statistic (Estatística)**, escolha uma das estatísticas ou percentis predefinidos ou especifique um percentil personalizado (por exemplo, **p95.45**).
1. Em **Período**, escolha o período de avaliação do alarme. Ao avaliar o alarme, todos os períodos são agregados em um único ponto de dados.
Também escolha se a legenda do eixo Y é exibida no lado esquerdo ou no lado direito enquanto você está criando o alarme. Essa preferência só é usada enquanto você está criando o alarme.
1. Escolha **Selecionar métrica**.
A página **Specify metric and conditions (Especificar métrica e condições)** será exibida, mostrando um gráfico e outras informações sobre a métrica e a estatística que você selecionou.
1. Em **Conditions (Condições)**, especifique o seguinte:
1. Em **Whenever *metric* is (Sempre que a métrica for)**, especifique se a métrica deve ser maior que, menor que ou igual ao limite. Em **than... (que...)**, especifique o valor limite.
1. Escolha **Additional configuration (Configuração adicional)**. Em **Datapoints to alarm (Pontos de dados para alarme)**, especifique quantos períodos de avaliação (pontos de dados) devem estar no estado `ALARM` para disparar o alarme. Se os dois valores forem correspondentes, você criará um alarme que passa para o estado `ALARM` se esses períodos consecutivos estiverem violando.
Para criar um alarme M de N, especifique um número menor para o primeiro valor que especificar para o segundo valor. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
1. Para o **Missing data treatment (Tratamento de dados ausentes)**, escolha como deseja que o alarme se comporte quando alguns pontos de dados estiverem ausentes. Para obter mais informações, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
1. Se o alarme usar um percentil como estatística monitorada, uma caixa **Percentiles with low samples (Percentis com amostras baixas)** será exibida. Use-a para escolher se deseja avaliar ou ignorar casos com taxas de amostra baixas. Se você escolher **ignore (maintain the alarm state) (ignorar (manter o estado do alarme))**, o estado do alarme atual será sempre mantido quando o tamanho da amostra for muito baixo. Para obter mais informações, consulte [Alarmes baseados em percentil e exemplos de poucos dados](percentiles-with-low-samples.md).
1. Escolha **Próximo**.
1. Em **Notification (Notificação)**, selecione um tópico do SNS para notificar quando o alarme estiver no estado `ALARM`, `OK` ou `INSUFFICIENT_DATA`.
Para que o alarme envie várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification (Adicionar notificação)**.
Na observabilidade entre contas do CloudWatch, você pode optar por enviar notificações para várias contas da AWS. Por exemplo, para a conta de monitoramento e também para a conta de origem.
Para que o alarme não envie notificações, escolha **Remove (Remover)**.
1. Para que o alarme execute ações do Auto Scaling, EC2, Lambda, investigação ou Systems Manager, escolha o botão apropriado e depois o estado do alarme e a ação a ser executada. Os alarmes só poderão executar ações do Systems Manager e de investigação ao entrarem no estado ALARM. Para obter mais informações sobre ações do Systems Manager, consulte [Configurar o CloudWatch para criar OpsItems a partir de alarmes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e [Criação de incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
Para que o alarme inicie uma investigação, escolha **Adicionar ação de investigação** e selecione o grupo de investigação. Para obter mais informações sobre , consulte [Investigações do CloudWatch](Investigations.md).
**nota**
Para criar um alarme que executa uma ação do SSM Incident Manager, é necessário ter determinadas permissões. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade para o AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Quando terminar, escolha **Next** (Próximo).
1. Digite um nome e uma descrição para o alarme. O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos. Escolha **Próximo**.
1. Em **Preview and create (Visualizar e criar)**, confirme se as informações e condições são o que você deseja e escolha **Create alarm (Criar alarme)**.
Também é possível adicionar alarmes a um painel. Para obter mais informações, consulte [Adição de um alarme a um painel do CloudWatch](add_alarm_dashboard.md).
# Criar um alarme do Cloudwatch com base em uma expressão matemática de métrica
Os alarmes de métricas são projetados para avaliar séries temporais que você define de uma única métrica ou de uma expressão matemática de métrica, que combina ou transforma uma ou mais métricas em uma série temporal que fornece insights mais alinhados às suas necessidades exclusivas. Para criar um alarme com base em uma expressão matemática métrica, escolha uma ou mais métricas do CloudWatch a serem usadas na expressão. Depois, especifique a expressão, o limite e os períodos de avaliação.
Não é possível criar um alarme com base na expressão **SEARCH**. Somente alarmes baseados em consultas SQL do Metrics Insights podem operar em várias séries temporais.
**Para criar um alarme com base em uma expressão matemática de métrica**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes) e depois escolha **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Select Metric** (Selecionar métrica) e, em seguida, execute uma das seguintes ações:
+ Selecione um namespace na lista suspensa **Namespaces da AWS** ou **Namespaces personalizados**. Depois de selecionar um namespace, continue escolhendo opções até que uma lista de métricas apareça, na qual você deve marcar a caixa de seleção ao lado da métrica correta.
+ Use a caixa de pesquisa para encontrar uma métrica, uma dimensão ou um ID de recurso. Depois de inserir a métrica, a dimensão ou o ID do recurso, continue escolhendo opções até que uma lista de métricas apareça, na qual você deve marcar a caixa de seleção ao lado da métrica correta.
1. (Opcional) Se quiser adicionar outra métrica a uma expressão matemática de métrica, você poderá usar a caixa de pesquisa para encontrar uma métrica específica. Você pode adicionar até dez métricas a uma expressão matemática de métrica.
1. Selecione a guia **Graphed metrics** (Representar métricas em gráficos). Para cada uma das métricas que você adicionou anteriormente, execute as seguintes ações:
1. Na coluna **Statistics** (Estatística), selecione o menu suspenso. No menu suspenso, escolha uma das estatísticas ou percentis predefinidos. Use a caixa de pesquisa no menu suspenso para especificar um percentil personalizado.
1. Na coluna **Period** (Período), selecione o menu suspenso. No menu suspenso, escolha um dos períodos de avaliação predefinidos.
Ao criar o alarme, você pode especificar se a legenda do eixo Y é exibida no lado esquerdo ou no lado direito do gráfico.
**nota**
Quando o CloudWatch avalia alarmes, os períodos são agregados em pontos de dados únicos.
1. Escolha o menu suspenso **Add math** (Adicionar matemática) e, em seguida, selecione **Start with an empty expression** (Começar com uma expressão vazia) da lista de expressões matemáticas de métrica predefinidas.
Depois de escolher **Start with an empty expression** (Começar com uma expressão vazia), uma caixa de expressão matemática aparecerá para que você possa aplicar ou editar expressões matemáticas.
1. Na caixa de expressão matemática, insira sua expressão matemática e, em seguida, escolha **Apply** (Aplicar).
Depois de escolher **Apply** (Aplicar), uma coluna de **ID** aparece ao lado da coluna **Label** (Rotular).
Para usar uma métrica ou o resultado de outra expressão matemática de métricas como parte da fórmula de sua expressão matemática atual, use o valor que é mostrado na coluna **ID**. Para alterar o valor de **ID**, selecione o ícone de caneta e papel ao lado do valor atual. O novo valor deve começar com uma letra minúscula e pode incluir números, letras e o símbolo de sublinhado. Alterar o valor do **ID** para um nome mais significativo também pode tornar o gráfico do alarme mais fácil de entender.
Para obter informações sobre as funções disponíveis para matemática de métrica, consulte [Sintaxe de funções da matemática métricas](using-metric-math.md#metric-math-syntax).
1. (Opcional) Adicione mais expressões matemáticas usando as métricas e os resultados de outras expressões matemáticas nas fórmulas das novas expressões matemáticas.
1. Quando você tiver a expressão a ser usada no alarme, desmarque as caixas de seleção à esquerda de todas as outras expressões e métricas na página. Somente a caixa de seleção ao lado da expressão a ser usada no alarme deve estar marcada. A expressão escolhida para o alarme deve produzir uma única série temporal e só mostrar uma linha no gráfico. Depois, escolha **Select metric (Selecionar métrica)**.
A página **Specify metric and conditions (Especificar métrica e condições)** será exibida, mostrando um gráfico e outras informações sobre a expressão matemática que você selecionou.
1. Em **Whenever *expression* is (Sempre que a expressão for)**, especifique se a expressão deverá ser maior que, menor que ou igual ao limite. Em **than... (que...)**, especifique o valor limite.
1. Escolha **Additional configuration (Configuração adicional)**. Em **Datapoints to alarm (Pontos de dados para alarme)**, especifique quantos períodos de avaliação (pontos de dados) devem estar no estado `ALARM` para disparar o alarme. Se os dois valores forem correspondentes, você criará um alarme que passa para o estado `ALARM` se esses períodos consecutivos estiverem violando.
Para criar um alarme M de N, especifique um número menor para o primeiro valor que especificar para o segundo valor. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
1. Para o **Missing data treatment (Tratamento de dados ausentes)**, escolha como deseja que o alarme se comporte quando alguns pontos de dados estiverem ausentes. Para obter mais informações, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
1. Escolha **Próximo**.
1. Em **Notification (Notificação)**, selecione um tópico do SNS para notificar quando o alarme estiver no estado `ALARM`, `OK` ou `INSUFFICIENT_DATA`.
Para que o alarme envie várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification (Adicionar notificação)**.
Para que o alarme não envie notificações, escolha **Remove (Remover)**.
1. Para que o alarme execute ações do Auto Scaling, Amazon EC2, Lambda ou Systems Manager, escolha o botão apropriado e depois o estado do alarme e a ação a ser executada. Se você escolher uma função do Lambda como uma ação de alarme, especifique o nome da função ou o ARN e, opcionalmente, você poderá escolher uma versão específica da função.
Os alarmes só poderão executar ações do Systems Manager ao entrarem no estado ALARM. Para obter mais informações sobre ações do Systems Manager, consulte [Configurar o CloudWatch para criar OpsItems a partir de alarmes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e [Criação de incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**nota**
Para criar um alarme que executa uma ação do SSM Incident Manager, é necessário ter determinadas permissões. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade para o AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Quando terminar, escolha **Next** (Próximo).
1. Digite um nome e uma descrição para o alarme. Escolha **Próximo**.
O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Em **Preview and create (Visualizar e criar)**, confirme se as informações e condições são o que você deseja e escolha **Create alarm (Criar alarme)**.
Também é possível adicionar alarmes a um painel. Para obter mais informações, consulte [Adição de um alarme a um painel do CloudWatch](add_alarm_dashboard.md).
# Criar um alarme do CloudWatch com base na detecção de anomalias
E possível criar um alarme com base na detecção de anomalias do CloudWatch, que analisa dados de métrica anteriores e cria um modelo de valores esperados. Os valores esperados levam em conta os padrões típicos por hora, dia e semana na métrica.
Defina um valor para o limite de detecção de anomalias, e o CloudWatch usará esse limite com o modelo para determinar o intervalo “normal” de valores para a métrica. Um valor mais alto para o limite produz uma faixa mais larga de valores "normais".
Você pode escolher se o alarme deve ser acionado quando o valor da métrica estiver acima do segmento de valores esperados, abaixo do segmento ou acima ou abaixo do segmento.
Você também pode criar alarmes de detecção de anomalias em métricas únicas e nas saídas de expressões matemáticas métricas. É possível usar essas expressões para criar gráficos de visualização de bandas de detecção de anomalias.
Em uma conta configurada como uma conta de monitoramento para a observabilidade entre contas do CloudWatch, você pode criar detectores de anomalias em métricas em contas de origem, além de métricas na conta de monitoramento.
Para obter mais informações, consulte [Usar a detecção de anomalias do CloudWatch](CloudWatch_Anomaly_Detection.md).
**nota**
Se você já estiver usando a detecção de anomalias para fins de visualização de uma métrica no console de métricas e criar um alarme de detecção de anomalias nessa mesma métrica, o limite que você definiu para o alarme não muda o limite já definido para visualização. Para obter mais informações, consulte [Criar um gráfico](graph_a_metric.md#create-metric-graph).
**Para criar um alarme com base em detecção de anomalias**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Select metric** (Selecionar métrica).
1. Execute um destes procedimentos:
+ Escolha o namespace de serviço que contém sua métrica e, em seguida, continue escolhendo as opções conforme elas aparecerem para limitar suas opções. Quando uma lista de métricas for exibida, marque a caixa de seleção ao lado da sua métrica.
+ Na caixa de pesquisa, digite o nome de uma métrica, dimensão ou ID de recurso. Selecione um dos resultados e continue escolhendo as opções apresentadas até que uma lista de métricas seja exibida. Marque a caixa de seleção ao lado de sua métrica.
1. Escolha **Métricas em gráficos**.
1. (Opcional) Em *Estatística*, escolha o menu suspenso e selecione uma das estatísticas ou percentis predefinidos. Você pode usar a caixa de pesquisa no menu suspenso para especificar um percentil personalizado, p. ex., **p95.45**.
1. (Opcional) Em *Período*, escolha o menu suspenso e selecione um dos períodos de avaliação predefinidos.
**nota**
Quando o CloudWatch avalia seu alarme, ele agrega o período em um só ponto de dados. Para alarmes de detecção de anomalias, o período de avaliação deve ser de um minuto ou mais.
1. Escolha **Próximo**.
1. Em ***Condições***, especifique o seguinte:
1. Selecione **Anomaly detection (Detecção de anomalias)**.
Se o modelo para essa métrica e estatística existir, o CloudWatch exibirá uma pré-visualização da faixa de detecção de anomalias no gráfico que se encontra na parte superior da tela. Após a criação do alarme, pode demorar até 15 minutos para que a faixa de detecção de anomalias real apareça no gráfico. Antes disso, a faixa que você visualiza será uma aproximação da faixa de detecção de anomalias.
**dica**
Para visualizar o gráfico na parte superior da tela por um período mais longo, escolha **Edit** (Editar) no canto superior direito da tela.
Se o modelo para essa métrica e estatística ainda não existir, o CloudWatch gerará a faixa de detecção de anomalias após você concluir a criação do alarme. Para novos modelos, pode demorar até três horas para que a faixa de detecção de anomalias real apareça no gráfico. Pode demorar até duas semanas para que o novo modelo seja treinado, então a faixa de detecção de anomalias mostrará valores esperados mais precisos.
1. Em **Whenever *metric* is** (Quando a métrica for), especifique quando acionar o alarme. Por exemplo, quando a métrica for maior que, menor que, ou fora da banda (em qualquer direção).
1. Em **Anomaly detection threshold (Limite de detecção de anomalias)**, escolha o número a ser usado para o limite de detecção de anomalias. Um número mais alto cria uma faixa mais espessa de valores "normais" que é mais tolerante a mudanças na métrica. Um número mais baixo cria uma faixa mais fina que entrará no estado `ALARM` com desvios menores na métrica. Não é necessário que o número seja um número inteiro.
1. Escolha **Additional configuration (Configuração adicional)**. Em **Datapoints to alarm (Pontos de dados para alarme)**, especifique quantos períodos de avaliação (pontos de dados) devem estar no estado `ALARM` para disparar o alarme. Se os dois valores forem correspondentes, você criará um alarme que passa para o estado `ALARM` se esses períodos consecutivos estiverem violando.
Para criar um alarme M de um alarme N, especifique um número para o primeiro valor que seja menor do que o segundo valor. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
1. Em **Missing data treatment** (Tratamento de dados ausentes), escolha como deseja que o alarme se comporte quando alguns pontos de dados estiverem ausentes. Para obter mais informações, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
1. Se o alarme usar um percentil como estatística monitorada, uma caixa **Percentiles with low samples (Percentis com amostras baixas)** será exibida. Use-a para escolher se deseja avaliar ou ignorar casos com taxas de amostra baixas. Se você escolher **Ignore (maintain the alarm state)** (Ignorar (manter o estado do alarme)), o estado do alarme atual será sempre mantido quando o tamanho da amostra for muito baixo. Para obter mais informações, consulte [Alarmes baseados em percentil e exemplos de poucos dados](percentiles-with-low-samples.md).
1. Escolha **Próximo**.
1. Em **Notification (Notificação)**, selecione um tópico do SNS para notificar quando o alarme estiver no estado `ALARM`, `OK` ou `INSUFFICIENT_DATA`.
Para enviar várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification (Adicionar notificação)**.
Escolha **Remove (Remover)** Se não quiser que o alarme envie notificações.
1. É possível configurar o alarme para executar ações do EC2 ou invocar uma função do Lambda quando ele mudar de estado, ou para criar um OpsItem ou incidente do Systems Manager quando ele entrar no estado ALARM. Para fazer isso, escolha o botão apropriado e, em seguida, escolha o estado do alarme e a ação a ser executada.
Se você escolher uma função do Lambda como uma ação de alarme, especifique o nome da função ou o ARN e, opcionalmente, você poderá escolher uma versão específica da função.
Para obter mais informações sobre ações do Systems Manager, consulte [Configurar o CloudWatch para criar OpsItems a partir de alarmes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e [Criação de incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**nota**
Para criar um alarme que executa uma ação do AWS Systems Manager Incident Manager, é necessário ter determinadas permissões. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade para o AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Escolha **Próximo**.
1. Em ***Name and description*** (Nome e descrição), insira um nome e uma descrição para o alarme e selecione **Next** (Próximo). O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
**dica**
O nome do alarme deve conter somente caracteres UTF-8 e não pode conter caracteres de controle ASCII
1. Em ***Preview and create*** (Previsualizar e criar), confirme se as informações e condições do seu alarme estão corretas e escolha **Create alarm** (Criar alarme).
## Editar um modelo de detecção de anomalias
Depois de criar um alarme, você pode ajustar o modelo de detecção de anomalias. É possível excluir determinados períodos de tempo para que não sejam usados na criação do modelo. É fundamental excluir eventos incomuns, como interrupções do sistema, implantações e feriados, dos dados de treinamento. Também é possível especificar se deseja ajustar o modelo para alterações de horário de verão.
**Para editar o modelo de detecção de anomalias para um alarme**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Escolha o nome do alarme. Se necessário, use a caixa de pesquisa para encontrar o alarme.
1. Escolha **Visualizar**, **Em métricas**.
1. Na coluna **Detalhes**, escolha a palavra-chave **ANOMALY\$1DETECTION\$1BAND** e depois **Editar modelo de detecção de anomalias** no pop-up.
![\[A guia Métricas em gráficos com o menu pop-up ANOMALY_DETECTION_BAND exibido.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
1. Para excluir um período de tempo de ser usado para produzir o modelo, escolha o ícone de calendário para **Data de término**. Em seguida, selecione ou insira os dias e horários a serem excluídos do treinamento e escolha **Apply** (Aplicar).
1. Se a métrica for sensível a alterações no horário de verão, selecione o fuso horário apropriado na caixa **Metric timezone ** (Fuso horário da métrica).
1. Selecione **Atualizar**.
## Excluir um modelo de detecção de anomalias
O uso da detecção de anomalias para um alarme gera cobranças na . Como prática recomendada, se o alarme não precisar mais de um modelo de detecção de anomalias, exclua primeiro o alarme e, em seguida, o modelo. Quando os alarmes de detecção de anomalias são avaliados, quaisquer detectores de anomalias ausentes são criados em seu nome. Se você excluir o modelo sem excluir o alarme, ele automaticamente recriará o modelo.
**Para excluir um alarme**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Escolha o nome do alarme.
1. Selecione **Ações**, **Excluir**.
1. Na caixa de confirmação, escolha **Excluir**.
**Para excluir um modelo de detecção de anomalias que foi usado para um alarme**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Metrics** (Métricas) e, em seguida, **All metrics** (Todas as métricas).
1. Escolha **Browse** (Navegar) e selecione a métrica que contém o modelo de detecção de anomalias. Você pode buscar sua métrica na caixa de pesquisa ou selecionar a métrica escolhendo entre as opções.
+ (Opcional) Se você estiver usando a interface original, escolha **All metrics** (Todas as métricas) e escolha a métrica que contém o modelo de detecção de anomalias. Você pode buscar sua métrica na caixa de pesquisa ou selecionar a métrica escolhendo entre as opções.
1. Escolha **Graphed metrics** (Métricas em gráfico).
1. Na guia **Métricas em grafos**, na coluna **Detalhes**, escolha a palavra-chave **ANOMALY\$1DETECTION\$1BAND** e depois **Excluir modelo de detecção de anomalias** no pop-up.
![\[A guia Métricas em gráficos com o menu pop-up ANOMALY_DETECTION_BAND exibido.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
+ (Opcional) Se estiver usando a interface original, escolha **Edit model** (Editar modelo). Você será direcionado para uma nova tela. Na nova tela, escolha **Delete model** (Excluir modelo) e escolha **Delete** (Excluir).
# Crie um alarme baseado em uma consulta ao Metrics Insights de várias séries temporais
Você pode criar um alarme que monitora várias séries temporais em uma frota de recursos. Diferentemente dos alarmes de instância única que acionam ações em instâncias individuais, os alarmes de monitoramento de frota permitem agregar métricas em vários recursos e acionar com base nas condições de toda a frota.
## Configuração de um alarme de várias séries temporais usando o Console de gerenciamento da AWS
Este exemplo mostra como criar um alarme que monitora a utilização da memória em uma frota de instâncias, e alerta você quando mais de duas instâncias excedem um limite.
**Para criar um alarme de várias séries temporais**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Selecionar métrica**.
1. Em **Métricas**, insira uma consulta do Metrics Insights:
```
SELECT MAX(mem_used_percent)
FROM "CWAgent"
GROUP BY InstanceId
ORDER BY MAX() DESC
```
1. Escolha **Próximo**.
1. Em **Conditions (Condições)**, especifique o seguinte:
+ Em **Tipo de limite**, escolha **Estático**.
+ Em **Quando a métrica for**, escolha **Maior que** e insira **80**.
+ Em **Pontos de dados para o alarme**, insira **2**.
1. Configure notificações e ações conforme necessário.
1. Adicione um nome e uma descrição para o alarme.
1. Selecione **Criar alarme**.
Esse alarme difere dos alarmes de instância única de várias maneiras:
+ Ele monitora várias séries temporais simultaneamente por meio do uso de uma consulta de métricas. A consulta de métricas é atualizada toda vez que o alarme é avaliado, portanto, seu alarme se adapta automaticamente à medida que os recursos são criados, pausados ou excluídos.
+ Para cada colaborador que ultrapassa o limite, o alarme envia um evento de alteração de estado do colaborador, que tem um tipo de evento diferente no EventBridge do que um evento de alteração de estado do alarme. O alarme em si também muda de estado: assim que pelo menos um colaborador está em alarme, o alarme também entra no estado de alarme.
+ No entanto, algumas ações, como o SSM Incident, são acionadas no nível do alarme. Essas ações não se repetem quando a lista de colaboradores no alarme muda.
Esse alarme difere dos alarmes agregados de consulta de métrica de várias maneiras:
+ Ele monitora séries temporais individualmente em vez de agregadas, usando a cláusula `GROUP BY`.
+ Ele segue o nível de granularidade que você define de acordo com suas necessidades: por exemplo, ele pode alertar em cada instância do Amazon EC2 (o nível mais granular das métricas do Amazon EC2) ou por tabela do Amazon RDS (agregada em várias operações em uma tabela), dependendo dos campos definidos na cláusula `GROUP BY`.
+ Ele prioriza a avaliação usando a cláusula `ORDER BY`.
+ Para cada colaborador que ultrapassa o limite, o alarme envia um evento de alteração de estado do colaborador, que tem um tipo de evento diferente no EventBridge do que um evento de alteração de estado do alarme. O alarme em si também muda de estado: assim que pelo menos um colaborador está em alarme, o alarme também entra no estado de alarme.
+ No entanto, algumas ações, como o SSM Incident, são acionadas no nível do alarme. Essas ações não se repetem quando a lista de colaboradores no alarme muda.
# Criação de um alarme com base em uma fonte de dados conectada
É possível criar alarmes que monitorem métricas de fontes de dados que não estejam no CloudWatch. Para obter mais informações sobre como criar conexões com essas outras fontes de dados, consulte [Métricas de consulta de outras fontes de dados](MultiDataSourceQuerying.md).
**Como criar um alarme para as métricas de uma fonte de dados à qual você está conectado**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Metrics** (Métricas), **All metrics** (Todas as métricas).
1. Escolha a guia **Consulta a várias fontes**.
1. Em **Fonte de dados**, selecione a fonte de dados que deseja usar.
1. O construtor de consultas solicita as informações necessárias para que a consulta recupere as métricas a serem usadas para o alarme. O fluxo de trabalho é diferente para cada fonte de dados e é adaptado à fonte de dados. Por exemplo, para as fontes de dados do Amazon Managed Service for Prometheus e do Prometheus, uma caixa do editor de consultas PromQL com um auxiliar de consulta é exibida.
1. Quando você terminar a estrutura da consulta, escolha **Representar consulta graficamente**.
1. Se o gráfico de amostra tiver a aparência esperada, escolha **Criar alarme**.
1. A página **Especificar métrica e condições** é exibida. Se a consulta que você estiver usando produzir mais de uma série temporal, você visualizará um banner de aviso na parte superior da página. Se isso acontecer, selecione uma função a ser usada para agregar a série temporal em **Função de agregação**.
1. (Opcional) Adicione um **Rótulo** para o alarme.
1. Para **Sempre que *your-metric-name* for …**, escolha **Maior**, **Maior/Igual**, **Menor/Igual** ou **Menor**. Em seguida, para **então …**, especifique um número para o valor limite.
1. Escolha **Additional configuration (Configuração adicional)**. Em **Datapoints to alarm (Pontos de dados para alarme)**, especifique quantos períodos de avaliação (pontos de dados) devem estar no estado `ALARM` para disparar o alarme. Se os dois valores forem correspondentes, você criará um alarme que passa para o estado `ALARM` se esses períodos consecutivos estiverem violando.
Para criar um alarme M de um alarme N, especifique um número para o primeiro valor que seja menor do que o segundo valor. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
1. Em **Missing data treatment** (Tratamento de dados ausentes), escolha como deseja que o alarme se comporte quando alguns pontos de dados estiverem ausentes. Para obter mais informações, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
1. Escolha **Próximo**.
1. Em **Notificação**, especifique um tópico do Amazon SNS a ser notificado quando o alarme transitar entre os estados `ALARM`, `OK` ou `INSUFFICIENT_DATA`.
1. (Opcional) Para enviar várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification** (Adicionar notificação).
**nota**
Recomendamos configurar o alarme para executar ações quando entrar no estado **Dados insuficientes**, além de para quando entrar no estado **Alarme**. Isso ocorre porque muitos problemas com a função do Lambda que se conecta à fonte de dados podem fazer com que o alarme transite para **Dados insuficientes**.
1. (Opcional) Para não enviar notificações do Amazon SNS, escolha **Remover**.
1. Para que o alarme execute ações do Auto Scaling, Lambda ou Systems Manager, escolha o botão apropriado e selecione o estado do alarme e a ação a ser executada. Se você escolher uma função do Lambda como uma ação de alarme, especifique o nome da função ou o ARN e, opcionalmente, você poderá escolher uma versão específica da função.
Os alarmes só poderão executar ações do Systems Manager ao entrarem no estado ALARM. Para obter mais informações sobre ações do Systems Manager, consulte [Configurar o CloudWatch para criar OpsItems a partir de alarmes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e [Criação de incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**nota**
Para criar um alarme que executa uma ação do SSM Incident Manager, é necessário ter determinadas permissões. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade para o AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Escolha **Próximo**.
1. Em **Nome e descrição**, insira um nome e uma descrição para o alarme e selecione **Próximo**. O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
**dica**
O nome do alarme deve conter somente caracteres UTF-8. Ele não pode conter caracteres de controle ASCII.
1. Em **Pré-visualizar e criar**, confirme se as informações e condições do seu alarme estão corretas e escolha **Criar alarme**.
# Criar um alarme usando uma consulta em PromQL
Você pode criar um alarme do CloudWatch que usa uma consulta instantânea do PromQL para monitorar métricas ingeridas por meio do endpoint do OTLP do CloudWatch. Todas as séries temporais correspondentes retornadas pela consulta são consideradas violações, e o alarme rastreia cada série temporal de violação como colaborador. Para obter mais informações sobre como os alarmes do PromQL funcionam, consulte [Alarmes do PromQL](alarm-promql.md).
## Criação de um alarme do PromQL usando o Console de gerenciamento da AWS
Este exemplo mostra como criar um alarme que monitora uma métrica de medidor, e alerta você quando seu valor cai abaixo de 20.
**Para criar um alarme do PromQL**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **PromQL** para o tipo de métrica.
1. No modo **Editor**, insira a consulta do PromQL:
```
my_gauge_metric < 20
```
1. Em **Conditions (Condições)**, especifique o seguinte:
+ Em **Intervalo de avaliação**, escolha **1 minute** para definir com que frequência a consulta do PromQL é avaliada.
+ Em **Período pendente**, insira **120**, que é a duração em segundos que um contribuidor deve estar em violação antes de entrar no estado de ALERTA.
+ Em **Período de recuperação**, insira **300**, que é a duração em segundos que um contribuidor deve estar em violação antes de entrar no estado de OK.
1. Configure notificações e ações conforme necessário.
1. Adicione um nome e uma descrição para o alarme.
1. Escolha **Próximo**.
1. Selecione **Criar alarme**.
## Criação de um alarme do PromQL (AWS CLI)
Use a ação da API [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) para criar um alarme do PromQL.
**Example Criar um alarme do PromQL que é acionado quando uma métrica de medição cai abaixo de 20**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20"}}' \
--evaluation-interval 60
```
**Example Criar um alarme do PromQL com um período pendente**
Esse alarme espera 300 segundos (5 minutos) antes de passar para o estado `ALARM`, e espera 600 segundos (10 minutos) antes de se recuperar.
```
aws cloudwatch put-metric-alarm \
--alarm-name HighLatencyAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5","PendingPeriod":300,"RecoveryPeriod":600}}' \
--evaluation-interval 60
```
**Example Criar um alarme do PromQL com uma ação de notificação do SNS**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarmWithAction \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20","PendingPeriod":0,"RecoveryPeriod":0}}' \
--evaluation-interval 60 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:MyTopic
```
## Criação de um alarme do PromQL no Query Studio
Este exemplo mostra como criar um alarme do PromQL no Query Studio que alerta você quando a duração média da solicitação HTTP para um serviço excede 500 milissegundos.
Diferentemente dos alarmes padrão do CloudWatch, em que o limite é configurado como uma etapa separada, os alarmes do PromQL definem a condição do alarme (limite) como parte da própria consulta. Por exemplo, o operador de comparação (`>`) e o valor limite (`0.5`) são incorporados diretamente na expressão do PromQL.
**Para criar um alarme do PromQL no Query Studio**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação abaixo de **Métricas**, escolha **Query Studio (pré-visualização)**.
1. Selecione **PromQL** no menu suspenso da linguagem de consulta.
1. Criar a consulta usando um dos seguintes modos:
+ No modo **Builder**, selecione um nome de métrica no campo **Métrica** (por exemplo, `http.server.request.duration`). Adicione filtros de rótulos conforme necessário (por exemplo, `@resource.service.name` = `my-api`). Para definir o limite de alarme, selecione uma **Operação básica** (por exemplo, `>`) e insira um **Número** (por exemplo, `0.5`).
+ No modo **Código**, insira a expressão do PromQL diretamente, por exemplo:
```
histogram_avg({"http.server.request.duration", "@resource.service.name"="my-api"}) > 0.5
```
1. Escolha **Executar** para executar a consulta e verificar se ela retorna os resultados esperados.
1. Escolha **Criar alarme** no menu de ações.
1. Você será redirecionado para a página de criação de alarmes do CloudWatch com sua consulta do PromQL pré-preenchida.
1. Em **Conditions (Condições)**, especifique o seguinte:
+ Em **Intervalo de avaliação**, escolha **1 minute** para definir com que frequência a consulta do PromQL é avaliada.
+ Em **Período pendente**, insira **60**, que é a duração em segundos que uma consulta deve estar em violação antes de entrar no estado de ALARME. Isso significa que a latência deve exceder o limite por pelo menos 60 segundos antes que o alarme seja acionado.
+ Em **Período de recuperação**, insira **120**, que é a duração em segundos que uma consulta deve estar em violação antes de entrar no estado de OK. Isso significa que a latência deve permanecer abaixo do limite por pelo menos 120 segundos antes que o alarme se recupere.
1. Configure notificações e ações conforme necessário.
1. Adicione um nome e uma descrição para o alarme.
1. Escolha **Próximo**.
1. Selecione **Criar alarme**.
**nota**
A consulta do PromQL deve retornar uma única série temporal para criar um alarme. Se sua consulta retornar várias séries temporais, use funções de agregação como `sum`, `avg` ou `topk` para reduzir o resultado a uma única série antes de criar o alarme.
# Alarmes nos logs
As etapas nas seções a seguir explicam como criar alarmes do CloudWatch para logs.
## Criar um alarme do CloudWatch com base em um filtro de métrica de grupo de logs
O procedimento contido nesta seção descreve como criar um alarme com base em um filtro de métrica de grupo de logs. Com filtros de métrica, você pode procurar termos e padrões em dados de log à medida que os dados são enviados ao CloudWatch Logs. Para obter mais informações, consulte [Criar métricas de eventos de logs usando filtros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) no *Guia do usuário do Amazon CloudWatch Logs*. Antes de criar um alarme com base em um filtro de métrica de grupo de logs, é necessário concluir as seguintes ações:
+ Crie um grupo de logs. Para obter mais informações, consulte [Trabalhar com grupos de logs e fluxos de logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group) no *Guia do usuário do Amazon CloudWatch Logs*.
+ Crie um filtro de métrica. Para obter mais informações, consulte [Criar um filtro de métrica para um grupo de logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) no *Guia do usuário do Amazon CloudWatch Logs*.
**Para criar um alarme com base em um filtro de métrica de grupo de logs**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Logs** e escolha **Log groups** (Grupos de logs).
1. Escolha o grupo de logs que contém seu filtro de métrica.
1. Escolha **Metric filters** (Filtros de métrica).
1. Na guia de filtros de métrica, selecione a caixa do filtro de métrica no qual deseja basear seu alarme.
1. Selecione **Criar alarme**.
1. (Opcional) Em **Metric** (Métrica), edite **Metric name** (Nome da métrica), **Statistic** (Estatística) e **Period** (Período).
1. Em **Conditions (Condições)**, especifique o seguinte:
1. Para **Threshold type** (Tipo de limite), escolha **Static** (Estático) ou **Anomaly detection** (Detecção de anomalias).
1. Em **Whenever *your-metric-name* is...** (Sempre que o nome da métrica for…), escolha **Greater** (Maior), **Greater/Equal** (Maior ou igual a), **Lower/Equal** (Menor ou igual a) ou **Lower** (Menor).
1. Em **than...** (que…), especifique um número para o valor limite.
1. Escolha **Additional configuration (Configuração adicional)**.
1. Em **Data points to alarm** (Pontos de dados para alarme), especifique quantos pontos de dados acionam seu alarme para entrar no estado `ALARM`. Se você especificar valores correspondentes, o alarme passará para o estado `ALARM` se existirem nessa quantidade períodos consecutivos violando. Para criar um alarme M de um alarme N, especifique um número para o primeiro valor que seja menor do que o segundo valor que você especificou. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
1. Em **Missing data treatment** (Tratamento de dados ausentes), selecione uma opção para especificar como tratar dados ausentes quando o alarme for avaliado.
1. Escolha **Próximo**.
1. Em **Notification** (Notificação), especifique um tópico do Amazon SNS para notificar quando o alarme estiver no estado `ALARM`, `OK` ou `INSUFFICIENT_DATA`.
1. (Opcional) Para enviar várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification** (Adicionar notificação).
1. (Opcional) Para não enviar notificações, escolha **Remove** (Remover).
1. Para que o alarme execute ações do Auto Scaling, EC2, Lambda ou Systems Manager, escolha o botão apropriado e selecione o estado do alarme e a ação a ser executada. Se você escolher uma função do Lambda como uma ação de alarme, especifique o nome da função ou o ARN e, opcionalmente, você poderá escolher uma versão específica da função.
Os alarmes só poderão executar ações do Systems Manager ao entrarem no estado ALARM. Para obter mais informações sobre ações do Systems Manager, consulte [Configurar o CloudWatch para criar OpsItems a partir de alarmes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e [Criação de incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**nota**
Para criar um alarme que executa uma ação do SSM Incident Manager, é necessário ter determinadas permissões. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade para o AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Escolha **Próximo**.
1. Em **Name e Description** (Nome e Descrição), insira um nome e uma descrição para o seu alarme. O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Em **Preview and create** (Pré-visualizar e criar), verifique se sua configuração está correta e escolha **Create alarm** (Criar alarme).
# Criar um alarme composto
As etapas desta seção explicam como usar o console do CloudWatch para criar um alarme composto. Você também pode usar a API ou a AWS CLI para criar um alarme composto. Para obter mais informações, consulte [PutCompositeAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutCompositeAlarm.html) ou [put-composite-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-composite-alarm.html)
**Como criar um alarme composto**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes) e depois escolha **All alarms** (Todos os alarmes).
1. Na lista de alarmes, marque a caixa de seleção ao lado de cada um dos alarmes existentes aos quais você deseja fazer referência na expressão da regra e, em seguida, escolha **Create composite alarm** (Criar alarme composto).
1. Em **Specify composite alarm conditions** (Especificar condições de alarme composto), especifique a expressão da regra para o novo alarme composto.
**nota**
Os alarmes que você selecionou na lista de alarmes são automaticamente listados na caixa **Conditions** (Condições). Por padrão, a função `ALARM` está designada para cada um de seus alarmes, e todos eles são unidos pelo operador lógico `OR`.
Você pode seguir estas subetapas para modificar a expressão da regra:
1. Você pode alterar o estado obrigatório de cada alarme de `ALARM` para `OK` ou `INSUFFICIENT_DATA`.
1. O operador lógico na expressão da regra pode ser alterado de `OR` para `AND` ou `NOT` e você pode adicionar parênteses para agrupar funções.
1. Você pode incluir outros alarmes na expressão da regra ou excluir alarmes dela.
**Exemplo: expressão de regra com condições**
```
(ALARM("CPUUtilizationTooHigh") OR
ALARM("DiskReadOpsTooHigh")) AND
OK("NetworkOutTooHigh")
```
Nesse exemplo de expressão de regra, o alarme composto passa a `ALARM` quando ALARM(“CPUUtilizationTooHigh” ou ALARM(“DiskReadOpsTooHigh”) está no estado `ALARM` ao mesmo tempo em que OK(“NetworkOutTooHigh”) está em `OK`.
1. Quando terminar, escolha **Next** (Próximo).
1. Em **Configure actions** (Configurar ações), você pode escolher uma das seguintes opções:
Em ***Notification*** (Notificação)
+ **Selecione um tópico de SNS existente** ou escolha **Create a new SNS topic** (Criar um novo tópico do SNS) ou **Use a topic ARN** (Usar o ARN do tópico) para definir o tópico do SNS que receberá a notificação.
+ Escolha **Add notification** (Adicionar notificação) para que o alarme possa enviar várias notificações para o mesmo estado ou para estados diferentes.
+ Escolha **Remove** (Remover) para que o alarme pare de enviar notificações ou executar ações.
(Opcional) Para que o alarme invoque uma função do Lambda quando mudar de estado, escolha **Adicionar ação do Lambda**. Em seguida, especifique o nome da função ou o ARN e, opcionalmente, escolha uma versão específica da função.
Para ***Systems Manager action*** (Ação do Systems Manager)
+ Escolha **Add Systems Manager action** (Adicionar ação do Systems Manager) para que o alarme possa executar uma ação do SSM ao entrar no estado ALARM.
Para saber mais sobre ações do Systems Manager, consulte [Configurar o CloudWatch para criar OpsItems de alarmes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) no *Guia do usuário do AWS Systems Manager* e [Incident creation](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) (Criação de incidentes) no *Guia do usuário do Incident Manager*. Para criar um alarme que realiza uma ação do SSM Incident Manager, você precisa ter as permissões corretas. Para saber mais, consulte [Exemplos de políticas baseadas em identidade do Incident Manager do AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) no *Guia do usuário do Incident Manager*.
Para que o alarme inicie uma investigação, escolha **Adicionar ação de investigação** e selecione o grupo de investigação. Para obter mais informações sobre , consulte [Investigações do CloudWatch](Investigations.md).
1. Quando terminar, escolha **Next** (Próximo).
1. Em **Add name and description** (Adicionar nome e descrição), insira o nome do alarme e uma descrição *opcional* para seu novo alarme composto. O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Quando terminar, escolha **Next** (Próximo).
1. Em **Preview and create** (Visualizar e criar), confirme as informações e, em seguida, escolha **Create composite alarm** (Criar alarme composto).
**nota**
Você pode criar um ciclo de alarmes compostos com dois alarmes compostos que dependem um do outro. Se isso acontecer, os alarmes compostos deixarão de ser avaliados e não poderão ser excluídos por causa da dependência mútua. A maneira mais fácil de quebrar um ciclo de dependência entre alarmes compostos é alterar a função `AlarmRule` em um deles para `False`.
# Atuação em mudanças de alarmes
O CloudWatch pode notificar os usuários sobre dois tipos de alterações de alarme: quando um alarme muda de estado e quando a configuração de um alarme é atualizada.
Quando um alarme é avaliado, ele pode mudar de um estado para outro, como ALARM ou OK. Para alarmes do Metrics Insights que monitoram várias séries temporais, cada série temporal (colaborador) só pode estar no estado ALARM ou OK, nunca no estado INSUFFICIENT\$1DATA. Isso ocorre porque uma série temporal somente existe quando os dados estão presentes.
Além disso, o CloudWatch envia eventos ao Amazon EventBridge sempre que um alarme do CloudWatch muda de estado, e quando os alarmes são criados, atualizados, excluídos ou alterados. É possível escrever regras do EventBridge para realizar ações ou ser notificado quando o EventBridge receber esses eventos.
Para obter mais informações sobre as ações de alarmes, consulte [Ações de alarme](alarm-actions.md).
**Topics**
+ [
# Notificação dos usuários sobre mudanças de alarmes
](Notify_Users_Alarm_Changes.md)
+ [
# Invocar uma função do Lambda de um alarme
](alarms-and-actions-Lambda.md)
+ [
# Iniciar uma investigação do CloudWatch em um alarme
](Start-Investigation-Alarm.md)
+ [
# Interrupção, encerramento, reinício ou recuperação de uma instância do EC2
](UsingAlarmActions.md)
+ [
# Eventos de alarme e o EventBridge
](cloudwatch-and-eventbridge.md)
# Notificação dos usuários sobre mudanças de alarmes
Esta seção explica como é possível usar as Notificações de Usuários da AWS ou o Amazon Simple Notification Service para que os usuários sejam notificados sobre alterações no alarme.
## Configurando notificações de usuário da AWS
É possível usar [notificações de usuário da AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) para configurar canais de entrega para receber notificações sobre eventos de alteração de estado de alarme da e alteração de configuração do CloudWatch. Você recebe uma notificação quando um evento corresponde a uma regra especificada. É possível receber notificações de eventos por meio de vários canais, incluindo email, notificações de chat do [Chatbot da AWS](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) ou [Notificações por push da aplicação móvel do Console da AWS](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/managing-notifications.html). Também é possível ver as notificações na [Central de notificações do console](https://console.aws.amazon.com/notifications). é compatível com agregação, o que pode reduzir o número de notificações recebidas durante eventos específicos.
As configurações de notificação que você cria com as Notificações de Usuários da AWS não contam para o limite do número de ações que podem ser configuradas por estado de alarme alvo. Como as Notificações de Usuários da AWS correspondem aos eventos emitidos para o Amazon EventBridge, ele envia notificações para todos os alarmes em sua conta e regiões selecionadas, a menos que você especifique um filtro avançado para permitir ou negar alarmes ou padrões específicos.
O exemplo a seguir de um filtro avançado corresponde a uma alteração do estado do alarme de OK para ALARM no alarme chamado `ServerCpuTooHigh`.
```
{
"detail": {
"alarmName": ["ServerCpuTooHigh"],
"previousState": { "value": ["OK"] },
"state": { "value": ["ALARM"] }
}
}
```
É possível usar qualquer uma das propriedades publicadas por um alarme nos eventos do EventBridge para criar um filtro. Para obter mais informações, consulte [Eventos de alarme e o EventBridge](cloudwatch-and-eventbridge.md).
## Configurar notificações do Amazon SNS
É possível usar o Amazon Simple Notification Service para enviar mensagens de aplicação para aplicação (A2A) e mensagens de aplicação para pessoa (A2P), mensagens de texto para celulares (SMS) e mensagens de email. Para obter mais informações, consulte [destinos de eventos do Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html).
Para cada estado que um alarme pode assumir, é possível configurar o alarme para enviar uma mensagem para um tópico do SNS. Cada tópico do Amazon SNS que você configurar para um estado em um determinado alarme contará para o limite do número de ações que poderão ser configuradas para esse alarme e estado. É possível enviar mensagens para o mesmo tópico do Amazon SNS a partir de qualquer alarme em sua conta e usar o mesmo tópico do Amazon SNS para consumidores de aplicações (A2A) e pessoais (A2P). Como essa configuração é feita no nível do alarme, somente os alarmes que você configurou enviam mensagens para o tópico selecionado do Amazon SNS.
Primeiro, crie um tópico e inscreva-se nele. Você também pode publicar uma mensagem de teste para o tópico. Para ver um exemplo, consulte [Configurar um tópico do Amazon SNS usando o Console de gerenciamento da AWS](#set-up-sns-topic-console). Ou, para obter mais informações, consulte [Conceitos básicos do Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html).
Se preferir, caso você planeje usar o Console de gerenciamento da AWS para criar seu alarme do CloudWatch, poderá ignorar esse procedimento, pois o tópico poderá ser criado junto com o alarme.
Ao criar um alarme do CloudWatch, será possível adicionar ações para qualquer estado de destino em que o alarme entre. Adicione uma notificação do Amazon SNS para o estado sobre o qual você deseja ser notificado e selecione o tópico do Amazon SNS que você criou na etapa anterior para enviar uma notificação por email quando o alarme entrar no estado selecionado.
**nota**
Ao criar um tópico do Amazon SNS, você pode escolher torná-lo um *tópico padrão* ou um *tópico FIFO*. O CloudWatch garante a publicação de todas as notificações de alarme para ambos os tipos de tópicos. No entanto, mesmo que você use um tópico FIFO, em alguns casos raros, o CloudWatch envia as notificações fora de ordem para o tópico. Se você usar um tópico FIFO, o alarme configura o ID do grupo de mensagens das notificações de alarme como um hash do ARN do alarme.
**Topics**
+ [
### Evitar problemas de segurança confused deputy
](#SNS_Confused_Deputy)
+ [
### Configurar um tópico do Amazon SNS usando o Console de gerenciamento da AWS
](#set-up-sns-topic-console)
+ [
### Configurar um tópico do SNS usando a AWS CLI
](#set-up-sns-topic-cli)
### Evitar problemas de segurança confused deputy
“Confused deputy” é um problema de segurança no qual uma entidade sem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executá-la. Na AWS, a personificação entre serviços pode resultar no problema do ‘confused deputy’. A personificação entre serviços pode ocorrer quando um serviço (o *serviço de chamada*) chama outro serviço (o *serviço chamado*). O serviço de chamada pode ser manipulado de modo a usar suas permissões para atuar nos recursos de outro cliente de uma forma na qual ele não deveria ter permissão para acessar. Para evitar isso, a AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com entidades principais de serviço que receberam acesso aos recursos em sua conta.
Recomendamos o uso das chaves de contexto de condição global [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths) nas políticas de recursos para limitar as permissões no recurso que o Amazon SNS concede a outro serviço. Use `aws:SourceArn` se quiser associar apenas um recurso ao acesso entre serviços. Use `aws:SourceAccount` se quiser permitir que qualquer recurso nessa conta seja associado ao uso entre serviços. Use `aws:SourceOrgID` se quiser permitir que qualquer recurso de qualquer conta de uma organização seja associado ao uso entre serviços. Use `aws:SourceOrgPaths` se quiser associar qualquer recurso das contas em um caminho do AWS Organizations seja associado ao uso entre serviços. Para obter mais informações sobre como usar e entender caminhos, consulte [aws:SourceOrgPaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths) no Guia do usuário do IAM.
A maneira mais eficaz de se proteger contra o problema do substituto confuso é usar a chave de contexto de condição global `aws:SourceArn` com o ARN completo do recurso. Se você não souber o ARN completo do recurso ou especificar vários recursos, use a chave de condição de contexto global `aws:SourceArn` com caracteres curinga (`*`) para as partes desconhecidas do ARN. Por exemplo, `arn:aws:servicename:*:123456789012:*`.
Se o valor do `aws:SourceArn` não contiver o ID da conta, como um ARN de bucket do Amazon S3, você deverá usar ambos, a `aws:SourceAccount` e o `aws:SourceArn` para limitar as permissões.
Para se proteger do problema de "confused deputy" em grande escala, use a chave de contexto de condição global `aws:SourceOrgID` ou `aws:SourceOrgPaths` com o ID ou o caminho da organização do recurso nas políticas baseadas em recursos. As políticas que incluem a chave `aws:SourceOrgID` ou `aws:SourceOrgPaths` incluem automaticamente as contas corretas e você não tem que atualizar manualmente as políticas quando adiciona, remove ou move contas na organização.
O valor de `aws:SourceArn` deve ser o ARN do alarme que está enviando notificações.
O exemplo a seguir mostra como é possível usar as chaves de contexto de condição globais `aws:SourceArn` e `aws:SourceAccount` no CloudWatch para evitar o problema de “confused deputy”.
```
{
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "cloudwatch.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-2:444455556666:MyTopic",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudwatch:us-east-2:111122223333:alarm:*"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}]
}
```
Se um ARN de alarme contiver caracteres não ASCII, utilize somente a chave de condição global `aws:SourceAccount` para limitar as permissões.
### Configurar um tópico do Amazon SNS usando o Console de gerenciamento da AWS
Primeiro, crie um tópico e inscreva-se nele. Você também pode publicar uma mensagem de teste para o tópico.
**Para criar um tópico do SNS**
1. Abra o console do Amazon SNS em [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home).
1. No painel do Amazon SNS, em **Common actions** (Ações comuns), escolha **Create Topic** (Criar tópico).
1. Na caixa de diálogo **Create new topic (Criar novo tópico)**, em **Topic name (Nome do tópico)**, insira um nome para o tópico (por exemplo, **my-topic**).
1. Escolha **Criar tópico**.
1. Copie o **Topic ARN** (ARN do tópico) para a próxima tarefa (por exemplo, arn:aws:sns:us-east-1:111122223333:my-topic).
**Para se inscrever em um tópico do SNS**
1. Abra o console do Amazon SNS em [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home).
1. No painel de navegação, escolha **Assinaturas**, **Criar assinatura**.
1. Na caixa de diálogo **Criar assinatura**, em **ARN do tópico**, cole o ARN do tópico que você criou na tarefa anterior.
1. Em **Protocolo**, escolha **E-mail**.
1. Em **Endpoint**, insira um endereço de e-mail para receber a notificação e escolha **Create subscription (Criar inscrição)**.
1. No aplicativo de e-mail, abra a mensagem de notificações da AWS e confirme a inscrição.
O navegador da Web exibe uma resposta de confirmação do Amazon SNS.
**Para publicar uma mensagem de teste em um tópico do SNS**
1. Abra o console do Amazon SNS em [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home).
1. No painel de navegação, escolha **Tópicos**.
1. Na página **Topics (Tópicos)**, selecione um tópico e escolha **Publish to topic (Publicar em um tópico)**.
1. Na página **Publish a message (Publicar uma mensagem)**, em **Subject (Assunto)**, digite uma linha de assunto para a mensagem e em **Message (Mensagem)**, digite uma breve mensagem.
1. Escolha **Publish Message (Publicar mensagem)**.
1. Verifique seu e-mail para confirmar que recebeu a mensagem.
### Configurar um tópico do SNS usando a AWS CLI
Primeiro você cria um tópico do SNS e, depois, publica uma mensagem diretamente no tópico para verificar se ele foi configurado corretamente.
**Para configurar um tópico do SNS**
1. Crie o tópico usando o comando [create-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/create-topic.html) da forma a seguir.
```
1. aws sns create-topic --name my-topic
```
O Amazon SNS retorna um ARN do tópico com o seguinte formato:
```
1. {
2. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic"
3. }
```
1. Assine o seu endereço de e-mail para o tópico usando o comando [subscribe](https://docs.aws.amazon.com/cli/latest/reference/sns/subscribe.html). Se a solicitação de assinatura for bem-sucedida, você receberá uma mensagem de e-mail de confirmação.
```
1. aws sns subscribe --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic --protocol email --notification-endpoint my-email-address
```
O Amazon SNS retorna o seguinte:
```
1. {
2. "SubscriptionArn": "pending confirmation"
3. }
```
1. No aplicativo de e-mail, abra a mensagem de notificações da AWS e confirme a inscrição.
O navegador da Web exibe uma resposta de confirmação do Amazon Simple Notification Service.
1. Verifique a assinatura usando o comando [list-subscriptions-by-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/list-subscriptions-by-topic.html).
```
1. aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic
```
O Amazon SNS retorna o seguinte:
```
1. {
2. "Subscriptions": [
3. {
4. "Owner": "111122223333",
5. "Endpoint": "me@mycompany.com",
6. "Protocol": "email",
7. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic",
8. "SubscriptionArn": "arn:aws:sns:us-east-1:111122223333:my-topic:64886986-bf10-48fb-a2f1-dab033aa67a3"
9. }
10. ]
11. }
```
1. (Opcional) Publique uma mensagem de teste no tópico usando o comando [publish](https://docs.aws.amazon.com/cli/latest/reference/sns/publish.html).
```
1. aws sns publish --message "Verification" --topic arn:aws:sns:us-east-1:111122223333:my-topic
```
O Amazon SNS retorna os resultados a seguir.
```
1. {
2. "MessageId": "42f189a0-3094-5cf6-8fd7-c2dde61a4d7d"
3. }
```
1. Verifique seu e-mail para confirmar que recebeu a mensagem.
## Esquema das notificações do Amazon SNS quando os alarmes mudarem de estado
Esta seção lista os esquemas das notificações enviadas aos tópicos do Amazon SNS quando os alarmes mudam de estado.
**Esquema quando um alarme de métrica muda de estado**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"AlarmConfigurationUpdatedTimestamp": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OldStateValue": "string",
"OKActions": ["string"],
"AlarmActions": ["string"],
"InsufficientDataActions": ["string"],
"Trigger": {
"MetricName": "string",
"Namespace": "string",
"StatisticType": "string",
"Statistic": "string",
"Unit": "string or null",
"Dimensions": [
{
"value": "string",
"name": "string"
}
],
"Period": "integer",
"EvaluationPeriods": "integer",
"DatapointsToAlarm": "integer",
"ComparisonOperator": "string",
"Threshold": "number",
"TreatMissingData": "string",
"EvaluateLowSampleCountPercentile": "string or null"
}
}
```
**Esquema quando um alarme composto muda de estado**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OKActions": [String],
"AlarmActions": [String],
"InsufficientDataActions": [String],
"OldStateValue": "string",
"AlarmRule": "string",
"TriggeringChildren": [String]
}
```
# Invocar uma função do Lambda de um alarme
Os alarmes do CloudWatch garantem uma invocação assíncrona da função do Lambda para uma determinada alteração de estado, exceto nos seguintes casos:
+ Quando a função não existe.
+ Quando o CloudWatch não está autorizado a invocar a função do Lambda.
Se o CloudWatch não conseguir acessar o serviço do Lambda ou se a mensagem for rejeitada por outro motivo, o CloudWatch tentará novamente até que a invocação seja bem-sucedida. O Lambda enfileira a mensagem e processa novas tentativas de execução. Para obter mais informações sobre esse modelo de execução, incluindo informações sobre como o Lambda lida com erros, consulte [Invocação assíncrona](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) no Guia do desenvolvedor do AWS Lambda.
Você pode invocar uma função do Lambda na mesma conta ou em outras contas da AWS.
Ao especificar um alarme para invocar uma função do Lambda como uma ação de alarme, é possível optar por especificar o nome da função, o alias da função ou uma versão específica de uma função.
Ao especificar uma função do Lambda como uma ação de alarme, você deve criar uma política de recursos para a função com a finalidade de permitir que a entidade principal de serviço do CloudWatch invoque a função.
Uma maneira de fazer isso é ao usar a AWS CLI, como no seguinte exemplo:
```
aws lambda add-permission \
--function-name my-function-name \
--statement-id AlarmAction \
--action 'lambda:InvokeFunction' \
--principal lambda.alarms.cloudwatch.amazonaws.com \
--source-account 111122223333 \
--source-arn arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name
```
Como alternativa, é possível criar uma política semelhante a um dos exemplos apresentados a seguir e, em seguida, atribuí-la à função.
O exemplo apresentado a seguir especifica a conta na qual o alarme está localizado, portanto, somente os alarmes dessa conta (111122223333) podem invocar a função.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
}]
}
```
------
O exemplo apresentado a seguir tem um escopo mais restrito, permitindo que somente o alarme especificado na conta indicada invoque a função.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333",
"AWS:SourceArn": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name"
}
}
}]
}
```
------
Não recomendamos a criação de uma política que não especifique uma conta de origem, porque essas políticas são vulneráveis a problemas de “confused deputy”.
## Adicionar métricas do Lambda às investigações do CloudWatch
Você pode adicionar métricas do Lambda às suas investigações ativas do CloudWatch. Na investigação de um problema, as métricas do Lambda podem fornecer insights valiosos sobre performance e comportamento da função. Por exemplo, se você estiver investigando um problema de performance da aplicação, as métricas do Lambda, como duração, taxas de erro ou controles de utilização, podem ajudar a identificar a causa raiz.
Para adicionar métricas do Lambda às investigações do CloudWatch:
1. Abra o console AWS Lambda em [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. Na seção **Monitorar**, encontre a métrica.
1. Abra o menu de contexto da métrica, escolha **Investigar**, **Adicionar à investigação**. Em seguida, no painel **Investigar**, selecione o nome da investigação.
## Objeto de evento enviado do CloudWatch para o Lambda
Ao configurar uma função do Lambda como uma ação de alarme, o CloudWatch entrega uma carga JSON à função do Lambda quando invoca a função. Essa carga JSON serve como o objeto de evento para a função. É possível extrair dados desse objeto em JSON e usá-los em sua função. Veja a seguir um exemplo de um objeto de evento de um alarme de métrica.
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:444455556666:alarm:lambda-demo-metric-alarm',
'accountId': '444455556666',
'time': '2023-08-04T12:36:15.490+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'lambda-demo-metric-alarm',
'state': {
'value': 'ALARM',
'reason': 'test',
'timestamp': '2023-08-04T12:36:15.490+0000'
},
'previousState': {
'value': 'INSUFFICIENT_DATA',
'reason': 'Insufficient Data: 5 datapoints were unknown.',
'reasonData': '{"version":"1.0","queryDate":"2023-08-04T12:31:29.591+0000","statistic":"Average","period":60,"recentDatapoints":[],"threshold":5.0,"evaluatedDatapoints":[{"timestamp":"2023-08-04T12:30:00.000+0000"},{"timestamp":"2023-08-04T12:29:00.000+0000"},{"timestamp":"2023-08-04T12:28:00.000+0000"},{"timestamp":"2023-08-04T12:27:00.000+0000"},{"timestamp":"2023-08-04T12:26:00.000+0000"}]}',
'timestamp': '2023-08-04T12:31:29.595+0000'
},
'configuration': {
'description': 'Metric Alarm to test Lambda actions',
'metrics': [
{
'id': '1234e046-06f0-a3da-9534-EXAMPLEe4c',
'metricStat': {
'metric': {
'namespace': 'AWS/Logs',
'name': 'CallCount',
'dimensions': {
'InstanceId': 'i-12345678'
}
},
'period': 60,
'stat': 'Average',
'unit': 'Percent'
},
'returnData': True
}
]
}
}
}
```
Veja a seguir um exemplo de um objeto de evento de um alarme composto.
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:SuppressionDemo.Main',
'accountId': '111122223333',
'time': '2023-08-04T12:56:46.138+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'CompositeDemo.Main',
'state': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:56:46.138+0000'
},
'previousState': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:54:46.138+0000',
'actionsSuppressedBy': 'WaitPeriod',
'actionsSuppressedReason': 'Actions suppressed by WaitPeriod'
},
'configuration': {
'alarmRule': 'ALARM(CompositeDemo.FirstChild) OR ALARM(CompositeDemo.SecondChild)',
'actionsSuppressor': 'CompositeDemo.ActionsSuppressor',
'actionsSuppressorWaitPeriod': 120,
'actionsSuppressorExtensionPeriod': 180
}
}
}
```
# Iniciar uma investigação do CloudWatch em um alarme
Inicie uma investigação do CloudWatch em um alarme ou em qualquer ponto nas últimas duas semanas do histórico de um alarme do CloudWatch.
Para obter mais informações sobre as investigações do CloudWatch, consulte [Investigações do CloudWatch](Investigations.md).
## Pré-requisitos
Antes de iniciar uma investigação do CloudWatch de um alarme do CloudWatch, você deve criar uma política de recursos para a função com a finalidade de permitir que a entidade principal de serviço do CloudWatch inicie a investigação. Para fazer isso usando a AWS CLI, use um comando semelhante ao seguinte exemplo:
```
aws aiops put-investigation-group-policy \
--identifier arn:aws:aiops:us-east-1:111122223333:investigation-group/investigation_group_id \
--policy "{\"Version\":\"2008-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"aiops.alarms.cloudwatch.amazonaws.com\"},\"Action\":[\"aiops:CreateInvestigation\",\"aiops:CreateInvestigationEvent\"],\"Resource\":\"*\",\"Condition\":{\"StringEquals\":{\"aws:SourceAccount\":\"111122223333\"},\"ArnLike\":{\"aws:SourceArn\":\"arn:aws:cloudwatch:us-east-1:111122223333:alarm:*\"}}}]}" \
--region eu-north-1
```
Substitua os valores de exemplo por seu próprio ID da conta da AWS, região e ID do grupo de investigação.
**Iniciar uma investigação em um alarme do CloudWatch**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação à esquerda, escolha **Alarmes**, **Todos os alarmes**.
1. Escolha o nome do alarme.
1. Escolha o período no histórico de alarmes que você deseja investigar.
1. Escolha **Investigar**, **Iniciar nova investigação**.
1. Em **Novo título da investigação**, insira um nome para a investigação. Em seguida, escolha **Iniciar investigação**.
O assistente de investigações do CloudWatch inicia e verifica os dados de telemetria para encontrar dados que possam estar associados a essa situação.
1. No painel de navegação do console do CloudWatch, escolha **Investigações** e depois o nome da investigação que você acabou de iniciar.
A seção **Descobertas** exibe um resumo em linguagem natural do status do alarme e o motivo pelo qual ele foi acionado.
1. (Opcional) No grafo do alarme, clique com o botão direito do mouse e escolha para se aprofundar no alarme ou na métrica que ele observa.
1. No lado direito da tela, escolha a guia **Sugestões**.
Será exibida uma lista com outras telemetrias que as investigações do CloudWatch descobriram e que podem ser relevantes para a investigação. Essas descobertas podem incluir outras métricas e resultados de consultas do CloudWatch Logs Insights. As investigações do CloudWatch executaram essas consultas com base no alarme.
+ Para cada descoberta, escolha **Adicionar às descobertas** ou **Descartar**.
Ao escolher **Adicionar às descobertas**, a telemetria é incluída na seção **Descobertas**, e as investigações do CloudWatch usam essa informação para direcionar suas verificações e sugestões futuras.
+ Para obter um resultado de consulta do CloudWatch Logs Insights, para alterar ou editar a consulta e executá-la novamente, abra o menu de contexto (clique com o botão direito do mouse) dos resultados e, em seguida, escolha **Abrir no Logs Insights**. Para obter mais informações, consulte [Analisar logs de dados com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html).
Para executar outra consulta, ao acessar a página do Logs Insights, você pode optar por usar o assistente de consulta para fazer uma consulta usando linguagem natural. Para obter mais informações, consulte [Usar linguagem natural para gerar e atualizar as consultas do CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-Assist.html).
+ (Opcional) Caso saiba de uma telemetria em outro serviço da AWS que possa se aplicar a essa investigação, acesse o console desse serviço e adicione a telemetria à investigação.
1. As investigações do CloudWatch também podem adicionar hipóteses à lista na guia **Sugestões**. Essas hipóteses são geradas pela investigação em linguagem natural.
Para cada hipótese, escolha **Adicionar às descobertas** ou **Descartar**.
1. Quando achar que concluiu a investigação e encontrou a causa raiz do problema, você pode escolher a guia **Visão geral** e, em seguida, escolher **Resumo da investigação**. As investigações do CloudWatch então criam um resumo em linguagem natural das descobertas e hipóteses importantes da investigação.
# Interrupção, encerramento, reinício ou recuperação de uma instância do EC2
Usando as ações de alarme do Amazon CloudWatch, você cria alarmes que automaticamente interrompem, terminam, reinicializam ou recuperam suas instâncias do EC2. É possível usar as ações de parada ou encerramento para ajudar a economizar dinheiro quando não precisar mais que uma instância seja executada. É possível usar as ações de reinicialização e recuperação para reinicializar automaticamente essas instâncias ou recuperá-las para um novo hardware caso ocorra um problema no sistema.
Há várias situações nas quais é possível querer interromper ou encerrar sua instância automaticamente. Por exemplo, é possível ter instâncias dedicadas a trabalhos de processamento de folha de pagamento em lote ou tarefas de computação científica que são executadas por um período e, em seguida, concluem seu trabalho. Em vez de permitir que essas instâncias permaneçam ociosas (e acumulem cobranças), interrompa ou as encerre, o que ajuda a economizar. A principal diferença entre usar as ações de alarme de interrupção e encerramento é que você poderá reiniciar facilmente uma instância interrompida se precisar reexecutá-la mais tarde. Também mantenha os mesmos ID de instância e volume raiz. No entanto, não é possível reiniciar uma instância encerrada. Em vez disso, é necessário executar uma nova instância.
É possível adicionar as ações de interromper, terminar, reinicializar ou recuperar a qualquer alarme definido em uma métrica por instância do Amazon EC2, incluindo métricas de monitoramento básicas e detalhadas fornecidas pelo Amazon CloudWatch (no namespace AWS/EC2), além de todas as métricas personalizadas que incluem a dimensão “InstanceId=”, desde que o valor de InstanceId se refira a uma instância do Amazon EC2 válida em execução. Você também pode adicionar a ação de recuperar aos alarmes definidos em qualquer métrica por instância do Amazon EC2, exceto `StatusCheckFailed_Instance`.
**Importante**
Os alarmes configurados nas métricas do Amazon EC2 podem entrar temporariamente no estado INSUFFICIENT\$1DATA se houver pontos de dados de métricas ausentes. Isso é raro, mas pode acontecer quando o relatório de métricas é interrompido, mesmo quando a instância do Amazon EC2 está íntegra. Para os alarmes nas métricas do Amazon EC2 que estão configurados para executar ações de interrupção, encerramento, reinicialização ou recuperação, recomendamos configurar esses alarmes para tratar os dados ausentes como `missing` e para que esses alarmes sejam acionados somente quando estiverem no estado ALARM.
Para obter mais informações sobre como configurar o CloudWatch para agir nas métricas ausentes que têm alarmes definidos, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
Para configurar uma ação de alarme do CloudWatch que pode reinicializar, interromper ou terminar uma instância, você deve usar uma função do IAM vinculada ao serviço *AWSServiceRoleForCloudWatchEvents*. A função do IAM AWSServiceRoleForCloudWatchEvents permite que a AWS execute ações de alarme em seu nome.
Para criar a função vinculada ao serviço para o CloudWatch Events, use o seguinte comando:
```
aws iam create-service-linked-role --aws-service-name events.amazonaws.com
```
**Suporte a consoles**
Você pode criar alarmes usando o console do CloudWatch ou o console do Amazon EC2. Os procedimentos nesta documentação usam o console do CloudWatch. Para procedimentos que usam o console do Amazon EC2, consulte [Criar alarmes para interromper, encerrar, reinicializar ou recuperar uma instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingAlarmActions.html) no *Guia do usuário do Amazon EC2*.
**Permissões**
Se você estiver usando uma conta do AWS Identity and Access Management (IAM) para criar ou modificar um alarme que executa ações do EC2 ou ações do Systems Manager OpsItem, deverá ter a permissão `iam:CreateServiceLinkedRole`.
**Topics**
+ [
## Adicionar ações de interromper a alarmes do Amazon CloudWatch
](#AddingStopActions)
+ [
## Adicionar ações de terminar a alarmes do Amazon CloudWatch
](#AddingTerminateActions)
+ [
## Adicionar ações de reinicializar a alarmes do Amazon CloudWatch
](#AddingRebootActions)
+ [
## Adicionar ações de recuperar a alarmes do Amazon CloudWatch
](#AddingRecoverActions)
+ [
## Visualizar o histórico de alarmes disparados e ações
](#ViewAlarmHistory)
## Adicionar ações de interromper a alarmes do Amazon CloudWatch
É possível criar um alarme que pare uma instância do Amazon EC2 quando o limite for atingido. Por exemplo, é possível executar instâncias de desenvolvimento ou teste e ocasionalmente se esquecer de desativá-las. É possível criar um alarme que seja acionado quando o percentual médio de utilização da CPU for inferior a 10% em 24 horas, sinalizando que ela está ociosa e não mais em uso. Você pode ajustar o limite, a duração e o período para atender às suas necessidades, além de poder adicionar uma notificação do SNS para receber um e-mail quando o alarme for disparado.
As instâncias do Amazon EC2 que usam um volume do Amazon Elastic Block Store como dispositivo raiz podem ser interrompidas ou terminadas, enquanto as instâncias que usam o armazenamento de instância como dispositivo raiz só podem ser terminadas.
**Para criar um alarme para interromper uma instância ociosa usando o console do Amazon CloudWatch**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Select metric** (Selecionar métrica).
1. Para **namespaces da AWS**, escolha **EC2**.
1. Faça o seguinte:
1. Escolha **Per-Instance Metrics** (Métricas por instância).
1. Selecione a caixa de seleção na linha com a instância correta e a métrica **CPUUtilization**.
1. Escolha a guia **Graphed metrics (Métricas em gráfico)**.
1. Para a estatística, escolha **Média**.
1. Escolha um período (por exemplo, **1 Hour**).
1. Escolha **Selecionar métrica**.
1. Em **Condições**, faça o seguinte:
1. Escolha **Static** (Estático).
1. Em **Whenever CPUUtilization is** (Sempre que a CPUUtilization for), escolha **Lower** (Mais baixo).
1. Para **than** (do que), digite **10**.
1. Escolha **Próximo**.
1. Em **Notification** (Notificação), para **Send notification to** (Enviar notificação para), escolha um tópico do SNS existente ou crie um novo.
Para criar um tópico do SNS, escolha **New list (Nova lista)**. Em **Send notification to (Enviar notificação para)**, digite um nome para o tópico do SNS (por exemplo, Stop\$1EC2\$1Instance). Para **Email list** (Lista de e-mails), digite uma lista de endereços de e-mail separados por vírgulas a serem notificados quando o alarme mudar para o estado `ALARM`. Para cada endereço de e-mail será enviado um e-mail de confirmação da inscrição no tópico. Você deve confirmar a assinatura para que as notificações sejam enviadas para um endereço de e-mail.
1. Escolha **Add EC2 Action** (Adicionar ação do EC2).
1. Em **Alarm state trigger** (Gatilho do estado do alarme), escolha **In alarm** (Em alarme). Em **Take the following action** (Executar a ação a seguir), escolha **Stop this instance** (Interromper a instância).
1. Escolha **Próximo**.
1. Digite um nome e uma descrição para o alarme. O nome deve conter somente caracteres ASCII. Escolha **Próximo**.
1. Em **Preview and create (Visualizar e criar)**, confirme se as informações e condições são o que você deseja e escolha **Create alarm (Criar alarme)**.
## Adicionar ações de terminar a alarmes do Amazon CloudWatch
É possível criar um alarme que encerre uma instância do EC2 automaticamente quando um certo limite for atingido (desde que a proteção contra encerramento não esteja ativada para a instância). Por exemplo, você pode encerrar uma instância quando ela tiver concluído seu trabalho e não precisar mais dela. Se você quiser usar a instância posteriormente, pare-a em vez de encerrá-la. Para obter informações sobre como habilitar e desabilitar a proteção contra o encerramento de uma instância, consulte [Habilitar a proteção contra o encerramento de uma instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_ChangingDisableAPITermination.html) no *Guia do usuário do Amazon EC2*.
**Para criar um alarme para terminar uma instância ociosa usando o console do Amazon CloudWatch**
1. Abra o console do CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms**, **Create Alarm**.
1. Na etapa **Selecionar métrica**, faça o seguinte:
1. Em **Métricas do EC2**, escolha **Métricas por instância**.
1. Selecione a linha com a instância e a métrica **CPUUtilization**.
1. Para a estatística, escolha **Média**.
1. Escolha um período (por exemplo, **1 Hour**).
1. Escolha **Próximo**.
1. Na etapa **Definir alarme**, faça o seguinte:
1. Em **Limite de alarme**, digite um nome exclusivo para o alarme (por exemplo, Encerrar instância do EC2) e uma descrição do alarme (por exemplo, Encerrar instância do EC2 quando a CPU estiver ociosa por muito tempo). Os nomes de alarme devem conter somente caracteres ASCII.
1. Em **Whenever (Sempre)**, em **is (é)**, escolha **<** e digite **10**. Em **for (para)**, digite **24** períodos consecutivos.
Uma representação gráfica do limite será exibida em **Alarm Preview (Visualização do alarme)**.
1. Em **Notification** (Notificação), para **Send notification to** (Enviar notificação para), escolha um tópico do SNS existente ou crie um novo.
Para criar um tópico do SNS, escolha **New list (Nova lista)**. Em **Send notification to (Enviar notificação para)**, digite um nome para o tópico do SNS (por exemplo, Terminate\$1EC2\$1Instance) Para **Email list** (Lista de e-mails), digite uma lista de endereços de e-mail separados por vírgulas a serem notificados quando o alarme mudar para o estado `ALARM`. Para cada endereço de e-mail será enviado um e-mail de confirmação da inscrição no tópico. Você deve confirmar a assinatura para que as notificações sejam enviadas para um endereço de e-mail.
1. Escolha **Ação do EC2**.
1. Em **Sempre que este alarme**, escolha **Estado é ALARME**. Em **Tomar esta medida**, escolha **Encerrar esta instância**.
1. Escolha **Criar Alarm**.
## Adicionar ações de reinicializar a alarmes do Amazon CloudWatch
É possível criar um alarme do Amazon CloudWatch que monitore uma instância do Amazon EC2 e reinicialize automaticamente a instância. A ação de alarme de reinicialização é recomendada para falhas de verificação de integridade da instância (ao contrário da ação de alarme de recuperação, que é adequado para falhas de verificação de integridade do sistema). Reinicializar a instância equivale a reinicializar o sistema operacional. Na maioria dos casos, leva apenas alguns minutos para reinicializar sua instância. Quando você reinicializa uma instância, ela permanece no mesmo host físico, para que sua instância mantenha seu nome DNS público, o endereço IP privado e os dados em seus volumes de armazenamento de instância.
A reinicialização de uma instância não inicia uma nova hora de faturamento de instância, ao contrário de pará-la e reiniciá-la. Para obter mais informações sobre como reiniciar uma instância, consulte [Reinicializar a instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html) no *Guia do usuário do Amazon EC2*.
**Importante**
Para evitar um comportamento de disputa entre as ações de reinicialização e recuperação, evite configurar o mesmo período de avaliação para um alarme de reinicialização e um alarme de recuperação. Recomendamos que você defina alarmes de reinicialização para três períodos de avaliação de um minuto cada.
**Para criar um alarme para reinicializar uma instância usando o console do Amazon CloudWatch**
1. Abra o console do CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms**, **Create Alarm**.
1. Na etapa **Selecionar métrica**, faça o seguinte:
1. Em **Métricas do EC2**, escolha **Métricas por instância**.
1. Selecione a linha com a instância e a métrica **StatusCheckFailed\$1Instance**.
1. Para a estatística, escolha **Mínima**.
1. Escolha um período (por exemplo, **1 Minute**).
1. Escolha **Próximo**.
1. Na etapa **Definir alarme**, faça o seguinte:
1. Em **Limite de alarme**, digite um nome exclusivo para o alarme (por exemplo, Reinicializar instância do EC2) e uma descrição do alarme (por exemplo, Reinicializar instância do EC2 quando a verificação de integridade falhar). Os nomes de alarme devem conter somente caracteres ASCII.
1. Em **Whenever (Sempre)**, em **is (é)**, escolha **>** e digite **0**. Em **for (para)**, digite **3** períodos consecutivos.
Uma representação gráfica do limite será exibida em **Alarm Preview (Visualização do alarme)**.
1. Em **Notification** (Notificação), para **Send notification to** (Enviar notificação para), escolha um tópico do SNS existente ou crie um novo.
Para criar um tópico do SNS, escolha **New list (Nova lista)**. Em **Send notification to (Enviar notificação para)**, digite um nome para o tópico do SNS (por exemplo, Reboot\$1EC2\$1Instance). Para **Email list** (Lista de e-mails), digite uma lista de endereços de e-mail separados por vírgulas a serem notificados quando o alarme mudar para o estado `ALARM`. Para cada endereço de e-mail será enviado um e-mail de confirmação da inscrição no tópico. Você deve confirmar a assinatura para que as notificações sejam enviadas para um endereço de e-mail.
1. Escolha **Ação do EC2**.
1. Em **Sempre que este alarme**, escolha **Estado é ALARME**. Para **Tomar esta medida**, escolha **Reinicializar esta instância**.
1. Escolha **Criar Alarm**.
## Adicionar ações de recuperar a alarmes do Amazon CloudWatch
Você pode criar um alarme do Amazon CloudWatch que monitore uma instância do Amazon EC2 e recupere-a automaticamente se ocorrer um problema devido a uma falha de hardware subjacente ou um problema que exija o envolvimento da AWS para repará-lo. Instâncias encerradas não podem ser recuperadas. Uma instância recuperada é idêntica à instância original, incluindo o ID da instância, endereços IP privados, endereços IP elásticos e todos os metadados de instância.
Quando o alarme `StatusCheckFailed_System` for acionado e a ação de recuperação for iniciada, você será notificado pelo tópico do Amazon SNS que escolheu ao criar o alarme e a ação de recuperação associada. Durante a recuperação da instância, a instância será migrada durante uma reinicialização da instância e todos os dados na memória serão perdidos. Quando o processo é concluído, as informações serão publicadas no tópico do SNS que você tiver configurado para o alarme. Qualquer pessoa que estiver inscrita neste tópico do SNS receberá uma notificação por e-mail com o status da tentativa de recuperação e mais instruções. Você perceberá uma reinicialização da instância na instância recuperada.
A ação de recuperação pode ser usada somente com `StatusCheckFailed_System`, não com `StatusCheckFailed_Instance`.
Exemplos de problemas que causam falha nas verificações de status do sistema incluem:
+ Perda de conectividade de rede
+ Perda de energia do sistema
+ Problemas de software no host físico
+ Problemas de hardware de host físico que afetam a acessibilidade de rede
A ação de recuperar só é compatível com alguns tipos de instâncias. Para obter mais informações sobre os tipos de instância compatíveis e outros requisitos, consulte [Recuperar sua instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) e [Requisitos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html#requirements-for-recovery).
**Importante**
Para evitar um comportamento de disputa entre as ações de reinicialização e recuperação, evite configurar o mesmo período de avaliação para um alarme de reinicialização e um alarme de recuperação. Recomendamos que você defina alarmes de recuperação para dois períodos de avaliação de um minuto cada e alarmes de reinicialização para três períodos de avaliação de um minuto cada.
**Para criar um alarme para recuperar uma instância usando o console do Amazon CloudWatch**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Escolha **Criar Alarm**.
1. Escolha **Selecionar métrica** e faça o seguinte:
1. Escolha **Métricas do EC2**, **Métricas por instância**.
1. Selecione a linha com a instância e a métrica **StatusCheckFailed\$1System** e escolha **Selecionar métrica**.
1. Para a estatística, escolha **Mínima**.
1. Escolha um período (por exemplo, **1 Minute**).
**Importante**
Para evitar um comportamento de disputa entre as ações de reinicialização e recuperação, evite configurar o mesmo período de avaliação para um alarme de reinicialização e um alarme de recuperação. É recomendável que você defina os alarmes de recuperação para dois períodos de avaliação de um minuto cada.
1. Em **Condições**, faça o seguinte:
1. Em **Tipo de limite**, escolha **Estático**.
1. Em **Sempre que**, escolha **Maior** e insira **0** para **que…**.
1. Escolha **Configuração adicional** e, em seguida, para **Pontos de dados para alarme**, especifique 2 **de** 2.
1. Escolha **Próximo**.
1. Em **Notificação**, faça o seguinte:
1. Em **Alarm state trigger** (Gatilho do estado do alarme), escolha **In alarm** (Em alarme).
1. Em **Enviar notificação para o seguinte tópico do SNS**, escolha um tópico existente do SNS ou crie um novo.
1. Escolha **Add EC2 Action** (Adicionar ação do EC2).
1. Em **Alarm state trigger** (Gatilho do estado do alarme), escolha **In alarm** (Em alarme).
1. Em **Adotar a seguinte ação**, escolha **Recuperar esta instância**.
1. Escolha **Próximo**.
1. Em **Nome do alarme**, insira um nome exclusivo para o alarme (por exemplo, **Recover EC2 instance**) e uma descrição do alarme (por exemplo, **Recover EC2 instance when health checks fail**). Os nomes de alarme devem conter somente caracteres ASCII.
1. Escolha **Próximo**.
1. Escolha **Criar Alarm**.
## Visualizar o histórico de alarmes disparados e ações
É possível visualizar o histórico de alarmes e ações no console do Amazon CloudWatch. O Amazon CloudWatch mantém o histórico de alarmes e de ações dos últimos 30 dias.
**Para visualizar o histórico de alarmes e ações disparados**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms (Alarmes)** e selecione um alarme.
1. Para visualizar a transição de estado mais recente com os valores de tempo e métrica, escolha a guia **Detalhes**.
1. Para visualizar as entradas mais recentes do histórico, escolha a guia **History (Histórico)**.
# Eventos de alarme e o EventBridge
O CloudWatch envia eventos ao Amazon EventBridge sempre que um alarme do CloudWatch é criado, atualizado, excluído ou altera o estado de um alarme. É possível usar o EventBridge e esses eventos para gravar regras que executam ações, como notificá-lo, quando um alarme mudar de estado. Para obter mais informações, consulte [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
O CloudWatch garante a entrega de eventos de alteração de estado de alarme ao EventBridge.
## Eventos de alteração do estado do alarme
Esta seção mostra exemplos de eventos enviados para o EventBridge quando o estado de um alarme muda. Selecione uma aba para visualizar diferentes tipos de eventos de alteração do estado do alarme.
------
#### [ Single Metric Alarm ]
Eventos gerados quando um alarme de métrica única muda de estado. Esses eventos incluem os campos `state` e `previousState` com os resultados da avaliação do alarme.
```
{
"version": "0",
"id": "c4c1c1c9-6542-e61b-6ef0-8c4d36933a92",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:04:40Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"configuration": {
"description": "Goes into alarm when server CPU utilization is too high!",
"metrics": [
{
"id": "30b6c6b2-a864-43a2-4877-c09a1afc3b87",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "CPUUtilization",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
]
},
"previousState": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [0.0666851903306472 (01/10/19 13:46:00)] was not greater than the threshold (50.0) (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-01T13:56:40.985+0000\",\"startDate\":\"2019-10-01T13:46:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[0.0666851903306472],\"threshold\":50.0}",
"timestamp": "2019-10-01T13:56:40.987+0000",
"value": "OK"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [99.50160229693434 (02/10/19 16:59:00)] was greater than the threshold (50.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:04:40.985+0000\",\"startDate\":\"2019-10-02T16:59:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[99.50160229693434],\"threshold\":50.0}",
"timestamp": "2019-10-02T17:04:40.989+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Metric Math Alarm ]
Eventos gerados quando um alarme de cálculo de métrica muda de estado. Esses eventos incluem os detalhes da expressão matemática no campo `configuration`.
```
{
"version": "0",
"id": "2dde0eb1-528b-d2d5-9ca6-6d590caf2329",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:20:48Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"configuration": {
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"metrics": [
{
"expression": "SUM(METRICS())",
"id": "e1",
"label": "Total Network Traffic",
"returnData": true
},
{
"id": "m1",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkIn",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkOut",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
}
]
},
"previousState": {
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2019-10-02T17:20:03.642+0000",
"value": "INSUFFICIENT_DATA"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [45628.0 (02/10/19 17:10:00)] was greater than the threshold (10000.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:20:48.551+0000\",\"startDate\":\"2019-10-02T17:10:00.000+0000\",\"period\":300,\"recentDatapoints\":[45628.0],\"threshold\":10000.0}",
"timestamp": "2019-10-02T17:20:48.554+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Anomaly Detection Alarm ]
Eventos gerados quando um alarme de detecção de anomalias muda de estado. Esses eventos incluem limites superiores e inferiores no campo `reasonData`.
```
{
"version": "0",
"id": "daafc9f1-bddd-c6c9-83af-74971fcfc4ef",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-03T16:00:04Z",
"region": "us-east-1",
"resources": ["arn:aws:cloudwatch:us-east-1:123456789012:alarm:EC2 CPU Utilization Anomaly"],
"detail": {
"alarmName": "EC2 CPU Utilization Anomaly",
"state": {
"value": "ALARM",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.0 (03/10/19 15:58:00)] was less than the lower thresholds [0.020599444741798756] or greater than the upper thresholds [0.3006915352732461] (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T16:00:04.650+0000\",\"startDate\":\"2019-10-03T15:58:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.0],\"recentLowerThresholds\":[0.020599444741798756],\"recentUpperThresholds\":[0.3006915352732461]}",
"timestamp": "2019-10-03T16:00:04.653+0000"
},
"previousState": {
"value": "OK",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.166666666664241 (03/10/19 15:57:00)] was not less than the lower thresholds [0.0206719426210418] or not greater than the upper thresholds [0.30076870222143803] (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T15:59:04.670+0000\",\"startDate\":\"2019-10-03T15:57:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.166666666664241],\"recentLowerThresholds\":[0.0206719426210418],\"recentUpperThresholds\":[0.30076870222143803]}",
"timestamp": "2019-10-03T15:59:04.672+0000"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
},
"configuration": {
"description": "Goes into alarm if CPU Utilization is out of band",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 60,
"stat": "Average"
},
"returnData": true
}, {
"id": "ad1",
"expression": "ANOMALY_DETECTION_BAND(m1, 0.8)",
"label": "CPUUtilization (expected)",
"returnData": true
}]
}
}
}
```
------
#### [ Composite Alarm ]
Eventos gerados quando um alarme composto muda de estado. Esses eventos incluem informações de supressão nos campos `actionsSuppressedBy` e `actionsSuppressedReason`.
```
{
"version": "0",
"id": "d3dfc86d-384d-24c8-0345-9f7986db0b80",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-22T15:57:45Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"actionsSuppressedReason": "Actions suppressed by WaitPeriod",
"value": "ALARM",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.FirstChild transitioned to ALARM at Friday 22 July, 2022 15:57:45 UTC",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"ALARM\",\"timestamp\":\"2022-07-22T15:57:45.394+0000\"}}]}",
"timestamp": "2022-07-22T15:57:45.394+0000"
},
"previousState": {
"value": "OK",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.Main was created and its alarm rule evaluates to OK",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:57.770+0000\"}},{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:54.191+0000\"}}]}",
"timestamp": "2022-07-22T15:56:14.552+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Multi Time Series Alarm ]
Eventos gerados quando um contribuidor de alarme ou um alarme muda de estado. Os eventos de alteração de estado do contribuidor do alarme contêm a identificação e os atributos do contribuidor do alarme, bem como o ponto de dados mais recente que ultrapassou o limite. Os eventos de alteração do estado do alarme têm um resumo do número de contribuidores que causaram a transição do alarme em seu motivo de estado.
**Exemplo de colaborador de alarme**
```
{
"version": "0",
"id": "6d226bbc-07f0-9a31-3359-1736968f8ded",
"detail-type": "CloudWatch Alarm Contributor State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"alarmContributor": {
"id": "6d442278dba546f6",
"attributes": {
"TableName": "example-dynamodb-table-name"
}
},
"state": {
"value": "ALARM",
"reason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData":true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
**Exemplo de alarme**
```
{
"version": "0",
"id": "80ddd249-dedf-7c4d-0708-0eb78132dd78",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"state": {
"value": "ALARM",
"reason": "6 out of 6 time series evaluated to ALARM",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2025-12-01T13:40:50.600+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData": true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
}
}
}
```
------
## Eventos de alteração da configuração do alarme
Esta seção mostra exemplos de eventos enviados para o EventBridge quando a configuração de um alarme é alterada. As alterações na configuração incluem criar, atualizar ou excluir alarmes.
------
#### [ Creation Events ]
Eventos gerados quando novos alarmes são criados. Esses eventos incluem a configuração inicial do alarme no campo `configuration`, com `operation` definido como “create”.
**Exemplo de alarme composto**
```
{
"version": "0",
"id": "91535fdd-1e9c-849d-624b-9a9f2b1d09d0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:22.289+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"alarmName": "ServiceAggregatedAlarm",
"description": "Aggregated monitor for instance",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:22.289+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**Exemplo de alarme composto com supressor**
```
{
"version": "0",
"id": "454773e1-09f7-945b-aa2c-590af1c3f8e0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:46Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Update Events ]
Eventos gerados quando os alarmes existentes são modificados. Esses eventos contêm os campos `configuration` e `previousConfiguration` para mostrar o que mudou.
**Exemplo de alarme de métricas**
```
{
"version": "0",
"id": "bc7d3391-47f8-ae47-f457-1b4d06118d50",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:34Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"operation": "update",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:13.757+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 80,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "86bfa85f-b14c-ebf7-8916-7da014ce23c0",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:34.267+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
},
"previousConfiguration": {
"evaluationPeriods": 1,
"threshold": 70,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "d6bfa85f-893e-b052-a58b-4f9295c9111a",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:13.757+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**Exemplo de alarme de métricas com supressor**
```
{
"version": "0",
"id": "4c6f4177-6bd5-c0ca-9f05-b4151c54568b",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:56Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "update",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [], Remove
"insufficientDataActions": []
},
"previousConfiguration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Deletion Events ]
Eventos gerados quando os alarmes são excluídos. Esses eventos incluem a configuração final do alarme e definem `operation` como "delete".
**Exemplo de alarme de cálculo de métrica**
```
{
"version": "0",
"id": "f171d220-9e1c-c252-5042-2677347a83ed",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:07:13Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"operation": "delete",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:17.672+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 10000,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkIn",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkOut",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "e1",
"expression": "SUM(METRICS())",
"label": "Total Network Traffic",
"returnData": true
}
],
"alarmName": "TotalNetworkTrafficTooHigh",
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:17.672+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**Exemplo de alarme de cálculo de métrica com supressor**
```
{
"version": "0",
"id": "e34592a1-46c0-b316-f614-1b17a87be9dc",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T14:00:01Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "delete",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
# Configurar regras de silenciamento de alarme
As etapas desta seção explicam como usar o console do CloudWatch para criar uma regra de silenciamento de alarme. Você também pode usar a API ou a AWS CLI para criar uma regra de silenciamento de alarme. Para obter mais informações, consulte [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html).
**Para criar uma regra de silenciamento de alarme**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarmes** e, em seguida, **Regras de silenciamento**.
1. Clique no botão **Criar regra de silenciamento de alarme**, que abre um assistente
1. Na seção **Detalhes da regra de silenciamento de alarme**, insira um nome e uma descrição opcional para a sua regra de silenciamento de alarme
1. Na seção **Padrão de programação**, escolha programação única ou recorrente.
1. Se você escolher uma ocorrência única,
1. Selecione o fuso horário para aplicar as programações de silenciamento
1. Escolha uma data e hora de início para definir quando a regra de silenciamento deve ficar ativa
1. Escolha a data e a hora de término para definir quando a regra de silenciamento deve expirar
1. Se escolher Programação recorrente, há duas opções. Ou usar o formulário do Console, ou a expressão cron para configurar os horários recorrentes.
1. Em **Tipo de criação de programação**, escolha “Especificar data, hora e recorrência” para usar o formulário do Console
1. Escolha o fuso horário para aplicar a regra de silenciamento
1. Escolha uma **Data e hora de início** para definir quando a regra de silenciamento deve ficar ativa
1. Escolha uma **Duração** para definir quanto tempo a regra de silenciamento deve durar quando ficar ativa
1. Escolha **Repetir** para definir como a programação deve se repetir, como em todos os dias, todos os meses, todo fim de semana ou em dias específicos da semana.
1. Escolha a opção **Até** para definir quando a programação de silenciamento deve expirar. A opção padrão é “Indefinidamente”
1. Em **Tipo de criação de programação**, escolha “Definir a partir de uma expressão cron” para configurar programações usando expressões cron
1. Na seção **Expressão cron**, insira os valores da expressão cron desejados.
1. Escolha uma **Duração** para definir quanto tempo a regra de silenciamento deve durar quando ficar ativa
1. Na seção **Período** opcional, insira a data e hora de início e término opcionais para definir quando a programação de silenciamento deve ficar ativa e expirar.
1. Na seção **Alarmes de destino**, escolha os alarmes no menu suspenso aos quais você deseja aplicar essa regra de silenciamento
1. Na seção **Definir tags para sua regra de silenciamento**, anexe tags à sua regra de silenciamento de alarme. Uma tag é um par de chave-valor aplicado a um recurso para armazenar metadados sobre esse recurso. Para obter mais informações, consulte [O que são tags?](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html).
1. Selecione o botão **Criar regra de silenciamento de alarme** para criar a regra de silenciamento
## Silenciamentos rápidos
Os alarmes podem ser adicionados por um curto período de tempo da forma a seguir,
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Alarmes**
1. Selecione os alarmes que você deseja silenciar na lista.
1. No menu **Ações**, escolha **Silenciar**
1. Na seção **Silenciamento rápido**, escolha os períodos de tempo predefinidos (15min, 1h, 3h), ou selecione **Silenciar até** para definir o período de tempo desejado.
1. Clique em **Confirmar** para silenciar os alarmes imediatamente até o período escolhido
## Adição de alarmes às regras de silenciamento existentes
Os alarmes podem ser adicionados às regras de silenciamento existentes da forma a seguir,
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Alarmes**
1. Selecione os alarmes que você deseja silenciar na lista.
1. No menu **Ações**, escolha **Silenciar**
1. Escolha **Aplicar regras de silenciamento existentes**, o que deve abrir um assistente
1. Selecione as regras de silenciamento de alarmes no menu suspenso ao qual deseja adicionar os alarmes
1. Clique em **Aplicar**
**nota**
O silenciamento rápido e a adição de um alarme às opções de regras de silenciamento existentes também estão disponíveis na página de detalhes do alarme. A guia **Regras de silenciamento** na página de detalhes exibe todas as regras de silenciamento associadas ao alarme.
# Gerenciar alarmes
**Topics**
+ [
# Como editar ou excluir um alarme do CloudWatch
](Edit-CloudWatch-Alarm.md)
+ [
# Ocultar alarmes do Auto Scaling
](hide-autoscaling-alarms.md)
+ [
# Alarmes e marcação
](CloudWatch_alarms_and_tagging.md)
+ [
# Visualização e gerenciamento de alarmes silenciados
](viewing-managing-muted-alarms.md)
# Como editar ou excluir um alarme do CloudWatch
É possível editar ou excluir um alarme existente.
Não é possível alterar o nome de um alarme existente. Copie o alarme e dê ao novo alarme um nome diferente. Para copiar um alarme, marque a caixa de seleção ao lado do nome do alarme na lista de alarmes e escolha **Action (Ação)**, **Copy (Copiar)**.
**Para editar um alarme**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Escolha o nome do alarme.
1. Para adicionar ou remover tags, escolha a guia **Tags** e, em seguida, escolha **Gerenciar tags**.
1. Para editar outras partes do alarme, escolha **Ações**, **Editar**.
A página **Specify metric and conditions (Especificar métrica e condições)** será exibida, mostrando um gráfico e outras informações sobre a métrica e a estatística que você selecionou.
1. Para alterar a métrica, escolha **Edit (Editar)**, escolha a guia **All metrics (Todas as métricas)** e execute uma das seguintes ações:
+ Escolha o namespace do serviço que contém a métrica desejada. Continue escolhendo as opções à medida que elas são exibidas para restringir as escolhas. Quando uma lista de métricas for exibida, marque a caixa de seleção ao lado da métrica que você deseja.
+ Na caixa de pesquisa, digite o nome de uma métrica, uma dimensão ou um ID de recurso e pressione Enter. Escolha um dos resultados e continue até uma lista de métricas ser exibida. Marque a caixa de seleção ao lado da métrica que você deseja.
Escolha **Selecionar métrica**.
1. Para alterar outros aspectos do alarme, escolha as opções apropriadas. Para alterar o número de pontos de dados que devem estar violando para o alarme entrar no estado `ALARM` ou para alterar a maneira como os dados ausentes são tratados, escolha **Additional configuration (Configuração adicional)**.
1. Escolha **Próximo**.
1. Em **Notification (Notificação)**, **Auto Scaling action (Ação do Auto Scaling)** e **EC2 action (Ação do EC2)**, é possível editar as ações executadas quando o alarme é acionado. Escolha **Próximo**.
1. Opcionalmente, altere a descrição do alarme.
Não é possível alterar o nome de um alarme existente. Copie o alarme e dê ao novo alarme um nome diferente. Para copiar um alarme, marque a caixa de seleção ao lado do nome do alarme na lista de alarmes e escolha **Action (Ação)**, **Copy (Copiar)**.
1. Escolha **Próximo**.
1. Em **Preview and create (Visualizar e criar)**, confirme se as informações e condições são o que você deseja e escolha **Update alarm (Atualizar alarme)**.
**Para atualizar uma lista de notificações por e-mail que foi criada usando o console do Amazon SNS**
1. Abra o console do Amazon SNS em [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home).
1. No painel de navegação, escolha **Topics (Tópicos)** e selecione o ARN para a sua lista de notificações (tópico).
1. Execute um destes procedimentos:
+ Para adicionar um endereço de e-mail, escolha **Create subscription (Criar inscrição)**. Em **Protocolo**, escolha **E-mail**. Em **Endpoint**, insira o endereço de e-mail do novo destinatário. Selecione **Criar assinatura**.
+ Para remover um endereço de e-mail, escolha **ID da inscrição**. Escolha **Outras ações de inscrição**, **Excluir inscrições**.
1. Selecione **Publicar em um tópico**.
**Para excluir um alarme**
1. Abra o console do CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Alarmes**.
1. Marque a caixa de seleção à esquerda do nome do alarme e escolha **Ações**, **Excluir**.
1. Escolha **Excluir**.
# Ocultar alarmes do Auto Scaling
Ao visualizar seus alertas no Console de gerenciamento da AWS, você pode ocultar os alarmes relacionados ao Amazon EC2 Auto Scaling e ao Application Auto Scaling. Esse recurso está disponível somente no Console de gerenciamento da AWS.
**Para ocultar temporariamente os alarmes do Auto Scaling**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os Alarmes), e selecione **Hide Auto Scaling alarms** (Ocultar todos os alarmes de AutoScaling).
# Alarmes e marcação
As *etiquetas* são pares de valores-chave que podem ajudar você a organizar e categorizar os recursos. Você também pode usá-las para definir o escopo de permissões de usuários, concedendo a um usuário permissão para acessar ou alterar apenas recursos com determinados valores de etiqueta. Para obter informações mais gerais sobre a marcação de recursos, consulte [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
A lista apresentada a seguir explica alguns detalhes sobre como a marcação funciona com os alarmes do CloudWatch.
+ Para que seja possível definir ou atualizar as etiquetas para um recurso do CloudWatch, é necessário estar conectado a uma conta que tenha a permissão `cloudwatch:TagResource`. Por exemplo, para criar um alarme e definir as etiquetas para ele, é necessário ter a permissão `cloudwatch:TagResource`, além da permissão `the cloudwatch:PutMetricAlarm `. Recomendamos que você se certifique de que qualquer pessoa em sua organização que criará ou atualizará os recursos do CloudWatch tenha a permissão `cloudwatch:TagResource`.
+ As etiquetas podem ser usadas para obter um controle de autorização baseado em etiquetas. Por exemplo, as permissões de perfil ou de usuário do IAM podem incluir condições para limitar as chamadas do CloudWatch para recursos específicos com base nas etiquetas. No entanto, considere o seguinte:
+ As etiquetas com nomes que começam com `aws:` não podem ser usadas para obter um controle de autorização baseado em etiquetas.
+ Os alarmes compostos não oferecem suporte para o controle de autorização baseado em etiquetas.
# Visualização e gerenciamento de alarmes silenciados
**Visualização de alarmes silenciados:** é possível identificar facilmente quais alarmes estão silenciados no momento por meio do console do CloudWatch. Tanto na exibição da lista de alarmes quanto nas páginas de detalhes dos alarmes individuais, um ícone de silenciamento é exibido ao lado dos alarmes cujas ações estão sendo silenciadas pelas regras ativas de silenciamento. Esse indicador visual ajuda você a entender rapidamente quais ações de alarmes estão sendo silenciadas no momento até que a janela de silenciamento expire.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_icon.png)
**Cronograma de alarmes:** o console de alarmes do CloudWatch fornece uma visão abrangente do cronograma que mostra quando suas ações de alarme foram silenciadas. Esse cronograma exibe os períodos de silêncio junto com as mudanças no estado do alarme, oferecendo uma visão histórica completa do comportamento do alarme e da atividade de silenciamento. É possível usar esse cronograma para analisar a eficácia de suas regras de silenciamento e entender como elas se correlacionam com suas atividades operacionais.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/alarm-mutes-timelineview.png)
**Verificação programática do status de silenciamento do alarme:** para determinar programaticamente se um alarme está silenciado no momento, é possível usar a API [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) com o nome do alarme como critério de filtro. Essa API retorna todas as regras ativas de silenciamento que estejam afetando o alarme especificado, permitindo que você integre verificações de status de silenciamento em seus fluxos de trabalho de automação, painéis de monitoramento ou ferramentas operacionais.
Por exemplo: para verificar se um alarme chamado “HighCpuAlarm” está silenciado no momento, chame a API [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) com o parâmetro de filtro definido como o nome do alarme. A resposta incluirá todas as regras de silenciamento direcionadas a esse alarme, junto com seu status atual (PROGRAMADO, ATIVO ou EXPIRADO).
**Histórico de alarmes:** sempre que as ações de alarme são silenciadas devido a uma regra ativa de silenciamento, o CloudWatch grava uma entrada de histórico no log de histórico do alarme. Isso fornece uma trilha de auditoria completa de quando seus alarmes foram silenciados, ajudando você a entender o cronograma dos eventos de silenciamento e a correlacioná-los com as atividades operacionais. É possível visualizar esse histórico por meio do console do CloudWatch ou recuperá-lo programaticamente usando a API [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html).
**nota**
Quando várias regras de silenciamento de alarme estão ativas simultaneamente, o nome da regra de silenciamento criada mais recentemente é gravado no histórico de alarmes junto com o número total de outras regras de silenciamento ativas.
A linha do tempo exibe períodos de silenciamento somente quando um estado de alarme muda durante uma janela ativa de silenciamento e as ações são impedidas de serem executadas.
**dica**
É possível gerenciar as regras de silenciamento de alarmes de forma programática usando a API do CloudWatch. Para obter mais informações, consulte [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html), [GetAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetAlarmMuteRule.html), [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) e [DeleteAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarmMuteRule.html).
## Recursos comuns dos alarmes do CloudWatch
Estes recursos se aplicam a todos os alarmes do CloudWatch:
+ Não há limite para o número de alarmes que você pode criar. Para criar ou atualizar um alarme, use o console do CloudWatch, a ação [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) da API ou o comando [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) na AWS CLI.
+ Os nomes dos alarmes devem conter somente caracteres UTF-8 da e não podem conter caracteres de controle ASCII
+ É possível listar um ou todos os alarmes configurados no momento e listar todos os alarmes em um determinado estado usando o console do CloudWatch, a ação [DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html) da API ou o comando [describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html) na AWS CLI.
+ É possível desabilitar e habilitar ações de alarmes usando as ações [DisableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DisableAlarmActions.html) e [ EnableAlarmActions ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_EnableAlarmActions.html) da API ou os comandos [disable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/disable-alarm-actions.html) e[ enable-alarm-actions ](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/enable-alarm-actions.html) na AWS CLI.
+ É possível testar um alarme configurando-o para qualquer estado usando a ação [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html) da API ou o comando [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) na AWS CLI. Essa alteração de estado temporária dura somente até ocorrer a próxima comparação de alarmes.
+ É possível criar um alarme para uma métrica personalizada antes de criar essa métrica personalizada. Para o alarme ser válido, é necessário incluir todas as dimensões para a métrica personalizada, além do namespace e do nome da métrica na definição do alarme. Para fazer isso, você pode usar a ação [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) da API ou o comando [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) na AWS CLI.
+ É possível exibir o histórico de um alarme usando o console do CloudWatch, a ação [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html) da API ou o comando [describe-alarm-history](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarm-history.html) na AWS CLI. O CloudWatch preserva o histórico de alarmes por 30 dias. Cada transição de estado é marcada com um time stamp exclusivo. Em casos raros, o histórico pode mostrar mais de uma notificação para uma alteração de estado. O time stamp permite confirmar alterações de estado exclusivas.
+ Você pode adicionar alarmes como favoritos na opção *Favorites and recents* (Favoritos e recentes) no painel de navegação do console do CloudWatch movendo o ponteiro do mouse sobre o alarme que deseja adicionar e escolhendo o símbolo de estrela próximo a ele.
+ Os alarmes têm uma cota de período de avaliação. O período de avaliação é calculado multiplicando-se o período do alarme pelo número de períodos de avaliação utilizados.
+ O período máximo de avaliação é de sete dias para alarmes com um período de pelo menos uma hora (3.600 segundos).
+ O período máximo de avaliação é de um dia para alarmes com um período mais curto.
+ O período máximo de avaliação é de um dia para alarmes que usam a fonte de dados do Lambda personalizada.
**nota**
Alguns recursos da AWS não enviam dados de métrica para o CloudWatch em determinadas condições.
Por exemplo, o Amazon EBS não pode enviar dados de métrica para um volume disponível que não esteja anexado a uma instância do Amazon EC2, porque não há atividade de métrica a ser monitorada para esse volume. Se você tiver um alarme definido para essa métrica, poderá visualizar a alteração do estado para `INSUFFICIENT_DATA`. Isso pode indicar que o recurso está inativo e não necessariamente indicar que há um problema. É possível especificar como cada alarme lida com os dados ausentes. Para obter mais informações, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
# Recomendações de alarmes de práticas recomendadas para serviços da AWS
O CloudWatch fornece recomendações de alarme prontas para uso. Esses são alarmes do CloudWatch que recomendamos que você crie para métricas publicadas por outros serviços da AWS. Essas recomendações podem ajudar a identificar as métricas para as quais você deve definir alarmes a fim de seguir as práticas recomendadas de monitoramento. As recomendações também sugerem os limites de alarme a serem definidos. Seguir essas recomendações pode contribuir para que você não perca um monitoramento importante da sua infraestrutura da AWS.
Para encontrar as recomendações de alarme, use a seção de métricas do console do CloudWatch e selecione a opção de filtro de recomendações de alarmes. Se você navegar até os alarmes recomendados no console e, em seguida, criar um alarme recomendado, o CloudWatch poderá preencher previamente algumas das configurações de alarme. Para alguns alarmes recomendados, o valor limite do alarme também é pré-preenchido. Também é possível usar o console para baixar definições de alarme de infraestrutura como código para alarmes recomendados e, em seguida, usar esse código para criar o alarme no AWS CloudFormation, na AWS CLI ou no Terraform.
Além disso, é possível visualizar a lista de alarmes recomendados em [Alarmes recomendados](Best_Practice_Recommended_Alarms_AWS_Services.md).
Será feita uma cobrança pelos alarmes que você criar, na mesma taxa de quaisquer outros alarmes que você criar no CloudWatch. O uso das recomendações não acarreta custos adicionais. Para obter mais informações, consulte [Preços do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Localizar e criar alarmes recomendados
Siga estas etapas para encontrar as métricas para as quais o CloudWatch recomenda que você defina alarmes e, opcionalmente, para criar um desses alarmes. O primeiro procedimento explica como encontrar as métricas que têm alarmes recomendados e como criar um desses alarmes.
Você também pode fazer o download em massa das definições de alarme de infraestrutura como código para todos os alarmes recomendados em um namespace da AWS, como `AWS/Lambda` ou `AWS/S3`. Essas instruções são apresentadas mais adiante neste tópico.
**Localizar as métricas com alarmes recomendados e criar um único alarme recomendado**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Metrics** (Métricas), **All metrics** (Todas as métricas).
1. Acima da tabela **Métricas**, selecione **Recomendações de alarme**.
A lista de namespaces de métricas é filtrada para incluir apenas as métricas que têm recomendações de alarme e que os serviços em sua conta estão publicando.
1. Escolha o namespace para um serviço.
A lista de métricas nesse namespace é filtrada para incluir apenas aquelas que têm recomendações de alarme.
1. Para visualizar a intenção do alarme e o limite recomendado para uma métrica, selecione **Exibir detalhes**.
1. Para criar um alarme para uma das métricas, siga um destes procedimentos:
+ Para usar o console para criar o alarme, faça o seguinte:
1. Marque a caixa de seleção da métrica e selecione a guia **Métricas representadas graficamente**.
1. Escolha o ícone de alarme.
![\[Criar um alarme de uma métrica representada em um gráfico\]](http://docs.aws.amazon.com/pt_br/AmazonCloudWatch/latest/monitoring/images/metric_graph_alarm.png)
O assistente de criação de alarme é exibido, com o nome da métrica, a estatística e o período preenchidos com base na recomendação de alarme. Se a recomendação incluir um valor limite específico, esse valor também será pré-preenchido.
1. Escolha **Próximo**.
1. Em **Notificação**, selecione um tópico do SNS para receber notificações quando o alarme transitar para o estado `ALARM`, `OK` ou `INSUFFICIENT_DATA`.
Para que o alarme envie várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification (Adicionar notificação)**.
Para que o alarme não envie notificações, escolha **Remove (Remover)**.
1. Para que o alarme execute o Auto Scaling ou ações do EC2, escolha o botão apropriado e escolha o estado do alarme e a ação a ser executada.
1. Quando terminar, escolha **Next** (Próximo).
1. Digite um nome e uma descrição para o alarme. O nome deve conter somente caracteres ASCII. Escolha **Próximo**.
1. Em **Preview and create (Visualizar e criar)**, confirme se as informações e condições são o que você deseja e escolha **Create alarm (Criar alarme)**.
+ Para fazer o download de uma definição de alarme de infraestrutura como código para usar no AWS CloudFormation, na AWS CLI ou no Terraform, escolha **Baixar código de alarme** e selecione o formato desejado. O código baixado terá as configurações recomendadas para o nome da métrica, a estatística e o limite.
**Fazer download das definições de alarme de infraestrutura como código para todos os alarmes recomendados para um serviço da AWS**
1. Abra o console CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Metrics** (Métricas), **All metrics** (Todas as métricas).
1. Acima da tabela **Métricas**, selecione **Recomendações de alarme**.
A lista de namespaces de métricas é filtrada para incluir apenas as métricas que têm recomendações de alarme e que os serviços em sua conta estão publicando.
1. Escolha o namespace para um serviço.
A lista de métricas nesse namespace é filtrada para incluir apenas aquelas que têm recomendações de alarme.
1. A opção **Baixe o código de alarme** exibe o número de alarmes recomendado para as métricas nesse namespace. Para baixar definições de alarme de infraestrutura como código para todos os alarmes recomendados, selecione **Download do código de alarme** e, em seguida, escolha o formato de código desejado.
# Alarmes recomendados
As seções a seguir listam as métricas para as quais recomendamos que você defina alarmes de práticas recomendadas. Para cada métrica, também são exibidas as dimensões, a intenção do alarme, o limite recomendado, a justificativa do limite, a duração do período e o número de pontos de dados.
Algumas métricas podem aparecer duas vezes na lista. Isso acontece quando alarmes diferentes são recomendados para combinações diferentes de dimensões dessa métrica.
**Pontos de dados para alarme** é o número de pontos de dados que devem ser violados para enviar o alarme para o estado ALARME. **Períodos de avaliação** é o número de períodos que são levados em conta quando o alarme é avaliado. Se esses números forem iguais, o alarme entrará em estado ALARME somente quando esse número de períodos consecutivos tiver valores que ultrapassem o limite. Se **Pontos de dados para alarme** for menor que **Períodos de avaliação**, então o alarme será um alarme "M de N" e entrará no estado ALARM se pelo menos os pontos de dados **Pontos de dados para alarme** forem violados dentro de qualquer conjunto de pontos de dados de **Períodos de avaliação**. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
**Topics**
+ [
## Amazon API Gateway
](#ApiGateway)
+ [
## Amazon EC2 Auto Scaling
](#AutoScaling)
+ [
## AWS Certificate Manager (ACM)
](#CertificateManager)
+ [
## Amazon CloudFront
](#CloudFront)
+ [
## Amazon Cognito
](#Cognito)
+ [
## Amazon DynamoDB
](#DynamoDB)
+ [
## Amazon EBS
](#Recommended_EBS)
+ [
## Amazon EC2
](#EC2)
+ [
## Amazon ElastiCache
](#ElastiCache)
+ [
## Amazon ECS
](#ECS)
+ [
## Amazon ECS com o Container Insights
](#ECS-ContainerInsights)
+ [
## Amazon ECS com o Container Insights com observabilidade aprimorada
](#ECS-ContainerInsights_enhanced)
+ [
## Amazon EFS
](#EFS)
+ [
## Amazon EKS com o Container Insights
](#EKS-ContainerInsights)
+ [
## Agendador do Amazon EventBridge
](#Eventbridge-Scheduler)
+ [
## Amazon Kinesis Data Streams
](#Kinesis)
+ [
## Lambda
](#Lambda)
+ [
## Lambda Insights
](#LambdaInsights)
+ [
## Amazon VPC (`AWS/NATGateway`)
](#NATGateway)
+ [
## Link privado da AWS (`AWS/PrivateLinkEndpoints`)
](#PrivateLinkEndpoints)
+ [
## Link privado da AWS (`AWS/PrivateLinkServices`)
](#PrivateLinkServices)
+ [
## `Amazon RDS`
](#RDS)
+ [
## `Amazon Route 53 Public Data Plane`
](#Route53)
+ [
## `Amazon S3`
](#S3)
+ [
## `S3ObjectLambda`
](#S3ObjectLambda)
+ [
## Amazon SNS
](#SNS)
+ [
## Amazon SQS
](#SQS)
+ [
## Site-to-Site VPN
](#VPN)
## Amazon API Gateway
**4XXError**
**Dimensões:** ApiName, estágio
**Descrição do alarme:** esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar um problema na autorização ou nos parâmetros da solicitação do cliente. Isso também pode significar que um recurso foi removido ou que um cliente está solicitando um recurso que não existe. Considere a possibilidade de ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando os erros 4XX. Ademais, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por recurso e método e restringir a origem dos erros. Os erros também podem ser causados por exceder o limite de controle de utilização configurado. Se as respostas e os logs estiverem relatando taxas altas e inesperadas de erros 429, siga [este guia](https://repost.aws/knowledge-center/api-gateway-429-limit) para solucionar esse problema.
**Intenção:** esse alarme pode detectar altas taxas de erros no lado do cliente para as solicitações do API Gateway.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 4XX. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 4XX que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**5XXError**
**Dimensões:** ApiName, estágio
**Descrição do alarme:** esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar que há algo errado no backend da API, na rede ou na integração entre o gateway da API e a API de backend. Essa [documentação](https://repost.aws/knowledge-center/api-gateway-5xx-error) pode ajudar a solucionar a causa dos erros 5xx.
**Intenção:** esse alarme pode detectar altas taxas de erros no lado do servidor para as solicitações do API Gateway.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 5XX. No entanto, é possível ajustar o limite de acordo com o tráfego das solicitações e com as taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 5XX que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**Contagem**
**Dimensões:** ApiName, estágio
**Descrição do alarme:** esse alarme ajuda a detectar um baixo volume de tráfego para o estágio da API REST. Isso pode ser um indicador de um problema com a aplicação que chama a API, como o uso de endpoints incorretos. Também pode ser um indicador de um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.
**Intenção:** esse alarme pode detectar um volume de tráfego inesperadamente baixo para o estágio da API REST. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Caso as métricas detalhadas do CloudWatch estejam ativadas e você possa prever o volume normal de tráfego por método e recurso, recomendamos que você crie alarmes alternativos para ter um monitoramento mais detalhado das quedas de volume de tráfego para cada recurso e método. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.
**Estatística:** SampleCount
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**Contagem**
**Dimensões:** ApiName, estágio, recurso, método
**Descrição do alarme:** esse alarme ajuda a detectar um baixo volume de tráfego para o recurso e o método da API REST no estágio. Isso pode indicar um problema com a aplicação que está chamando a API, como o uso de endpoints incorretos. Também pode ser um indicador de um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.
**Intenção:** esse alarme pode detectar um volume de tráfego inesperadamente baixo para o recurso e o método da API REST no estágio. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.
**Estatística:** SampleCount
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**Contagem**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme ajuda a detectar um baixo volume de tráfego para o estágio da API HTTP. Isso pode indicar um problema com a aplicação que está chamando a API, como o uso de endpoints incorretos. Também pode ser um indicador de um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.
**Intenção:** esse alarme pode detectar um volume de tráfego inesperadamente baixo para o estágio da API HTTP. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Caso as métricas detalhadas do CloudWatch estejam ativadas e você possa prever o volume normal de tráfego por rota, recomendamos que você crie alarmes alternativos a esse para que haja um monitoramento mais detalhado das quedas no volume de tráfego de cada rota. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.
**Estatística:** SampleCount
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o valor limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**Contagem**
**Dimensões:** ApiId, estágio, recurso, método
**Descrição do alarme:** esse alarme ajuda a detectar um baixo volume de tráfego para a rota da API HTTP no estágio. Isso pode indicar um problema com a aplicação que está chamando a API, como o uso de endpoints incorretos. Isso também pode indicar um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.
**Intenção:** esse alarme pode detectar um volume de tráfego inesperadamente baixo para a rota da API HTTP no estágio. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.
**Estatística:** SampleCount
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o valor limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**IntegrationLatency**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme ajuda a detectar se há alta latência de integração para as solicitações de API em um estágio. Você pode correlacionar o valor da métrica `IntegrationLatency` com a métrica de latência correspondente do seu backend, como a métrica `Duration` para integrações do Lambda. Isso ajuda a determinar se o backend da API está demorando mais para processar as solicitações dos clientes devido a problemas de performance ou se há alguma outra sobrecarga da inicialização ou da inicialização a frio. Além disso, considere a possibilidade de ativar o CloudWatch Logs para sua API e verificar se há erros nos registros que possam estar causando os problemas de alta latência. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para obter uma visão dessa métrica por rota, o que ajudará você a restringir a origem da latência da integração.
**Intenção:** esse alarme pode detectar quando as solicitações do API Gateway em um estágio têm uma alta latência de integração. Recomendamos esse alarme para APIs de WebSocket e o consideramos opcional para APIs HTTP porque elas já têm recomendações de alarme separadas para a métrica de latência. Caso as métricas detalhadas do CloudWatch estejam ativadas e você tenha diferentes requisitos de performance de latência de integração por rota, recomendamos que você crie alarmes alternativos para ter um monitoramento mais refinado da latência de integração para cada rota.
**Estatística:** p90
**Limite recomendado: **2000.0
**Justificativa do limite:** o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência mais alta em geral, defina um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar os dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, usá-la para ajustar o valor limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**IntegrationLatency**
**Dimensões:** ApiId, estágio, rota
**Descrição do alarme:** esse alarme ajuda a detectar se há alta latência de integração para as solicitações da API de WebSocket para uma rota em um estágio. Você pode correlacionar o valor da métrica `IntegrationLatency` com a métrica de latência correspondente do seu backend, como a métrica `Duration` para integrações do Lambda. Isso ajuda a determinar se o backend da API está demorando mais para processar solicitações de clientes devido a problemas de performance ou se há alguma outra sobrecarga de inicialização ou inicialização a frio. Além disso, considere a possibilidade de ativar o CloudWatch Logs para sua API e verificar se há erros nos registros que possam estar causando os problemas de alta latência.
**Intenção:** esse alarme pode detectar quando as solicitações do API Gateway para uma rota em um estágio têm alta latência de integração.
**Estatística:** p90
**Limite recomendado: **2000.0
**Justificativa do limite:** o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar os dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, usá-la para ajustar o valor limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latência**
**Dimensões:** ApiName, estágio
**Descrição do alarme:** esse alarme detecta alta latência em um estágio. Encontre o valor da métrica `IntegrationLatency` para verificar a latência do backend da API. Se as duas métricas estiverem alinhadas em sua maior parte, o backend da API será a fonte de maior latência e você deve investigar se há problemas. Considere também ativar o CloudWatch Logs e verificar se há erros que possam estar causando a alta latência. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por recurso e método e restringir a origem da latência. Se aplicável, consulte os guias de [solução de problemas com o Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda) ou de [solução de problemas para endpoints de API otimizados para borda](https://repost.aws/knowledge-center/source-latency-requests-api-gateway).
**Intenção:** esse alarme pode detectar quando as solicitações do API Gateway em um estágio têm alta latência. Se você tiver as métricas detalhadas do CloudWatch ativadas e tiver diferentes requisitos de performance de latência para cada método e recurso, recomendamos que crie alarmes alternativos para ter um monitoramento mais detalhado da latência de cada recurso e método.
**Estatística:** p90
**Limite recomendado: **2500.0
**Justificativa do limite:** o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar qual é a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latência**
**Dimensões:** ApiName, estágio, recurso, método
**Descrição do alarme:** esse alarme detecta alta latência para um recurso e método em um estágio. Encontre o valor da métrica `IntegrationLatency` para verificar a latência do back-end da API. Se as duas métricas estiverem alinhadas, o backend da API será a fonte de maior latência e você deve investigar se há problemas de performance. Considere também ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando a alta latência. Você também pode consultar os guias de [solução de problemas com o Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda) ou de [solução de problemas para endpoints de API otimizados para borda](https://repost.aws/knowledge-center/source-latency-requests-api-gateway), se aplicável.
**Intenção:** esse alarme pode detectar quando as solicitações do API Gateway para um recurso e método em um estágio têm alta latência.
**Estatística:** p90
**Limite recomendado: **2500.0
**Justificativa do limite:** o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latência**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme detecta alta latência em um estágio. Encontre o valor da métrica `IntegrationLatency` para verificar a latência do back-end da API. Se as duas métricas estiverem alinhadas, o backend da API será a fonte de maior latência e você deve investigar se há problemas de performance. Considere também ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando a alta latência. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por rota e restringir a origem da latência. Você também pode consultar o guia de [solução de problemas com integrações do Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda), se aplicável.
**Intenção:** esse alarme pode detectar quando as solicitações do API Gateway em um estágio têm alta latência. Caso as métricas detalhadas do CloudWatch estejam ativadas e você tenha diferentes requisitos de performance de latência por rota, recomendamos que você crie alarmes alternativos para ter um monitoramento mais detalhado da latência de cada rota.
**Estatística:** p90
**Limite recomendado: **2500.0
**Justificativa do limite:** o valor limite sugerido não funciona para todas as workloads da API. No entanto, ele pode ser usado como ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e na latência aceitável, na performance e nos requisitos de SLA da API. Se for aceitável que a API tenha uma latência mais alta em geral, você poderá definir um valor limite mais alto para torná-la menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latência**
**Dimensões:** ApiId, estágio, recurso, método
**Descrição do alarme:** esse alarme detecta alta latência para uma rota em um estágio. Encontre o valor da métrica `IntegrationLatency` para verificar a latência do backend da API. Se as duas métricas estiverem mais alinhadas, o backend da API será a fonte de maior latência e deve-se investigar quanto a problemas de performance. Considere também ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando a alta latência. Você também pode consultar o guia de [solução de problemas com integrações do Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda), se aplicável.
**Intenção:** esse alarme é usado para detectar quando as solicitações do API Gateway para uma rota em um estágio têm alta latência.
**Estatística:** p90
**Limite recomendado: **2500.0
**Justificativa do limite:** o valor limite sugerido não funciona para todas as workloads da API. No entanto, ele pode ser usado como ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**4xx**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar um problema na autorização ou nos parâmetros da solicitação do cliente. Isso também pode significar que uma rota foi removida ou que um cliente está solicitando uma rota que não existe na API. Considere a possibilidade de ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando os erros 4xx. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por rota, o que ajudará você a restringir a origem dos erros. Os erros também podem ser causados por exceder o limite de controle de utilização configurado. Se as respostas e os logs estiverem relatando taxas altas e inesperadas de erros 429, siga [este guia](https://repost.aws/knowledge-center/api-gateway-429-limit) para solucionar esse problema.
**Intenção:** esse alarme pode detectar altas taxas de erros no lado do cliente para as solicitações do API Gateway.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 4xx. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 4xx que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**5xx**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar que há algo errado no backend da API, na rede ou na integração entre o gateway da API e a API de backend. Essa [documentação](https://repost.aws/knowledge-center/api-gateway-5xx-error) pode ajudar você a solucionar a causa dos erros 5xx.
**Intenção:** esse alarme pode detectar altas taxas de erros no lado do servidor para as solicitações do API Gateway.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 5xx. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar qual é a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 5xx que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**MessageCount**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme ajuda a detectar baixo volume de tráfego para o estágio da API de WebSocket. Isso pode indicar um problema quando os clientes chamam a API, como o uso de endpoints incorretos ou problemas com o backend que envia mensagens aos clientes. Isso também pode indicar um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.
**Intenção:** esse alarme pode detectar um volume de tráfego inesperadamente baixo para o estágio da API de WebSocket. Recomendamos que você crie esse alarme se a sua API receber e enviar um número previsível e consistente de mensagens em condições normais. Caso as métricas detalhadas do CloudWatch estejam ativadas e você possa prever o volume normal de tráfego por rota, é melhor criar alarmes alternativos a esse para ter um monitoramento mais refinado das quedas no volume de tráfego para cada rota. Não recomendamos esse alarme para APIs que não esperam tráfego constante e consistente.
**Estatística:** SampleCount
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o valor limite com base na análise de dados históricos para determinar qual é a contagem de mensagens de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de tráfego normal e baixo esperado. Por outro lado, a definição de um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**MessageCount**
**Dimensões:** ApiId, estágio, rota
**Descrição do alarme:** esse alarme ajuda a detectar um baixo volume de tráfego para a rota da API de WebSocket no estágio. Isso pode indicar um problema com os clientes que chamam a API, como o uso de endpoints incorretos, ou problemas com o backend que envia mensagens aos clientes. Isso também pode indicar um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.
**Intenção:** esse alarme pode detectar um volume de tráfego inesperadamente baixo para a rota da API de WebSocket no estágio. Recomendamos que você crie esse alarme se a sua API receber e enviar um número previsível e consistente de mensagens em condições normais. Não recomendamos esse alarme para APIs que não esperam tráfego constante e consistente.
**Estatística:** SampleCount
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite com base na análise de dados históricos para determinar qual é a contagem de mensagens de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de tráfego normal e baixo esperado. Por outro lado, a definição de um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**ClientError**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme detecta uma alta taxa de erros do cliente. Isso pode indicar um problema nos parâmetros de autorização ou de mensagem. Isso também pode significar que uma rota foi removida ou que um cliente está solicitando uma rota que não existe na API. Considere a possibilidade de ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando os erros 4xx. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por rota, o que ajudará você a restringir a origem dos erros. Os erros também podem ser causados por exceder o limite de controle de utilização configurado. Se as respostas e os logs estiverem relatando taxas altas e inesperadas de erros 429, siga [este guia](https://repost.aws/knowledge-center/api-gateway-429-limit) para solucionar esse problema.
**Intenção:** esse alarme pode detectar altas taxas de erros do cliente para as mensagens do API Gateway de WebSocket.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 4xx. Você pode ajustar o limite de acordo com o tráfego das solicitações e com as taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 4xx que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ExecutionError**
**Dimensões:** ApiId, estágio
**Descrição do alarme:** esse alarme ajuda a detectar uma alta taxa de erros de execução. Isso pode ser causado por erros 5xx de sua integração, problemas de permissão ou outros fatores que impedem a invocação bem-sucedida da integração, como o fato de a integração ter passado por um controle de utilização ou ter sido excluída. Considere ativar o CloudWatch Logs para sua API e verificar os registros quanto ao tipo e à causa dos erros. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para obter uma visão dessa métrica por rota, o que ajudará você a restringir a origem dos erros. Essa [documentação](https://repost.aws/knowledge-center/api-gateway-websocket-error) também pode ajudá-lo a solucionar a causa de qualquer erro de conexão.
**Intenção:** esse alarme pode detectar altas taxas de erros de execução para as mensagens da API Gateway de WebSocket.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros de execução. Você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como para se adequar às taxas de erro aceitáveis. Você pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros de execução que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon EC2 Auto Scaling
**GroupInServiceCapacity**
**Dimensões:** AutoScalingGroupName
**Descrição do alarme:** esse alarme ajuda a detectar quando a capacidade do grupo está abaixo da capacidade desejada para sua workload. Para solucionar problemas, verifique se há falhas de inicialização em suas atividades de escalonamento e confirme se a configuração da capacidade desejada está correta.
**Intenção:** esse alarme pode detectar uma baixa disponibilidade em seu grupo do Auto Scaling devido a falhas de inicialização ou inicializações suspensas.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite deve ser a capacidade mínima necessária para executar sua workload. Na maioria dos casos, é possível definir isso para corresponder à métrica GroupDesiredCapacity.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
## AWS Certificate Manager (ACM)
**DaysToExpiry**
**Dimensões: **CertificateARN
**Descrição do alarme:** este alarme ajuda a detectar quando um certificado gerenciado ou importado para o ACM está se aproximando da data de expiração. Isso ajuda a evitar expirações inesperadas de certificados que podem causar interrupções no serviço. Quando o alarme passar para o estado ALARME, você deve tomar medidas imediatas para renovar ou reimportar o certificado. Para certificados gerenciados pelo ACM, consulte as instruções no [processo de renovação do certificado](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html). Para certificados importados, consulte as instruções no [processo de reimportação](https://docs.aws.amazon.com/acm/latest/userguide/import-reimport.html).
**Intenção: **este alarme pode alertar proativamente sobre as expirações futuras de certificados. Ele fornece aviso prévio suficiente para permitir a intervenção manual, permitindo que você renove ou substitua os certificados antes que eles expirem. Isso ajuda você a manter a segurança e a disponibilidade dos serviços habilitados para TLS. Quando entrar em ALARME, investigue imediatamente o status do certificado e inicie o processo de renovação, se necessário.
**Estatística:** mínima
**Limite recomendado: **44.0
**Justificativa do limite: **o limite de 44 dias fornece um equilíbrio entre o aviso prévio e a prevenção de alarmes falsos. Isso permitirá tempo suficiente para uma intervenção manual se a renovação automática falhar. Ajuste esse valor com base no processo de renovação do certificado e nos tempos de resposta operacional.
**Período: **86400
**Pontos de dados para o alarme: **1
**Períodos de avaliação: **1
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon CloudFront
**5xxErrorRate**
**Dimensões:** DistributionID, Região=Global
**Descrição do alarme:** esse alarme monitora a porcentagem de respostas de erro 5xx do seu servidor de origem para ajudar você a detectar se o serviço CloudFront está com problemas. Consulte [Como solucionar problemas de respostas de erro da sua origem](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-response-errors.html) para obter informações que ajudem a entender os problemas com o servidor. Além disso, [ative as métricas adicionais](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html#monitoring-console.distributions-additional) para obter métricas de erro detalhadas.
**Intenção:** esse alarme é usado para detectar problemas com o atendimento de solicitações do servidor de origem ou problemas com a comunicação entre o CloudFront e seu servidor de origem.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme é altamente dependente da tolerância para respostas 5xx. Você pode analisar dados históricos e tendências e, em seguida, definir o limite adequadamente. Como os erros 5xx podem ser causados por problemas transitórios, recomendamos que você defina o limite como um valor maior que 0 para que o alarme não seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**OriginLatency**
**Dimensões:** DistributionID, Região=Global
**Descrição do alarme:** o alarme ajuda a monitorar se o servidor de origem está demorando muito para responder. Se o servidor demorar muito para responder, isso pode levar a um tempo limite. Consulte [Encontre e corrija respostas atrasadas de aplicações no seu servidor de origem](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-504-gateway-timeout.html#http-504-gateway-timeout-slow-application) se você tiver valores `OriginLatency` consistentemente altos.
**Intenção:** esse alarme é usado para detectar problemas com o servidor de origem que está demorando muito para responder.
**Estatística:** p90
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** você deve calcular o valor de cerca de 80% do tempo limite da resposta de origem e usar o resultado como valor limite. Se essa métrica estiver consistentemente próxima do valor de tempo limite da resposta de origem, é possível que você comece a receber erros 504.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**FunctionValidationErrors**
**Dimensões:** DistributionID, FunctionName, Região=Global
**Descrição do alarme:** esse alarme ajuda a monitorar os erros de validação do CloudFront Functions para que você possa tomar medidas para resolvê-los. Analise os logs do CloudWatch Functions e observe o código da função para encontrar e resolver a causa-raiz do problema. Consulte [Restrições nas funções de borda](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-restrictions.html) para entender as configurações incorretas comuns do CloudFront Functions.
**Intenção:** esse alarme é usado para detectar erros de validação do CloudFront Functions.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** um valor maior que 0 indica um erro de validação. Recomendamos definir o limite como 0, pois os erros de validação implicam um problema quando o CloudFront Functions é transferido de volta para o CloudFront. Por exemplo, o CloudFront precisa do cabeçalho HTTP Host para processar uma solicitação. Não há nada que impeça um usuário de excluir o cabeçalho Host em seu código do CloudFront Functions. Mas quando o CloudFront recebe a resposta de volta e o cabeçalho Host está ausente, o CloudFront gera um erro de validação.
**Período: **60
**Pontos de dados para o alarme: **2
**Períodos de avaliação: **2
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**FunctionExecutionErrors**
**Dimensões:** DistributionID, FunctionName, Região=Global
**Descrição do alarme:** esse alarme ajuda a monitorar os erros de execução do CloudFront Functions para que você possa tomar medidas para resolvê-los. Analise os logs do CloudWatch Functions e observe o código da função para encontrar e resolver a causa-raiz do problema.
**Intenção:** esse alarme é usado para detectar erros de execução do CloudFront Functions.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** recomendamos definir o limite como 0, pois um erro de execução indica um problema com o código que ocorre no runtime.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**FunctionThrottles**
**Dimensões:** DistributionID, FunctionName, Região=Global
**Descrição do alarme:** esse alarme ajuda você a monitorar se o CloudFront Functions está com controle de utilização. Caso sua função esteja com um controle de utilização, isso significa que ela está demorando muito para ser executada. Para evitar o controle de utilização de funções, considere otimizar o código da função.
**Intenção:** esse alarme pode detectar quando o CloudFront Functions está com um controle de utilização, de modo que você possa reagir e resolver o problema para proporcionar uma experiência tranquila ao cliente.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** recomendamos definir o limite como 0 para permitir uma resolução mais rápida dos controles de utilização da função.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon Cognito
**SignUpThrottles**
**Dimensões:** UserPool, UserPoolClient
**Descrição do alarme:** esse alarme monitora a contagem de solicitações com controle de utilização. Se os usuários estiverem constantemente com um controle de utilização, você deverá aumentar o limite solicitando um aumento da cota de serviços. Consulte [Cotas no Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) para saber como solicitar um aumento de cotas. Para tomar medidas proativas, considere monitorar a [cota de uso](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage).
**Intenção:** esse alarme ajuda a monitorar a ocorrência de solicitações de cadastro com controle de utilização. Isso pode ajudar você a saber quando tomar medidas para atenuar qualquer degradação na experiência de cadastro. O controle de utilização contínuo das solicitações é uma experiência negativa de cadastro do usuário.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** um grupo de usuários bem provisionado não deve encontrar nenhum controle de utilização que se estenda por vários pontos de dados. Portanto, um limite típico para uma workload esperada deve ser zero. Para uma workload irregular com picos frequentes, você pode analisar dados históricos para determinar o controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Uma solicitação de controle de utilização deve ser testada novamente para minimizar o impacto na aplicação.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**SignInThrottles**
**Dimensões:** UserPool, UserPoolClient
**Descrição do alarme:** esse alarme monitora a contagem de solicitações com controle de utilização de autenticação do usuário. Caso os usuários estejam constantemente passando por controle de utilização, talvez seja necessário aumentar o limite solicitando um aumento da cota de serviços. Consulte [Cotas no Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) para saber como solicitar um aumento de cotas. Para tomar medidas proativas, considere monitorar a [cota de uso](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage).
**Intenção:** esse alarme ajuda a monitorar a ocorrência de solicitações de login com controle de utilização. Isso pode ajudar você a saber quando tomar medidas para atenuar qualquer degradação na experiência de login. O controle de utilização contínuo das solicitações é uma experiência ruim de autenticação do usuário.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** um grupo de usuários bem provisionado não deve encontrar nenhum controle de utilização que se estenda por vários pontos de dados. Portanto, um limite típico para uma workload esperada deve ser zero. Para uma workload irregular com picos frequentes, você pode analisar dados históricos para determinar o controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Uma solicitação de controle de utilização deve ser testada novamente para minimizar o impacto na aplicação.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TokenRefreshThrottles**
**Dimensões:** UserPool, UserPoolClient
**Descrição do alarme:** você pode definir o valor do limite para se adequar ao tráfego da solicitação, bem como para corresponder ao controle de utilização aceitável para solicitações de atualização de token. O controle de utilização é usado para proteger seu sistema de muitas solicitações. No entanto, é importante monitorar se o provisionamento também é insuficiente para o seu tráfego normal. Você pode analisar dados históricos para encontrar o controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite de alarme para que ele seja maior do que o nível de controle de utilização aceitável. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo para o limite pode fazer com que o alarme seja sensível.
**Intenção:** esse alarme ajuda a monitorar a ocorrência de solicitações de atualização de token com controle de utilização. Isso pode ajudar você a saber quando tomar medidas para atenuar possíveis problemas, para garantir uma experiência de usuário tranquila e a integridade e confiabilidade do seu sistema de autenticação. O controle de utilização contínuo das solicitações é uma experiência ruim de autenticação do usuário.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite também pode ser definido/ajustado para se adequar ao tráfego da solicitação, bem como ao controle de utilização aceitável para solicitações de atualização de token. O controle de utilização existe para proteger seu sistema de muitas solicitações. No entanto, é importante monitorar se o provisionamento para o tráfego normal também está insuficiente e verificar se isso está causando o impacto. Os dados históricos também podem ser analisados para verificar qual é o controle de utilização aceitável para a workload da aplicação, e o limite pode ser ajustado para um nível mais alto do que o controle de utilização aceitável habitual. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo para o limite pode fazer com que o alarme seja sensível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**FederationThrottles**
**Dimensões:** UserPool, UserPoolClient, IdentityProvider
**Descrição do alarme:** esse alarme monitora a contagem de solicitações de federação de identidades com controle de utilização. Se você observar um controle de utilização constante, isso pode indicar que é necessário aumentar o limite solicitando um aumento da cota de serviços. Consulte [Cotas no Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) para saber como solicitar um aumento de cotas.
**Intenção:** esse alarme ajuda a monitorar a ocorrência de solicitações de federação de identidades com controle de utilização. Isso pode ajudar você a responder proativamente a gargalos de performance ou configurações incorretas e garantir uma experiência de autenticação tranquila para seus usuários. O controle de utilização contínuo das solicitações é uma experiência ruim de autenticação do usuário.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** você pode definir o limite para se adequar ao tráfego da solicitação, bem como para corresponder ao controle de utilização aceitável para solicitações de federação de identidades. O controle de utilização é usado para proteger seu sistema de um número excessivo de solicitações. No entanto, é importante monitorar se o provisionamento também é insuficiente para o seu tráfego normal. Você pode analisar os dados históricos para encontrar o controle de utilização aceitável para a workload da aplicação e, em seguida, definir o limite para um valor acima do nível de controle de utilização aceitável. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo para o limite pode fazer com que o alarme seja sensível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon DynamoDB
**AccountProvisionedReadCapacityUtilization**
**Dimensões:** nenhuma
**Descrição do alarme:** esse alarme detecta se a capacidade de leitura da conta está atingindo o limite provisionado. Se isso ocorrer, você poderá aumentar a cota da conta para utilização da capacidade de leitura. Você pode visualizar suas cotas atuais para unidades de capacidade de leitura e solicitar aumentos usando o [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**Intenção:** o alarme pode detectar se a utilização da capacidade de leitura da conta está se aproximando da utilização da capacidade de leitura provisionada. Se a utilização atingir seu limite máximo, o DynamoDB começará a realizar o controle de utilização nas solicitações de leitura.
**Estatística:** máxima
**Limite recomendado: **80.0
**Justificativa do limite:** defina o limite para 80%, de modo que uma medida (como aumentar os limites da conta) possa ser tomada antes de atingir a capacidade total para evitar o controle de utilização.
**Período: **300
**Pontos de dados para o alarme: **2
**Períodos de avaliação: **2
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**AccountProvisionedWriteCapacityUtilization**
**Dimensões:** nenhuma
**Descrição do alarme:** esse alarme detecta se a capacidade de gravação da conta está atingindo o limite provisionado. Se isso ocorrer, você poderá aumentar a cota da conta para utilização da capacidade de gravação. Você pode visualizar suas cotas atuais para unidades de capacidade de gravação e solicitar aumentos usando o [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**Intenção:** esse alarme pode detectar se a utilização da capacidade de gravação da conta está se aproximando da utilização da capacidade de gravação provisionada. Se a utilização atingir seu limite máximo, o DynamoDB começará a realizar o controle de utilização das solicitações de gravação.
**Estatística:** máxima
**Limite recomendado: **80.0
**Justificativa do limite:** defina o limite para 80%, para que a medida (como aumentar os limites da conta) possa ser tomada antes de atingir a capacidade total para evitar o controle de utilização.
**Período: **300
**Pontos de dados para o alarme: **2
**Períodos de avaliação: **2
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**AgeOfOldestUnreplicatedRecord**
**Dimensões:** TableName, DelegateDoperation
**Descrição do alarme:** esse alarme detecta o atraso na replicação para um fluxo de dados do Kinesis. Em operação normal, `AgeOfOldestUnreplicatedRecord` deve estar na ordem dos milissegundos. Esse número cresce com base em tentativas de replicação malsucedidas causadas por escolhas de configuração controladas pelo cliente. Exemplos de configurações controladas pelo cliente que levam a tentativas de replicação malsucedidas são uma capacidade de fluxo de dados do Kinesis com provisionamento insuficiente que leva a um controle de utilização excessivo ou uma atualização manual das políticas de acesso do fluxo de dados do Kinesis que impede o DynamoDB de adicionar dados ao fluxo de dados. Para manter essa métrica o mais baixa possível, você precisa garantir o provisionamento correto da capacidade do fluxo de dados do Kinesis e certificar-se de que as permissões do DynamoDB não foram alteradas.
**Intenção:** esse alarme pode monitorar tentativas de replicação malsucedidas e o atraso resultante na replicação para o fluxo de dados do Kinesis.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com o atraso de replicação desejado, medido em milissegundos. Esse valor depende dos requisitos de sua workload e da performance esperada.
**Período: **300
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**FailedToReplicateRecordCount**
**Dimensões:** TableName, DelegateDoperation
**Descrição do alarme:** esse alarme detecta o número de registros que o DynamoDB não conseguiu replicar para o fluxo de dados do Kinesis. Determinados itens com mais de 34 KB podem se expandir em tamanho para alterar registros de dados maiores que o limite de 1 MB para itens do Kinesis Data Streams. Essa expansão de tamanho ocorre quando os itens com mais de 34 KB contêm um grande número de valores de atributos booleanos ou vazios. Valores de atributos booleanos e vazios são armazenados como 1 byte no DynamoDB, mas expandem até 5 bytes quando são serializados usando JSON padrão para replicação do Kinesis Data Streams. O DynamoDB não consegue replicar esses registros de alteração para o fluxo de dados do Kinesis. O DynamoDB ignora esses registros de dados de alteração e continua automaticamente a replicar registros subsequentes.
**Intenção:** esse alarme pode monitorar o número de registros que o DynamoDB não conseguiu replicar para o seu fluxo de dados do Kinesis devido ao limite de tamanho de item dos fluxos de dados do Kinesis.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** defina o limite como 0 para detectar quaisquer registros que o DynamoDB não conseguiu replicar.
**Período: **60
**Pontos de dados para o alarme: **1
**Períodos de avaliação: **1
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**Dimensões:** TableName
**Descrição do alarme:** esse alarme detecta se há um grande número de solicitações de leitura passando por um controle de utilização para a tabela do DynamoDB. Para solucionar o problema, consulte [Solução de problemas de controle de utilização no Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
**Intenção:** esse alarme pode detectar o controle de utilização contínuo de solicitações de leitura na tabela do DynamoDB. O controle de utilização contínuo das solicitações de leitura pode afetar negativamente as operações de leitura de sua workload e reduzir a eficiência geral do sistema.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com o tráfego de leitura esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar o nível de controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite para que seja mais alto do que o nível de controle de utilização habitual. As solicitações com controle de utilização devem ser repetidas pela aplicação ou serviço, pois são transitórias. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**Dimensões:** TableName, GlobalSecondaryIndexName
**Descrição do alarme:** esse alarme detecta se há um grande número de solicitações de leitura sendo limitadas para o índice secundário global da tabela do DynamoDB. Para solucionar o problema, consulte [Solução de problemas de controle de utilização no Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
**Intenção:** o alarme pode detectar o controle de utilização contínuo de solicitações de leitura para o índice secundário global da tabela do DynamoDB. O controle de utilização contínuo das solicitações de leitura pode afetar negativamente as operações de leitura de sua workload e reduzir a eficiência geral do sistema.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com o tráfego de leitura esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar um nível de controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite para que seja mais alto do que o nível de controle de utilização aceitável habitual. As solicitações com controle de utilização devem ser repetidas pela aplicação ou serviço, pois são transitórias. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ReplicationLatency**
**Dimensões:** TableName, ReceivingRegion
**Descrição do alarme:** o alarme detecta se a réplica em uma região para a tabela global está atrasada em relação à região de origem. A latência poderá aumentar se uma região da AWS ficar degradada e você tiver uma tabela de réplica nessa região. Nesse caso, você pode redirecionar temporariamente as atividades de leitura e gravação da aplicação para outra região da AWS. Se você estiver usando 2017.11.29 (herdado) de tabelas globais, verifique se as unidades de capacidade de gravação (WCUs) são idênticas para cada uma das tabelas de réplica. Você também pode seguir as recomendações em [Práticas recomendadas e requisitos de gerenciamento de capacidade](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables_reqs_bestpractices.html#globaltables_reqs_bestpractices.tables).
**Intenção:** o alarme pode detectar se a tabela de réplica em uma região está ficando para trás na replicação das alterações de outra região. Isso pode fazer com que sua réplica se desvie das outras réplicas. É útil saber a latência de replicação de cada região da AWS e alertar se essa latência de replicação aumenta continuamente. A replicação da tabela se aplica somente a tabelas globais.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do seu caso de uso. Latências de replicação superiores a três minutos geralmente são motivo de investigação. Analise a importância e os requisitos do atraso de replicação e analise as tendências históricas. Em seguida, selecione o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**SuccessfulRequestLatency**
**Dimensões:** TableName, operação
**Descrição do alarme:** esse alarme detecta uma alta latência para a operação da tabela do DynamoDB (indicada pelo valor da dimensão da `Operation` no alarme). Consulte este [documento de solução de problemas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingLatency.html) para solucionar problemas de latência no Amazon DynamoDB.
**Intenção:** esse alarme pode detectar uma alta latência para a operação da tabela do DynamoDB. A latência mais alta para as operações pode afetar negativamente a eficiência geral do sistema.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o DynamoDB fornece latência de um dígito de milissegundos, em média, para as operações singleton, como GetItem, PutItem e assim por diante. No entanto, é possível definir o limite com base na tolerância aceitável para a latência do tipo de operação e da tabela envolvida na workload. Você pode analisar os dados históricos dessa métrica para descobrir a latência usual da operação da tabela e, em seguida, definir o limite para um número que represente o atraso crítico da operação.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**SystemErrors**
**Dimensões:** TableName
**Descrição do alarme:** esse alarme detecta um número alto e contínuo de erros de sistema para as solicitações de tabela do DynamoDB. Se você continuar recebendo erros 5xx, abra o [AWS Service Health Dashboard](https://status.aws.amazon.com/) para verificar se há problemas operacionais no serviço. Você pode usar esse alarme para receber notificações caso haja um problema prolongado de serviço interno do DynamoDB, e isso ajuda você a se correlacionar com o problema que a aplicação cliente está enfrentando. Consulte [Tratamento de erros com o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http5xx) para obter mais informações.
**Intenção:** esse alarme pode detectar erros de sistema contínuos para as solicitações de tabela do DynamoDB. Os erros do sistema indicam erros de serviço interno do DynamoDB e ajudam a correlacionar com o problema que o cliente está enfrentando.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com o tráfego esperado, levando em conta um nível aceitável de erros do sistema. Você também pode analisar dados históricos para encontrar a contagem de erros aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros do sistema devem ser testados novamente pela aplicação/serviço, pois são transitórios. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ThrottledPutRecordCount**
**Dimensões:** TableName, DelegateDoperation
**Descrição do alarme:** esse alarme detecta os registros que estão tendo controle de utilização pelo fluxo de dados do Kinesis durante a replicação da captura de dados de alteração para o Kinesis. Esse controle de utilização ocorre devido à capacidade insuficiente do fluxo de dados do Kinesis. Se você perceber controle de utilização excessivo e regular, talvez seja necessário aumentar o número de fragmentos de fluxos do Kinesis proporcionalmente ao throughput de gravação observada da tabela. Para saber mais sobre a determinação do tamanho de um fluxo de dados do Kinesis, consulte [Como determinar o tamanho inicial de um fluxo de dados do Kinesis](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-streams.html#how-do-i-size-a-stream).
**Intenção:** esse alarme pode monitorar o número de registros com controle de utilização pelo fluxo de dados do Kinesis devido à capacidade insuficiente do fluxo de dados do Kinesis.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** é possível que haja algum controle de utilização durante picos de uso excepcionais, mas os registros com controle de utilização devem permanecer o mais baixo possível para evitar maior latência de replicação (o DynamoDB tenta novamente enviar registros com controle de utilização para o fluxo de dados do Kinesis). Defina o limite para um número que possa ajudar você a detectar o controle de utilização excessivo regular. Você também pode analisar os dados históricos dessa métrica para encontrar as taxas de controle de utilização aceitáveis para a workload da aplicação. Ajuste o limite para um valor que a aplicação possa tolerar com base no seu caso de uso.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**UserErrors**
**Dimensões:** nenhuma
**Descrição do alarme:** esse alarme detecta um número alto e contínuo de erros de usuário para as solicitações da tabela do DynamoDB. Você pode verificar os logs da aplicação cliente durante o período do problema para ver por que as solicitações são inválidas. Você pode verificar o [código de status HTTP 400](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http400) para ver o tipo de erro que você está recebendo e tomar as medidas necessárias. Talvez seja necessário corrigir a lógica da aplicação para criar solicitações válidas.
**Intenção:** esse alarme pode detectar erros de usuário contínuos para as solicitações da tabela do DynamoDB. Os erros do usuário para operações solicitadas significam que o cliente está produzindo solicitações inválidas e está falhando.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite como zero para detectar quaisquer erros do lado do cliente. Ou você pode defini-lo com um valor mais alto se quiser evitar o acionamento do alarme para um número muito baixo de erros. Decida com base no seu caso de uso e no tráfego das solicitações.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**Dimensões:** TableName
**Descrição do alarme:** esse alarme detecta se há um grande número de solicitações de gravação passando por um controle de utilização para a tabela do DynamoDB. Consulte [Solução de problemas de controle de utilização no Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html) para solucionar o problema.
**Intenção:** esse alarme pode detectar o controle de utilização contínuo de solicitações de gravação na tabela do DynamoDB. O controle de utilização contínuo das solicitações de gravação pode afetar negativamente as operações de gravação de sua workload e reduzir a eficiência geral do sistema.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com o tráfego de gravação esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar o nível aceitável de controle de utilização para a workload da aplicação e, em seguida, ajustar o limite para um valor mais alto do que o nível aceitável de controle de utilização habitual. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**Dimensões:** TableName, GlobalSecondaryIndexName
**Descrição do alarme:** esse alarme detecta se há um grande número de solicitações de gravação sendo limitadas para o índice secundário global da tabela do DynamoDB. Consulte [Solução de problemas de controle de utilização no Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html) para solucionar o problema.
**Intenção:** esse alarme pode detectar o controle de utilização contínuo de solicitações de gravação para o índice secundário global da tabela do DynamoDB. O controle de utilização contínuo das solicitações de gravação pode afetar negativamente as operações de gravação de sua workload e reduzir a eficiência geral do sistema.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com o tráfego de gravação esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar o nível de controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite para um valor mais alto do que o nível de controle de utilização aceitável usual. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo pode fazer com que o alarme seja sensível demais, o que causa transições de estado indesejadas.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon EBS
**VolumeStalledIOCheck**
**Dimensões: **VolumeId, InstanceId
**Descrição do alarme:** este alarme ajuda você a monitorar o desempenho de E/S dos seus volumes do Amazon EBS. Essa verificação detecta problemas subjacentes com a infraestrutura do Amazon EBS, como problemas de hardware ou software nos subsistemas de armazenamento subjacentes aos volumes do Amazon EBS, problemas de hardware no host físico que afetam a acessibilidade dos volumes do Amazon EBS da sua instância do Amazon EC2 e pode detectar problemas de conectividade entre a instância e os volumes do Amazon EBS. Se a verificação Stalled IO falhar, você poderá esperar a AWS resolver o problema ou pode tomar medidas, como substituir os volumes afetados ou parar e reiniciar a instância à qual o volume está anexado. Na maioria dos casos, quando essa métrica falha, o Amazon EBS diagnostica e recupera automaticamente o volume em alguns minutos.
**Intenção:** este alarme pode detectar o status dos seus volumes do Amazon EBS para determinar quando esses volumes estão danificados e não conseguem concluir as operações de E/S.
**Estatística:** máxima
**Limite recomendado: **1.0
**Justificativa do limite:** quando uma verificação de status falha, o valor dessa métrica é 1. O limite é definido de modo que, sempre que a verificação de status falhar, o alarme estará no estado ALARME.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon EC2
**CPUUtilization**
**Dimensões:** InstanceId
**Descrição do alarme:** esse alarme ajuda a monitorar a utilização da CPU de uma instância do EC2. Dependendo da aplicação, níveis de utilização consistentemente altos podem ser normais. Porém, se a performance for prejudicada e a aplicação não for limitada por E/S de disco, memória ou recursos de rede, uma CPU no limite máximo poderá indicar um gargalo de recursos ou problemas de performance da aplicação. A alta utilização da CPU pode indicar que é necessário fazer um upgrade para uma instância que consome mais CPU. Se o monitoramento detalhado estiver ativado, você poderá alterar o período para 60 segundos em vez de 300 segundos. Para obter mais informações, consulte [Habilitar ou desabilitar o monitoramento detalhado para instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html).
**Intenção:** esse alarme é usado para detectar a alta utilização da CPU.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite:** normalmente, é possível definir o limite de utilização da CPU para 70% a 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload. Para alguns sistemas, a utilização consistentemente alta da CPU pode ser normal e não indicar um problema, enquanto para outros pode ser motivo de preocupação. Analise os dados históricos de utilização da CPU para identificar o uso, descubra qual utilização da CPU é aceitável para seu sistema e defina o limite adequadamente.
**Período: **300
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**StatusCheckFailed**
**Dimensões:** InstanceId
**Descrição do alarme:** esse alarme ajuda a monitorar as verificações de status do sistema e as verificações de status da instância. Se qualquer um dos tipos de verificação de status falhar, esse alarme deverá estar no estado ALARME.
**Intenção:** esse alarme é usado para detectar os problemas subjacentes com as instâncias, incluindo falhas na verificação do status do sistema e falhas na verificação do status da instância.
**Estatística:** máxima
**Limite recomendado: **1.0
**Justificativa do limite:** quando uma verificação de status falha, o valor dessa métrica é 1. O limite é definido de modo que, sempre que a verificação de status falhar, o alarme estará no estado ALARME.
**Período: **300
**Pontos de dados para o alarme: **2
**Períodos de avaliação: **2
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**StatusCheckFailed\$1AttachedEBS**
**Dimensões:** InstanceId
**Descrição do alarme:** esse alarme ajuda a monitorar se os volumes do Amazon EBS anexados a uma instância estão acessíveis e são capazes de concluir operações de E/S. Essa verificação de status detecta problemas subjacentes na infraestrutura do Amazon EBS ou com a computação, por exemplo:
+ Problemas de hardware ou software nos subsistemas de armazenamento subjacentes aos volumes do Amazon EBS
+ Problemas de hardware no host físico que afetam a acessibilidade dos volumes do Amazon EBS
+ Problemas de conectividade entre a instância e os volumes do Amazon EBS
Quando houver uma falha na verificação de status do EBS anexado, você poderá esperar que a Amazon resolva o problema ou adotar medidas por conta própria, p. ex., substituir os volumes afetados ou interromper e reiniciar a instância.
**Intenção:** esse alarme é usado para detectar volumes inacessíveis do Amazon EBS conectados a uma instância. Isso pode causar falhas nas operações de E/S.
**Estatística:** máxima
**Limite recomendado: **1.0
**Justificativa do limite:** quando uma verificação de status falha, o valor dessa métrica é 1. O limite é definido de modo que, sempre que a verificação de status falhar, o alarme estará no estado ALARME.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon ElastiCache
**CPUUtilization**
**Dimensões:** CacheClusterId, CacheNodeId
**Descrição do alarme:** esse alarme ajuda a monitorar a utilização da CPU de toda a instância do ElastiCache, incluindo os processos do mecanismo de banco de dados e outros processos em execução na instância. O AWS O Elasticache é compatível com dois tipos de mecanismo: Memcached e Redis OSS. Quando atingir uma alta utilização da CPU em um nó do Memcached, considere aumentar a escala verticalmente do tipo de instância ou adicionar novos nós de cache. Para o Redis OSS, se sua workload principal for de solicitações de leitura, você deverá considerar a adição de mais réplicas de leitura ao seu cluster de cache. Se a sua workload principal for de solicitações de gravação, considere adicionar mais fragmentos para distribuir a workload entre mais nós primários, caso esteja usando o modo em cluster, ou considere aumentar a escala verticalmente do seu tipo de instância, caso esteja executando o Redis OSS no modo sem cluster.
**Intenção:** esse alarme é usado para detectar a alta utilização da CPU dos hosts do ElastiCache. É útil obter uma visão ampla do uso da CPU em toda a instância, incluindo processos que não são do mecanismo.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite como a porcentagem que reflete um nível crítico de utilização da CPU para sua aplicação. Para o Memcached, o mecanismo pode usar até núcleos num\$1threads. Para o Redis OSS, o mecanismo é basicamente de thread único, mas pode usar núcleos adicionais, se houver disponibilidade, para acelerar a E/S. Na maioria dos casos, você pode definir o limite para cerca de 90% do seu nível de CPU disponível. Como o Redis OSS tem thread único, o valor efetivo do limite deve ser calculado como uma fração da capacidade total do nó.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**CurrConnections**
**Dimensões:** CacheClusterId, CacheNodeId
**Descrição do alarme:** esse alarme detecta uma alta contagem de conexões, o que pode indicar uma carga pesada ou problemas de performance. Um aumento constante de `CurrConnections` pode levar ao esgotamento das 65 mil conexões disponíveis. Isso pode indicar que as conexões foram fechadas incorretamente no lado da aplicação e permaneceram estabelecidas no lado do servidor. Considere o uso do pooling de conexões ou tempos limite de conexão ociosa para limitar o número de conexões feitas a esse cluster ou, no caso do Redis OSS, considere o ajuste do [tcp-keepalive](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html) em seu cluster para detectar e encerrar possíveis pares mortos.
**Intenção:** o alarme ajuda a identificar altas contagens de conexões que podem afetar a performance e a estabilidade do cluster do ElastiCache.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do intervalo aceitável de conexões para o seu cluster. Revise a capacidade e a workload esperada de seu cluster do ElastiCache e analise as contagens históricas de conexões durante o uso regular para estabelecer uma linha de base e, em seguida, selecione um limite adequadamente. Lembre-se de que cada nó comporta até 65 mil conexões simultâneas.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**DatabaseMemoryUsagePercentage**
**Dimensões: **CacheClusterId
**Descrição do alarme:** esse alarme ajuda você a monitorar a utilização da memória do seu cluster. Quando `DatabaseMemoryUsagePercentage` atinge 100%, a política de memória máxima do Redis OSS é acionada e podem ocorrer remoções com base na política selecionada. Se nenhum objeto no cache corresponder à política de remoção, as operações de gravação falharão. Algumas workloads esperam ou dependem de remoções, mas, se não for o caso, você precisará aumentar a capacidade de memória do seu cluster. Você pode escalar verticalmente seu cluster adicionando mais nós primários, ou aumentá-lo usando um tipo de nó maior. Consulte [Scaling ElastiCache for Redis OSS clusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html) para obter detalhes.
**Intenção:** esse alarme é usado para detectar a alta utilização de memória do seu cluster para que você possa evitar falhas ao gravar no cluster. É útil saber quando você precisará aumentar a escala verticalmente do seu cluster caso sua aplicação não espere passar por remoções.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** dependendo dos requisitos de memória da sua aplicação e da capacidade de memória do seu cluster do ElastiCache, você deve definir o limite para a porcentagem que reflete o nível crítico de uso de memória do cluster. Você pode usar dados históricos de uso de memória como referência para o limite aceitável de uso de memória.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**EngineCPUUtilization**
**Dimensões: **CacheClusterId
**Descrição do alarme:** esse alarme ajuda a monitorar a utilização da CPU de um thread do mecanismo Redis OSS na instância do ElastiCache. Os motivos comuns para o alto nível de CPU do mecanismo são comandos de longa execução que consomem muita CPU, um alto número de solicitações, um aumento de novas solicitações de conexão de cliente em um curto período de tempo e grandes remoções quando o cache não tem memória suficiente para armazenar novos dados. Você deve considerar promover a [escalabilidade de clusters do ElastiCache para Redis OSS](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html) adicionando mais nós ou aumentando a escala verticalmente do seu tipo de instância.
**Intenção:** esse alarme é usado para detectar a alta utilização da CPU do thread do mecanismo Redis OSS. Ele é útil caso deseje monitorar o uso da CPU do próprio mecanismo de banco de dados.
**Estatística:** média
**Limite recomendado: **90.0
**Justificativa do limite:** defina o limite como uma porcentagem que reflita o nível crítico de utilização da CPU do mecanismo para a sua aplicação. Você pode fazer um benchmark do seu cluster usando sua aplicação e a workload esperada para correlacionar a utilização do EngineCPUUtilization e a performance como referência e, em seguida, definir o limite adequadamente. Na maioria dos casos, você pode definir o limite para cerca de 90% da CPU disponível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ReplicationLag**
**Dimensões: **CacheClusterId
**Descrição do alarme:** esse alarme ajuda a monitorar a integridade da replicação do cluster do ElastiCache. Um alto atraso de replicação significa que o nó primário ou a réplica não consegue manter o ritmo da replicação. Se a atividade de gravação for muito alta, considere escalar o cluster adicionando mais nós primários ou ampliando-o usando um tipo de nó maior. Consulte [Scaling ElastiCache for Redis OSS clusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html) para obter detalhes. Se suas réplicas de leitura estiverem sobrecarregadas pela quantidade de solicitações de leitura, considere adicionar mais réplicas de leitura.
**Intenção:** esse alarme é usado para detectar um atraso entre as atualizações de dados no nó primário e sua sincronização com o nó de réplica. Ele ajuda a garantir a consistência dos dados de um nó de cluster de réplica de leitura.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com os requisitos de sua aplicação e o possível impacto do atraso da replicação. Você deve considerar as taxas de gravação esperadas da sua aplicação e as condições de rede para o atraso de replicação aceitável.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon ECS
Veja abaixo os alarmes recomendados do Amazon ECS.
**CPUReservation**
**Dimensões: **ClusterName
**Descrição do alarme:** esse alarme ajuda a detectar uma alta reserva de CPU no cluster do ECS. A alta reserva de CPU pode indicar que o cluster está ficando sem CPUs registradas para a tarefa. Para solucionar problemas, você pode adicionar mais capacidade, escalar o cluster ou configurar o ajuste de escala automático.
**Intenção:** o alarme é usado para detectar se o número total de unidades de CPU reservadas por tarefas no cluster está atingindo o total de unidades de CPU registradas para o cluster. Isso ajuda você a saber quando aumentar a escala do cluster verticalmente. Alcançar o total de unidades de CPU do cluster pode resultar na falta de CPU para tarefas. Se o escalonamento gerenciado dos provedores de capacidade do EC2 estiver ativado ou se você tiver associado o Fargate a provedores de capacidade, esse alarme não é recomendado.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite da reserva de CPU para 80%. Como alternativa, você pode escolher um valor mais baixo com base nas características do cluster.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**CPUUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme:** esse alarme ajuda você a detectar uma alta utilização da CPU do serviço do ECS. Se não houver nenhuma implantação de ECS em andamento, a utilização máxima da CPU poderá indicar um gargalo de recursos ou problemas de performance da aplicação. Para solucionar o problema, você pode aumentar o limite da CPU.
**Intenção: **este alarme é usado para detectar alta utilização da CPU no serviço do Amazon ECS. A alta utilização consistente da CPU pode indicar um gargalo de recursos ou problemas de performance da aplicação.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite:** as métricas de serviço para utilização da CPU podem exceder 100% de utilização. No entanto, recomendamos que você monitore a métrica quanto à alta utilização da CPU para evitar o impacto em outros serviços. Defina o limite para cerca de 80% a 85%. Recomendamos que você atualize suas definições de tarefas para refletir o uso real a fim de evitar problemas futuros com outros serviços.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**EBSFilesystemUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar a alta utilização do armazenamento do volume do Amazon EBS anexado às tarefas do Amazon ECS. Se a utilização do volume do Amazon EBS for consistentemente alta, você poderá verificar o uso e aumentar o tamanho do volume para novas tarefas.
**Descrição do alarme: **este alarme é usado para detectar a alta utilização do armazenamento dos volumes do Amazon EBS anexados às tarefas do Amazon ECS. A alta utilização de armazenamento de forma consistente pode indicar que o volume do Amazon EBS está cheio e pode resultar em falhas do contêiner.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **você pode definir o limite de utilização do sistema de arquivos do Amazon EBS para cerca de 80%. Você pode ajustar esse valor com base na utilização aceitável do armazenamento. Para um volume de snapshot somente para leitura, uma alta utilização pode indicar que o volume está no tamanho certo. Para um volume de dados ativo, a alta utilização do armazenamento pode indicar que a aplicaação está gravando uma grande quantidade de dados, o que pode fazer com que o contêiner falhe se não houver capacidade suficiente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**MemoryReservation**
**Dimensões: **ClusterName
**Descrição do alarme: **este alarme ajuda você a detectar uma reserva de memória alta no cluster do Amazon ECS. A alta reserva de memória pode indicar um gargalo de recursos para o cluster. Para solucionar problemas, analise a performance da tarefa de serviço para ver se a utilização da memória da tarefa pode ser otimizada. Além disso, é possível registrar mais memória ou configurar o ajuste de escala automático.
**Intenção:** o alarme é usado para detectar se o total de unidades de memória reservadas por tarefas no cluster está atingindo o total de unidades de memória registradas para o cluster. Isso pode ajudar você a saber quando aumentar a escala verticalmente do cluster. Atingir o total de unidades de memória do cluster pode fazer com que o cluster não consiga iniciar novas tarefas. Se você tiver o escalonamento gerenciado dos provedores de capacidade do EC2 ativado ou se tiver associado o Fargate a provedores de capacidade, esse alarme não é recomendado.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite da reserva de memória para 80%. Você pode ajustar isso para um valor mais baixo com base nas características do cluster.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**MemoryUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda você a detectar uma alta utilização do serviço do Amazon ECS. Se não houver nenhuma implantação do Amazon ECS em andamento, uma utilização máxima da memória poderá indicar um gargalo de recursos ou problemas de performance da aplicação. Para solucionar o problema, você pode aumentar o limite da memória.
**Intenção: **este alarme é usado para detectar alta utilização de memória no serviço do Amazon ECS. A alta utilização consistente de memória pode indicar um gargalo de recursos ou problemas de performance da aplicação.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **as métricas de serviço para a utilização da memória podem exceder 100% de utilização. No entanto, recomendamos que você monitore a métrica quanto à alta utilização de memória para evitar afetar outros serviços. Defina o limite para cerca de 80%. Recomendamos que você atualize suas definições de tarefas para refletir o uso real a fim de evitar problemas futuros com outros serviços.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**HTTPCode\$1Target\$15XX\$1Count**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme:** esse alarme ajuda você a detectar uma alta contagem de erros no lado do servidor para o serviço do ECS. Isso pode indicar que há erros que fazem com que o servidor não consiga atender às solicitações. Para solucionar o problema, verifique os logs da aplicação.
**Intenção:** esse alarme é usado para detectar uma alta contagem de erros no lado do servidor para o serviço do ECS.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** calcule o valor de cerca de 5% de seu tráfego médio e use esse valor como ponto de partida para o limite. Você pode encontrar o tráfego médio usando a métrica `RequestCount`. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 5XX que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TargetResponseTime**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme:** esse alarme ajuda você a detectar um tempo de resposta alvo alto para solicitações de serviço do ECS. Isso pode indicar que há problemas que fazem com que o serviço não consiga atender às solicitações a tempo. Para solucionar problemas, verifique a métrica CPUUtilization para verificar se o serviço está ficando sem CPU ou verifique a utilização da CPU de outros serviços downstream dos quais seu serviço depende.
**Intenção:** esse alarme é usado para detectar um tempo de resposta alvo alto para solicitações de serviço do ECS.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do seu caso de uso. Analise a criticidade e os requisitos do tempo alvo de resposta do serviço e analise o comportamento histórico dessa métrica para determinar níveis de limite adequados.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon ECS com o Container Insights
Veja abaixo os alarmes recomendados do Amazon ECS com o Container Insights.
**EphemeralStorageUtilized**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme:** este alarme ajuda a detectar a alta utilização do armazenamento temporário no cluster do Fargate. Se o uso do armazenamento temporário for consistentemente alto, você poderá verificá-lo e aumentá-lo.
**Intenção:** este alarme será usado para detectar a alta utilização do armazenamento temporário para o cluster do Fargate. A alta utilização de um armazenamento temporário de forma consistente pode indicar que o disco está cheio e pode resultar em falhas do contêiner.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite como cerca de 90% do tamanho do armazenamento temporário. É possível ajustar esse valor com base na utilização aceitável do armazenamento temporário do cluster do Fargate. Para alguns sistemas, a alta utilização de um armazenamento temporário de forma consistente pode ser normal, enquanto para outros, pode resultar em falhas do contêiner.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**RunningTaskCount**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar uma baixa contagem de tarefas em execução do serviço do Amazon ECS. Caso a contagem de tarefas em execução seja muito baixa, isso pode indicar que a aplicação não consegue lidar com a carga de serviço e pode resultar em problemas de performance. Caso não haja tarefas em execução, o serviço Amazon ECS pode estar indisponível ou pode haver problemas de implantação.
**Intenção:** este alarme é usado para detectar se o número de tarefas em execução está muito baixo. Uma baixa contagem de tarefas em execução de forma consistente pode indicar problemas de implantação ou de performance do serviço do Amazon ECS.
**Estatística:** média
**Limite recomendado: **0.0
**Justificativa do limite: **é possível ajustar o limite com base na contagem mínima de tarefas em execução do serviço do Amazon ECS. Se a contagem de tarefas em execução for 0, o serviço do Amazon ECS estará indisponível.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**TaskCpuUtilization**
**Dimensões: **ClusterName
**Descrição do alarme: **este alarme ajuda a detectar uma alta utilização de tarefas da CPU no cluster do Amazon ECS. Se a utilização de tarefas da CPU for consistentemente alta, talvez seja necessário otimizar as tarefas ou aumentar a reserva de CPU.
**Intenção: **este alarme é usado para detectar alta utilização da CPU para tarefas no serviço do Amazon ECS. A alta utilização consistente da CPU pode indicar que as tarefas estão sob estresse e podem precisar de mais otimização ou recursos da CPU para manter a performance.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva de CPU da tarefa. Você pode ajustar esse valor com base na utilização aceitável da CPU para as tarefas. Para algumas workloads, a alta utilização consistente da CPU pode ser normal, enquanto para outras, pode indicar problemas de performance ou a necessidade de mais recursos.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TaskCpuUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda você a detectar uma alta utilização da CPU das tarefas pertencentes ao serviço do Amazon ECS. Se a utilização de tarefas da CPU for consistentemente alta, talvez seja necessário otimizar as tarefas ou aumentar a reserva de CPU.
**Intenção: **este alarme é usado para detectar alta utilização da CPU para tarefas pertencentes ao serviço do Amazon ECS. A alta utilização consistente da CPU pode indicar que as tarefas estão sob estresse e podem precisar de mais otimização ou recursos da CPU para manter a performance.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva de CPU da tarefa. Você pode ajustar esse valor com base na utilização aceitável da CPU para as tarefas. Para algumas workloads, a alta utilização consistente da CPU pode ser normal, enquanto para outras, pode indicar problemas de performance ou a necessidade de mais recursos.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**Dimensões: **ClusterName
**Descrição do alarme: **este alarme monitora a porcentagem de unidades de CPU usadas pelos contêineres no cluster do Amazon ECS em relação à CPU reservada. Ele ajuda a detectar quando os contêineres estão se aproximando dos limites de CPU com base na taxa de ContainerCpuUtilized/ContainerCpuReserved.
**Intenção: **este alarme detecta quando os contêineres no cluster do Amazon ECS estão usando uma alta porcentagem da capacidade reservada de CPU, calculada como `ContainerCpuUtilized/ContainerCpuReserved`. Valores altos sustentados indicam que os contêineres estão operando perto dos limites da CPU e podem precisar de ajustes de capacidade.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da taxa de utilização da CPU do contêiner. Isso fornece um aviso antecipado quando os contêineres estão se aproximando dos limites de capacidade da CPU, ao mesmo tempo em que permite flutuações normais no uso da CPU. O limite pode ser ajustado com base nas características das workloads e nos requisitos de performance.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme monitora a porcentagem de unidades de CPU usadas por contêineres pertencentes ao serviço do Amazon ECS em relação à CPU reservada. Ele ajuda a detectar quando os contêineres estão se aproximando dos limites de CPU com base na taxa de ContainerCpuUtilized/ContainerCpuReserved.
**Intenção: **este alarme detecta quando os contêineres pertencentes ao serviço Amazon ECS estão usando uma alta porcentagem de sua capacidade de CPU reservada, calculada como ContainerCpuUtilized/ContainerCpuReserved. Valores altos sustentados indicam que os contêineres estão operando perto dos limites da CPU e podem precisar de ajustes de capacidade.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da taxa de utilização da CPU do contêiner. Isso fornece um aviso antecipado quando os contêineres estão se aproximando dos limites de capacidade da CPU, ao mesmo tempo em que permite flutuações normais no uso da CPU. O limite pode ser ajustado com base nas características das workloads e nos requisitos de performance.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**Dimensões: **ClusterName
**Descrição do alarme: **este alarme ajuda a detectar a alta utilização do armazenamento temporário no cluster do Amazon ECS. Se a utilização do armazenamento for consistentemente alta, talvez seja necessário otimizar o uso do armazenamento ou aumentar a reserva de armazenamento.
**Intenção: **este alarme é usado para detectar alta utilização de armazenamento temporário para tarefas no cluster do Amazon ECS. A alta utilização consistente do armazenamento pode indicar que a tarefa está ficando sem espaço em disco e pode precisar de mais recursos de armazenamento ou de uma otimização para manter a operação adequada.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva do armazenamento temporário da tarefa. Você pode ajustar esse valor com base na utilização aceitável do armazenamento para as tarefas. Para algumas workloads, a alta utilização do armazenamento de forma consistente pode ser normal, enquanto para outras, pode indicar possíveis problemas de espaço em disco ou a necessidade de mais armazenamento.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda você a detectar uma alta utilização de armazenamento temporário das tarefas pertencentes ao serviço do Amazon ECS. Se a utilização do armazenamento for consistentemente alta, talvez seja necessário otimizar o uso do armazenamento ou aumentar a reserva de armazenamento.
**Intenção: **este alarme é usado para detectar alta utilização de armazenamento temporário para tarefas pertencentes ao serviço do Amazon ECS. A alta utilização consistente do armazenamento pode indicar que a tarefa está ficando sem espaço em disco e pode precisar de mais recursos de armazenamento ou de uma otimização para manter a operação adequada.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva do armazenamento temporário da tarefa. Você pode ajustar esse valor com base na utilização aceitável do armazenamento para as tarefas. Para algumas workloads, a alta utilização do armazenamento de forma consistente pode ser normal, enquanto para outras, pode indicar possíveis problemas de espaço em disco ou a necessidade de mais armazenamento.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**Dimensões: **ClusterName
**Descrição do alarme: **este alarme ajuda a detectar uma alta utilização de memória das tarefas no cluster do Amazon ECS. Se a utilização da memória for consistentemente alta, talvez seja necessário otimizar suas tarefas ou aumentar a reserva de memória.
**Intenção: **este alarme é usado para detectar alta utilização de memória para tarefas no cluster do Amazon ECS. A alta utilização consistente da memória pode indicar que a tarefa está sob estresse e pode precisar de mais otimização ou recursos de memória para manter a estabilidade.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva de memória da tarefa. Você pode ajustar esse valor com base na utilização aceitável da memória para as tarefas. Para algumas workloads, a alta utilização de memória de forma consistente pode ser normal, enquanto para outras, pode indicar pressão de memória ou a necessidade de mais recursos.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda você a detectar uma alta utilização de memória das tarefas pertencentes ao serviço do Amazon ECS. Se a utilização da memória for consistentemente alta, talvez seja necessário otimizar suas tarefas ou aumentar a reserva de memória.
**Intenção: **este alarme é usado para detectar alta utilização de memória para tarefas pertencentes ao serviço do Amazon ECS. A alta utilização consistente da memória pode indicar que a tarefa está sob estresse e pode precisar de mais otimização ou recursos de memória para manter a estabilidade.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva de memória da tarefa. Você pode ajustar esse valor com base na utilização aceitável da memória para as tarefas. Para algumas workloads, a alta utilização de memória de forma consistente pode ser normal, enquanto para outras, pode indicar pressão de memória ou a necessidade de mais recursos.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**Dimensões: **ClusterName
**Descrição do alarme: **este alarme ajuda a detectar uma alta utilização de memória dos contêineres no cluster do Amazon ECS. Se a utilização da memória for consistentemente alta, talvez seja necessário otimizar os contêineres ou aumentar a reserva de memória.
**Intenção: **este alarme é usado para detectar alta utilização de memória para contêineres no cluster do Amazon ECS. A utilização consistentemente alta da memória pode indicar que o contêiner está sob pressão de memória e pode precisar de mais recursos de memória ou uma otimização para manter a estabilidade.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva de memória do contêiner. Você pode ajustar esse valor com base na utilização aceitável da memória para os contêineres. Para algumas workloads, a alta utilização de memória de forma consistente pode ser normal, enquanto para outras, pode indicar pressão de memória ou a necessidade de mais recursos.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda você a detectar uma alta utilização de memória dos contêineres pertencentes ao serviço do Amazon ECS. Se a utilização da memória for consistentemente alta, talvez seja necessário otimizar os contêineres ou aumentar a reserva de memória.
**Intenção: **este alarme é usado para detectar alta utilização de memória para contêineres pertencentes ao serviço do Amazon ECS. A utilização consistentemente alta da memória pode indicar que o contêiner está sob pressão de memória e pode precisar de mais recursos de memória ou uma otimização para manter a estabilidade.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% da reserva de memória do contêiner. Você pode ajustar esse valor com base na utilização aceitável da memória para os contêineres. Para algumas workloads, a alta utilização de memória de forma consistente pode ser normal, enquanto para outras, pode indicar pressão de memória ou a necessidade de mais recursos.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**instance\$1filesystem\$1utilization**
**Dimensões:** InstanceId, ContainerInstanceId e ClusterName
**Descrição do alarme:** este alarme ajuda a detectar uma alta utilização do sistema de arquivos do cluster do Amazon ECS. Se a utilização do sistema de arquivos for consistentemente alta, verifique o uso do disco.
**Intenção:** este alarme é usado para detectar uma alta utilização do sistema de arquivos para o cluster do Amazon ECS. Uma alta utilização do sistema de arquivos de forma consistente pode indicar um gargalo de recursos ou problemas de performance da aplicação e pode impedir a execução de novas tarefas.
**Estatística:** média
**Limite recomendado: **90.0
**Justificativa do limite:** é possível definir o limite de utilização do sistema de arquivos para cerca de 90 a 95%. Você pode ajustar esse valor com base no nível aceitável de capacidade para o sistema de arquivos do cluster do Amazon ECS. Para alguns sistemas, uma alta utilização do sistema de arquivos de forma consistente pode ser normal e não indicar problemas, enquanto que para outros, pode ser um motivo de preocupação e pode resultar em problemas de performance e impedir a execução de novas tarefas.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon ECS com o Container Insights com observabilidade aprimorada
Veja abaixo os alarmes recomendados do Amazon ECS com o Container Insights com observabilidade aprimorada.
**TaskCpuUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar a porcentagem total de unidades de CPU usadas por uma tarefa.
**Intenção: **este alarme é usado para detectar a alta utilização da CPU.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **normalmente, você pode definir o limite de utilização da CPU para 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload. Para algumas tarefas, a utilização consistentemente alta da CPU pode ser normal e não indicar um problema, enquanto para outros pode ser motivo de preocupação. Analise os dados históricos de utilização da CPU para identificar o uso, descubra qual utilização da CPU é aceitável para as tarefas e defina o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar a porcentagem total de memória usada por uma tarefa.
**Intenção: **este alarme é usado para detectar a alta utilização da memória.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **normalmente, você pode definir o limite de utilização de memória para 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload. Para algumas tarefas, a utilização consistentemente alta de memória pode ser normal e não indicar um problema, enquanto para outros pode ser motivo de preocupação. Analise os dados históricos de utilização de memória para identificar o uso, descubra qual utilização de memória é aceitável para as tarefas e defina o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ContainerCPUUtilization**
**Dimensões: **ContainerName, ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar a porcentagem total de unidades de CPU usadas por um contêiner.
**Intenção: **este alarme é usado para detectar a alta utilização da CPU.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **normalmente, você pode definir o limite de utilização da CPU para 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload. Para alguns contêineres, a utilização consistentemente alta da CPU pode ser normal e não indicar um problema, enquanto para outros pode ser motivo de preocupação. Analise os dados históricos de utilização da CPU para identificar o uso, descubra qual utilização da CPU é aceitável para os contêineres e defina o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**Dimensões: **ContainerName, ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar a porcentagem total de unidades de memória usadas por um contêiner.
**Intenção:** esse alarme é usado para detectar a utilização elevada da memória por uma tarefa.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **normalmente, você pode definir o limite de utilização de memória para 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload. Para alguns sistemas, a utilização consistentemente alta de memória pode ser normal e não indicar um problema, enquanto para outros pode ser motivo de preocupação. Analise os dados históricos de utilização de memória para identificar o uso, descubra qual utilização de memória é aceitável para as tarefas e defina o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**TaskEBSfilesystemUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar a porcentagem total de armazenamento temporário usado por uma tarefa.
**Intenção:** este alarme é usado para detectar uma alta utilização do sistema de arquivos do Amazon EBS para uma tarefa.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite para cerca de 80% do tamanho do sistema de arquivos do Amazon EBS.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**Dimensões:** ClusterName, ServiceName
**Descrição do alarme: **este alarme ajuda a detectar a porcentagem total de armazenamento temporário usado por uma tarefa.
**Intenção: **este alarme será usado para detectar a alta utilização do armazenamento temporário de uma tarefa. A alta utilização de um armazenamento temporário de forma consistente pode indicar que o disco está cheio e pode resultar em falhas da tarefa.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **defina o limite como cerca de 80% do tamanho do armazenamento temporário.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon EFS
**PercentIOLimit**
**Dimensões:** FileSystemID
**Descrição do alarme:** esse alarme ajuda a garantir que a workload permaneça dentro do limite de E/S disponível para o sistema de arquivos. Se a métrica atingir o limite de E/S de forma consistente, considere transferir a aplicação para um sistema de arquivos que use a performance máxima de E/S como modo. Para solucionar o problema, verifique os clientes que estão conectados ao sistema de arquivos e as aplicações dos clientes que controlam a utilização do sistema de arquivos.
**Intenção:** esse alarme é usado para detectar o quanto o sistema de arquivos está próximo de atingir o limite de E/S do modo de performance de uso geral. Uma porcentagem consistentemente alta de E/S pode ser um indicador de que o sistema de arquivos não pode ser escalonado com relação a solicitações de E/S suficientes, e o sistema de arquivos pode ser um gargalo de recursos para as aplicações que usam o sistema de arquivos.
**Estatística:** média
**Limite recomendado: **100.0
**Justificativa do limite:** quando o sistema de arquivos atinge seu limite de E/S, ele pode responder mais lentamente às solicitações de leitura e gravação. Portanto, é recomendável que a métrica seja monitorada para evitar o impacto nas aplicações que usam o sistema de arquivos. O limite pode ser definido em torno de 100%. No entanto, esse valor pode ser ajustado para um valor menor com base nas características do sistema de arquivos.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BurstCreditBalance**
**Dimensões:** FileSystemID
**Descrição do alarme:** esse alarme ajuda a garantir que haja um saldo de crédito de estouro disponível para o uso do sistema de arquivos. Quando não houver crédito de burst disponível, o acesso das aplicações ao sistema de arquivos será limitado devido ao baixo throughput. Se a métrica cair para 0 de forma consistente, considere alterar o modo de throughput para o [modo de throughput Elástico ou Provisionado](https://docs.aws.amazon.com/efs/latest/ug/performance.html#throughput-modes).
**Intenção:** esse alarme é usado para detectar o baixo saldo de crédito de burst do sistema de arquivos. Um saldo de crédito de burst baixo e consistente pode ser um indicador da diminuição do throughput e do aumento da latência de E/S.
**Estatística:** média
**Limite recomendado: **0.0
**Justificativa do limite:** quando o sistema de arquivos fica sem créditos de burst e mesmo que o throughput de linha de base seja menor, o EFS continua a fornecer um throughput medido de 1 MiBps para todos os sistemas de arquivos. No entanto, recomenda-se que a métrica seja monitorada quanto ao baixo saldo de crédito de burst para evitar que o sistema de arquivos atue como gargalo de recursos para as aplicações. O limite pode ser definido em torno de 0 bytes.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon EKS com o Container Insights
**node\$1cpu\$1utilization**
**Dimensões: **ClusterName
**Descrição do alarme:** esse alarme ajuda a detectar a alta utilização da CPU nos nós de processamento do cluster do EKS. Se a utilização for consistentemente alta, isso pode indicar a necessidade de substituir os nós de processamento por instâncias que tenham mais CPU ou a necessidade de escalar o sistema horizontalmente.
**Intenção:** esse alarme ajuda a monitorar a utilização da CPU dos nós de processamento no cluster do EKS para que a performance do sistema não diminua.
**Estatística:** máxima
**Limite recomendado: **80.0
**Justificativa do limite:** recomenda-se definir o limite como menor ou igual a 80% para permitir tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**node\$1filesystem\$1utilization**
**Dimensões: **ClusterName
**Descrição do alarme:** esse alarme ajuda a detectar a alta utilização do sistema de arquivos nos nós de processamento do cluster do EKS. Se a utilização for consistentemente alta, talvez seja necessário atualizar os nós de processamento para que tenham um volume de disco maior, ou talvez seja necessário escalar horizontalmente.
**Descrição do alarme:** esse alarme ajuda a monitorar a utilização do sistema de arquivos dos nós de processamento no cluster do EKS. Se a utilização atingir 100%, isso pode levar à falha da aplicação, a gargalos de E/S do disco, à remoção de pods ou ao fato de o nó deixar de responder completamente.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** se houver pressão suficiente no disco (o que significa que o disco está ficando cheio), os nós serão marcados como não íntegros e os pods serão removidos do nó. Os pods em um nó com pressão de disco são removidos quando o sistema de arquivos disponível é menor do que os limites de remoção definidos no kubelet. Defina o limite do alarme para que você tenha tempo suficiente para reagir antes que o nó seja removido do cluster.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**node\$1memory\$1utilization**
**Dimensões: **ClusterName
**Descrição do alarme:** esse alarme ajuda a detectar a alta utilização de memória nos nós de processamento do cluster do EKS. Se a utilização for consistentemente alta, isso pode indicar a necessidade de escalar o número de réplicas de pod ou otimizar a sua aplicação.
**Intenção:** esse alarme ajuda a monitorar a utilização da memória dos nós de processamento no cluster do EKS para que a performance do sistema não diminua.
**Estatística:** máxima
**Limite recomendado: **80.0
**Justificativa do limite:** recomenda-se definir o limite como menor ou igual a 80% para permitir que se tenha tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**pod\$1cpu\$1utilization\$1over\$1pod\$1limit**
**Dimensões:** ClusterName, Namespace, serviço
**Descrição do alarme:** esse alarme ajuda a detectar a alta utilização da CPU em pods do cluster do EKS. Se a utilização for consistentemente alta, isso poderá indicar a necessidade de aumentar o limite da CPU para o pod afetado.
**Intenção:** esse alarme ajuda a monitorar a utilização da CPU dos pods pertencentes a um Serviço do Kubernetes no cluster do EKS para que você possa identificar rapidamente se o pod de um serviço está consumindo mais CPU do que o esperado.
**Estatística:** máxima
**Limite recomendado: **80.0
**Justificativa do limite:** recomenda-se definir o limite como menor ou igual a 80% para permitir que se tenha tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**pod\$1memory\$1utilization\$1over\$1pod\$1limit**
**Dimensões:** ClusterName, Namespace, serviço
**Descrição do alarme:** esse alarme ajuda a detectar a alta utilização de memória em pods do cluster do EKS. Se a utilização for consistentemente alta, isso poderá indicar a necessidade de aumentar o limite de memória para o pod afetado.
**Intenção:** esse alarme ajuda a monitorar a utilização da memória dos pods no cluster do EKS para que a performance do sistema não diminua.
**Estatística:** máxima
**Limite recomendado: **80.0
**Justificativa do limite:** recomenda-se definir o limite como menor ou igual a 80% para permitir que se tenha tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Agendador do Amazon EventBridge
**TargetErrorThrottledCount**
**Dimensões:** nenhuma
**Descrição do alarme: **este alarme ajuda a identificar o controle de utilização do destino. Para evitar erros de controle de utilização de destino, considere [configurar janelas de tempo flexíveis](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html) para distribuir sua carga de invocações ou aumentar os limites com o serviço de destino.
**Intenção: **este alarme é usado para detectar erros de controle de utilização do destino, que podem causar atrasos na programação.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do controle de utilização: **se o erro de controle de utilização do destino for consistentemente maior que 0, a entrega programada será atrasada. Para alguns sistemas, erros de controle de utilização do destino por um breve período de tempo pode ser normal, enquanto para outros, pode ser um motivo de preocupação. Defina `datapointsToAlarm`, `evaluationPeriods` e o limite desse alarme adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**InvocationThrottleCount**
**Dimensões:** nenhuma
**Descrição do alarme: **este alarme ajuda a identificar o controle de utilização de invocações pelo Agendador do Amazon EventBridge. Para evitar erros de controle de utilização de invocações, considere [configurar janelas de tempo flexíveis](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html) para distribuir sua carga de invocações ou [aumentar o limite controle de utilização de invocações](https://docs.aws.amazon.com/scheduler/latest/UserGuide/scheduler-quotas.html).
**Intenção: **este alarme é usado para detectar erros de controle de utilização de invocações do Agendador do Amazon EventBridge, que podem causar atrasos na programação.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite: **se o controle de utilização de invocações for consistentemente maior que 0, a entrega programada será atrasada. Para alguns sistemas, erros de controle de utilização de invocações por um breve período de tempo pode ser normal, enquanto para outros, pode ser um motivo de preocupação. Defina `datapointsToAlarm`, `evaluationPeriods` e o limite desse alarme adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**InvocationDroppedCount**
**Dimensões:** nenhuma
**Descrição do alarme: **este alarme ajuda a identificar as invocações descartadas pelo Agendador do Amazon EventBridge. Considere investigar [configurando uma DLQ](https://docs.aws.amazon.com/scheduler/latest/UserGuide/configuring-schedule-dlq.html) para a programação.
**Intenção: **este alarme é usado para detectar invocações descartadas pelo Agendador do Amazon EventBridge. Se você configurou uma DLQ corretamente em todas as suas programações, as invocações descartadas aparecerão na DLQ e você poderá pular a configuração desse alarme.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite: **defina o limite como 0 para detectar invocações descartadas.
**Período: **60
**Pontos de dados para o alarme: **1
**Períodos de avaliação: **1
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**InvocationsFailedToBeSentToDeadLetterCount**
**Dimensões:** nenhuma
**Descrição do alarme: **este alarme ajuda a identificar invocações que não foram enviadas à DLQ configurada pelo Agendador do Amazon EventBridge. Se a métrica for consistentemente maior que 0, modifique sua configuração de DLQ para resolver o problema. Use `InvocationsFailedToBeSentToDeadLetterCount`\$1metrics para determinar o problema.
**Intenção: **este alarme é usado para detectar invocações que não foram enviadas à DLQ configurada pelo Agendador do Amazon EventBridge.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite: **defina o limite como 0 para detectar quaisquer invocações que não foram enviadas para a DLQ configurada. Erros repetíveis também aparecem nessa métrica, portanto `datapointsToAlarm` para esse alarme foi definido como 15.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon Kinesis Data Streams
**GetRecords.IteratorAgeMilliseconds**
**Dimensões:** StreamName
**Descrição do alarme:** esse alarme pode detectar se a idade máxima do iterador é muito alta. Para aplicações de processamento de dados em tempo real, configure a retenção de dados de acordo com a tolerância do atraso. Isso geralmente ocorre em minutos. Para aplicações que processam dados históricos, use essa métrica para monitorar a velocidade de recuperação. Uma solução rápida para impedir a perda de dados é aumentar o período de retenção enquanto você soluciona o problema. Também é possível aumentar o número de trabalhadores que processam registros em sua aplicação do consumidor. As causas mais comuns para o aumento gradual da idade do iterador são recursos físicos insuficientes ou lógica de processamento de registros que não foi escalonada com um aumento no throughput do fluxo. Consulte o [link](https://repost.aws/knowledge-center/kinesis-data-streams-iteratorage-metric) para obter mais detalhes.
**Intenção:** esse alarme é usado para detectar se os dados no seu fluxo vão expirar por terem sido preservados por muito tempo ou porque o processamento de registros está muito lento. Ele ajuda a evitar a perda de dados após atingir 100% do tempo de retenção do fluxo.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do período de retenção do fluxo e da tolerância de atraso no processamento dos registros. Revise seus requisitos e analise as tendências históricas e, em seguida, defina o limite para o número de milissegundos que representa um atraso crítico no processamento. Se a idade de um iterador ultrapassar 50% do período de retenção (por padrão, 24 horas, configurável até 365 dias), haverá um risco de perda de dados devido à expiração do registro. Você pode monitorar a métrica para garantir que nenhum dos seus fragmentos se aproxime desse limite.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**GetRecords.Success**
**Dimensões:** StreamName
**Descrição do alarme:** essa métrica é incrementada sempre que os consumidores leem com êxito os dados do fluxo. O `GetRecords` não retorna nenhum dado quando lança uma exceção. A exceção mais comum é `ProvisionedThroughputExceededException`, pois a taxa de solicitação do fluxo é muito alta ou porque o throughput disponível já foi atendido para o segundo em questão. Reduzir a frequência ou o tamanho de suas solicitações. Para obter mais informações, consulte [Limites](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) de fluxos no Guia do desenvolvedor do Amazon Kinesis Data Streams e [Repetições de erro e recuo exponencial na AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html).
**Intenção:** esse alarme pode detectar se a recuperação de registros do fluxo pelos consumidores está falhando. Ao definir um alarme para essa métrica, você pode detectar proativamente qualquer problema com o consumo de dados, como o aumento das taxas de erro ou a diminuição das recuperações bem-sucedidas. Isso permite que você tome medidas oportunas para resolver possíveis problemas e mantenha um pipeline de processamento de dados regular.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** dependendo da importância da recuperação de registros do fluxo, defina o limite com base na tolerância da sua aplicação para registros com falha. O limite deve ser a porcentagem correspondente de operações bem-sucedidas. Você pode usar dados históricos da métrica GetRecords como referência para a taxa de falha aceitável. Também é preciso considerar as novas tentativas ao definir o limite, pois os registros com falha podem ser tentados novamente. Isso ajuda a evitar que picos transitórios acionem alertas desnecessários.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**PutRecord.Success**
**Dimensões:** StreamName
**Descrição do alarme:** esse alarme detecta quando o número de operações de `PutRecord` com falha ultrapassa o limite. Investigue os logs do produtor de dados para encontrar as causas principais das falhas. O motivo mais comum é o throughput provisionado insuficiente no fragmento que causou o `ProvisionedThroughputExceededException`. Isso acontece porque a taxa de solicitação do fluxo é muito alta ou o throughput tentado para ser ingerido no fragmento é muito alto. Reduzir a frequência ou o tamanho de suas solicitações. Para obter mais informações, consulte [Limites](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) de fluxos e [Repetições de erro e recuo exponencial na AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html).
**Intenção:** esse alarme pode detectar se a ingestão de registros no fluxo está falhando. Ele ajuda a identificar problemas na gravação de dados no fluxo. Ao definir um alarme para essa métrica, é possível detectar proativamente quaisquer problemas de produtores na publicação de dados no fluxo, como aumento das taxas de erro ou diminuição dos registros publicados com êxito. Isso permite que você tome medidas oportunas para resolver possíveis problemas e mantenha um processo de ingestão de dados confiável.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** dependendo da importância da ingestão de dados e do processamento para o seu serviço, defina o limite com base na tolerância da sua aplicação para registros com falha. O limite deve ser a porcentagem correspondente de operações bem-sucedidas. É possível usar dados históricos da métrica PutRecord como referência para a taxa de falha aceitável. Também é preciso considerar as novas tentativas ao definir o limite, pois os registros com falha podem ser tentados novamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**PutRecords.FailedRecords**
**Dimensões:** StreamName
**Descrição do alarme:** esse alarme detecta quando o número de operações `PutRecords` com falha excede o limite. O fluxo de dados do Kinesis tenta processar todos os registros em cada solicitação `PutRecords`, mas uma única falha de registro não interrompe o processamento dos registros subsequentes. O principal motivo dessas falhas é exceder o throughput de um fluxo ou de um fragmento individual. As causas comuns são picos de tráfego e latências de rede que fazem com que os registros cheguem ao fluxo de forma desigual. Você deve detectar registros processados sem sucesso e tentar novamente em uma chamada subsequente. Consulte [Tratamento de falhas ao usar PutRecords](https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-sdk.html) para obter mais detalhes.
**Intenção:** esse alarme pode detectar falhas consistentes ao usar a operação em lote para colocar registros no seu fluxo. Ao definir um alarme para essa métrica, é possível detectar proativamente um aumento no número de registros com falha, o que permite tomar medidas oportunas para resolver os problemas subjacentes e garantir um processo de ingestão de dados regular e confiável.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite para o número de registros com falha que reflete a tolerância da aplicação para registros com falha. Você pode usar dados históricos como referência para o valor de falha aceitável. Também é preciso considerar as novas tentativas ao definir o limite, pois os registros com falha podem ser tentados novamente em chamadas PutRecords subsequentes.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ReadProvisionedThroughputExceeded**
**Dimensões:** StreamName
**Descrição do alarme:** o alarme rastreia o número de registros que resultam no controle de utilização da capacidade de throughput de leitura. Se você perceber que o controle de utilização está sendo constante, considere adicionar mais fragmentos ao seu fluxo para aumentar o throughput de leitura provisionado. Se houver mais de uma aplicação de consumo em execução no fluxo e elas compartilharem o limite do `GetRecords`, recomendamos que você registre novas aplicações de consumo via distribuição aprimorada. Se a adição de mais fragmentos não reduzir o número de controles de utilização, é possível que haja um fragmento "quente" que esteja sendo lido mais do que os outros fragmentos. Ative a distribuição aprimorada, localize o fragmento "quente" e divida-o.
**Intenção:** esse alarme pode detectar se os consumidores passam por um controle de utilização quando excedem o throughput de leitura provisionado (determinado pelo número de fragmentos que você tem). Nesse caso, não será possível fazer a leitura do fluxo, e o fluxo pode começar a fazer o backup.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** normalmente, as solicitações com controle de utilização podem ser repetidas e, portanto, definir o limite como zero torna o alarme muito sensível. No entanto, o controle de utilização consistente pode afetar a leitura do fluxo e deve acionar o alarme. Defina o limite como uma porcentagem de acordo com as solicitações com controle de utilização para as configurações da aplicação e de repetição.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**SubscribeToShardEvent.MillisBehindLatest**
**Dimensões:** StreamName, ConsumerName
**Descrição do alarme:** esse alarme detecta quando o atraso do processamento de registros na aplicação ultrapassa o limite. Problemas transitórios, como falhas na operação da API em uma aplicação downstream, podem causar um aumento repentino na métrica. É necessário investigar se isso ocorre de forma consistente. Uma causa comum é que o consumidor não está processando registros com rapidez suficiente devido a recursos físicos insuficientes ou à lógica de processamento de registros que não foi escalonada com um aumento no throughput do fluxo. O bloqueio de chamadas no caminho crítico geralmente é a causa de lentidão no processamento de registros. Você pode aumentar o paralelismo aumentando o número de fragmentos. Você também deve confirmar se os nós de processamento subjacentes têm recursos físicos suficientes durante o pico de demanda.
**Intenção:** esse alarme pode detectar atraso na assinatura do evento de fragmento do fluxo. Isso indica um atraso no processamento e pode ajudar a identificar possíveis problemas com a performance da aplicação do consumidor ou com a integridade geral do fluxo. Quando o atraso no processamento torna-se significativo, você deve investigar e resolver quaisquer gargalos ou ineficiências das aplicações do consumidor para garantir o processamento de dados em tempo real e minimizar o acúmulo de dados.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do atraso que sua aplicação pode tolerar. Analise os requisitos da sua aplicação e analise as tendências históricas e, em seguida, selecione um limite adequadamente. Quando a chamada SubscribeToShard for bem-sucedida, o consumidor começará a receber eventos SubscribeToShardEvent pela conexão persistente por até cinco minutos, após os quais será necessário chamar o SubscribeToShard novamente para renovar a assinatura se quiser continuar a receber registros.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**WriteProvisionedThroughputExceeded**
**Dimensões:** StreamName
**Descrição do alarme:** esse alarme detecta quando o número de registros que resultam no controle de utilização da capacidade de throughput de gravação atingiu o limite. Quando seus produtores excedem o throughput de gravação provisionado (determinado pelo número de fragmentos que você tem), eles passam por um controle de utilização e você não poderá colocar registros no fluxo. Para resolver o controle de utilização consistente, você deve considerar a adição de fragmentos ao seu fluxo. Isso aumenta seu throughput de gravação provisionado e evita o controle de utilização no futuro. Você também deve considerar a escolha da chave de partição ao ingerir registros. A chave de partição aleatória é preferível porque distribui os registros uniformemente entre os fragmentos do fluxo, sempre que possível.
**Intenção:** esse alarme pode detectar se os seus produtores estão sendo rejeitados para gravar registros devido ao controle de utilização do fluxo ou do fragmento. Se o seu fluxo estiver no modo Provisionado, a configuração desse alarme ajudará você a tomar medidas proativas quando o fluxo de dados atingir seus limites, permitindo otimizar a capacidade provisionada ou tomar medidas de escalonamento adequadas para evitar a perda de dados e manter o processamento de dados regular.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** normalmente, as solicitações com controle de utilização podem ser repetidas, portanto, definir o limite como zero torna o alarme muito sensível. No entanto, o controle de utilização consistente pode afetar a gravação no fluxo, e você deve definir o limite de alarme para detectar isso. Defina o limite como uma porcentagem de acordo com as solicitações com controle de utilização para as configurações da aplicação e de repetição.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Lambda
**ClaimedAccountConcurrency**
**Dimensões:** nenhuma
**Descrição do alarme:** esse alarme ajuda a monitorar se a simultaneidade de suas funções do Lambda está se aproximando do limite de simultaneidade por região da sua conta. Uma função começa a passar por um controle de utilização ao atingir o limite de simultaneidade. Você pode realizar as ações a seguir para evitar o controle de utilização.
1. [Solicitar um aumento de simultaneidade](https://repost.aws/knowledge-center/lambda-concurrency-limit-increase) nesta região.
1. Identificar e reduzir qualquer simultaneidade reservada ou simultaneidade provisionada não utilizada.
1. Identificar problemas de desempenho nas funções para aumentar a velocidade de processamento e, portanto, melhorar o throughput.
1. Aumentar o tamanho de lote das funções para que cada invocação de função processe mais mensagens.
**Intenção:** esse alarme pode detectar proativamente se a simultaneidade de suas funções do Lamba está se aproximando da cota de simultaneidade no nível de região da sua conta para que você possa agir. As funções passam por um controle de utilização se `ClaimedAccountConcurrency` atingir a cota de simultaneidade no nível de região da conta. Se você estiver usando Simultaneidade reservada (RC) ou Simultaneidade provisionada (PC), esse alarme proporcionará mais visibilidade sobre a utilização da simultaneidade em comparação a um alarme em `ConcurrentExecutions`.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** você deve calcular o valor de aproximadamente 90% da cota de simultaneidade definida para a conta na região e usar o resultado como valor limite. Por padrão, sua conta tem uma cota de simultaneidade de mil em todas as funções de uma região. No entanto, verifique a cota da sua conta no painel do Service Quotas.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**Erros**
**Dimensões:** FunctionName
**Descrição do alarme:** esse alarme detecta altas contagens de erros. Os erros incluem as exceções lançadas pelo código, bem como as exceções lançadas pelo runtime do Lambda. Você pode verificar os logs relacionados à função para diagnosticar o problema.
**Intenção:** o alarme ajuda a detectar altas contagens de erros em invocações de funções.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite como um número maior que zero. O valor exato pode depender da tolerância a erros em sua aplicação. Entenda a criticidade das invocações que a função está tratando. Para algumas aplicações, qualquer erro pode ser inaceitável, enquanto outras aplicações podem permitir uma certa margem de erro.
**Período: **60
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**Controles de utilização**
**Dimensões:** FunctionName
**Descrição do alarme:** esse alarme detecta um alto número de solicitações de invocação com controle de utilização. O controle de utilização ocorre quando não há simultaneidade disponível para aumentar a escala verticalmente. Há várias abordagens para resolver esse problema. 1) Solicitar um aumento de simultaneidade do AWS Suporte nesta região. 2) Identificar problemas de performance na função para aumentar a velocidade de processamento e, portanto, melhorar o throughput. 3) Aumentar o tamanho do lote da função para que mais mensagens sejam processadas por cada invocação de função.
**Intenção:** o alarme ajuda a detectar um alto número de solicitações de invocação com controle de utilização para uma função do Lambda. É importante saber se as solicitações estão sendo constantemente rejeitadas devido ao controle de utilização e se você precisa melhorar a performance da função do Lambda ou aumentar a capacidade de simultaneidade para evitar o controle de utilização constante.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite como um número maior que zero. O valor exato do limite pode depender da tolerância da aplicação. Defina o limite de acordo com seu uso e os requisitos de escalonamento da função.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Duração**
**Dimensões:** FunctionName
**Descrição do alarme:** esse alarme detecta tempos de longa duração para o processamento de um evento por uma função do Lambda. As longas durações podem ser causadas por alterações no código da função, fazendo com que a função demore mais para ser executada, ou que as dependências da função demorem mais.
**Intenção:** esse alarme pode detectar uma longa duração de funcionamento de uma função do Lambda. A alta duração do runtime indica que uma função está levando mais tempo para ser invocada e também pode afetar a capacidade de simultaneidade da invocação se o Lambda estiver lidando com um número maior de eventos. É fundamental saber se a função do Lambda está constantemente levando mais tempo de execução do que o esperado.
**Estatística:** p90
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o limite para a duração depende de sua aplicação, das workloads e de seus requisitos de performance. Para requisitos de alta performance, defina o limite para um tempo mais curto para verificar se a função está atendendo às expectativas. Você também pode analisar dados históricos de métricas de duração para ver se o tempo gasto corresponde à expectativa de performance da função e, em seguida, definir o limite para um tempo maior do que a média histórica. Certifique-se de definir o limite inferior ao tempo limite da função configurada.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ConcurrentExecutions**
**Dimensões:** FunctionName
**Descrição do alarme:** esse alarme ajuda a monitorar se a simultaneidade da função está se aproximando do limite de simultaneidade no nível de região da sua conta. Uma função começa a passar por um controle de utilização ao atingir o limite de simultaneidade. Você pode realizar as ações a seguir para evitar o controle de utilização.
1. Solicitar um aumento de simultaneidade nesta região.
1. Identificar problemas de desempenho nas funções para aumentar a velocidade de processamento e, portanto, melhorar o throughput.
1. Aumentar o tamanho de lote das funções para que cada invocação de função processe mais mensagens.
Para obter melhor visibilidade da utilização da simultaneidade reservada e da simultaneidade provisionada, defina um alarme para a nova métrica `ClaimedAccountConcurrency`.
**Intenção:** esse alarme pode detectar proativamente se a simultaneidade da função está se aproximando da cota de simultaneidade no nível de região da sua conta para que você possa agir. Uma função passa por um controle de utilização ao atingir a cota de simultaneidade no nível de região da conta.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite para cerca de 90% da cota de simultaneidade definida para a conta na região. Por padrão, sua conta tem uma cota de simultaneidade de mil em todas as funções de uma região. No entanto, você pode verificar a cota da sua conta, pois ela pode ser aumentada entrando em contato com o suporte da AWS.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Lambda Insights
Recomendamos definir alarmes de práticas recomendadas para as seguintes métricas do Lambda Insights.
**memory\$1utilization**
**Dimensões:** function\$1name
**Descrição do alarme:** esse alarme é usado para detectar se a utilização da memória de uma função do Lambda está se aproximando do limite configurado. Para solucionar problemas, você pode tentar 1) Otimizar seu código. 2) Dimensionar corretamente sua alocação de memória, estimando com precisão os requisitos de memória. Você pode consultar o [Lambda Power Tuning](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html) para realizar essa operação. 3) Use o pooling de conexões. Consulte [Using Amazon RDS Proxy with Lambda](https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/) para o pooling de conexões para o banco de dados do RDS. 4) Você também pode considerar a possibilidade de projetar suas funções para evitar o armazenamento de grandes quantidades de dados na memória entre as invocações.
**Descrição do alarme:** esse alarme é usado para detectar se a utilização da memória para a função do Lambda está se aproximando do limite configurado.
**Estatística:** média
**Sugestão de limite: **90.0
**Justificativa do limite:** defina o limite como 90% para receber um alerta quando a utilização da memória exceder 90% da memória alocada. Você pode ajustar isso para um valor mais baixo caso se preocupe com a workload para a utilização da memória. Você também pode verificar os dados históricos dessa métrica e definir o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon VPC (`AWS/NATGateway`)
**ErrorPortAllocation**
**Dimensões:** NatGatewayId
**Descrição do alarme:** esse alarme ajuda a detectar quando o gateway NAT não consegue alocar portas para novas conexões. Para resolver esse problema, consulte [Resolver erros de alocação de portas em um gateway NAT.](https://repost.aws/knowledge-center/vpc-resolve-port-allocation-errors)
**Intenção:** esse alarme é usado para detectar se o gateway NAT não pôde alocar uma porta de origem.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** se o valor de ErrorPortAllocation for maior que zero, isso significa que muitas conexões simultâneas para um único destino popular estão abertas por meio do gateway NAT.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**PacketsDropCount**
**Dimensões:** NatGatewayId
**Descrição do alarme:** esse alarme ajuda a detectar quando os pacotes são descartados pelo gateway NAT. Isso pode ocorrer devido a um problema com o gateway NAT, portanto, verifique o [painel de integridade do serviço da AWS](https://health.aws.amazon.com/health/status) para saber o status do gateway NAT da AWS em sua região. Isso pode ajudar você a correlacionar o problema de rede relacionado ao tráfego usando o gateway NAT.
**Intenção:** esse alarme é usado para detectar se os pacotes estão sendo descartados pelo gateway NAT.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** você deve calcular o valor de 0,01% do tráfego total no gateway NAT e usar esse resultado como valor limite. Use dados históricos do tráfego no gateway NAT para determinar o limite.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Link privado da AWS (`AWS/PrivateLinkEndpoints`)
**PacketsDropped**
**Dimensões:** ID da VPC, ID do endpoint da VPC, tipo de endpoint, ID da sub-rede, nome do serviço
**Descrição do alarme:** esse alarme ajuda a detectar se o endpoint ou o serviço de endpoint não está íntegro por meio do monitoramento do número de pacotes descartados pelo endpoint. Observe que os pacotes maiores que 8500 bytes que chegam ao endpoint da VPC são descartados. Para solução de problemas, consulte [Solucionar problemas de conectividade entre um endpoint da VPC de interface e um serviço de endpoint](https://repost.aws/knowledge-center/connect-endpoint-service-vpc).
**Intenção:** esse alarme é usado para detectar se o endpoint ou o serviço de endpoint não está íntegro.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com o caso de uso. Se você quiser estar ciente do status de não integridade do endpoint ou do serviço de endpoint, defina o limite baixo para ter a chance de corrigir o problema antes de uma grande perda de dados. Você pode usar dados históricos para entender a tolerância de pacotes descartados e definir o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Link privado da AWS (`AWS/PrivateLinkServices`)
**RstPacketsSent**
**Dimensões:** ID do serviço, balanceador de carga Arn, Az
**Descrição do alarme:** esse alarme ajuda você a detectar alvos não íntegros de um serviço de endpoint com base no número de pacotes de redefinição enviados aos endpoints. Ao depurar erros de conexão com um consumidor do seu serviço, você pode validar se o serviço está redefinindo as conexões com a métrica RstPacketsSent ou se algo mais está falhando no caminho da rede.
**Intenção:** esse alarme é usado para detectar alvos não íntegros de um serviço de endpoint.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o limite depende do caso de uso. Se o seu caso de uso puder tolerar que os alvos não sejam íntegros, você poderá definir o limite como alto. Se o caso de uso não tolerar alvos não íntegros, você poderá definir um limite como muito baixo.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## `Amazon RDS`
**CPUUtilization**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar a alta utilização da CPU de forma consistente. A utilização da CPU mede o tempo não ocioso. Considere usar o [Monitoramento avançado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling.html) ou [Insights de Performance](https://aws.amazon.com/rds/performance-insights/) para analisar qual [tempo de espera](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring-Available-OS-Metrics.html) está consumindo mais tempo da CPU (`guest`, `irq`, `wait`, `nice` etc.) para MariaDB, MySQL, Oracle e PostgreSQL. Em seguida, avalie quais consultas consomem a maior quantidade de CPU. Se não for possível ajustar a workload, considere migrar para uma classe de instância de banco de dados maior.
**Intenção:** este alarme é usado para detectar uma alta utilização da CPU de forma consistente a fim de evitar tempos de resposta muito altos e o atingimento do tempo limite. Se desejar verificar a microexpansão da utilização da CPU, é possível definir um tempo de avaliação inferior para o alarme.
**Estatística:** média
**Limite recomendado: **90.0
**Justificativa do limite:** os aumentos randômicos no consumo da CPU podem não prejudicar a performance do banco de dados, mas manter uma elevada utilização da CPU pode prejudicar futuras solicitações para o banco de dados. Dependendo da workload geral do banco de dados, a alta utilização da CPU na instância do RDS ou do Aurora pode degradar a performance geral.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**DatabaseConnections**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme detecta um grande número de conexões. Analise as conexões existentes e encerre aquelas que estiverem no estado “em repouso” ou que foram encerradas incorretamente. Considere usar um grupo de conexões para limitar o número de novas conexões. Como alternativa, aumente o tamanho da instância de banco de dados para usar uma classe com mais memória e, portanto, com um valor padrão mais alto para “max\$1connections”, ou aumente o valor de “max\$1connections” no [RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html) e no [MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html) e [PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Managing.html) do Aurora para a classe atual, caso ela seja compatível com sua workload.
**Intenção:** este alarme é usado para ajudar a evitar conexões rejeitadas quando o número máximo de conexões para o banco de dados é atingido. Esse alarme não é recomendado se você altera a classe da instância de banco de dados com frequência, pois realiza alterações na memória e no número máximo de conexões padrão.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o número de conexões permitidas depende do tamanho da classe da instância de banco de dados e dos parâmetros específicos para o mecanismo de banco de dados relacionados aos processos ou às conexões. Você deve calcular um valor entre 90 e 95% do número máximo de conexões para seu banco de dados e usar esse resultado como o valor limite.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**EBSByteBalance%**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar uma baixa porcentagem de créditos de throughput restantes. Para solução de problemas, verifique [problemas de latência no RDS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck).
**Intenção:** este alarme é usado para detectar uma baixa porcentagem de créditos de throughput restantes no bucket de intermitência. A baixa porcentagem de saldo para bytes pode causar problemas de gargalo de throughput. Esse alarme não é recomendado para instâncias do Aurora PostgreSQL.
**Estatística:** média
**Limite recomendado: **10.0
**Justificativa do limite:** um saldo de créditos de throughput inferior a 10% é considerado ruim e você deve definir o limite adequadamente. Além disso, é possível definir um limite mais baixo se a aplicação puder tolerar um throughput mais baixo para a workload.
**Período: **60
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**EBSIOBalance%**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar uma baixa porcentagem de créditos de IOPS restantes. Para obter uma solução de problemas, consulte [problemas de latência no RDS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck).
**Intenção:** este alarme é usado para detectar uma baixa porcentagem de créditos de E/S restantes no bucket de intermitência. A baixa porcentagem de saldo para IOPS pode causar problemas de gargalo de IOPS. Esse alarme não é recomendado para instâncias do Aurora.
**Estatística:** média
**Limite recomendado: **10.0
**Justificativa do limite:** um saldo de créditos de IOPS inferior a 10% é considerado ruim e você pode definir o limite adequadamente. Além disso, é possível definir um limite mais baixo se a aplicação puder tolerar um número de IOPS mais baixo para a workload.
**Período: **60
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**FreeableMemory**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar pouca memória que pode ser liberada, o que pode significar que há um aumento nas conexões do banco de dados ou que a instância pode estar sob alta pressão de memória. Verifique a pressão de memória ao monitorar as métricas do CloudWatch para `SwapUsage`, além de realizar o monitoramento para `FreeableMemory`. Se o consumo de memória da instância for frequentemente muito alto, indica que você deve verificar a workload ou atualizar a classe da instância. Para as instâncias de banco de dados de leitor do Aurora, considere adicionar mais instâncias de banco de dados de leitor ao cluster. Para obter informações sobre como solucionar problemas do Aurora, consulte [problemas de memória que pode ser liberada](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#Troubleshooting.FreeableMemory).
**Intenção:** este alarme é usado para ajudar a evitar a falta de memória, o que pode resultar em conexões rejeitadas.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** dependendo da workload e da classe da instância, valores diferentes para o limite podem ser apropriados. Preferencialmente, a memória disponível não deve ser inferior a 25% da memória total por períodos prolongados. Para o Aurora, é possível definir o limite próximo pa 5%, porque a métrica próxima de zero significa que a instância de banco de dados aumentou a escala verticalmente o máximo possível. Você pode analisar o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**FreeLocalStorage**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar pouco armazenamento local livre. A edição do Aurora compatível com PostgreSQL usa o armazenamento local para armazenar logs de erros e arquivos temporários. O Aurora MySQL usa armazenamento local para armazenar logs de erros, logs gerais, logs de consultas lentas, logs de auditoria e tabelas temporárias que não são do InnoDB. Esses volumes de armazenamento local são apoiados pelo Amazon EBS e podem ser ampliados ao usar uma classe de instância de banco de dados maior. Para obter a solução de problemas, verifique instâncias do Aurora [compatíveis com PostgreSQL](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue) e [compatíveis com MySQL](https://repost.aws/knowledge-center/aurora-mysql-local-storage).
**Intenção:** este alarme é usado para detectar o quão perto a instância de banco de dados do Aurora está de atingir o limite de armazenamento local, se você não usar o Aurora Sem Servidor v2 ou versões posteriores. O armazenamento local pode atingir a capacidade máxima quando você armazena dados não persistentes, como tabelas temporárias e arquivos de log, no armazenamento local. Esse alarme pode evitar um erro de falta de espaço que ocorre quando a instância de banco de dados fica sem o armazenamento local.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** você deve calcular cerca de 10% a 20% da quantidade de armazenamento disponível com base na velocidade e na tendência de uso do volume e, em seguida, usar esse resultado como o valor limite para tomar medidas proativas antes que o volume atinja o limite.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**FreeStorageSpace**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme monitora uma pequena quantidade de espaço de armazenamento disponível. Considere aumentar a escala verticalmente para o armazenamento do banco de dados caso você frequentemente se aproxime dos limites de capacidade de armazenamento. Inclua algum buffer para acomodar aumentos não previstos na demanda das aplicações. Como alternativa, considere habilitar o ajuste de escala automático para o armazenamento do RDS. Além disso, considere liberar mais espaço ao excluir dados e logs não utilizados ou desatualizados. Para obter mais informações, verifique o [documento do RDS para quando não há mais espaço de armazenamento](https://repost.aws/knowledge-center/rds-out-of-storage) e o [documento sobre problemas de armazenamento do PostgreSQL](https://repost.aws/knowledge-center/diskfull-error-rds-postgresql).
**Intenção:** este alarme ajuda a evitar problemas de armazenamento cheio. O alarme pode evitar o tempo de inatividade que ocorre quando a instância de banco de dados fica sem armazenamento. Não recomendamos usar esse alarme se você tiver o ajuste de escala automático para o armazenamento habilitado ou caso realize alterações da capacidade de armazenamento da instância de banco de dados com frequência.
**Estatística:** mínima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor do limite dependerá do espaço de armazenamento atualmente alocado. Normalmente, você deve calcular o valor de 10% do espaço de armazenamento alocado e usar esse resultado como valor limite.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**MaximumUsedTransactionIDs**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a evitar a conclusão de IDs de transação para o PostgreSQL. Consulte as etapas para a solução de problemas [nesta publicação do blog](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) para investigar e resolver o problema. Você também pode consultar [esta publicação do blog](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) para se familiarizar ainda mais com os conceitos de autovacuum, os problemas comuns e as práticas recomendadas.
**Intenção:** este alarme é usado para ajudar a evitar a conclusão de IDs de transação para o PostgreSQL.
**Estatística:** média
**Limite recomendado: **1.0E9
**Justificativa do limite: **definir este limite para um bilhão deverá fornecer tempo hábil para que você investigue o problema. O valor padrão para autovacuum\$1freeze\$1max\$1age é de 200 milhões. Se o tempo da transação mais antiga for de um bilhão, o autovacuum terá problemas para manter esse limite abaixo da meta de 200 milhões de IDs de transação.
**Período: **60
**Pontos de dados para o alarme: **1
**Períodos de avaliação: **1
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ReadLatency**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar a alta latência de leitura. Se a latência de armazenamento for alta, é porque a workload está excedendo os limites de recursos. É possível analisar a utilização de E/S em relação à configuração da instância e do armazenamento alocado. Consulte a [solução de problemas de latência de volumes do Amazon EBS causada por um gargalo de IOPS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck). Para o Aurora, é possível alternar para uma classe da instância que tenha [configuração de armazenamento I/O-Optimized](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html). Consulte [Planning I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/) para obter orientação.
**Intenção:** este alarme é usado para detectar alta latência de leitura. Geralmente, os discos de banco de dados têm baixa latência de leitura e de gravação, mas podem apresentar problemas que podem causar operações com alta latência.
**Estatística:** p90
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do seu caso de uso. Latências de leitura superiores a 20 milissegundos são provavelmente motivo para uma investigação. Também é possível definir um limite mais alto caso a aplicação possa ter uma latência mais alta para as operações de leitura. Avalie a criticidade e os requisitos para a latência de leitura e analise o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**ReplicaLag**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda você a compreender quantos segundos uma réplica tem de diferença quando comparada com a instância primária. Uma réplica de leitura do PostgreSQL relata um atraso de replicação de até cinco minutos caso não haja transações de usuário ocorrendo na instância de banco de dados de origem. Quando a métrica ReplicaLag atinge zero, a réplica alcançou a instância de banco de dados primária. Se a métrica ReplicaLag retornar -1, significa que a replicação não está ativa no momento. Para obter orientações relacionadas ao RDS para PostgreSQL, consulte as [práticas recomendadas de replicação](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/). Para solucionar problemas relacionados à métrica `ReplicaLag` e erros relacionados, consulte a [solução de problemas para ReplicaLag](https://repost.aws/knowledge-center/rds-postgresql-replication-lag).
**Intenção: **este alarme pode detectar o atraso da réplica, que reflete a perda de dados que pode ocorrer em caso de falha da instância primária. Se a réplica tiver uma diferença muito grande quando comparada com a instância primária e ela falhar, faltarão dados na réplica que estavam na instância primária.
**Estatística:** máxima
**Limite recomendado: **60.0
**Justificativa do limite: **normalmente, o atraso aceitável depende da aplicação. Recomendamos não mais do que 60 segundos.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**WriteLatency**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar a alta latência de gravação. Se a latência de armazenamento for alta, é porque a workload está excedendo os limites de recursos. É possível analisar a utilização de E/S em relação à configuração da instância e do armazenamento alocado. Consulte a [solução de problemas de latência de volumes do Amazon EBS causada por um gargalo de IOPS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck). Para o Aurora, é possível alternar para uma classe da instância que tenha [configuração de armazenamento I/O-Optimized](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html). Consulte [Planning I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/) para obter orientação.
**Intenção: **este alarme é usado para detectar alta latência de gravação. Embora, geralmente, os discos de banco de dados tenham baixa latência de leitura e de gravação, eles podem enfrentar problemas que causam operações com alta latência. Monitorar isso garantirá que a latência do disco seja tão baixa quanto o esperado.
**Estatística:** p90
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do seu caso de uso. Latências de gravação superiores a 20 milissegundos são provavelmente motivo para uma investigação. Também é possível definir um limite mais alto caso a aplicação puossa ter uma latência mais alta para as operações de gravação. Avalie a criticidade e os requisitos para a latência de gravação e analise o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**DBLoad**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar a alta carga do banco de dados. Se o número de processos exceder o número de vCPUs, os processos começarão a ser colocados em fila. Quando o enfileiramento aumenta, a performance é impactada. Se a carga do banco de dados estiver frequentemente acima da vCPU máxima e o estado de espera primário for a CPU, ela estará sobrecarregada. Nesse caso, é possível monitorar `CPUUtilization`, `DBLoadCPU` e as tarefas enfileiradas no Insights de Performance ou no Monitoramento Aprimorado. Talvez você deseje realizar o controle de utilização das conexões para a instância, ajustar quaisquer consultas SQL com uma alta carga de CPU ou considerar uma classe da instância maior. As instâncias altas e consistentes de qualquer estado de espera indicam que pode haver problemas de gargalos ou de contenção de recursos que você deve resolver.
**Intenção: **este alarme é usado para detectar uma alta carga do banco de dados. A alta carga do banco de dados pode causar problemas de performance na instância de banco de dados. Esse alarme não é aplicável para instâncias de banco de dados com tecnologia sem servidor.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite: **o valor máximo de vCPU é determinado pelo número de núcleos de vCPU (CPU virtual) da instância de banco de dados. Dependendo da vCPU máxima, valores diferentes para o limite podem ser apropriados. Preferencialmente, a carga do banco de dados não deve ultrapassar a linha da vCPU.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**AuroraVolumeBytesLeftTotal**
**Dimensões:** DBClusterIdentifier
**Descrição do alarme:** este alarme ajuda a monitorar o baixo volume total restante. Quando o volume total restante atinge o limite de tamanho, o cluster relata um erro de falta de espaço. O armazenamento do Aurora é escalado automaticamente com os dados no volume do cluster e é ampliado até 128 TiB ou 64 TiB, dependendo da [versão do mecanismo de banco de dados](https://repost.aws/knowledge-center/aurora-version-number). Considere reduzir o armazenamento ao descartar as tabelas e os bancos de dados que não são mais necessários. Para obter mais informações, consulte a [escalabilidade de armazenamento](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html).
**Intenção:** este alarme é usado para detectar o quão próximo o cluster do Aurora está do limite de tamanho para o volume. Esse alarme pode evitar um erro de falta de espaço que ocorre quando o cluster fica sem espaço. Ele é recomendado somente para o Aurora MySQL.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** você deve calcular de 10% a 20% do limite de tamanho real com base na velocidade e na tendência de aumento de uso do volume e, em seguida, usar esse resultado como o valor limite para tomar medidas proativas antes que o volume atinja o limite.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**AuroraBinlogReplicaLag**
**Dimensões: **DBClusterIdentifier, Role=WRITER
**Descrição do alarme:** este alarme ajuda a monitorar o estado de erro da replicação da instância do gravador do Aurora. Para ter mais informações, consulte [Como replicar clusters de bancos de dados Amazon Aurora MySQL entre regiões da AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html). Para obter a solução de problemas, consulte [Problemas de replicação no Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL).
**Intenção:** este alarme é usado para detectar se a instância do gravador está em um estado de erro e não pode replicar a origem. Ele é recomendado somente para o Aurora MySQL.
**Estatística:** média
**Limite recomendado: **-1.0
**Justificativa do limite: **recomendamos usar -1 como o valor limite porque o Aurora MySQL publicará esse valor se a réplica estiver em um estado de erro.
**Período: **60
**Pontos de dados para o alarme: **2
**Períodos de avaliação: **2
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BlockedTransactions**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme: **este alarme ajuda a monitorar uma alta contagem de transações bloqueadas em uma instância de banco de dados do Aurora. As transações bloqueadas podem terminar em uma reversão ou uma confirmação. A alta simultaneidade, a ociosidade nas transações ou as transações de longa execução podem ocasionar transações bloqueadas. Para obter a solução de problemas, consulte a documentação do [Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/ams-waits.row-lock-wait.html).
**Intenção: **este alarme é usado para detectar uma alta contagem de transações bloqueadas em uma instância de banco de dados do Aurora com a finalidade de evitar as reversões de transações e a degradação da performance.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite: **você deve calcular 5% de todas as transações da sua instância usando a métrica `ActiveTransactions` e usar esse resultado como o valor limite. Também é possível avaliar a criticidade e os requisitos para as transações bloqueadas e analisar o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**BufferCacheHitRatio**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme: **este alarme ajuda a monitorar uma proporção de ocorrências do cache que esteja baixa e consistente para o cluster do Aurora. Uma alta de acertos baixa indica que as consultas nessa instância de banco de dados estão acessando o disco com maior frequência. Para solucionar problemas, investigue a workload para visualizar quais consultas estão causando esse comportamento e consulte o documento de [recomendações de RAM para a instância de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.BestPractices.html#Aurora.BestPractices.Performance.Sizing).
**Intenção: **este alarme é usado para detectar uma proporção de ocorrências do cache que esteja baixa e consistente a fim de evitar que se mantenha uma diminuição da performance na instância do Aurora.
**Estatística:** média
**Limite recomendado: **80.0
**Justificativa do limite: **é possível definir o limite para a proporção de ocorrências do cache em buffer como 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload.
**Período: **60
**Pontos de dados para o alarme: **10
**Períodos de avaliação: **10
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**EngineUptime**
**Dimensões: **DBClusterIdentifier, Role=WRITER
**Descrição do alarme: **este alarme ajuda a monitorar o baixo tempo de inatividade da instância de banco de dados do gravador. A instância de banco de dados do gravador pode se tornar inativa devido a uma reinicialização, uma manutenção, uma atualização ou um failover. Quando o tempo de atividade atinge zero devido a um failover no cluster, e o cluster tem uma ou mais réplicas do Aurora, uma réplica do Aurora é promovida como a instância primária do gravador durante um evento de falha. Para aumentar a disponibilidade do cluster de banco de dados, considere criar uma ou mais réplicas do Aurora em duas ou mais zonas de disponibilidade diferentes. Para obter mais informações, verifique os [fatores que influenciam o tempo de inatividade do Aurora](https://repost.aws/knowledge-center/aurora-mysql-downtime-factors).
**Intenção: **este alarme é usado para detectar se a instância de banco de dados do gravador do Aurora está com um tempo de inatividade. Isso pode evitar falhas de execução prolongada na instância do gravador que ocorrem devido a uma falha ou a um failover.
**Estatística:** média
**Limite recomendado: **0.0
**Justificativa do limite: **um evento de falha resulta em uma breve interrupção durante a qual as operações de leitura e de gravação falham com uma exceção. No entanto, o serviço é restaurado normalmente em menos de 60 segundos e muitas vezes em menos de 30 segundos.
**Período: **60
**Pontos de dados para o alarme: **2
**Períodos de avaliação: **2
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**RollbackSegmentHistoryListLength**
**Dimensões: **DBInstanceIdentifier
**Descrição do alarme: **este alarme ajuda a monitorar um tamanho consistente e amplo para o histórico do segmento de reversão de uma instância do Aurora. Um tamanho amplo para a lista de histórico do InnoDB indica que um grande número de versões antigas de linhas, consultas e desligamentos de banco de dados tornaram-se mais lentos. Para obter mais informações e a solução de problemas, consulte a documentação [O tamanho da lista de histórico do InnoDB aumentou significativamente](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/proactive-insights.history-list.html).
**Intenção: **este alarme é usado para detectar um tamanho amplo e consistente para o histórico do segmento de reversão. Isso pode ajudar a evitar manter a degradação da performance e o alto uso da CPU na instância do Aurora. Ele é recomendado somente para o Aurora MySQL.
**Estatística:** média
**Limite recomendado: **1000000.0
**Justificativa do limite: **definir este limite para um milhão deverá fornecer tempo hábil para que você investigue o problema. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**StorageNetworkThroughput**
**Dimensões: **DBClusterIdentifier, Role=WRITER
**Descrição do alarme: **este alarme ajuda a monitorar o alto throughput da rede de armazenamento. Se o throughput da rede de armazenamento ultrapassar a largura de banda da rede total da [instância do EC2](https://aws.amazon.com/ec2/instance-types/), ele poderá ocasionar uma alta latência de leitura e de gravação, o que pode causar degradação da performance. É possível verificar o tipo de instância do EC2 no Console da AWS. Para solucionar problemas, verifique quaisquer alterações nas latências de gravação e de leitura e avalie se você também acionou um alarme nessa métrica. Se for esse o caso, avalie o padrão de workload durante os horários em que o alarme foi acionado. Isso pode ajudar você a identificar se é possível otimizar a workload para reduzir a quantidade total de tráfego de rede. Se isso não for possível, talvez seja necessário considerar escalar a instância.
**Intenção: **este alarme é usado para detectar o alto throughput da rede de armazenamento. A detecção de alto throughput pode evitar as quedas de pacotes de rede e a degradação da performance.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite: **você deve calcular cerca de 80% a 90% da largura de banda da rede total do tipo de instância do EC2 e, em seguida, usar esse resultado como o valor limite para tomar medidas proativas antes que os pacotes de rede sejam afetados. Também é possível avaliar a criticidade e os requisitos para o throughput da rede de armazenamento e analisar o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## `Amazon Route 53 Public Data Plane`
**HealthCheckStatus**
**Dimensões:** HealthCheckId
**Descrição do alarme:** esse alarme ajuda a detectar endpoints não íntegros de acordo com os verificadores de integridade. Para entender o motivo de uma falha que resulta em status de não integridade, use a guia Verificadores de integridade no console de verificação de integridade do Route 53 para visualizar o status de cada região, bem como a última falha da verificação de integridade. A guia de status também exibe o motivo pelo qual o endpoint é relatado como não íntegro. Consulte as [etapas de solução de problemas](https://repost.aws/knowledge-center/route-53-fix-unhealthy-health-checks).
**Intenção:** esse alarme usa os verificadores de integridade do Route 53 para detectar endpoints não íntegros.
**Estatística:** média
**Limite recomendado: **1.0
**Justificativa do limite:** o status do endpoint é relatado como 1 quando ele está íntegro. Qualquer valor inferior a 1 indica não integridade.
**Período: **60
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
## `Amazon S3`
**4xxErrors**
**Dimensões:** BucketName, FilterId
**Descrição do alarme:** esse alarme nos ajuda a informar o número total de códigos de status de erro 4xx que são criados em resposta a solicitações de clientes. Os códigos de erro 403 podem indicar uma política do IAM incorreta e os códigos de erro 404 podem indicar uma aplicação cliente com comportamento incorreto, por exemplo. [Habilitar o registro em log de acesso ao servidor do S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html) ajudará você a identificar a origem do problema usando os campos Status HTTP e Código de erro. Para entender mais sobre o código de erro, consulte [Respostas de erro](https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html).
**Intenção:** esse alarme é usado para criar uma linha de base para as taxas de erro 4xx típicas, de modo que você possa analisar qualquer anormalidade que possa indicar um problema de configuração.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** o limite recomendado é detectar se mais de 5% do total de solicitações estão recebendo erros 4XX. Os erros 4XX que ocorrem com frequência devem receber um alarme. Entretanto, a definição de um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível. Você também pode ajustar o limite de acordo com a carga das solicitações, levando em conta um nível aceitável de erros 4XX. Você também pode analisar dados históricos para encontrar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**Dimensões:** BucketName, FilterId
**Descrição do alarme:** esse alarme ajuda você a detectar um grande número de erros no lado do servidor. Esses erros indicam que um cliente fez uma solicitação que o servidor não conseguiu concluir. Isso pode ajudar você a correlacionar o problema que sua aplicação está enfrentando por causa do S3. Para obter mais informações para ajudar você a tratar ou reduzir erros de forma eficiente, consulte [Optimizing performance design patterns](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries). Os erros também podem ser causados por um problema com o S3. Verifique o [painel de integridade do serviço da AWS](https://health.aws.amazon.com/health/status) para saber o status do Amazon S3 em sua região.
**Intenção:** esse alarme pode ajudar a detectar se a aplicação está apresentando problemas devido a erros 5xx.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo o 5XXError. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para ver qual é a taxa de erro aceitável para a workload da aplicação e ajustar o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**OperationsFailedReplication**
**Dimensões:** SourceBucket, DestinationBucket, RuleId
**Descrição do alarme:** esse alarme ajuda a entender uma falha de replicação. Essa métrica rastreia o status de novos objetos replicados usando o S3 CRR ou S3 SRR e também rastreia os objetos existentes replicados usando a replicação em lote do S3. Consulte [Solução de problemas de replicação](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-troubleshoot.html) para obter mais detalhes.
**Intenção:** esse alarme é usado para detectar se houve falha na operação de replicação.
**Estatística:** máxima
**Limite recomendado: **0.0
**Justificativa do limite:** essa métrica emite um valor de 0 para operações bem-sucedidas e nenhum valor quando não há operações de replicação realizadas para o minuto. Quando a métrica emite um valor maior que 0, a operação de replicação não é bem-sucedida.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## `S3ObjectLambda`
**4xxErrors**
**Dimensões:** AccessPointName, DataSourceARN
**Descrição do alarme:** esse alarme nos ajuda a informar o número total de códigos de status de erro 4xx que são criados em resposta a solicitações de clientes. [Habilitar o registro em log de acesso ao servidor do S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html) ajudará você a identificar a origem do problema usando os campos Status HTTP e Código de erro.
**Intenção:** esse alarme é usado para criar uma linha de base para as taxas de erro 4xx típicas, de modo que você possa analisar qualquer anormalidade que possa indicar um problema de configuração.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo o 4XXError. Os erros 4XX que ocorrem com frequência devem receber um alarme. Entretanto, a definição de um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível. Você também pode ajustar o limite de acordo com a carga das solicitações, levando em conta um nível aceitável de erros 4XX. Você também pode analisar dados históricos para encontrar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**Dimensões:** AccessPointName, DataSourceARN
**Descrição do alarme:** esse alarme ajuda a detectar um grande número de erros no lado do servidor. Esses erros indicam que um cliente fez uma solicitação que o servidor não conseguiu concluir. Esses erros podem ser causados por um problema com o S3. Verifique o [painel de integridade do serviço da AWS](https://health.aws.amazon.com/health/status) para saber o status do Amazon S3 em sua região. Isso pode ajudar você a correlacionar o problema que sua aplicação está enfrentando por causa do S3. Para obter informações que o ajudem a tratar ou reduzir esses erros com eficiência, consulte [Optimizing performance design patterns](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries).
**Intenção:** esse alarme pode ajudar a detectar se a aplicação está apresentando problemas devido a erros 5xx.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo erros 5XX. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para ver qual é a taxa de erro aceitável para a workload da aplicação e ajustar o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**LambdaResponse4xx**
**Dimensões:** AccessPointName, DataSourceARN
**Descrição do alarme:** esse alarme ajuda você a detectar e diagnosticar falhas (500s) em chamadas para o S3 Object Lambda. Esses erros podem ser causados por erros ou configurações incorretas na função do Lambda responsável por responder às suas solicitações. Investigar os fluxos de logs do CloudWatch da função do Lambda associada ao ponto de acesso do Object Lambda pode ajudar você a identificar a origem do problema com base na resposta do S3 Object Lambda.
**Intenção:** esse alarme é usado para detectar erros de cliente 4xx para chamadas WriteGetObjectResponse.
**Estatística:** média
**Limite recomendado: **0.05
**Justificativa do limite:** recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo o 4XXError. Os erros 4XX que ocorrem com frequência devem receber um alarme. Entretanto, a definição de um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível. Você também pode ajustar o limite de acordo com a carga das solicitações, levando em conta um nível aceitável de erros 4XX. Você também pode analisar dados históricos para encontrar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon SNS
**NumberOfMessagesPublished**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme pode detectar quando o número de mensagens do SNS publicadas é muito baixo. Para solucionar problemas, verifique por que os publicadores estão enviando menos tráfego.
**Intenção:** esse alarme ajuda você a monitorar e detectar proativamente quedas significativas na publicação de notificações. Isso ajuda você a identificar possíveis problemas com a aplicação ou com os processos comerciais, de modo que você possa tomar as medidas adequadas para manter o fluxo esperado de notificações. Você deve criar esse alarme se você espera que seu sistema tenha um tráfego mínimo a ser atendido.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o número de mensagens publicadas deve estar de acordo com o número esperado de mensagens publicadas para sua aplicação. Você também pode analisar os dados históricos, as tendências e o tráfego para encontrar o limite correto.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsDelivered**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme pode detectar quando o número de mensagens do SNS entregues é muito baixo. Isso pode ocorrer devido ao cancelamento não intencional da assinatura de um endpoint ou devido a um evento do SNS que causa atraso nas mensagens.
**Intenção:** esse alarme ajuda você a detectar uma queda no volume de mensagens entregues. Você deve criar esse alarme se você espera que seu sistema tenha um tráfego mínimo a ser atendido.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o número de mensagens entregues deve estar de acordo com o número esperado de mensagens produzidas e o número de consumidores. Você também pode analisar os dados históricos, as tendências e o tráfego para encontrar o limite correto.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailed**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme pode detectar quando o número de mensagens do SNS com falha é muito alto. Para solucionar problemas de notificações com falha, ative o registro em log no CloudWatch Logs. A verificação dos logs pode ajudar a descobrir quais assinantes estão apresentando falhas, bem como os códigos de status que estão retornando.
**Intenção:** esse alarme ajuda você a encontrar proativamente problemas com a entrega de notificações e a tomar as medidas adequadas para resolvê-los.
**Estatística:** soma
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do impacto das notificações com falha. Analise os SLAs fornecidos aos seus usuários finais, a tolerância a falhas e a importância das notificações, e analise os dados históricos, e então selecione um limite adequadamente. O número de notificações com falha deve ser 0 para tópicos que tenham apenas assinaturas do SQS, Lambda ou Firehose.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidAttributes**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme ajuda a monitorar e resolver possíveis problemas com o publicador ou com os assinantes. Verifique se um publicador está publicando mensagens com atributos inválidos ou se um filtro inadequado foi aplicado a um assinante. Você também pode analisar o CloudWatch Logs para ajudar a encontrar a causa-raiz do problema.
**Intenção:** o alarme é usado para detectar se as mensagens publicadas não são válidas ou se foram aplicados filtros inadequados a um assinante.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** atributos inválidos são quase sempre um erro do publicador. Recomendamos definir o limite como 0 porque atributos inválidos não são esperados em um sistema íntegro.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidMessageBody**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme ajuda a monitorar e resolver possíveis problemas com o publicador ou com os assinantes. Verifique se um publicador está publicando mensagens com corpos de mensagem inválidos ou se um filtro inadequado foi aplicado a um assinante. Você também pode analisar o CloudWatch Logs para ajudar a encontrar a causa-raiz do problema.
**Intenção:** o alarme é usado para detectar se as mensagens publicadas não são válidas ou se foram aplicados filtros inadequados a um assinante.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** corpos de mensagem inválidos são quase sempre um erro do publicador. Recomendamos definir o limite como 0 porque corpos de mensagens inválidos não são esperados em um sistema íntegro.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsRedrivenToDlq**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme ajuda a monitorar o número de mensagens que são movidas para uma fila de mensagens não entregues.
**Intenção:** o alarme é usado para detectar mensagens que foram movidas para uma fila de mensagens não entregues. Recomendamos que você crie esse alarme quando o SNS estiver acoplado ao SQS, Lambda ou Firehose.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** em um sistema íntegro de qualquer tipo de assinante, as mensagens não devem ser movidas para a fila de mensagens não entregues. Recomendamos que você receba uma notificação caso alguma mensagem caia na fila para que possa identificar e resolver a causa-raiz e, possivelmente, redirecionar as mensagens na fila de mensagens não entregues para evitar a perda de dados.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailedToRedriveToDlq**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme ajuda a monitorar as mensagens que não puderam ser movidas para uma fila de mensagens não entregues. Verifique se a fila de mensagens não entregues existe e se está configurada corretamente. Além disso, verifique se o SNS tem permissões para acessar a fila de mensagens não entregues. Consulte a [documentação da fila de mensagens não entregues](https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html) para saber mais.
**Intenção:** o alarme é usado para detectar mensagens que não puderam ser movidas para uma fila de mensagens não entregues.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** quase sempre é um erro se as mensagens não puderem ser movidas para a fila de mensagens não entregues. A recomendação para o limite é 0, o que significa que todas as mensagens que falharem no processamento deverão ser capazes de alcançar a fila de mensagens não entregues quando a fila tiver sido configurada.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**SMSMonthToDateSpentUSD**
**Dimensões: **TopicName
**Descrição do alarme:** o alarme ajuda a monitorar se você tem uma cota suficiente em sua conta para que o SNS possa entregar mensagens. Se você atingir sua cota, o SNS não poderá enviar mensagens SMS. Para obter informações sobre como definir sua cota mensal de gastos com SMS ou sobre como solicitar um aumento da cota de gastos com a AWS, consulte [Definição das preferências de mensagens SMS](https://docs.aws.amazon.com/sns/latest/dg/sms_preferences.html).
**Intenção:** esse alarme é usado para detectar se você tem uma cota suficiente em sua conta para que as mensagens SMS sejam entregues com êxito.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite de acordo com a cota (limite de gastos da conta) da conta. Escolha um limite que informe a você com antecedência suficiente que você está atingindo o limite da cota para que você tenha tempo de solicitar um aumento.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
**SMSSuccessRate**
**Dimensões: **TopicName
**Descrição do alarme:** esse alarme ajuda a monitorar a taxa de falhas nas entregas de mensagens SMS. Você pode configurar o [Cloudwatch Logs](https://docs.aws.amazon.com/sns/latest/dg/sms_stats_cloudwatch.html) para entender a natureza da falha e tomar medidas com base nisso.
**Intenção:** esse alarme é usado para detectar falhas na entrega de mensagens SMS.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** defina o limite do alarme de acordo com sua tolerância para falhas na entrega de mensagens SMS.
**Período: **60
**Pontos de dados para o alarme: **5
**Períodos de avaliação: **5
**Operador de comparação:** GREATER\$1THAN\$1THRESHOLD
## Amazon SQS
**ApproximateAgeOfOldestMessage**
**Dimensões:** QueueName
**Descrição do alarme:** esse alarme observa a idade da mensagem mais antiga na fila. Você pode usar esse alarme para monitorar se os seus consumidores estão processando mensagens do SQS na velocidade desejada. Considere a possibilidade de aumentar o número de consumidores ou o throughput dos consumidores para reduzir a idade das mensagens. Essa métrica pode ser usada em combinação com `ApproximateNumberOfMessagesVisible` para determinar o tamanho do backlog da fila e a rapidez com que as mensagens estão sendo processadas. Para evitar que as mensagens sejam excluídas antes de serem processadas, considere a possibilidade de configurar a fila de mensagens não entregues para deixar de lado as possíveis mensagens “poison pill”.
**Intenção:** esse alarme é usado para detectar se a idade da mensagem mais antiga na fila QueueName é muito alta. Uma idade maior pode ser uma indicação de que as mensagens não estão sendo processadas com rapidez suficiente ou de que há algumas mensagens “poison-pill” que estão presas na fila e não podem ser processadas.
**Estatística:** máxima
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme depende muito do tempo esperado de processamento da mensagem. Você pode usar dados históricos para calcular o tempo médio de processamento de mensagens e, em seguida, definir o limite como 50% maior do que o tempo máximo esperado de processamento de mensagens do SQS pelos consumidores da fila.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesNotVisible**
**Dimensões:** QueueName
**Descrição do alarme:** esse alarme ajuda a detectar um número alto de mensagens em andamento com relação ao `QueueName`. Para solucionar problemas, verifique [message backlog decreasing](https://repost.aws/knowledge-center/sqs-message-backlog).
**Intenção:** esse alarme é usado para detectar um número alto de mensagens em andamento na fila. Se os consumidores não excluírem as mensagens dentro do período de tempo limite de visibilidade, quando a fila for pesquisada, as mensagens reaparecerão na fila. Para filas FIFO, pode haver um máximo de 20 mil mensagens em andamento. Se você atingir essa cota, o SQS não retornará nenhuma mensagem de erro. Uma fila FIFO examina as primeiras 20.000 mensagens para determinar os grupos de mensagens disponíveis. Isso significa que, se houver um acúmulo de mensagens em um único grupo de mensagens, não será possível consumir mensagens de outros grupos de mensagens que foram enviadas para a fila posteriormente até que as mensagens do backlog sejam processadas com êxito.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** o valor limite recomendado para esse alarme é altamente dependente do número esperado de mensagens em andamento. Você pode usar dados históricos para calcular o número máximo esperado de mensagens em andamento e definir o limite para 50% acima desse valor. Se os consumidores da fila estiverem processando, mas não excluindo mensagens da fila, esse número aumentará repentinamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesVisible**
**Dimensões:** QueueName
**Descrição do alarme:** esse alarme observa se o backlog da fila de mensagens é maior do que o esperado, indicando que os consumidores estão muito lentos ou que não há consumidores suficientes. Considere aumentar a contagem de consumidores ou acelerar os consumidores, se esse alarme entrar no estado ALARME.
**Intenção:** esse alarme é usado para detectar se a contagem de mensagens da fila ativa está muito alta e se os consumidores estão demorando para processar as mensagens ou se não há consumidores suficientes para processá-las.
**Estatística:** média
**Limite recomendado:** depende da sua situação
**Justificativa do limite:** um número inesperadamente alto de mensagens visíveis indica que as mensagens não estão sendo processadas por um consumidor na taxa esperada. Você deve considerar os dados históricos ao definir esse limite.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**NumberOfMessagesSent**
**Dimensões:** QueueName
**Descrição do alarme:** esse alarme ajuda a detectar se não há mensagens sendo enviadas de um produtor com relação ao `QueueName`. Para solucionar problemas, verifique o motivo pelo qual o produtor não está enviando mensagens.
**Intenção:** esse alarme é usado para detectar quando um produtor para de enviar mensagens.
**Estatística:** soma
**Limite recomendado: **0.0
**Justificativa do limite:** se o número de mensagens enviadas for 0, o produtor não está enviando nenhuma mensagem. Se essa fila tiver um TPS baixo, aumente o número de EvaluationPeriods adequadamente.
**Período: **60
**Pontos de dados para o alarme: **15
**Períodos de avaliação: **15
**Operador de comparação:** LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Site-to-Site VPN
**TunnelState**
**Dimensões:** VpnId
**Descrição do alarme:** esse alarme ajuda você a entender se o estado de um ou mais túneis é INATIVO. Para solucionar problemas, consulte [VPN tunnel troubleshooting](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting).
**Intenção:** esse alarme é usado para detectar se pelo menos um túnel está no estado INATIVO para essa VPN para que você possa solucionar o problema da VPN afetada. Esse alarme sempre estará no estado ALARME para redes que tenham apenas um único túnel configurado.
**Estatística:** mínima
**Limite recomendado: **1.0
**Justificativa do limite:** um valor menor que 1 indica que pelo menos um túnel está no estado INATIVO.
**Período: **300
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
**TunnelState**
**Dimensões:** TunnelIpAddress
**Descrição do alarme:** esse alarme ajuda você a entender se o estado desse túnel é INATIVO. Para solucionar problemas, consulte [VPN tunnel troubleshooting](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting).
**Intenção:** esse alarme é usado para detectar se o túnel está no estado INATIVO para que você possa solucionar o problema da VPN afetada. Esse alarme sempre estará no estado ALARME para redes que tenham apenas um único túnel configurado.
**Estatística:** mínima
**Limite recomendado: **1.0
**Justificativa do limite:** um valor menor que 1 indica que o túnel está no estado INATIVO.
**Período: **300
**Pontos de dados para o alarme: **3
**Períodos de avaliação: **3
**Operador de comparação:** LESS\$1THAN\$1THRESHOLD
# Casos de uso e exemplos de alarmes
As seções a seguir fornecem exemplos e tutoriais de alarmes para casos de uso comuns.
**Topics**
+ [
# Criar um alarme de faturamento para monitorar suas cobranças estimadas da AWS
](monitor_estimated_charges_with_cloudwatch.md)
+ [
# Criar um alarme de utilização de CPU
](US_AlarmAtThresholdEC2.md)
+ [
# Criar um alarme de latência do balanceador de carga que envie um email
](US_AlarmAtThresholdELB.md)
+ [
# Criar um alarme de throughput de armazenamento que envie emails
](US_AlarmAtThresholdEBS.md)
+ [
# Crie um alarme para as métricas do contador do Performance Insights a partir de um banco de dados da AWS
](CloudWatch_alarm_database_performance_insights.md)
# Criar um alarme de faturamento para monitorar suas cobranças estimadas da AWS
É possível monitorar suas cobranças estimadas da AWS usando o Amazon CloudWatch. Quando você habilita o monitoramento de estimativas de cobrança para sua conta da AWS, as estimativas de cobrança são calculadas e enviadas várias vezes por dia para o CloudWatch como dados de métrica.
Os dados de métrica de faturamento são armazenados na região Leste dos EUA (Norte da Virgínia) e representam cobranças mundiais. Esses dados incluem as estimativas de cobrança para cada serviço da AWS que você usa, além do total geral estimado de suas cobranças da AWS.
O alarme é acionado quando o faturamento da conta excede o limite especificado. Ele é acionado somente quando o faturamento atual excede o limite. Ele não usa projeções com base no seu uso até o momento no mês.
Se você criar um alerta de faturamento quando suas cobranças já tiverem excedido o limite, o alarme mudará para o estado `ALARM` imediatamente.
**nota**
Para obter informações sobre como analisar as cobranças do CloudWatch nas quais você já incorreu, consulte [Análise, otimização e redução de custos do CloudWatch](cloudwatch_billing.md).
**Topics**
+ [
## Habilitar alertas de faturamento
](#turning_on_billing_metrics)
+ [
## Criar um alarme de faturamento
](#creating_billing_alarm_with_wizard)
+ [
## Excluir um alarme de faturamento
](#deleting_billing_alarm)
## Habilitar alertas de faturamento
Para criar um alarme para suas estimativas de despesas, habilite alertas de faturamento para poder monitorar suas estimativas de despesas da AWS e criar um alarme usando dados de métrica de faturamento. Depois que habilitar alertas de faturamento, você não poderá desativar a coleta de dados, mas poderá excluir qualquer alarme de faturamento que tenha criado.
Depois que habilitar alertas de pagamento pela primeira vez, levará cerca de 15 minutos para que você possa visualizar dados de faturamento e definir alertas de pagamento.
**Requisitos**
+ É necessário estar conectado usando as credenciais de usuário-raiz da conta ou como um usuário do IAM que tenha recebido permissão para visualizar as informações de faturamento.
+ Para contas de faturamento consolidado, os dados de faturamento para cada conta vinculada podem ser encontrados fazendo login como a conta de pagamento. Você pode visualizar dados de faturamento para o total de cobranças estimadas e cobranças estimadas por serviço para cada conta vinculada, além da conta consolidada.
+ Em uma conta de faturamento consolidado, as métricas da conta vinculada ao membro serão capturadas somente se a conta pagante habilitar a preferência **Receber alertas de faturamento**. Se você alterar qual é a conta de gerenciamento/pagante, será necessário habilitar os alertas de faturamento na nova conta de gerenciamento/pagante.
+ A conta não deve fazer parte da Rede de parceiros da Amazon (APN) porque as métricas de faturamento não são publicadas no CloudWatch para contas do APN. Para obter mais informações, consulte [Rede de parceiros da AWS](https://aws.amazon.com/partners/).
**Para ativar o monitoramento de estimativas de gastos**
1. Abra o console de Gerenciamento de Faturamento e Custos da AWS em [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. No painel de navegação, selecione **Billing Preferences (Preferências de faturamento)**.
1. Em **Preferências de alertas**, escolha **Editar**.
1. Escolha **Receber alertas de faturamento do CloudWatch**.
1. Selecione **Salvar preferências**.
## Criar um alarme de faturamento
**Importante**
Antes de criar um alarme de faturamento, defina a região como Leste dos EUA (Norte da Virgínia). Os dados de métrica de faturamento são armazenados nessa região e representam as despesas em todo o mundo. É necessário habilitar alertas de faturamento na conta ou na conta de gerenciamento/pagante (se você estiver usando faturamento consolidado). Para obter mais informações, consulte [Habilitar alertas de faturamento](#turning_on_billing_metrics).
Neste procedimento, você cria um alarme que envia uma notificação quando suas estimativas de cobrança da AWS excedem um limite definido.
**Para criar um alarme de cobrança usando o console do CloudWatch**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes) e depois escolha **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Selecionar métrica**. Em **AWS Namespaces**, escolha **Cobrança** e, em seguida, escolha **Cobrança total estimada**.
**nota**
Caso não veja a métrica **Faturamento**/**Total da cobrança estimada**, habilite os alertas de faturamento e altere a região para Leste dos EUA (Norte da Virgínia). Para obter mais informações, consulte [Habilitar alertas de faturamento](#turning_on_billing_metrics).
1. Marque a caixa de seleção **EstimatedCharges** e escolha **Select metric** (Selecionar métrica).
1. Em **Statistic** (Estatística), escolha **Maximum** (Máximo).
1. Em **Period** (Período), escolha **6 hours** (6 horas).
1. Em **Tipo de limite**, escolha **Estático**.
1. Em **Whenever EstimatedCharges is…** (Sempre que EstimatedCharges for…), escolha **Greater** (Maior).
1. Em **que . . .**, defina o valor para o qual você deseja que seu alarme seja acionado. Por exemplo, **200** USD.
Os valores da métrica **EstimatedCharges** estão somente em dólares americanos (USD), e a conversão da moeda é fornecida pela Amazon Services LLC. Para obter mais informações, consulte [O que é o AWS Billing?](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html).
**nota**
Após definir um valor limite, o gráfico de pré-visualização exibirá suas cobranças estimadas do mês atual.
1. Em **Configuração adicional**, faça o seguinte:
+ Em **Datapoints to alarm** (Pontos de dados para alarme), especifique **1 of 1** (1 de 1).
+ Em **Missing data treatment** (Tratamento de dados ausentes), escolha **Treat missing data as missing** (Tratar dados ausentes como ausentes).
1. Escolha **Próximo**.
1. Em **Notificação**, certifique-se de que a opção **Em alarme** esteja selecionada. Em seguida, especifique um tópico do Amazon SNS a ser notificado quando o alarme estiver no estado `ALARM`. O tópico do Amazon SNS pode incluir seu endereço de e-mail para que você receba e-mails quando o valor do faturamento ultrapassar o limite especificado.
É possível selecionar um tópico existente do Amazon SNS, criar um novo tópico do Amazon SNS ou usar um ARN do tópico para notificar outra conta. Se quiser que o alarme envie várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification** (Adicionar notificação).
1. Escolha **Próximo**.
1. Em **Name and description** (Nome e descrição), insira um nome para o alarme. O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII.
1. (Opcional) Insira uma descrição do alarme. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Escolha **Próximo**.
1. Em **Preview and create** (Pré-visualizar e criar), verifique se a configuração está correta e escolha **Create alarm** (Criar alarme).
## Excluir um alarme de faturamento
É possível excluir seu alarme de faturamento quando não precisar mais dele.
**Para excluir um alarme de faturamento**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Se necessário, altere a região para US East (N. Virginia) (Leste dos EUA (Norte da Virgínia)). Os dados da métrica de faturamento são armazenados nessa região e refletem os custos em todo o mundo.
1. No painel de navegação, selecione **Alarmes**, **Todos os alarmes**.
1. Marque a caixa de seleção ao lado do alarme e escolha **Actions (Ações)**, **Delete (Excluir)**.
1. Quando a confirmação for solicitada, escolha **Sim, excluir**.
# Criar um alarme de utilização de CPU
É possível criar um alarme do CloudWatch que envia uma notificação usando o Amazon SNS quando o alarme muda do estado `OK` para `ALARM`.
O alarme muda para o estado `ALARM` quando o uso médio da CPU de uma instância do EC2 ultrapassa um limite especificado por períodos consecutivos especificados.
## Configurar um alarme de uso da CPU usando o Console de gerenciamento da AWS
Use estas etapas da Console de gerenciamento da AWS para criar um alarme de utilização de CPU.
**Como criar um alarme baseado no uso da CPU**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Selecionar métrica**.
1. Na guia **Todas as métricas**, escolha **Métricas do EC2**.
1. Escolha uma categoria da métrica (por exemplo, **Métricas por instância**).
1. Localize a linha com a instância que deseja listar na coluna **InstanceId** e **CPUUtilization** na coluna **Nome da métrica**. Marque a caixa de seleção ao lado dessa linha e escolha **Selecionar métrica**.
1. Em **Especificar métrica e condições**, em **Estatística**, escolha **Média** e selecione um dos percentis predefinidos ou especifique um percentil personalizado (por exemplo, **p95.45**).
1. Escolha um período (por exemplo, **5 minutes**).
1. Em **Conditions (Condições)**, especifique o seguinte:
1. Em **Tipo de limite**, escolha **Estático**.
1. Em **Sempre que CPUUtilization for**, especifique **Maior**. Em **que...**, especifique o limite que deve acionar o alarme para ir para o estado ALARM se a utilização da CPU exceder essa porcentagem. Por exemplo, 70.
1. Escolha **Additional configuration (Configuração adicional)**. Em **Datapoints to alarm (Pontos de dados para alarme)**, especifique quantos períodos de avaliação (pontos de dados) devem estar no estado `ALARM` para disparar o alarme. Se os dois valores forem correspondentes, você criará um alarme que passa para o estado `ALARM` se esses períodos consecutivos estiverem violando.
Para criar um alarme M de N, especifique um número menor para o primeiro valor que especificar para o segundo valor. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
1. Para o **Missing data treatment (Tratamento de dados ausentes)**, escolha como deseja que o alarme se comporte quando alguns pontos de dados estiverem ausentes. Para obter mais informações, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
1. Se o alarme usar um percentil como estatística monitorada, uma caixa **Percentiles with low samples (Percentis com amostras baixas)** será exibida. Use-a para escolher se deseja avaliar ou ignorar casos com taxas de amostra baixas. Se você escolher **ignore (maintain the alarm state) (ignorar (manter o estado do alarme))**, o estado do alarme atual será sempre mantido quando o tamanho da amostra for muito baixo. Para obter mais informações, consulte [Alarmes baseados em percentil e exemplos de poucos dados](percentiles-with-low-samples.md).
1. Escolha **Próximo**.
1. Em **Notificação**, escolha **Em alarme** e selecione um tópico do SNS para notificar quando o alarme estiver no estado `ALARM`
Para que o alarme envie várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification (Adicionar notificação)**.
Para que o alarme não envie notificações, escolha **Remove (Remover)**.
1. Quando terminar, escolha **Next** (Próximo).
1. Digite um nome e uma descrição para o alarme. Escolha **Próximo**.
O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Em **Preview and create (Visualizar e criar)**, confirme se as informações e condições são o que você deseja e escolha **Create alarm (Criar alarme)**.
## Configurar um alarme de uso da CPU usando o AWS CLI
Use estas etapas da AWS CLI para criar um alarme de utilização de CPU.
**Como criar um alarme baseado no uso da CPU**
1. Configure um tópico do SNS. Para obter mais informações, consulte [Configurar notificações do Amazon SNS](Notify_Users_Alarm_Changes.md#US_SetupSNS).
1. Crie um alarme usando o comando [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) da seguinte forma.
```
aws cloudwatch put-metric-alarm --alarm-name cpu-mon --alarm-description "Alarm when CPU exceeds 70%" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 70 --comparison-operator GreaterThanThreshold --dimensions Name=InstanceId,Value=i-12345678 --evaluation-periods 2 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Percent
```
1. Teste o alarme forçando uma alteração de estado com o comando [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html).
1. Altere o estado do alarme de `INSUFFICIENT_DATA` para `OK`.
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value OK
```
1. Altere o estado do alarme de `OK` para `ALARM`.
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value ALARM
```
1. Verifique se você recebeu uma notificação sobre o alarme.
# Criar um alarme de latência do balanceador de carga que envie um email
É possível configurar uma notificação do Amazon SNS e um alarme que monitore a latência que exceda 100 ms para Classic Load Balancer.
## Configurar um alarme de latência usando o Console de gerenciamento da AWS
Use estas etapas para usar a Console de gerenciamento da AWS para criar um alarme de latência de load balancer.
**Criar um alarme de latência de balanceador de carga**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Em **Métricas do CloudWatch por categoria**, selecione a categoria **Métricas do ELB**.
1. Selecione a linha com o Classic Load Balancer e a métrica **Latency** (Latência).
1. Para a estatística, escolha **Average (Média)**, escolha um dos percentis predefinidos ou especifique um percentil personalizado (por exemplo, **p95.45**).
1. Para o período, escolha **1 Minute (1 minuto)**.
1. Escolha **Próximo**.
1. Em **Alarm Threshold (Limite do alarme)**, insira um nome exclusivo para o alarme (por exemplo, **myHighCpuAlarm**) e uma descrição do alarme (por exemplo, **Alarm when Latency exceeds 100s**). Os nomes dos alarmes devem conter somente caracteres UTF-8 da e não podem conter caracteres de controle ASCII
O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Em **Whenever (Sempre que)**, em **is (é)**, escolha **>** e insira **0.1**. Em **for (para)**, insira **3**.
1. Em **Additional settings (Configurações adicionais)**, em **Treat missing data as (Tratar dados ausentes como)**, escolha **ignore (maintain alarm state) (ignorar (manter estado do alarme))** para que os pontos de dados ausentes não acionem mudanças do estado do alarme.
Em **Percentiles with low samples** (Percentis com amostras baixas), escolha **ignore (maintain the alarm state)** (ignorar [manter estado do alarme]) para que o alarme só avalie situações com números adequados de amostras de dados.
1. Em **Actions** (Ações), em **Whenever this alarm** (Sempre que este alarme), escolha **State is ALARM** (Estado é ALARME). Em **Enviar notificação para**, escolha um tópico do SNS existente ou crie um novo.
Para criar um tópico do SNS, escolha **New list (Nova lista)**. Em **Send notification to (Enviar notificação para)**, insira um nome para o tópico do SNS (por exemplo, **myHighCpuAlarm**). Em **Email list (Lista de e-mails)**, insira uma lista de endereços de e-mail separados por vírgulas a serem notificados quando o alarme mudar para o estado `ALARM`. Para cada endereço de e-mail será enviado um e-mail de confirmação da inscrição no tópico. Você deve confirmar a inscrição para que as notificações sejam enviadas.
1. Escolha **Criar Alarm**.
## Configurar um alarme de latência usando o AWS CLI
Use estas etapas para usar a AWS CLI para criar um alarme de latência de load balancer.
**Criar um alarme de latência de balanceador de carga**
1. Configure um tópico do SNS. Para obter mais informações, consulte [Configurar notificações do Amazon SNS](Notify_Users_Alarm_Changes.md#US_SetupSNS).
1. Crie o alarme usando o comando [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) da seguinte forma:
```
1. aws cloudwatch put-metric-alarm --alarm-name lb-mon --alarm-description "Alarm when Latency exceeds 100s" --metric-name Latency --namespace AWS/ELB --statistic Average --period 60 --threshold 100 --comparison-operator GreaterThanThreshold --dimensions Name=LoadBalancerName,Value=my-server --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Seconds
```
1. Teste o alarme forçando uma alteração de estado com o comando [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html).
1. Altere o estado do alarme de `INSUFFICIENT_DATA` para `OK`.
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value OK
```
1. Altere o estado do alarme de `OK` para `ALARM`.
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value ALARM
```
1. Verifique se você recebeu uma notificação por e-mail sobre o alarme.
# Criar um alarme de throughput de armazenamento que envie emails
É possível configurar uma notificação do SNS e um alarme que é acionado quando o Amazon EBS excede a throughput de 100 MB.
## Configurar um alarme de throughput de armazenamento usando o Console de gerenciamento da AWS
Realize estas etapas para usar o Console de gerenciamento da AWS para criar um alarme baseado na throughput do Amazon EBS.
**Para criar um alarme de throughput de armazenamento**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes), **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Em **Métricas do EBS**, escolha uma categoria de métrica.
1. Selecione a linha com o volume e a métrica **VolumeWriteBytes**.
1. Para a estatística, escolha **Média**. Para o período, escolha **5 minutos**. Escolha **Próximo**.
1. Em **Alarm Threshold (Limite do alarme)**, insira um nome exclusivo para o alarme (por exemplo, **myHighWriteAlarm**) e uma descrição do alarme (por exemplo, **VolumeWriteBytes exceeds 100,000 KiB/s**). O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Em **Whenever (Sempre que)**, em **is (é)**, escolha **>** e insira **100000**. Em **for (para)**, insira **15** períodos consecutivos.
Uma representação gráfica do limite será exibida em **Alarm Preview (Visualização do alarme)**.
1. Em **Additional settings (Configurações adicionais)**, em **Treat missing data as (Tratar dados ausentes como)**, escolha **ignore (maintain alarm state) (ignorar (manter estado do alarme))** para que os pontos de dados ausentes não acionem mudanças do estado do alarme.
1. Em **Actions** (Ações), em **Whenever this alarm** (Sempre que este alarme), escolha **State is ALARM** (Estado é ALARME). Em **Enviar notificação para**, escolha um tópico do SNS existente ou crie um.
Para criar um tópico do SNS, escolha **New list (Nova lista)**. Em **Send notification to (Enviar notificação para)**, insira um nome para o tópico do SNS (por exemplo, **myHighCpuAlarm**). Em **Email list (Lista de e-mails)**, insira uma lista de endereços de e-mail separados por vírgulas a serem notificados quando o alarme mudar para o estado `ALARM`. Para cada endereço de e-mail será enviado um e-mail de confirmação da inscrição no tópico. Você deve confirmar a assinatura para que as notificações sejam enviadas para um endereço de e-mail.
1. Escolha **Criar Alarm**.
## Configurar um alarme de throughput de armazenamento usando o AWS CLI
Realize estas etapas para usar o AWS CLI para criar um alarme baseado na throughput do Amazon EBS.
**Para criar um alarme de throughput de armazenamento**
1. Criar um tópico do SNS. Para obter mais informações, consulte [Configurar notificações do Amazon SNS](Notify_Users_Alarm_Changes.md#US_SetupSNS).
1. Crie o alarme.
```
1. aws cloudwatch put-metric-alarm --alarm-name ebs-mon --alarm-description "Alarm when EBS volume exceeds 100MB throughput" --metric-name VolumeReadBytes --namespace AWS/EBS --statistic Average --period 300 --threshold 100000000 --comparison-operator GreaterThanThreshold --dimensions Name=VolumeId,Value=my-volume-id --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-alarm-topic --insufficient-data-actions arn:aws:sns:us-east-1:111122223333:my-insufficient-data-topic
```
1. Teste o alarme forçando uma alteração de estado com o comando [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html).
1. Altere o estado do alarme de `INSUFFICIENT_DATA` para `OK`.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value OK
```
1. Altere o estado do alarme de `OK` para `ALARM`.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value ALARM
```
1. Altere o estado do alarme de `ALARM` para `INSUFFICIENT_DATA`.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value INSUFFICIENT_DATA
```
1. Verifique se você recebeu uma notificação por e-mail sobre o alarme.
# Crie um alarme para as métricas do contador do Performance Insights a partir de um banco de dados da AWS
O CloudWatch inclui uma função matemática métrica **DB\$1PERF\$1INSIGHTS** que pode ser usada para trazer métricas de contador do Performance Insights para o CloudWatch a partir do Amazon Relational Database Service e do Amazon DocumentDB (compativel com MongoDB). **DB\$1PERF\$1INSIGHTS** também traz a métrica `DBLoad` em intervalos inferiores a um minuto. Também é possível usar definir alarmes do CloudWatch para essas métricas.
Para obter mais informações sobre o Insights de Performance do Amazon RDS, consulte [Monitoramento de carga de banco de dados com o Insights de Performance no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
Para obter mais informações sobre o Insights de Performance do Amazon DocumentDB, consulte [Monitoramento com o Insights de Performance](https://docs.aws.amazon.com/documentdb/latest/developerguide/performance-insights.html.html).
Não há suporte para a detecção de anomalias para alarmes baseados na função **DB\$1PERF\$1INSIGHTS**.
**nota**
Métricas de alta resolução com granularidade de menos de um minuto recuperadas pelo **DB\$1PERF\$1INSIGHTS** são aplicáveis somente à métrica **DBLoad** ou às métricas do sistema operacional caso você tenha ativado o monitoramento aprimorado em uma resolução maior. Para obter mais informações sobre o monitoramento avançado do Amazon RDS, consulte [Monitoramento de métricas do SO com monitoramento avançado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html).
É possível criar um alarme de alta resolução usando a função **DB\$1PERF\$1INSIGHTS**. Três horas é o intervalo máximo de avaliação para um alarme de alta resolução. É possível usar o console do CloudWatch para representar graficamente as métricas recuperadas com a função **DB\$1PERF\$1INSIGHTS** para qualquer intervalo de tempo.
**Para criar um alarme com base nas métricas do Insights de Performance**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Alarms** (Alarmes) e depois escolha **All alarms** (Todos os alarmes).
1. Selecione **Criar alarme**.
1. Escolha **Select metric** (Selecionar métrica).
1. Escolha o menu suspenso **Adicionar matemática** e, em seguida, selecione **Todas as funções**, **DB\$1PERF\$1INSIGHTS** na lista.
Depois de escolher **DB\$1PERF\$1INSIGHTS**, uma caixa de expressão matemática aparecerá onde você aplica ou edita expressões matemáticas.
1. Na caixa de expressão matemática, insira sua expressão matemática **DB\$1PERF\$1INSIGHTS** e, em seguida, escolha **Aplicar**.
Por exemplo, ., **DB\$1PERF\$1INSIGHTS(‘RDS’, ‘db-ABCDEFGHIJKLMNOPQRSTUVWXY1’, ‘os.cpuUtilization.user.avg’)**
**Importante**
Ao usar a expressão matemática **DB\$1PERF\$1INSIGHTS**, você deve especificar o ID de recurso exclusivo do banco de dados para o banco de dados. Isso é diferente do identificador do banco de dados. Para encontrar o ID de recurso do banco de dados no console do Amazon RDS, escolha a instância de banco de dados para visualizar os detalhes. Em seguida, escolha a guia **Configuration (Configuração)**. O **ID de recurso** é exibido na seção **Configuração**.
Para obter informações sobre a função **DB\$1PERF\$1INSIGHTS** e outras funções disponíveis para matemática de métrica, consulte [Sintaxe de funções da matemática métricas](using-metric-math.md#metric-math-syntax).
1. Escolha **Selecionar métrica**.
A página **Specify metric and conditions (Especificar métrica e condições)** será exibida, mostrando um gráfico e outras informações sobre a expressão matemática que você selecionou.
1. Em **Whenever *expression* is (Sempre que a expressão for)**, especifique se a expressão deverá ser maior que, menor que ou igual ao limite. Em **than... (que...)**, especifique o valor limite.
1. Escolha **Additional configuration (Configuração adicional)**. Em **Datapoints to alarm (Pontos de dados para alarme)**, especifique quantos períodos de avaliação (pontos de dados) devem estar no estado `ALARM` para disparar o alarme. Se os dois valores forem correspondentes, você criará um alarme que passa para o estado `ALARM` se esses períodos consecutivos estiverem violando.
Para criar um alarme M de N, especifique um número menor para o primeiro valor que especificar para o segundo valor. Para obter mais informações, consulte [Avaliação de alarme](alarm-evaluation.md).
1. Para o **Missing data treatment (Tratamento de dados ausentes)**, escolha como deseja que o alarme se comporte quando alguns pontos de dados estiverem ausentes. Para obter mais informações, consulte [Configurar como os alarmes do CloudWatch tratam dados ausentes](alarms-and-missing-data.md).
1. Escolha **Próximo**.
1. Em **Notification (Notificação)**, selecione um tópico do SNS para notificar quando o alarme estiver no estado `ALARM`, `OK` ou `INSUFFICIENT_DATA`.
Para que o alarme envie várias notificações para o mesmo estado de alarme ou para diferentes estados de alarme, escolha **Add notification (Adicionar notificação)**.
Para que o alarme não envie notificações, escolha **Remove (Remover)**.
1. Para que o alarme execute ações do Auto Scaling, EC2, Lambda ou Systems Manager, escolha o botão apropriado e selecione o estado do alarme e a ação a ser executada. Se você escolher uma função do Lambda como uma ação de alarme, especifique o nome da função ou o ARN e, opcionalmente, você poderá escolher uma versão específica da função.
Os alarmes só poderão executar ações do Systems Manager ao entrarem no estado ALARM. Para obter mais informações sobre ações do Systems Manager, consulte [Configurar o CloudWatch para criar OpsItems a partir de alarmes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e [Criação de incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**nota**
Para criar um alarme que executa uma ação do SSM Incident Manager, é necessário ter determinadas permissões. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade para o AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Quando terminar, escolha **Next** (Próximo).
1. Digite um nome e uma descrição para o alarme. Escolha **Próximo**.
O nome deve conter somente caracteres UTF-8, e não poderá conter caracteres de controle ASCII. A descrição pode incluir a formatação de markdown, que é exibida somente na guia **Detalhes** do alarme no console do CloudWatch. O markdown pode ser útil para adicionar links para runbooks ou outros recursos internos.
1. Em **Preview and create (Visualizar e criar)**, confirme se as informações e condições são o que você deseja e escolha **Create alarm (Criar alarme)**.