Melhores Práticas para Seus Alarmes

Para cada métrica emitida pelos recursos, crie alarmes que definem os seguintes comportamentos de recursos:

• Em risco. O recurso corre o risco de se tornar inoperante, conforme indicado pelos valores da métrica.
• Não ideal. O recurso está sendo executado em níveis não ideais, conforme indicado pelos valores da métrica.
• O recurso está ativo ou inativo. O recurso não está acessível ou não está em operação.

Os exemplos a seguir usam a métrica CpuUtilization emitida pelo namespace de métricas oci_computeagent. Esta métrica monitora a utilização da instância de computação e o nível de atividade de quaisquer serviços e aplicativos em execução na instância. CpuUtilization é uma métrica de desempenho chave para um serviço de nuvem porque ele indica o uso da CPU da instância de computação e pode ser usado para investigar problemas de desempenho. Para saber mais sobre o uso da CPU, consulte o seguinte URL: https://en.wikipedia.org/wiki/CPU_time.

Exemplo de At-Risk

Um limite de risco típico para a métrica CpuUtilization é qualquer valor superior a 80%. Uma instância de computação que ultrapasse esse limite corre o risco de se tornar inoperante. Geralmente, a causa desse comportamento é um ou mais aplicativos que consomem uma alta porcentagem da CPU.

Neste exemplo, você decide notificar a equipe de operações imediatamente, definindo a gravidade do alarme como "Crítico", pois é necessário reparo para trazer as instâncias de volta aos níveis operacionais ideais. Você configura notificações de alarme para a equipe responsável pelo PagerDuty e por e-mail, solicitando uma investigação e correções apropriadas antes que as instâncias entrem em um estado inoperante. Você define notificações repetidas a cada minuto. Quando alguém responde às notificações de alarme, você interrompe temporariamente as notificações usando a melhor prática para suprimir o alarme. Quando as métricas retornam aos valores ideais, você remove a supressão.

NonOptimal Exemplo

Um limite não ideal típico para a métrica CpuUtilization está de 60 a 80%. Quando os valores de métrica de uma instância de computação estão dentro dessa faixa, a instância excede a faixa operacional ideal.

Neste exemplo, você decide notificar o indivíduo ou a equipe apropriada de que um aplicativo ou processo está consumindo mais CPU do que o habitual. Você configura um alarme de limite para notificar os contatos apropriados, definindo a gravidade do alarme como "Advertência", pois nenhuma ação imediata é necessária para investigar e reduzir a CPU. Defina a notificação somente para e-mail, direcionada para o desenvolvedor ou equipe apropriada, com notificações repetidas a cada 24 horas para reduzir o ruído de notificação por e-mail.

Exemplo de Recurso Ativo ou Inativo

Um indicador típico de disponibilidade de recursos é uma ausência de cinco minutos da métrica CpuUtilization. Uma instância de computação que está ultrapassando esse limite não está acessível ou não está funcionando. O recurso pode ter parado de responder ou pode ter se tornado indisponível em decorrência de problemas de conectividade.

Neste exemplo, você decide notificar a equipe de operações imediatamente, definindo a gravidade do alarme de ausência como "Crítico", pois é necessário reparo para colocar as instâncias on-line. Você configura notificações de alarme para a equipe responsável pelo PagerDuty e por e-mail, solicitando uma investigação e uma movimentação das cargas de trabalho para outro recurso disponível. Você define notificações repetidas a cada minuto. Quando alguém responde às notificações de alarme, você interrompe temporariamente as notificações usando a melhor prática para suprimir o alarme. Quando a métrica CpuUtilization é detectada novamente no recurso, você remove a supressão.

Selecione um intervalo de alarme com base na frequência na qual a métrica é emitida. Por exemplo, uma métrica emitida a cada cinco minutos requer um intervalo de alarme de 5 minutos ou mais. A maioria das métricas é emitida a cada minuto, o que significa que a maioria das métricas suporta qualquer intervalo de alarme. Para determinar intervalos de alarme válidos para uma métrica específica, verifique a referência de métrica do serviço relevante.

Quando um membro da equipe responder a um alarme, suprima as notificações durante o esforço para investigar ou mitigar o problema. A interrupção temporária das notificações ajuda a evitar distrações durante a investigação e atenuação. Remova a supressão quando o problema for resolvido. Para obter instruções, consulte Adicionando uma Supressão de Alarme Específica da Dimensão e Adicionando uma Supressão em Todo o Alarme.

Com uma regularidade, como semanalmente, revise seus alarmes para garantir a configuração ideal. Calibre os detalhes de limite, gravidade e notificação de cada alarme, incluindo método, frequência e público-alvo.

A configuração de alarme ideal aborda os seguintes fatores:

• A importância do recurso.
• O comportamento apropriado de recursos. Avalie o comportamento individualmente e dentro do contexto do ecossistema de serviço. Revise as flutuações de valor de métrica para um período específico e, em seguida, ajuste os limites conforme necessário.
• O ruído de notificação aceitável. Avalie o método de notificação (por exemplo, e-mail ou PagerDuty), os destinatários apropriados e a frequência de notificações repetidas.

A tabela a seguir mostra um exemplo de calibração de alarme.

Para obter instruções, consulte Atualizando um Alarme.