Livre blanc

Les meilleures pratiques de gestion des logs

Introduction

La gestion des logs a évolué. L'examen minutieux des dumps de données brutes des logs d'applications et d'infrastructure dès qu'il y a une panne quelque part appartient désormais au passé. Aujourd'hui, la gestion des logs (ou le logging) joue un rôle essentiel au niveau des opérations, de l'intelligence commerciale et du marketing d'une organisation. Les logs sont le moteur de l'observabilité. S'ils sont bien structurés, ils en sont le turbo et vous permettent de rapidement et facilement comprendre comment fonctionne tout votre système et d'éviter les problèmes. C'est pourquoi New Relic One propose une plateforme unique, uniformisée et unifiée pour toutes les données de télémétrie, y compris les logs détaillés.

Vous pouvez facilement modifier vos pratiques de gestion des logs pour améliorer l'observabilité full-stack. Dans cet article, nous abordons quelques-unes des meilleures pratiques de gestion des logs pour les organisations modernes.

Qu'est-ce que l'observabilité full-stack ?

L'observabilité full-stack apporte une visibilité complète sur les performances de vos applications et systèmes complexes à partir d'une solution intégrée unique qui permet le dépannage des incidents, la réduction du temps moyen de résolution (MTTR), et l'analyse de l'expérience client. Lorsque toutes vos informations se trouvent en un seul et même endroit, vous passez moins de temps à rechercher et dépanner les problèmes. En outre, vous ne devez plus passer d'un outil à l'autre pour voir les différentes parties du stack de logiciels ni gérer les inconnues qui bloquent la vue sur tout ce qui se passe réellement.

Gestion classique des logs

Comparez la description ci-dessus à la gestion classique des logs dans un silo de données qui est stocké séparément des autres systèmes. Auparavant, l'observabilité s'appuyait sur le monitoring des performances des applications (APM) et le monitoring de l'infrastructure. Mais si le monitoring est important, il ne révèle pas tout ce qui passe dans les différents logs d'applications et appareils d'infrastructure. En effet, de nombreux outils de monitoring et de gestion des logs autonomes et compartimentés en silos se focalisent essentiellement sur les applications en ne tenant compte que d'une partie du stack et en ne donnant pas d'informations complètes sur ce qui se passe et pourquoi. Il est essentiel que vous ayez les informations dont vous avez besoin pour accélérer les délais de commercialisation, obtenir des renseignements complets sur le comportement des clients, et réduire le temps de réponse aux incidents.

Les organisations qui veulent une observabilité full-stack doivent soit choisir de ne pas disposer des détails granulaires de leurs logs et se battre pour déterminer la cause profonde des problèmes, soit utiliser différents outils autonomes et essayer de relier les détails provenant des logs aux erreurs et aux traces. Lorsque les logs détaillés sont maintenus dans des silos distincts, il n'est pas possible d'avoir une vue complète sur tout. En conséquence, les coûts augmentent, le temps de commercialisation des produits est plus long, la visibilité sur l'expérience client s'en trouve réduite et le temps moyen de résolution des problèmes s'allonge.

Full-Stack Observability dans New Relic One

Full-Stack Observability dans New Relic One incorpore la gestion des logs, l'APM, le monitoring (infrastructure, serverless, mobile, navigateur, synthétique, et Kubernetes) et le tracing distribué. Ces fonctionnalités vous permettent de visualiser, analyser et dépanner tout votre stack de logiciels. Dans ce cadre, la gestion des logs de New Relic vous permet de combiner les données de logs avec les données de monitoring des applications et de l'infrastructure, ce qui crée une plateforme d'observabilité puissante et complète.

Logs best practices in New Relic One

Full-Stack Observability intègre les métriques, événements, logs et traces (MELT) de tout votre stack de logiciels jusqu'à l'intelligence artificielle pour les opérations IT (AIOps). Plus abordable que les solutions legacy disparates, cette fonctionnalité permet aussi d'effectuer des recherches bien plus rapides dans les logs. Au lieu d'utiliser des outils distincts dans différentes sections du stack, les développeurs peuvent facilement visualiser tous les logs détaillés qui ont un rapport avec une erreur spécifique. Les problèmes de rapidité et de scalabilité dans les solutions de logs legacy rendent difficile l'interrogation des logs détaillés, car leur exécution avec des données différées peut prendre plusieurs minutes voire des heures. Les recherches avec la gestion des logs de New Relic prennent seulement quelques secondes, ce qui permet une analyse des incidents et une réponse sur tout le stack de logiciels extrêmement rapides.

Pour que l'observabilité avec les logs soit efficace, il ne suffit pas de verser d'énormes quantités de logs piètrement formatés dans une base de données ou dans un fichier, il faut plutôt y réfléchir plus profondément et la préparer avec attention. Comment changer intelligemment vos pratiques de gestion afin que les logs détaillés améliorent votre capacité à corréler les incidents sur l'infrastructure et toutes les applications, en temps réel, sans avoir à basculer entre différents outils ? Comment mieux atteindre l'observabilité de bout en bout ? Comment vous rapprocher encore plus de l'observabilité full-stack afin qu'elle soit utile à toute l'entreprise ?

Les logs pour l'observabilité full-stack

La génération de logs pour tout votre stack peut sembler colossale. Vous pouvez vous poser des questions sur ce qui doit se trouver dans les logs, la somme de détails à inclure, et le coût entraîné par une quantité trop importante de données. Des milliers d'entreprises paient le prix fort pour centraliser la gestion de leurs logs sur une plateforme différente et doivent finalement limiter les données de log envoyées en fonction des performances et du prix, ce qui limite la visibilité et l'utilité pour l'entreprise.

Dans Telemetry Data Platform, New Relic assure entre autres la gestion des logs. Celle-ci comprend un accès gratuit (Free Tier) pour les clients ayant un faible volume, et un prix bas par Go permettant d'ingérer tous les logs détaillés dont l'organisation a besoin.

Dans cette optique, abordons quelques-unes des meilleures pratiques à appliquer à la gestion des logs pour l'observabilité.

Savoir ce qu'il faut intégrer dans les logs

Tout ce dont vous avez besoin pour générer un log consiste à écrire du texte vers stdout ou un fichier. La décision la plus importante consiste à choisir ce qui sera inclus dans les logs. Vos logs doivent contenir toutes les métadonnées nécessaires pour vous aider à identifier les événements et la cause profonde que vous recherchez. Il peut s'agir d'éléments tels que des messages d'erreur ou des traces de stack et des valeurs, métriques ou événements connexes.

Tout ce que vous devez consigner dans les logs doit avoir un but. Qu'il s'agisse des données d'utilisation, des événements d'utilisateur ou des erreurs et exceptions d'application, tout doit présenter un intérêt pour votre équipe. Pour savoir ce qu'il faut incorporer dans les logs, posez-vous la question : « Cette information est-elle immédiatement utile d'une façon ou d'une autre et apportera-t-elle les détails dont j'ai besoin pour comprendre la cause sous-jacente et prendre des décisions ? »

Anticiper les scénarios courants

Les logs ne servent pas qu'à répondre aux incidents. Ils peuvent aider avec d'autres éléments de votre activité, comme le profilage de la performance ou la collecte de statistiques.

Il est important de garder quelques scénarios courants en tête pour vous assurer que les logs sont directement utiles à votre organisation. Par exemple, les logs sur les interactions des utilisateurs peuvent fournir des informations précieuses sur l'expérience des clients ; les logs système peuvent monitorer les problèmes ou les pannes matérielles ; les logs détaillés sur l'application peuvent vous permettre de mieux comprendre la performance et les problèmes potentiels tels que les fuites de mémoire. Tout cela peut s'avérer très important lors des prises de décision. 

Inclure dans les logs des messages utiles

Les messages de logs sont aussi importants que les informations et les contextes qu'ils fournissent. En ajoutant suffisamment de détails et en les rendant explicitement lisibles, votre équipe peut véritablement utiliser les logs. Une infrastructure tierce tend déjà à capturer les détails granulaires nécessaires. Mais pour les applications programmées en interne, vous devez toujours vous demander : « Est-ce que je capture dans les logs tous les détails qui permettront de diagnostiquer les problèmes et d'en déterminer les raisons pour que mes utilisateurs puissent prendre les mesures nécessaires qui auront un impact sur l'activité ? »

Pour les erreurs d'application, assurez-vous que le message communique ce qui se passe sur cette ligne de code. Par exemple, un message d'erreur qui dit « Échec de la transaction » n'est pas aussi utile qu'un message d'erreur avec une description de type : « Échec de la transaction : impossible de créer l'utilisateur ${path/to/file:line-number} ». Et si le log inclut des données sur la transaction, cela aide le développeur à comprendre les raisons de l'échec.

En général, les codes d'erreur ou les codes d'état dans les programmes peuvent également indiquer le type de problèmes de votre application. Au lieu de simplement sortir le texte de l'erreur ou son numéro du code, accompagnez-les d'une description courte dans le log afin de permettre à un autre développeur de ne pas perdre de temps à faire des recherches lors du dépannage.

Les logs doivent fournir des informations critiques à votre organisation. Évitez de placer dans les logs des messages cryptiques ou non descriptifs que seuls certains membres de votre équipe peuvent comprendre.

S'assurer que les logs sont simples et concis

Bien qu'il faille incorporer suffisamment d'informations dans le message de log, il est également important de ne pas en mettre trop. En effet, trop de données inutiles dans le message peuvent faire gonfler la taille du stockage et les coûts, mais aussi ralentir les logs de recherche, distraire du problème principal et compliquer son débogage.

Assurez-vous que les logs sont concis afin de capturer les informations les plus importantes. Les logs doivent contenir les raisons tout en évitant tout élément inutile.

En cas d'erreur, vous pouvez fournir des informations sur la cause profonde de l'erreur sans toutefois inclure tous les petits détails sur l'environnement. Par exemple, si une application ne réussit pas à se connecter et à récupérer les données d'une API interne, il peut être bon de consigner tout message d'erreur provenant de l'API ou des informations sur l'état du réseau de l'environnement. Mais vous n'avez probablement pas besoin d'inclure la quantité de mémoire utilisée par l'application, ni combien d'applications sont exécutées. 

Ne pas oublier l'horodatage

L'horodatage est très important. C'est peut-être une évidence, mais si vous avez l'habitude d'enregistrer les logs sur une base de données qui inclut la date et l'heure, il est très possible d'oublier l'horodatage dans les messages de log. Sélectionnez le niveau granulaire le plus logique pour vous et mettez-le dans vos logs. Les tâches très fréquentes peuvent nécessiter de faire le suivi de l'heure à la milliseconde près, alors que pour d'autres tâches plus rares un suivi à la minute (voire au jour) près est préférable. Ce qui est important n'est pas simplement la granularité, mais l'application d'un standard homogène dans toute votre organisation.

Autre point peut-être évident, mais néanmoins important : assurez-vous que tous vos systèmes sont synchronisés sur la même heure. Cela permet à la plateforme d'observabilité d'utiliser l'horodatage pour corréler les événements avec d'autres données télémétriques.

Utiliser un format de logs analysable

Si votre plateforme d'observabilité ne peut pas extraire les données de vos logs, elles ne seront pas très utiles. Utilisez un format de log que vous pouvez analyser et établissez une structure de logs homogène pour une collecte et une agrégation simples.

New Relic facilite la définition des règles d'analyse des logs personnalisées, mais ces règles ne peuvent pas remplir leur fonction si vos données sont illisibles. Le format courant des MELT (métriques, événements, logs et traces) est un bon exemple de format de log analysable. Si vous utilisez un format complètement personnalisé, le paramétrage du type de log déclenche des règles d'analyse définies par le client.

Lorsque vous avez plusieurs applications qui servent à un objectif commun, concentrez-vous sur la standardisation d'un format de log pour toutes les applications. Cela permet d'incorporer plus facilement les données dans votre plateforme d'observabilité, même si la visibilité souhaitée par les équipes associées à chaque application vise différents attributs.

Les formats de logs en détail

Abordons plus en détail les formats de log. Une fois que l'outil d'agrégation des logs collecte les données, il y a trois thèmes récurrents concernant la structuration du texte. Ils ont tous des implications sur l'exploitabilité.

Les trois catégories de format sont les suivantes :

  • Structuré — Le format structuré le plus courant pour les logs est JSON. De nombreux outils peuvent rapidement l'analyser. Il est très flexible et léger. Dans l'idéal, tous les logs sont générés dans un format structuré. Mais si JSON permet d'organiser hiérarchiquement les données, d'autres formats courants comme le format CSV (valeurs séparées par des virgules) et le format TSV (valeurs séparées par des tabulations) sont également des exemples de données de log structurées.
  • Commun — Un format commun n'est pas structuré, mais il est bien connu, défini et cohérent. Le format de logs courant Apache pour les logs d'accès en est un exemple. L'avantage d'un format courant est que de nombreux outils peuvent analyser les données immédiatement.
  • Personnalisé — Si le format des logs d'une application n'est ni structuré ni commun, il est alors personnalisé. Au cours du transfert des logs, il peut s'avérer nécessaire d'effectuer une analyse pour reconnaître le début et la fin d'une ligne de log. La création de règles définies par le client permettra de rendre les données plus utiles.

Catégoriser et grouper les logs

Le fait de spécifier un modèle de données pour vos logs vous permet de faire des recherches plus efficacement. Définissez et incluez les attributs dès que possible pour catégoriser et grouper vos logs en conséquence. Il peut être utile de lire les normes d'OpenTelemetry pour les logs. Elles ont été créées par une coalition de leaders du secteur, dont New Relic, et elles couvrent de nombreux éléments tels que les conventions d'attribution de noms et les définitions des valeurs de champs. Les frameworks ne sont pas tous compatibles nativement avec les logs formatés exactement selon ces normes, mais elles servent de guide pratique.

Les éléments suivants sont des attributs courants qui peuvent être utiles dans un modèle de données de log.

Ressources

Les ressources déterminent l'horodatage et la provenance des logs, par exemple :

  • La date et l'heure
  • La machine, le nom d'hôte ou l'identificateur
  • L'application ou le nom du service

Le nom de l'hôte peut être important dans les logs d'applications basées sur l'hôte classiques dont les environnements sont nommés. Un identifiant de pod ou de conteneur organise mieux les logs d'environnement conteneurisés ou orchestrés.

Les environnements orchestrés ou PaaS renseignent souvent automatiquement les logs avec un grand nombre de métadonnées, ce qui est parfait pour l'organisation, mais il est également important d'annoter les logs avec des qualificateurs qu'un système ne peut pas connaître. Par exemple, les numéros de version des produits, les environnements de préproduction et de production, les branches de test, les versions de test A/B sont tous utiles. N'oubliez pas que l'agrégation des logs signifie que tous les logs de plusieurs sources seront collectés dans le même système. Sans les bonnes métadonnées, vous ne pourrez pas distinguer un vrai log d'erreur en production d'une transaction qui a échoué dans le cadre d'un test.

Les informations de transfert d'un log sont une autre ressource pouvant aider à identifier l'origine d'un log. La plupart des solutions de transfert de log fournies par New Relic annotent automatiquement les données avec le type et la version de l'outil utilisé pour envoyer les données.

Logs in Context

Logs in Context est une fonctionnalité de New Relic qui peut ajouter automatiquement les informations de l'application aux logs. Les données de gestion des performances des applications sont fournies par l'agent APM de New Relic à votre framework et incluses dans les logs des applications. Résultat : Logs in Context corrèle automatiquement les données de logs avec les événements et traces d'application associés. Les erreurs et les traces distribuées d'APM sont directement liées aux logs créés pendant la même transaction que l'erreur ou la trace. Logs in Context crée cette corrélation en insérant un identifiant de span, un identifiant de trace et le nom de l'application dans les messages de log. Cela signifie que vous pouvez regrouper les données de l'application et des logs et effectuer un dépannage beaucoup plus rapidement.

Logs best practices in New Relic One

Niveaux de logs

Les développeurs, les professionnels DevOps et les managers appellent parfois les niveaux de logs des « niveaux de sévérité ». Ces niveaux décrivent l'importance relative de l'événement (avec des termes tels que « debug », « info », « warning », « error », et « fatal ») et le niveau de densité des informations du framework de gestion des logs. L'attribut de sévérité aide à filtrer ou rejeter les informations moins critiques afin que vous puissiez rechercher uniquement les erreurs critiques.

L'utilisation efficace des niveaux de logs peut limiter la quantité de données, réduire les coûts d'utilisation d'un outil de gestion des logs centralisé et assurer la rapidité des recherches. Dans certains cas, il peut être impossible de contrôler la façon dont les applications génèrent les logs, toutefois, le système de gestion des logs peut aussi rejeter les données indésirables. Dans New Relic One, vous pouvez faire remonter à la surface les valeurs hors normes en utilisant des schémas guidés par l'apprentissage machine en fonction du niveau de log. Les niveaux de log codés par couleur vous donnent également un indicateur visuel qui vous permet de porter votre attention sur les zones les plus importantes.

Veuillez noter que vous devez utiliser les niveaux de logs avec précaution, en particulier lorsque vous utilisez le niveau de débogage (debug). Ce niveau peut être particulièrement utile quand vous devez capturer des messages très longs associés à un comportement particulier, mais si vous l'utilisez de manière injustifiée, cela peut créer un bien plus grand volume de logs et ralentir les fonctions d'ingestion et de recherche sans pour autant vous apporter plus d'éléments. Dans le cas des équipes plus importantes et des gros projets, il peut être bénéfique de partager une norme pour les niveaux de log afin que les méthodes de regroupement, de catégorisation et de gestion soient homogènes.

Utiliser des outils et frameworks de gestion des logs

Utilisez des outils et frameworks de gestion des logs existants et éprouvés. Au lieu de passer du temps et de gaspiller des ressources à implémenter une solution de gestion des logs à partir de rien, utilisez plutôt un framework reconnu qui vous permettra de gagner du temps et d'éviter les ennuis. L'utilisation d'un framework cohérent simplifie l'adoption par les équipes d'ingénierie, normalise la sortie des logs et garantit que vous pouvez activer les logs en contexte de manière uniforme. De même qu'avec tout nouveau code, soyez prudent lors des premières utilisations des frameworks de gestion des logs et testez leur impact sur la performance.

Faire référence aux valeurs importantes, sans les inclure

Dans certains cas, vous aurez peut-être besoin de volumes de données plus importants pour apporter un contexte plus détaillé (vidage mémoire ou jeu de fichiers ou d'images, par exemple). Il est généralement recommandé de conserver ces données séparément voire de les transférer sur un serveur désigné et de référencer son emplacement dans le log, au lieu de tout enregistrer dans le log. Faites en sorte que vos logs soient les plus légers possible et accèdent aux données séparément.

Partager des vues, requêtes et alertes utiles

Enfin, créez et partagez des vues, requêtes et alertes standard pour les logs de vos équipes. Vous pourrez obtenir des informations plus globales sur l'état actuel de votre organisation et augmenter la visibilité et la communication entre les équipes. Profitez ainsi de toute la puissance de l'observabilité full-stack. Pourquoi ne pas avoir plus de personnes qui observent ce qui se passe ?

Quels sont les éléments à ne pas ajouter aux logs ?

Même si vous avez envie de consigner tout ce qui pourrait être utile, il existe quelques exceptions et pièges que vous devez essayer d'éviter.

Informations sensibles

Traitez les informations sensibles avec précaution. Il est essentiel de protéger les données réglementées telles que les renseignements personnels et les numéros de cartes bancaires. Pensez aux lois telles que le règlement général sur la protection des données (RGPD) de l'Union européenne et le Health Insurance Portability and Accountability Act (HIPAA) des États-Unis.

Les directives de logging de l'Open Web Application Security Project (OWASP) précisent ce qui ne doit pas se trouver dans les logs, comme les jetons d'accès, les mots de passe, les informations sensibles, et les renseignements que les personnes souhaitent garder privés./p>

Lorsque vous conservez des logs sur un serveur ou dans une base de données privé(e), il est facile d'inclure accidentellement dans le log des renseignements personnels, tels que le nom ou l'adresse e-mail. Cela n'améliore généralement pas l'observabilité, mais si vous devez faire le suivi des actions ou événements d'un utilisateur particulier, il est préférable d'utiliser des identifiants anonymes. Bien que vos données de log soient en sécurité sur une plateforme d'observabilité comme celle de New Relic, il est important de faire très attention à ne pas transmettre de renseignements personnels en dehors de votre organisation.

Code source et données exclusives

Outre les informations réglementaires et de conformité, il peut y avoir d'autres informations que vous ne voulez pas forcément stocker dans vos logs. Cela peut inclure le code source des applications ou données protégées au sein de votre organisation.

Même si vos logs sont stockés de manière sécurisée, leur accès peut ne pas l'être. Des informations qui peuvent révéler des secrets commerciaux ou des projets et fonctionnalités en cours de conception ou non annoncés n'ont pas leur place dans les logs. Assurez-vous donc de ne pas les inclure dans les logs, surtout si vous stockez ces derniers en dehors de votre entreprise avec un service tiers.

Informations en double

Enfin, si l'ajout d'informations en double ne cause pas de problème et s'il vaut également mieux avoir trop d'informations que pas assez, l'inclusion de beaucoup d'informations identiques peut créer des logs inutiles et entraîner des coûts plus élevés sans apporter aucun avantage.

Conclusion

Des logs plus efficaces pour améliorer l'observabilité full-stack permettent une prise de décisions en temps réel qui a un impact sur l'activité, mais aussi un débogage plus rapide pour les ingénieurs qui passent ainsi moins de temps à répondre aux incidents et plus à développer les logiciels.

Une fois ces pratiques en place, vos logs peuvent vous apporter les détails dont vous avez besoin pour une exécution sans problème pour vos clients, et une visibilité encore plus détaillée de l'intégralité de votre stack qui vous permet de résoudre les problèmes plus rapidement et d'accélérer le développement.

Commencez à utiliser vos logs pour l'observabilité et à tirer parti de la gestion des logs en vous inscrivant et recevez un compte gratuit avec lequel vous pourrez essayer la gestion des logs proposée par New Relic.