Les logs sont cruciaux pour vous aider à comprendre les applications et les services que vous développez et exploitez, mais l'utilisation efficace des logs est plus que la simple collecte en masse de données de log dans une base de données ou un fichier. 

Les logs bien structurés peuvent vous aider à comprendre un système complexe. Découvrez comment améliorer les performances ou obtenir des informations cruciales sur les erreurs. La configuration des logs pour tout le stack peut sembler être une tâche colossale et laisser des angles morts et des inconnues si elle est mal maîtrisée. Vous devez décider de ce qu'il faut consigner dans les logs, le niveau de détails à inclure, et si un excès de données entraîne des coûts trop élevés.

Nous abordons ici les bonnes pratiques de logs qui vous aideront à gagner en visibilité sur votre stack, résoudre les erreurs plus rapidement et mieux comprendre l'expérience utilisateur.

Décidez des données à consigner dans les logs

Un log est un fichier qui stocke les données d'événements sur vos applications logicielles, systèmes d'exploitation et infrastructure. Les logs sont générés en écrivant du texte sur des fichiers ou sorties standard et peuvent inclure l'horodatage, les messages d'erreur, les traces de stack et d'autres points de données qui indiquent ce qui s'est passé et pourquoi.

Pour obtenir le maximum de vos logs, vous devez sélectionner avec précaution ce que vous y mettez. En effet, ils doivent contenir toutes les métadonnées nécessaires pour aider à identifier les événements et causes profondes recherchés.

Les informations dans les logs doivent avoir un objectif et être immédiatement utiles. Qu'il s'agisse des données d'utilisation, des événements utilisateur, ou des erreurs et exceptions dans l'application, les données doivent servir les besoins de l'équipe. En outre, les informations stockées dans un log doivent également fournir les détails nécessaires pour comprendre les problèmes et prendre des décisions.

Prévoyez les possibilités les plus courantes pour les logs 

Les logs peuvent non seulement vous aider à déboguer, mais ils peuvent aussi vous permettre de mieux comprendre vos stacks, comme lors du profilage des performances ou de la collecte de statistiques. 

Lors de la configuration de vos logs, n'oubliez pas les possibilités les plus courantes, car elles vous aideront à décider des points de données importants. Par exemple, les logs détaillés sur l'application peuvent fournir des informations sur les performances et les problèmes potentiels tels que les fuites de mémoire. Comparés aux autres données sur l'interaction utilisateur, les logs peuvent fournir des informations cruciales sur l'expérience des clients.

Tout cela peut être important lorsque vous prenez des décisions et peut différer en fonction du scénario choisi.

Ajoutez des messages de log clairs pour faciliter la prise de décision  

Les messages de log sont utiles seulement s'ils donnent des informations importantes et aident à prendre des décisions. Une infrastructure tierce aura tendance à capturer des détails granulaires, alors que pour les applications logicielles, vous devez plutôt décider des détails qui vous aideront à diagnostiquer pourquoi une erreur ou un événement s'est produit afin de prendre les mesures nécessaires.  

Dans le cas des erreurs dans l'application, les messages de logs doivent communiquer ce qui se passe sur une certaine ligne de code. 

Par exemple, si une transaction échoue, le message de log pourrait être : 

Transaction Failed: Could not create user ${path/to/file:line-number}

Ce message permet de mieux comprendre pourquoi la transaction a échoué et quelle ligne de code doit être révisée. 

Outre la sortie du texte ou du numéro du code d'erreur, l'ajout d'une courte description dans le log permettra peut-être à vos collègues de ne pas perdre de temps lors de la résolution d'un problème. 
 

Les messages de logs doivent être simples et concis 

Bien qu'il soit essentiel d'incorporer suffisamment d'informations dans le message de log, il est également important de ne pas en mettre trop.

Les données inutiles augmentent les besoins de stockage, ralentissent les recherches dans les logs et rendent plus difficile le débogage des problèmes. Les messages de log doivent être utiles et précis et s'assurer que vous ne collectez que les données les plus importantes.

Lors du formatage de vos logs, collectez les informations nécessaires pour déboguer une erreur sans toutefois inclure tous les détails sur l'environnement. Par exemple, si un API échoue, il peut être utile de consigner dans le log tous les messages d'erreur de l'API. Envisagez toutefois d'omettre les détails sur la mémoire de l'application.

N'oubliez pas l'horodatage

N'oubliez pas d'inclure l'horodatage dans tous vos messages de log. En fonction de la fréquence d'une tâche, sélectionnez le bon moment pour en faire le suivi, mais assurez-vous d'inclure l'horodatage dans tous vos logs. Certaines tâches peuvent nécessiter de faire le suivi de l'heure à la milliseconde près, alors que d'autres nécessitent un suivi à la minute (voire au jour) près.

Dans le cadre des bonnes pratiques, appliquez certaines normes sur tout votre stack ou dans toute votre organisation afin de pouvoir corréler vos logs avec les types de données télémétriques comme les métriques ou événements. 

Utilisez des formats de logs simples à comprendre

Vos messages de log doivent fournir des informations essentielles simples à lire qui favorisent la prise de mesures ou fournissent des détails importants. En règle générale, évitez les messages cryptiques ou non descriptifs que seuls certains membres de l'équipe pourront comprendre. Les formats de log doivent également être simples à analyser et maintenir une structure cohérente, ce qui assurera une collecte et une agrégation faciles des données. Par exemple, des outils tels que la gestion des logs New Relic facilitent la définition de règles d'analyse pour les logs personnalisées, mais les règles d'analyse ne fonctionneront pas si vos données sont illisibles. 

Exemples de formats de log 

### Exemple d'un log d'accès NGINX difficile à analyser :
127.180.71.3 - - [10/May/2022:08:05:32 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"### Exemple des mêmes infos de log dans un format analysable :
{
  "remote_addr":"93.180.71.3",
  "time":"1586514731",
  "method":"GET",
  "path":"/downloads/product_1",
  "version":"HTTP/1.1",
}

Ces deux logs montrent des informations très similaires, mais le premier est difficile à lire parce que les différentes parties ne sont pas démarquées clairement. Dans le second exemple, vous pouvez facilement et rapidement trouver les détails que vous voulez, sans devoir lire tout le log. La normalisation d'un format de log pour toutes vos applications signifie également que vos logs seront simples à analyser, collecter et exploiter sur d'autres plateformes.

Comme vous pouvez le voir, la capture et l'élaboration des logs avec les bonnes informations peuvent vous permettre d'économiser de l'argent, vous aider à diagnostiquer les erreurs plus rapidement et vous faire gagner du temps lorsque vous êtes d'astreinte.