Como em qualquer comunicação de interrupção, um leitor não técnico procurará principalmente entender:
- Quanto tempo durou?
- Quão ruim foi?
As métricas do Amazon CloudWatch fornecem as seguintes métricas para filas SQS que podem ajudar a responder a estas perguntas:
- NumberOfMessagesSent: o número de mensagens adicionadas a uma fila.
- NumberOfMessagesReceived: o número de mensagens retornadas por chamadas para a ação da API ReceiveMessage.
- ApproximateNumberOfMessagesVisible: O número de mensagens disponíveis para recuperação da fila.
Quando representadas corretamente, essas métricas podem ser auxiliares visuais poderosos na descrição de atrasos no processamento da fila. Aqui estão alguns exemplos de uma interrupção que experimentei em que a capacidade da tarefa de processar mensagens da fila foi severamente degradada:
NumberOfMessagesSent & NumberOfMessagesReceived
- Tipo de gráfico: Gráfico de linhas
- Estatística: Soma
- Período: 5 minutos
Isso representa graficamente o contraste entre as mensagens enviadas e recebidas, o que ajuda a isolar qual componente de processamento é responsável pelo atraso. Neste gráfico, a métrica recebida cai drasticamente enquanto a métrica enviada continua em sua tendência normal, portanto, podemos inferir que o problema está no componente de leitura da fila em vez do componente de gravação da fila.
Isso responde quanto tempo / quão ruim foi o evento? Sim; descreve processos impactados ao longo do tempo.
NumberOfMessagesReceived & ApproximateNumberOfMessagesVisible
- Tipo de gráfico: Gráfico de área empilhada
- Estatística: Soma
- Período: 5 minutos
Isso representa um gráfico da profundidade da fila sobre as mensagens recebidas, o que ajuda a mostrar até que ponto a fila fez backup e como se recuperou. Neste gráfico, podemos ver que a profundidade da fila fez um backup dramático enquanto o componente de leitura da fila estava com problemas e começou a se recuperar quando o componente de leitura da fila começou a ler as mensagens novamente.
Isso responde quanto tempo / quão ruim foi o evento? Sim; descreve mensagens impactadas ao longo do tempo.
Discussão gráfica
Nos dois gráficos, o processamento da fila geralmente pode ser considerado íntegro quando as linhas se sobrepõem e não íntegro quando as linhas divergem. Esse é um padrão fácil de ensinar a um membro da equipe não técnico e pode ajudá-lo a disseminar rapidamente onde e como há problemas quando apresentados com esses gráficos.
Para comunicar ainda mais pontos específicos nos gráficos, você pode simplesmente anotá-los:
Dicas gráficas:
- Rotular unidades e eixos.
- Use cores consistentes para combinar métricas entre gráficos. Observe que NumberOfMessagesReceived é laranja nos dois gráficos; isso ajudará a visualizar a mesma métrica em gráficos diferentes.
- Alinhe verticalmente os gráficos que descrevem métricas semelhantes para facilitar a comparação ao longo do tempo.
Nota: Formatei esses gráficos para apresentação no StackExchange, portanto, não são necessariamente como os apresentaria em uma interrupção post mortem. Eu removi explicitamente os valores do eixo esquerdo aqui para ocultá-los do StackExchange; convém mantê-los em seus post-mortems.
Dicas adicionais
- Capacite sua equipe: depois de treinar os membros da equipe para ler esses gráficos, não há motivo para mantê-los escondidos. Considere a possibilidade de configurar um painel do CloudWatch e conceder aos membros da equipe não técnica acesso IAM somente leitura ao CloudWatch , para que eles possam visualizar esses gráficos a qualquer momento.
- Configurar notificações: considere configurar os Alarmes do Cloudwatch com base na métrica ApproximateNumberOfMessagesVisible se exceder algum valor alto acordado e inscreva os membros da equipe para notificá-los sobre possíveis problemas. Os Alarmes do Cloudwatch têm campos de descrição que são enviados junto com os e-mails de notificação - inclua uma descrição legível por humanos para ajudar seus membros não técnicos a disseminar o alarme.
- Explore outros dados: de acordo com o comentário de Evgeny , explore outros dados além do que o CloudWatch fornece e pense em como você pode transmitir esses dados para sua equipe. Seu exemplo de uso da vida útil da mensagem na fila para criar um histograma é um ótimo exemplo desse pensamento criativo e pode ser realizado registrando os horários de envio e recebimento de mensagens em seu aplicativo. Você pode obter a mensagem Timestamp Enviado por meio do Atributo SentTimeStamp em cada mensagem da fila da resposta da API ReceiveMessage. Mais detalhes aqui .