Comment utiliser AWS Logs Insights pour interroger les métriques du tableau de bord à partir des journaux des services AWS

Chaque service AWS consigne ses opérations dans des fichiers structurés, regroupés dans des journaux CloudWatch. Ces groupes sont souvent nommés d'après le service lui-même pour faciliter leur identification. Par défaut, ces fichiers contiennent les messages système du service ou les informations d'état courantes.

Cependant, il est possible d'enrichir ces journaux avec des informations personnalisées. Une conception judicieuse de ces journaux peut mener à la création de tableaux de bord CloudWatch très utiles.

Grâce à des métriques et des informations structurées qui détaillent le traitement des tâches, ces journaux peuvent aller au-delà des simples informations système. Il est possible d'y ajouter du contenu personnalisé, agrégé dans des widgets ou métriques définis par l'utilisateur.

Interrogation des fichiers journaux

Source : aws.amazon.com

AWS CloudWatch Log Insights permet d'explorer et d'analyser les données des journaux de vos ressources AWS en temps réel. On peut le considérer comme une interface de base de données. La requête est définie dans le tableau de bord et est exécutée à chaque consultation du tableau de bord ou selon l'intervalle de temps spécifié.

Ce service utilise un langage de requête appelé CloudWatch Logs Insights, qui est un sous-ensemble du langage SQL. Il permet de rechercher et de filtrer les données du journal. Vous pouvez ainsi identifier des événements spécifiques, des textes ou mots-clés, ou filtrer les données en fonction de champs particuliers. De plus, il est possible d'agréger les données de plusieurs fichiers journaux pour générer des métriques et des visualisations résumées.

Lorsqu'une requête est exécutée, CloudWatch Log Insights explore les données du groupe de journaux et retourne les textes des fichiers qui correspondent aux critères spécifiés.

Exemple de requête de fichier journal

Examinons quelques requêtes de base pour illustrer le fonctionnement.

Chaque service enregistre par défaut certaines erreurs critiques. Même sans créer de journal personnalisé dédié à ces erreurs, il est possible de les compter grâce à une requête simple, par exemple pour les erreurs des applications sur la dernière heure :

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)

Voici une requête pour surveiller le temps de réponse moyen d'une API sur la dernière journée :

fields @timestamp, @message
| filter @message like /API response time/
| stats avg(response_time) by bin(1d)

De même, l'utilisation du processeur étant une information enregistrée par défaut dans CloudWatch, il est possible de collecter cette métrique :

fields @timestamp, @message
| filter @message like /CPUUtilization/
| stats avg(value) by bin(1h)

Ces requêtes peuvent être adaptées à des cas d'utilisation spécifiques et intégrées dans des métriques et visualisations personnalisées sur les tableaux de bord CloudWatch. Pour cela, il suffit d'ajouter un widget au tableau de bord et d'y inclure le code de la requête.

Voici quelques types de widgets qui peuvent être utilisés sur les tableaux de bord CloudWatch et alimentés par les données de Log Insights :

• Widgets de texte : affichent des informations textuelles, comme le résultat d'une requête CloudWatch Insights.

• Widgets de requête de journal : présentent les résultats d'une requête CloudWatch Insights, comme le nombre d'erreurs dans les journaux d'application.

Comment optimiser les informations de journal pour les tableaux de bord

Source : aws.amazon.com

Pour exploiter au mieux les requêtes CloudWatch Insights dans les tableaux de bord CloudWatch, il est recommandé d'adopter certaines bonnes pratiques lors de la création des journaux pour chaque service utilisé. Voici quelques conseils :

#1. Adopter une journalisation structurée

Il est important d'utiliser un format de journalisation avec un schéma prédéfini pour enregistrer les données de manière structurée. Cela facilite la recherche et le filtrage des données à l'aide des requêtes CloudWatch Insights.

Cela implique la standardisation des journaux entre les différents services de votre plateforme d'architecture. L'intégration de cette norme dans les pratiques de développement est extrêmement bénéfique.

Par exemple, il est possible de définir qu'un problème lié à une table de base de données sera enregistré avec un message commençant par "[TABLE_NAME] Avertissement/Erreur : ".

Il est également possible de distinguer les tâches de données complètes des tâches de données delta par des préfixes tels que "[FULL/DELTA]" pour filtrer uniquement les messages relatifs à un type de traitement de données spécifique.

De la même manière, le nom du système peut être utilisé comme préfixe pour chaque entrée de journal lors du traitement des données provenant d'une source spécifique. Cela simplifie grandement le filtrage et la création de métriques.

Source : aws.amazon.com

#2. Uniformiser les formats de journaux

Utiliser des formats de journaux uniformes pour toutes vos ressources AWS simplifie la recherche et le filtrage des données à l'aide de requêtes CloudWatch Insights.

Ce point est lié au précédent : plus le format des journaux est standardisé, plus il est facile d'exploiter les données. Les développeurs peuvent alors s'appuyer sur ce format de manière intuitive.

Il est regrettable que de nombreux projets ne suivent aucune norme en matière de journalisation. Pire encore, beaucoup ne créent même aucun journal personnalisé, une pratique surprenante mais fréquente.

Il est étonnant de constater combien de projets fonctionnent sans aucune approche de gestion des erreurs. Et lorsque des mécanismes de gestion d'erreur existent (comme la gestion d'exceptions), ils sont souvent mal mis en œuvre.

Un format de journal cohérent est donc un atout majeur, malheureusement rare.

#3. Inclure les métadonnées pertinentes

Il est essentiel d'inclure des métadonnées telles que les horodatages, les identifiants de ressource et les codes d'erreur pour faciliter la recherche et le filtrage des données de journal à l'aide de requêtes CloudWatch Insights.

#4. Activer la rotation des journaux

L'activation de la rotation des journaux évite l'accumulation excessive de données et facilite la recherche et le filtrage à l'aide de CloudWatch Insights.

L'absence de données de journal est un problème, mais un volume trop important sans structure est tout aussi problématique. Si les données sont inutilisables, c'est comme si elles n'existaient pas.

#5. Utiliser les agents CloudWatch Logs

Si vous ne pouvez ou ne voulez pas créer votre propre système de journalisation personnalisé, utilisez au moins les agents CloudWatch Logs. Ils envoient automatiquement les données de vos ressources AWS vers CloudWatch Logs, ce qui facilite leur analyse à l'aide de requêtes CloudWatch Insights.

Exemples de requêtes Insights plus complexes

Les requêtes CloudWatch Insights peuvent être plus sophistiquées qu'une simple instruction de deux lignes.

fields @timestamp, @message
| filter @message like /ERROR/
| filter @message not like /404/
| parse @message /.*[(?<timestamp>[^]]+)].*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20

Cette requête effectue les opérations suivantes :

• Sélectionne les événements de journal contenant la chaîne "ERROR", mais pas "404".
• Analyse le message pour extraire l'horodatage, la méthode HTTP, le chemin, le code d'état et le temps de réponse.
• Calcule le temps de réponse moyen et le nombre d'événements de journal pour chaque combinaison de méthode HTTP, de chemin, de code d'état et d'heure.
• Trie les résultats par nombre d'événements, en ordre décroissant.
• Limite l'affichage aux 20 premiers résultats.

Cette requête permet d'identifier les erreurs les plus fréquentes dans votre application et de suivre le temps de réponse moyen pour chaque combinaison de méthode HTTP, de chemin et de code d'état. Ces résultats peuvent être utilisés pour créer des métriques et des visualisations personnalisées dans les tableaux de bord CloudWatch afin de surveiller les performances de l'application et de résoudre les problèmes.

Autre exemple, une requête ciblant les messages du service Amazon S3 :

fields @timestamp, @message
| filter @message like /REST.API.REQUEST/
| parse @message /.*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20

• La requête sélectionne les événements de journal contenant la chaîne "REST.API.REQUEST".
• Elle analyse ensuite le message pour extraire la méthode HTTP, le chemin, le code d'état et le temps de réponse.
• Elle calcule le temps de réponse moyen et le nombre d'événements de journal pour chaque combinaison de méthode HTTP, de chemin et de code d'état et trie les résultats par nombre en ordre décroissant.
• Elle limite la sortie aux 20 premiers résultats.

Les résultats de cette requête peuvent être affichés sous forme de graphique linéaire dans un tableau de bord CloudWatch, montrant l'évolution du temps de réponse moyen pour chaque combinaison de méthode HTTP, de chemin et de code d'état.

Création du tableau de bord

Pour afficher des métriques et des visualisations basées sur les résultats des requêtes CloudWatch Insights dans un tableau de bord CloudWatch, vous pouvez utiliser la console CloudWatch et suivre l'assistant de création de tableaux de bord.

Voici un exemple de code de tableau de bord CloudWatch incluant des métriques issues des requêtes CloudWatch Insights :

{
    "widgets": [
        {
            "type": "metric",
            "x": 0,
            "y": 0,
            "width": 12,
            "height": 6,
            "properties": {
                "metrics": [
                    [
                        "AWS/EC2",
                        "CPUUtilization",
                        "InstanceId",
                        "i-0123456789abcdef0",
                        {
                            "label": "CPU Utilization",
                            "stat": "Average",
                            "period": 300
                        }
                    ]
                ],
                "view": "timeSeries",
                "stacked": false,
                "region": "us-east-1",
                "title": "EC2 CPU Utilization"
            }
        },
        {
            "type": "log",
            "x": 0,
            "y": 6,
            "width": 12,
            "height": 6,
            "properties": {
                "query": "fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
",
                "region": "us-east-1",
                "title": "Application Errors"
            }
        }
    ]
}

Ce tableau de bord CloudWatch contient deux widgets :

• Un widget de métrique qui affiche l'utilisation moyenne du processeur d'une instance EC2 au fil du temps. La requête CloudWatch Insights remplit ce widget, sélectionnant les données d'utilisation du processeur pour une instance spécifique et les agrégeant par intervalles de 5 minutes.
• Un widget de journal qui affiche le nombre d'erreurs d'application au fil du temps. Il sélectionne les événements de journal contenant la chaîne "ERROR" et les regroupe par heure.

Il s'agit d'un fichier JSON contenant la définition du tableau de bord et les métriques associées. La requête Insight est également intégrée (en tant que propriété).

Ce code peut être déployé sur le compte AWS souhaité. Si les services et les messages de journal sont uniformes sur l'ensemble de vos comptes et environnements AWS, le tableau de bord fonctionnera sans modification du code source.

Conclusion

Mettre en place une structure de journalisation robuste est un investissement judicieux pour la fiabilité future du système. Cette structure peut désormais servir un objectif encore plus large : la création de tableaux de bord utiles avec des métriques et des visualisations.

Cette approche permet de satisfaire les besoins de l'équipe de développement, de test et des utilisateurs en production, tout en nécessitant un investissement initial minimal.

Pour aller plus loin, explorez les meilleurs outils de surveillance AWS.