Une application mobile envoie des requêtes HTTP à un Application Load Balancer (ALB) qui les achemine vers une fonction AWS Lambda. Plusieurs versions de l'application sont utilisées et la version de l'application est fournie dans l'en-tête User-Agent. La fonction Lambda a été modifiée pour extraire le nom de l'opération d'API, la version de l'application de l'en-tête User-Agent et le code de réponse. Quelles étapes supplémentaires l'ingénieur DevOps doit-il suivre pour collecter des métriques pour chaque opération d'API par code de réponse et par version d'application ?

La bonne approche consiste à utiliser les filtres de métriques CloudWatch Logs. La fonction Lambda peut écrire des journaux structurés contenant les informations nécessaires (nom de l'opération d'API, code de réponse, version de l'application). Un filtre de métriques CloudWatch peut ensuite extraire ces informations des lignes de journal et les publier en tant que métriques CloudWatch personnalisées, en utilisant le code de réponse et la version de l'application comme dimensions. Cela permet une surveillance granulaire et des alertes basées sur ces attributs. L'option CloudWatch Logs Insights est incorrecte car Insights est un outil d'analyse de journaux interactif et non un mécanisme pour alimenter automatiquement des métriques CloudWatch en continu. L'activation des journaux d'accès ALB ne permet pas de capturer directement le code de réponse de la fonction Lambda ni la version de l'application de manière structurée pour les métriques. L'utilisation d'AWS X-Ray est pour le traçage distribué et l'analyse de performance, pas pour la création de métriques personnalisées basées sur des attributs de journaux de cette manière.