Définition d’un log d’erreurs

Un log d’erreurs est un fichier qui détaille les conditions d’erreur rencontrées lors de l’exécution d’un logiciel. Cette appellation est générique et il arrive que les messages consignés par les applications ne soient pas des erreurs, même si les logs d’erreurs visent essentiellement à enregistrer uniquement les messages d’erreur générés par un programme donné. Ce programme peut prendre la forme d’un système d’exploitation de serveur ou de réseau ou encore d’une application tierce. Dans cet article, nous nous concentrerons exclusivement sur les logs d’erreurs d’applications.

Lorsqu’une application connaît une panne ou un problème de performance, le moyen le plus rapide d’identifier la cause sous-jacente est de consulter son log d’erreurs et de vérifier les messages. Un log d’erreurs de qualité fournit suffisamment d’informations pour pouvoir amorcer le processus de résolution. Il vous renseigne notamment sur la nature de l’événement, le moment où il est survenu, sa criticité et, éventuellement, le nom du module en cause ou un identifiant de traçabilité destiné à établir une corrélation avec d’autres événements.

Les logs d’erreurs sont indispensables aux systèmes traditionnels de surveillance et aux solutions de gestion des événements et des informations de sécurité (SIEM). Ils leur permettent notamment d’analyser et d’identifier les erreurs critiques, de révéler les tendances historiques d’erreurs similaires et d’envoyer des alertes en cas d’incidents de sécurité.

Cet article présente le contenu d’un log d’erreurs d’application type et son utilité pour votre équipe d’exploitation, et vous explique comment en tirer le meilleur parti.

Que contient un log d’erreurs ?

Les logs d’erreurs contiennent deux types d’erreurs d’application : les messages d’erreur non gérés et les messages d’erreur personnalisés. Les messages d’erreur non gérés portent aussi le nom de messages non interceptés, car ils ne sont pas traités par le code du développeur. Il arrive en effet que les bibliothèques ou les composants d’exécution d’une application génèrent une erreur. Or ces composants ne sont pas créés par les développeurs de l’application, mais sont ajoutés par le compilateur lors de la phase de génération du build. L’incompatibilité des types de variables, la division par zéro, etc. sont quelques exemples d’erreurs non gérées.

Les messages d’erreur personnalisés sont quant à eux enregistrés dans le code du programme par des gestionnaires d’exceptions. Il s’agit de conditions d’erreur que les développeurs ont anticipées et pour lesquelles ils ont écrit un code. Par exemple, une application bancaire peut consigner une erreur lorsqu’un utilisateur tente de retirer une somme d’argent supérieure au solde existant et afficher un message plus compréhensible pour les humains.

L’utilité d’un log d’erreurs dépend du niveau de précision des informations enregistrées pour chaque erreur. En l’absence de détails suffisants, il sera difficile de prendre des mesures correctives. Si les détails concernant les erreurs fournis par les différentes applications varient, les logs d’erreurs bien conçus sont quant à eux structurés et comportent des champs communs :

Horodatage

Ce champ indique la date et l’heure auxquelles l’erreur s’est produite. Idéalement, il doit également inclure le fuseau horaire, une information particulièrement utile dans le cas de systèmes distribués. Le format généralement adopté est celui de la norme ISO 8601, qui se présente comme suit :

2022-04-15T14:19:10+00:00 2022-04-15T14:20:10+00:00 …

Niveau de criticité

La plupart des entrées de log sont associées à un niveau de criticité qui indique si une attention immédiate est nécessaire. Les niveaux de criticité généralement utilisés sont les suivants : TRACE, DEBUG, INFO, WARN, ERROR et FATAL, TRACE correspondant à la criticité la plus faible et FATAL à la plus élevée. Les systèmes de surveillance s’appuient sur ces niveaux de criticité pour envoyer automatiquement des alertes et déclencher des actions automatisées.

Par exemple, le manque d’espace sur un disque pourra être consigné dans un log avec le niveau WARN. Dès lors que la solution de surveillance détecte cette erreur, elle envoie un message d’alerte à l’équipe chargée des opérations, puis crée un ticket d’assistance. Un disque complètement saturé pourra quant à lui être consigné comme CRITICAL et déclencher l’extension automatique du disque par la solution de surveillance.

Utilisateur

Ce champ affiche le nom de l’utilisateur du réseau associé à l’erreur. Il s’agit généralement de l’utilisateur du système à l’origine de l’erreur. Les noms d’utilisateur peuvent se révéler utiles pour la résolution des problèmes ou la réalisation d’une analyse historique. Par exemple, vous pouvez analyser les logs d’erreurs afin de déterminer si certains utilisateurs rencontrent plus d’erreurs que d’autres. Il convient toutefois de noter que tous les événements de log ne sont pas associés à un utilisateur.

Description

Il s’agit d’une brève explication de l’erreur. Les logs d’erreurs sont souvent consultés dans des moments où le temps est compté. Il est donc essentiel que cette description soit succincte et qu’elle fournisse les informations nécessaires. Par exemple, une description du type « Accès refusé » ne sera pas d’une grande utilité en cas de problème d’accès d’un utilisateur à une application. Une description de type « Accès refusé : privilèges insuffisants » serait plus pertinente.

Outre les champs courants, d’autres attributs figurent souvent dans les logs d’erreurs, à savoir :

• Identifiants d’erreur : ces identifiants sont utilisés pour distinguer chaque type d’erreur.
• Adresses IP : certains messages d’erreur contiennent les adresses IP des appareils source et de destination.
• Appareil ou serveur : il peut s’agir du nom réseau ou de l’adresse IP de l’appareil pour lequel l’application a déclenché une erreur.

Avantages des logs d’erreurs

Les logs d’erreurs s’apparentent aux boîtes noires des avions. C’est vers eux que se tournent en priorité la plupart des ingénieurs d’assistance. Voici quelques-uns de leurs avantages :

Réduction des délais de résolution

Les logs d’erreurs contribuent à réduire le délai moyen de réparation (MTTR) de votre environnement informatique, en particulier lorsqu’ils sont ingérés par des systèmes modernes de gestion des logs. En effet, ces solutions de gestion permettent de filtrer, de rechercher et d’identifier les erreurs qui vous intéressent, d’analyser les valeurs de champs spécifiques, de mettre en corrélation les événements de différents logs d’erreurs et de prédire les éventuels problèmes à venir. Toutes ces actions peuvent déboucher sur des mesures proactives qui réduiront encore le risque de temps d’arrêt.

Simplification de la prise de décision

Les tableaux de bord, les graphiques de tendance, les systèmes de hiérarchisation des erreurs et les différents rapports établis par les solutions de gestion des logs contribuent à identifier les erreurs critiques, à évaluer les performances des systèmes touchés et à déterminer si une intervention immédiate est nécessaire. De même, des schémas récurrents dans les logs d’erreurs peuvent indiquer des problèmes cachés et permettre aux équipes de prendre des mesures rapides et proactives afin de prévenir les réclamations des clients.

Performances supérieures

Les logs d’erreurs peuvent mettre en évidence les problèmes de performance des applications, tels que les plantages, les problèmes de mémoire ou les lenteurs. L’analyse des logs au fil du temps peut révéler des situations conduisant fréquemment à des goulots d’étranglement. Par exemple, l’examen d’un log d’erreurs contenant des événements d’abandon de paniers d’achats peut révéler que votre application d’e-commerce connaît des problèmes de performances lors du Black Friday. Vous pourrez ainsi décider de renforcer votre infrastructure au cours de cette période en particulier.

Renforcement de la sécurité

Les logs d’erreurs sont essentiels pour la résolution des incidents de sécurité. L’analyse de l’historique des erreurs liées à la sécurité peut vous aider à distinguer les comportements normaux des comportements suspects. Par exemple, si une application présente un schéma récurrent d’échec des tentatives de connexion pour plusieurs comptes d’utilisateur, il peut être utile de vérifier si ces utilisateurs sont toujours actifs et de leur demander d’utiliser des mots de passe plus sûrs, voire de recourir à l’authentification à deux facteurs. L’utilisation d’un outil d’orchestration de la sécurité, d’automatisation et de réponse à incident (SOAR) vous permettra d’aller plus loin encore en ajoutant une mesure automatisée de désactivation des comptes.

Tirer le meilleur parti des logs d’erreurs

Malgré leurs avantages évidents, les logs d’erreurs sont souvent très prolixes. L’ingestion, l’analyse et l’indexation de bon nombre des événements peuvent par conséquent mobiliser considérablement les systèmes de gestion des logs. C’est pourquoi il est préférable de respecter quelques principes généraux pour tirer le meilleur parti des logs d’erreurs.

Utiliser des filtres

Il est important d’exclure les événements inutiles pour ne capturer que ceux qui présentent de l’intérêt. Pour ce faire, vous pouvez configurer l’application pour qu’elle ne consigne que certains types d’événements ou ceux qui présentent un niveau de criticité particulier ou supérieur. Une autre option consiste à ne filtrer que les événements pertinents et à les envoyer à l’application de journalisation.

Décider quoi faire des événements

Appuyez-vous sur le niveau de criticité pour décider du type de mesure à prendre. Vous pouvez par exemple choisir de déclencher des alertes et des mesures automatisées pour les erreurs CRITICAL ou FATAL et de créer des tickets pour tous les événements WARN. Pour définir de telles mesures, vous aurez besoin de l’avis des dirigeants de l’entreprise, des propriétaires de l’application, des responsables techniques et équipes chargées des opérations.

Alerter uniquement les équipes concernées

Une fois que vous avez établi quels événements capturer et à quelle fin, vous devez vous assurer que les équipes concernées reçoivent les alertes correspondantes. L’envoi non ciblé de telles alertes risque de provoquer une lassitude à l’égard des erreurs, de sorte que des événements importants pourraient être négligés. Par exemple, l’équipe chargée de l’infrastructure doit recevoir les erreurs liées au stockage, tandis que l’équipe SecOps devra être informée des erreurs en lien avec la sécurité.

Analyser les erreurs dans la durée

Même s’il n’y a pas de problèmes à résoudre, il peut être utile d’examiner les tendances historiques des erreurs afin de déceler les anomalies et de comparer des périodes similaires. Ces tendances peuvent être utiles aux fins de l’établissement de cadres et d’étalons de référence. Par exemple, si vous constatez que les erreurs liées aux performances se multiplient lorsque l’utilisation du processeur dépasse 80 % ou que le taux de connexion du client d’API dépasse 50 par seconde, vous pouvez en conclure qu’il s’agit des chiffres de référence. Vous pourrez ensuite utiliser ces données à des fins de comparaison au moment d’augmenter la capacité de votre infrastructure.

Rendre les alertes exploitables

Les alertes déclenchées par des erreurs doivent toujours être assorties d’un plan d’action clair et approuvé. Une matrice RACI est un outil précieux qui identifie les responsabilités de chacun en cas d’alerte. De même, il est utile de disposer d’une stratégie de gestion des incidents pour les actions automatisées. Les équipes chargées des opérations devraient par ailleurs exploiter les fonctions d’automatisation de leurs solutions de gestion des logs afin de réduire les délais de réponse et d’améliorer la qualité du service.

Journalisez toutes vos données et répondez à toutes les questions – gratuitement

Falcon LogScale Community Edition (anciennement Humio) offre une plateforme moderne et gratuite de gestion des logs pour le cloud. Exploitez l’ingestion des données de streaming pour bénéficier d’une visibilité instantanée sur les systèmes distribués, de même que détecter et résoudre les incidents.

Falcon LogScale Community Edition, disponible instantanément et gratuitement, inclut les fonctionnalités suivantes :

• Ingestion de jusqu’à 16 Go de données par jour
• Durée de rétention de 7 jours
• Aucune carte de crédit n’est requise
• Accès continu sans période d’essai
• Journalisation sans index, alertes en temps réel et tableaux de bord en direct
• Accès à notre place de marché et à nos packages, y compris aux guides de création de nouveaux packages
• Formation et collaboration avec une communauté active

Démarrer gratuitement