Métricas aprimoradas do Amazon CloudWatch para o Amazon EventBridge

Este post foi escrito por Vaibhav Shah, arquiteto de soluções sênior

Os clientes usam arquiteturas orientada a eventos para orquestrar e automatizar seus fluxos de eventos, de produtores aos consumidores. O Amazon EventBridge atua como um roteador de eventos Serverless para vários destinos com base em regras. Ele separa produtores e consumidores, permitindo que os clientes criem arquiteturas assíncronas.

O EventBridge fornece métricas para permitir que você monitore seus eventos. Algumas das métricas incluem: monitorar o número de eventos de parceiros ingeridos, o número de invocações que falharam permanentemente e o número de vezes que um destino é invocado por uma regra em resposta a um evento ou o número de eventos que corresponderam a qualquer regra.

Em resposta às solicitações dos clientes, o EventBridge adicionou métricas adicionais que permite os clientes a monitorar seus eventos e fornecer visibilidade adicional. Este blog post explica essas novas métricas.

O que há de novo?

O EventBridge tem novas métricas principalmente relacionadas às métricas de API, eventos e invocações. Essas métricas fornecem informações sobre o número total de eventos publicados, eventos publicados que foram bem-sucedidos, eventos com falha, número de eventos correspondentes a qualquer regra específica, eventos rejeitados devido à limitação (throttling), latência e métricas baseadas em invocações.

Isso permite que você acompanhe toda a extensão do fluxo de eventos no EventBridge e identifique e resolva problemas rapidamente à medida que eles surgirem.

O EventBridge agora tem as seguintes métricas:

Casos de uso dessas métricas

Essas novas métricas ajudam você a melhorar a observabilidade e o monitoramento de seus aplicativos orientados a eventos. Você pode monitorar proativamente as métricas que ajudam a entender o fluxo de eventos, as invocações, a latência e a utilização do serviço. Você também pode configurar alertas sobre métricas específicas e tomar as medidas necessárias, que ajudam a melhorar o desempenho do seu aplicativo, gerenciar proativamente as cotas e melhorar a resiliência.

Monitore o uso do serviço com base nas cotas de serviço

A métrica putEventsApproximateCallCount da família de eventos ajuda a identificar o número aproximado de eventos publicados no barramento de eventos usando a ação da API PutEvents. A métrica putEventsApproximateSuccessfulCount mostra o número aproximado de eventos bem-sucedidos publicados no barramento de eventos.

Da mesma forma, você pode monitorar a contagem de eventos limitados (throttled) e com falha utilizando as métricas putEventsApproximateThrottledCount e putEventsApproximateFailedCount, respectivamente. Essas métricas permitem monitorar se você está atingindo sua cota para PutEvents. Você pode usar um alarme do CloudWatch e definir um limite próximo às cotas da sua conta. Se for acionado, envie notificações usando o Amazon SNS para sua equipe de operações. Eles podem trabalhar para aumentar as cotas de serviço.

Você também pode definir um alarme sobre o limite (throttled) do PutEvents na cota de serviço de transações por segundo.

1. Navegue até o console Service Quotas. No painel esquerdo, escolha os serviços da AWS, pesquise por EventBridge e selecione Amazon EventBridge (CloudWatch Events).
2. Na seção Monitoramento, você pode monitorar a porcentagem de utilização do limite (throttled) do PutEvents em transações por segundo.
   
3. Vá para a guia Alarm e escolha Create alarm. Em Alarm threshold, escolha 80% do valor da cota aplicada na lista suspensa. Defina o nome do alarme (Alarm name) como PutEventsThrottleAlarm e escolha Create.
   
4. Para ser notificado se esse limite for violado, navegue até o  Amazon CloudWatch Alarms console e escolha PutEventsThrottleAlarm.
5. Selecione o menu suspenso Actions no canto superior direito e clique em Edit.
6. Na página Specify metric and conditions, em Conditions, certifique-se de que o tipo de Threshold (Limite) esteja selecionado como Static e a % de Utilização selecionada como Greater/Equal (Maior/Igual) a 80. Selecione Next.
   
7. Configure ações para enviar notificações para um tópico do Amazon SNS e escolha Next.
   
8. O nome do alarme já deve estar definido como putEventsThrottleAlarm. Escolha Next e, em seguida, selecione Update alarm.
   

Isso ajuda você a ser notificado quando a porcentagem de utilização do limite do PutEvents em transações por segundo chegar perto do limite definido. Em seguida, você pode solicitar aumentos de cota de serviço, se necessário.

Da mesma forma, você também pode criar alarmes do CloudWatch sobre a porcentagem de utilização do limite de throttle das invocações em transações por segundo em relação à cota de serviço.

Observabilidade aprimorada

A métrica putEventsLatency mostra o tempo gasto por operação da API PutEvents. Há duas métricas adicionais, a métrica ingestionToInvocationStartLatency e a métrica ingestionToInvocationCompleteLatency. A primeira métrica mostra o tempo de processamento de eventos medido desde o momento em que os eventos são ingeridos pela primeira vez pelo EventBridge até a primeira invocação de um destino. A segunda mostra o tempo gasto desde a ingestão do evento até a conclusão da primeira tentativa de invocação bem-sucedida.

Isso ajuda a identificar problemas relacionados à latência desde o momento da ingestão até o momento em que atinge a meta com base no RuleName. Se houver alta latência, essas duas métricas darão visibilidade sobre esse problema, permitindo que você tome as medidas apropriadas.

Você pode definir um limite em torno dessas métricas e, se o limite for atingido, as ações definidas poderão ajudar na recuperação de possíveis falhas. Uma das ações definidas aqui pode ser enviar eventos gerados posteriormente para o EventBridge na região secundária usando endpoints globais do EventBridge.

Às vezes, os eventos não são entregues ao alvo especificado na regra. Isso pode ocorrer porque o recurso de destino não está disponível, você não tem permissão para invocar o destino ou há problemas de rede. Nesses cenários, o EventBridge tenta enviar novamente esses eventos ao destino por 24 horas ou até 185 vezes, sendo que esses valores são configuráveis.

A nova métrica RetryInvocationAttempts mostra o número de vezes que o EventBridge tentou invocar novamente o destino. As novas tentativas são feitas quando as solicitações são limitadas (throttled), o serviço de destino tem problemas de disponibilidade, problemas de rede e falhas no serviço. Isso fornece observabilidade adicional aos clientes e pode ser usado para acionar um alarme do CloudWatch para notificar as equipes se o limite desejado for ultrapassado. Se as novas tentativas estiverem esgotadas, armazene os eventos com falha nas filas de mensagens mortas do Amazon SQS para processar os eventos com falha posteriormente.

Além disso, o EventBridge oferece suporte a dimensões adicionais, como DetailType, Source e RuleName, às métricas de MatchedEvents. Isso ajuda você a monitorar o número de eventos correspondentes provenientes de diferentes fontes.

1. Navegue até o Amazon CloudWatch. No painel esquerdo, escolha Metrics e All metrics.
2. Na seção Browse, selecione Events e Source.
3. Na guia Graphed metrics, você pode monitorar eventos correspondentes provenientes de diferentes fontes.

Eventos de failover para a região secundária

A métrica putEventsFailedEntriesCount mostra o número de eventos que falharam na ingestão. Monitore essa métrica e defina um alarme do CloudWatch. Se ele ultrapassar um limite definido, você poderá tomar as medidas apropriadas.

Além disso, defina um alarme na métrica PutEventsApproximateThrottledCount, que mostra o número de eventos que são rejeitados devido às restrições de throttling. Para essas falhas de ingestão de eventos, o cliente deve reenviar os eventos com falha para o barramento de eventos novamente, permitindo que você processe cada evento crítico para seu aplicativo.

Como alternativa, envie eventos para o serviço EventBridge na região secundária usando endpoints globais do Amazon EventBridge para melhorar a resiliência de seus aplicativos orientados a eventos.

Conclusão

Este blog mostra como usar essas novas métricas para melhorar a visibilidade dos fluxos de eventos em seus aplicativos orientados a eventos. Ele ajuda você a monitorar os eventos com mais eficiência, desde a invocação até a entrega ao destino. Isso melhora a observabilidade ao alertar proativamente sobre as principais métricas.

Para obter mais recursos de aprendizado serverless, visite Serverless Land.

Este conteúdo é uma tradução do blog original em inglês, o qual pode ser acessado aqui.

Sobre o autor

Vaibhav Shah é arquiteto sênior de soluções.

Tradutora

Letícia Dornelas tem mais de 10 anos de atuação na área de tecnologia. Atualmente, ela desempenha o cargo de Arquiteta de Soluções na AWS, onde apoia clientes do setor de saúde. Formada pelo IFSP, tem interesse especial por temas como Machine Learning, Arquitetura Orientada a Eventos e Serverless.