Um aplicativo móvel envia requisições HTTP para um Application Load Balancer (ALB) que as roteia para uma função AWS Lambda. Múltiplas versões do aplicativo estão em uso e a versão do aplicativo é fornecida no cabeçalho User-Agent. A função Lambda foi modificada para extrair o nome da operação da API, a versão do aplicativo do cabeçalho User-Agent e o código de resposta. Que etapas adicionais o engenheiro de DevOps deve seguir para coletar métricas para cada operação da API por código de resposta e por versão do aplicativo?

A opção correta descreve a abordagem mais eficiente e nativa da AWS para coletar métricas detalhadas. Ao fazer com que a função Lambda grave os dados relevantes (nome da operação da API, código de resposta, versão do aplicativo) como logs no CloudWatch Logs, e então criar um filtro de métricas, é possível extrair e agregar esses dados em métricas personalizadas do CloudWatch. A utilização de dimensões de métrica (código de resposta e versão do aplicativo) permite a granularidade necessária para analisar o desempenho por operação da API, por código de resposta e por versão do aplicativo. As outras opções são menos ideais: Usar o CloudWatch Logs Insights para preencher métricas não é um recurso nativo; o Insights é para análise ad-hoc de logs, não para criação automática de métricas contínuas. Habilitar logs de acesso do ALB e modificar a Lambda para incluir metadados na resposta do ALB não é a forma padrão de coletar métricas detalhadas da execução da Lambda, e a Lambda não controla diretamente os metadados dos logs de acesso do ALB dessa forma. O AWS X-Ray é excelente para rastreamento distribuído e análise de latência, mas não é a ferramenta principal para criar métricas personalizadas agregadas com base em dimensões arbitrárias de logs de aplicação da forma solicitada. Embora possa coletar dados, a criação de métricas personalizadas a partir de logs via filtros de métricas é mais direta para este caso.