Uma aplicação é executada em instâncias EC2 atrás de um Application Load Balancer (ALB) em um grupo do Auto Scaling. A aplicação começa a produzir erros sempre que o total de requisições excede 100 requisições por segundo. O administrador precisa coletar o total de requisições durante um período de duas semanas para descobrir quando o limite foi excedido. Qual é a maneira apropriada de coletar esses dados?

A métrica RequestCount do Application Load Balancer (ALB) no CloudWatch é a solução mais direta e apropriada. Ela já agrega o total de requisições que passam pelo ALB, que é o ponto de entrada para a aplicação e onde o limite de 100 requisições por segundo é excedido. Definir o intervalo de tempo para duas semanas e o período para 1 minuto permite uma análise granular dos picos de requisição. As outras opções são menos eficientes ou incorretas: Somar métricas de requisições por instância via CloudWatch Metric Math é desnecessário, pois o ALB já fornece a métrica agregada. Além disso, não é garantido que cada instância tenha uma métrica de requisição individual que possa ser somada de forma precisa para representar o tráfego total do ALB. Adicionar métricas personalizadas na configuração de inicialização do EC2 é uma abordagem mais complexa e que exigiria desenvolvimento adicional para coletar e enviar esses dados, quando a métrica já existe. Criar uma regra do EventBridge para eventos do EC2 não é a ferramenta correta para coletar métricas de requisição de forma contínua e agregada. O EventBridge é mais adequado para rotear eventos entre serviços, não para monitoramento de métricas em tempo real.