Niveaux de journalisation - Logback - règle générale pour attribuer des niveaux de journalisation

J'utilise la déconnexion dans mon projet actuel.

Il offre six niveaux de journalisation: TRACE DEBUG INFO WARN ERROR OFF

Je recherche une règle empirique pour déterminer le niveau de journalisation des activités courantes. Par exemple, si un thread est verrouillé, le message de journal doit-il être défini au niveau de débogage ou au niveau d'informations. Ou si un socket est utilisé, si son ID spécifique doit être enregistré au niveau de débogage ou au niveau de trace.

J'apprécierai les réponses avec plus d'exemples pour chaque niveau de journalisation.

Je construis principalement des systèmes de type à grande échelle et à haute disponibilité, donc ma réponse est orientée vers le regarder du point de vue du support de production; cela dit, nous attribuons à peu près comme suit:

• erreur : le système est en détresse, les clients sont probablement affectés (ou le seront bientôt) et le correctif nécessite probablement une intervention humaine. La "règle de 2 heures du matin" s'applique ici - si vous êtes de garde, voulez-vous être réveillé à 2 heures du matin si cette condition se produit? Si oui, enregistrez-le comme "erreur".

• avertir : un événement technique ou commercial inattendu s'est produit, les clients peuvent être affectés, mais probablement aucune intervention humaine immédiate n'est requise. Les personnes sur appel ne seront pas appelées immédiatement, mais le personnel de soutien voudra examiner ces problèmes dès que possible pour comprendre leur impact. Fondamentalement, tout problème qui doit être suivi mais qui ne nécessite pas d'intervention immédiate.

• info : les choses que nous voulons voir à un volume élevé au cas où nous aurions besoin d'analyser en profondeur un problème. Les événements du cycle de vie du système (démarrage, arrêt du système) vont ici. Les événements du cycle de vie de "session" (connexion, déconnexion, etc.) vont ici. Les événements limites importants doivent également être pris en compte (par exemple, les appels de base de données, les appels d'API distants). Les exceptions commerciales typiques peuvent aller ici (par exemple, la connexion a échoué en raison de mauvaises informations d'identification). Tout autre événement que vous pensez avoir besoin de voir en production à un volume élevé va ici.

• débogage : à peu près tout ce qui ne coupe pas les "informations" ... tout message utile pour suivre le flux dans le système et isoler les problèmes, en particulier pendant les phases de développement et d'assurance qualité. Nous utilisons des journaux de niveau de «débogage» pour l'entrée / sortie de la plupart des méthodes non triviales et pour marquer des événements intéressants et des points de décision à l'intérieur des méthodes.

• trace : nous ne l'utilisons pas souvent, mais ce serait pour des journaux de volume extrêmement détaillés et potentiellement élevés que vous ne souhaitez généralement pas activer, même pendant le développement normal. Les exemples incluent le vidage d'une hiérarchie d'objets complète, la consignation d'un état à chaque itération d'une grande boucle, etc.

Il est plus important que de choisir les bons niveaux de journal de s'assurer que les journaux sont significatifs et ont le contexte nécessaire. Par exemple, vous souhaiterez presque toujours inclure l'ID de thread dans les journaux afin de pouvoir suivre un seul thread si nécessaire. Vous pouvez également utiliser un mécanisme pour associer des informations commerciales (par exemple, l'ID utilisateur) au thread afin qu'il soit également enregistré. Dans votre message de journal, vous souhaiterez inclure suffisamment d'informations pour vous assurer que le message peut être actionné. Un journal comme "Exception FileNotFound interceptée" n'est pas très utile. Un meilleur message est «Exception FileNotFound interceptée lors de la tentative d'ouverture du fichier de configuration: /usr/local/app/somefile.txt. UserId = 12344».

Il existe également un certain nombre de bons guides de journalisation ... par exemple, voici un extrait édité de JCL (Jakarta Commons Logging) :

• error - Autres erreurs d'exécution ou conditions inattendues. Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.
• warn - Utilisation d'API obsolètes, mauvaise utilisation d'API, «presque» erreurs, autres situations d'exécution indésirables ou inattendues, mais pas nécessairement «erronées». Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.
• info - Événements d'exécution intéressants (démarrage / arrêt). Attendez-vous à ce qu'ils soient immédiatement visibles sur une console, alors soyez prudent et gardez-le au minimum.
• debug - informations détaillées sur le flux dans le système. Attendez-vous à ce qu'ils soient écrits dans les journaux uniquement.
• trace - informations plus détaillées. Attendez-vous à ce qu'ils soient écrits dans les journaux uniquement.

Mon approche, je pense venir plus d'un développement que d'un point de vue opérationnel, est:

• L'erreur signifie que l'exécution de certaines tâches n'a pas pu être terminée; un e-mail n'a pas pu être envoyé, une page n'a pas pu être affichée, certaines données n'ont pas pu être stockées dans une base de données, quelque chose comme ça. Quelque chose a définitivement mal tourné.
• L'avertissement signifie que quelque chose d'inattendu s'est produit, mais que l'exécution peut continuer, peut-être en mode dégradé; un fichier de configuration manquait mais des valeurs par défaut ont été utilisées, un prix a été calculé comme négatif, il a donc été fixé à zéro, etc. Quelque chose ne va pas, mais il ne s'est pas encore mal passé - les avertissements sont souvent le signe qu'il y aura une erreur très bientôt.
• Info signifie que quelque chose de normal mais significatif s'est produit; le système a démarré, le système s'est arrêté, la tâche de mise à jour quotidienne de l'inventaire a été exécutée, etc.
• Le débogage signifie que quelque chose de normal et insignifiant s'est produit; un nouvel utilisateur est venu sur le site, une page a été rendue, une commande a été prise, un prix a été mis à jour. C'est ce qui est exclu des informations car il y en aurait trop.
• La trace est quelque chose que je n'ai jamais utilisé.

Cela peut également aider tangentiellement à comprendre si une demande de journalisation (à partir du code) à un certain niveau entraînera sa journalisation en raison du niveau de journalisation effectif avec lequel un déploiement est configuré. Décidez du niveau effectif avec lequel vous souhaitez configurer votre déploiement à partir des autres réponses ici, puis référez-vous à cela pour voir si une demande de journalisation particulière de votre code sera réellement enregistrée alors ...

Par exemple :

• "Une ligne de code de journalisation qui se connecte à WARN sera-t-elle réellement connectée à mon déploiement configuré avec ERREUR?" Le tableau dit NON.
• "Une ligne de code de journalisation qui se connecte à WARN sera-t-elle réellement connectée à mon déploiement configuré avec DEBUG?" Le tableau dit OUI.

à partir de la documentation de déconnexion :

De manière plus graphique, voici comment fonctionne la règle de sélection. Dans le tableau suivant, l'en-tête vertical indique le niveau de la demande d'enregistrement, désigné par p, tandis que l'en-tête horizontal indique le niveau effectif de l'enregistreur, désigné par q. L'intersection des lignes (demande de niveau) et des colonnes (niveau effectif) est le booléen résultant de la règle de sélection de base.

Ainsi, une ligne de code qui demande la journalisation ne sera réellement enregistrée que si le niveau de journalisation effectif de son déploiement est inférieur ou égal au niveau de gravité demandé pour cette ligne de code .

Je réponds à cela en venant d'une architecture basée sur des composants, où une organisation peut exécuter de nombreux composants qui peuvent s'appuyer les uns sur les autres. Lors d'un échec de propagation, les niveaux de journalisation doivent aider à identifier à la fois les composants affectés et ceux qui sont à l'origine.

• ERREUR - Ce composant a subi une défaillance et la cause est supposée être interne (toute exception interne non gérée, défaillance de la dépendance encapsulée ... par exemple, la base de données, l'exemple REST serait qu'il a reçu une erreur 4xx d'une dépendance). Sortez-moi (responsable de cette composante) du lit.

• AVERTISSEMENT - Ce composant a rencontré une défaillance qui serait due à un composant dépendant (l'exemple REST serait un état 5xx d'une dépendance). Sortez les mainteneurs de CE composant du lit.

• INFO - Tout ce que nous voulons apporter à un opérateur. Si vous décidez de consigner des chemins heureux, je recommande de limiter à 1 message de journal par opération importante (par exemple, par demande http entrante).

Pour tous les messages de journal, assurez-vous de consigner le contexte utile (et donnez la priorité à la création de messages lisibles / utiles par l'homme plutôt que d'avoir des rames de "codes d'erreur")

• DEBUG (et ci-dessous) - Ne devrait pas être utilisé du tout (et certainement pas en production). En développement, je conseillerais d'utiliser une combinaison de TDD et de débogage (si nécessaire) par opposition à un code polluant avec des instructions de journal. En production, la journalisation INFO ci-dessus, combinée à d'autres mesures, devrait être suffisante.

Une bonne façon de visualiser les niveaux d'enregistrement ci-dessus consiste à imaginer un ensemble d'écrans de surveillance pour chaque composant. Lorsque tout fonctionne bien, ils sont verts, si un composant enregistre un AVERTISSEMENT, il deviendra orange (orange) si quelque chose enregistre une ERREUR, il deviendra rouge.

En cas d'incident, vous devez faire en sorte qu'un composant (cause principale) devienne rouge et que tous les composants affectés deviennent orange / orange.

Pas différent pour les autres réponses, mon framework a presque les mêmes niveaux:

1. Erreur: erreurs logiques critiques sur l'application, comme un délai d'expiration de connexion à la base de données. Choses qui appellent une correction de bogue dans un avenir proche
2. Avertir: des problèmes qui ne cassent pas, mais des choses à surveiller. Comme une page demandée introuvable
3. Info: utilisé dans la première ligne des fonctions / méthodes, pour montrer une procédure qui a été appelée ou une étape qui s'est bien passée, comme une requête d'insertion effectuée
4. log: informations logiques, comme le résultat d'une instruction if
5. débogage: contenu variable pertinent à surveiller en permanence