As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Geração de alertas
Os alertas são uma das fontes de informação mais importantes quando se trata de segurança, disponibilidade, performance e confiabilidade de sua infraestrutura e serviços de TI. Eles notificam e informam suas equipes de TI sobre ameaças de segurança contínuas, interrupções, problemas de performance ou falhas no sistema.
A Biblioteca de Infraestrutura de Tecnologia da Informação (ITIL), especificamente as práticas de gerenciamento de serviços de TI (ITSM), define alertas automatizados no ponto focal das práticas recomendadas de monitoramento e gerenciamento de eventos e incidentes.
Os alertas de incidentes ocorrem quando as ferramentas de monitoramento geram alertas para notificar sua equipe e as ferramentas automatizadas (para itens que podem ser acionados automaticamente) sobre mudanças, ações de alto risco ou falhas no ambiente de TI. Os alertas de TI são a primeira linha de defesa contra mudanças ou interrupções do sistema que podem se transformar em incidentes graves. Ao monitorar automaticamente os sistemas e gerar alertas para interrupções e mudanças arriscadas, as equipes de TI podem minimizar o tempo de inatividade e reduzir o alto custo que o acompanha.
[Como melhores práticas, o AWS Well-Architected Framework prescreve que [você use o monitoramento para gerar notificações baseadas em alarmes e monitorar e alarmar](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_monitor_instances_post_launch_generate_alarms.html) proativamente.](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_monitor_instances_post_launch_proactive.html) Use CloudWatch um serviço de monitoramento terceirizado para definir alarmes que indicam quando as métricas estão fora dos limites esperados.
O objetivo do gerenciamento de alertas é estabelecer procedimentos eficientes e padronizados para lidar com eventos e incidentes relacionados à TI por meio de registro em log, classificação, definição e implementação de ações, encerramento e atividades de análise pós-incidentes.
**Seções**
+ [CloudWatch alarmes](cloudwatch-alarms.md)
+ [EventBridge regras](eventbridge-rules.md)
+ [Especificação de ações e habilitação e desabilitação de alarmes](enable-disable-alarms.md)
# CloudWatch alarmes
Ao operar suas instâncias de banco de dados do Amazon RDS, você deseja monitorar e gerar alertas sobre diferentes tipos de métricas, eventos e rastreamentos. Para bancos de dados MySQL e MariaDB, as fontes críticas de informação são [métricas das instâncias do banco de dados](db-instance-monitoring.md), [métricas do sistema operacional](os-monitoring.md), [eventos, logs e trilhas de auditoria](events-logs-audit.md). Recomendamos que você use [CloudWatch alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para observar uma única métrica durante um período especificado por você.
O exemplo a seguir ilustra como você pode definir um alarme que monitora a métrica `CPUUtilization` (porcentagem de utilização da CPU) em todas as suas instâncias de banco de dados Amazon RDS. Você configura o alarme para ser acionado se a utilização da CPU em qualquer instância de banco de dados for maior que 80% durante o período de avaliação de cinco minutos.
![\[Configurando um alarme para a CPUUtilization métrica\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/setting-alarm.png)
Isso significa que o alarme entrará no estado `ALARM` se algum de seus bancos de dados apresentar uma alta utilização da CPU (mais de 80%) por cinco minutos ou mais. O alarme permanecerá no estado `OK` se a CPU ocasionalmente atingir mais de 80% de utilização por um curto período de tempo e, em seguida, cair novamente para abaixo do limite. O grafo a seguir ilustra essa lógica.
![\[Limites e estados dos alarmes\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/thresholds.png)
CloudWatch os alarmes suportam alarmes métricos e compostos.
+ Um *alarme métrico* observa uma única CloudWatch métrica e pode executar expressões matemáticas na métrica. Um alarme de métrica pode enviar mensagens para o Amazon SNS, que, por sua vez, pode executar uma ou mais ações com base no valor da métrica relativo a um determinado limite ao longo de vários períodos.
+ Um *alarme composto* é baseado em uma expressão de regra, que avalia os estados de vários alarmes e entra no estado `ALARM` somente se todas as condições da regra são atendidas. Os alarmes compostos são normalmente usados para reduzir o número de alertas desnecessários. Por exemplo, você pode ter um alarme composto que contém vários alarmes de métricas configurados para nunca executar ações. O alarme composto enviará um alerta quando todos os alarmes individuais de métricas no composto já estivessem no estado `ALARM`
CloudWatch os alarmes só podem observar CloudWatch métricas. Se você quiser criar um alarme com base no erro, na consulta lenta ou nos registros gerais, deverá criar CloudWatch métricas a partir dos registros. Você pode realizar isso, conforme discutido anteriormente nas seções [Monitoramento do sistema operacional](os-monitoring.md) e [Eventos, logs e trilhas de auditoria](events-logs-audit.md), usando filtros para [criar métricas de eventos de logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html). Da mesma forma, para alertar sobre métricas de monitoramento aprimorado, você deve criar filtros de métricas CloudWatch a partir dos CloudWatch registros.
# EventBridge regras
Os [eventos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) são entregues à Amazon EventBridge, e você pode usar [EventBridge regras](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) para reagir a esses eventos. Por exemplo, você pode criar EventBridge regras que o notificariam e tomariam uma ação se uma instância de banco de dados específica parasse ou fosse inicializada, conforme mostra a tela a seguir.
![\[EventBridge regras para paradas e inícios de instâncias de banco de dados\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/eventbridge-rules.png)
A regra que detecta o evento `The DB instance has been stopped` tem o ID `RDS-EVENT-0087` do evento do Amazon RDS, então você define a propriedade `Event Pattern` da regra como:
```
{
"source": ["aws.rds"],
"detail-type": ["RDS DB Instance Event"],
"detail": {
"SourceArn": ["arn:aws:rds:eu-west-3:111122223333:db:database-3"],
"EventID": ["RDS-EVENT-0087"]
}
}
```
Essa regra monitora somente a instância `database-3` de banco de dados e o evento `RDS-EVENT-0087`. [Quando EventBridge detecta o evento, ele envia o evento para um recurso ou endpoint, conhecido como alvo.](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) É aqui que você pode especificar a ação que deseja realizar se a instância do Amazon RDS for encerrada. Você pode enviar o evento para vários destinos possíveis, incluindo um tópico do SNS, uma fila do Amazon Simple Queue Service (Amazon SQS) AWS Lambda , uma AWS Systems Manager função, automação, um trabalho AWS Batch , Amazon API Gateway e muitos outros. Por exemplo, você pode criar um tópico do SNS que enviará um e-mail de notificação e SMS e atribuirá esse tópico do SNS como o destino da EventBridge regra. Se a instância de banco de dados do Amazon RDS `database-3` tiver sido interrompida, o Amazon RDS entrega o evento `RDS-EVENT-0087` para EventBridge, onde ele será detectado. EventBridge em seguida, chama o alvo, que é o tópico do SNS. O tópico do SNS está configurado para enviar um e-mail (conforme mostrado na ilustração a seguir) e um SMS.
![\[Configuração do tópico do SNS\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/sns-notification.png)
# Especificação de ações e habilitação e desabilitação de alarmes
Você pode usar um CloudWatch alarme para especificar quais ações o alarme deve tomar quando muda entre os `INSUFFICIENT_DATA` estados `OK``ALARM`, e. CloudWatch tem integração integrada com tópicos do SNS e várias categorias de ações adicionais que não são aplicáveis às métricas do Amazon RDS, como ações do Amazon Elastic Compute Cloud (Amazon EC2) ou ações de grupo do Amazon EC2 Auto Scaling. EventBridge geralmente é usado para escrever regras e definir metas que realizam ações quando o alarme é acionado para as métricas do Amazon RDS. CloudWatch envia eventos para EventBridge toda vez que um CloudWatch alarme muda de estado. Você pode usar esses eventos de mudança de estado de alarme para acionar um destino de evento EventBridge. Para obter mais informações, consulte [Eventos de alarme e EventBridge](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) na CloudWatch documentação.
Você talvez também precise gerenciar alarmes, por exemplo, desabilitar automaticamente um alarme durante testes ou alterações planejadas na configuração e, em seguida, reabilitar o alarme quando a ação planejada terminar. Por exemplo, se você tiver uma atualização planejada e programada do software do banco de dados que exija tempo de inatividade e tiver alarmes que serão ativados se o banco de dados ficar indisponível, você poderá desativar e ativar os alarmes usando as ações da API [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)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)no. AWS CLI Você também pode ver o histórico do alarme no CloudWatch console ou usando a ação da [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html)API ou o [describe-alarm-history](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarm-history.html)comando no AWS CLI. CloudWatch preserva o histórico de alarmes por duas semanas. No CloudWatch console, você pode escolher o menu **Favoritos e recentes** no painel de navegação para definir e acessar seus alarmes favoritos e os mais visitados recentemente.