Quand utiliser les différents niveaux de journalisation

Il existe différentes manières de consigner les messages, par ordre de fatalité:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Comment décider quand utiliser quoi?

Quelle bonne heuristique utiliser?

Je souscris généralement à la convention suivante:

• Trace - Uniquement lorsque je "traçais" le code et essayais de trouver une partie d'une fonction en particulier.
• Débogage - Informations qui sont utiles au diagnostic pour les gens plus que pour les développeurs (informatique, administrateurs système, etc.).
• Info - Informations généralement utiles pour se connecter (démarrage / arrêt du service, hypothèses de configuration, etc.). Infos Je veux toujours avoir à disposition, mais je m'en fiche généralement dans des circonstances normales. Ceci est mon niveau de configuration prêt à l'emploi.
• Avertir - Tout ce qui peut potentiellement provoquer des bizarreries d'application, mais pour lequel je récupère automatiquement. (Par exemple, le passage d'un serveur principal à un serveur de sauvegarde, une nouvelle tentative d'une opération, des données secondaires manquantes, etc.)
• Erreur - Toute erreur fatale à l' opération , mais pas au service ou à l'application (impossible d'ouvrir un fichier requis, des données manquantes, etc.). Ces erreurs forceront l'intervention de l'utilisateur (administrateur ou utilisateur direct). Ceux-ci sont généralement réservés (dans mes applications) aux chaînes de connexion incorrectes, aux services manquants, etc.
• Fatal - Toute erreur qui force un arrêt du service ou de l'application pour éviter la perte de données (ou toute autre perte de données). Je les réserve uniquement pour les erreurs et les situations les plus odieuses où il est garanti qu'il y a eu corruption ou perte de données.

Souhaitez-vous que le message envoie un administrateur système hors du lit au milieu de la nuit?

• oui -> erreur
• non -> avertir

Je trouve plus utile de réfléchir aux gravités du point de vue de l'affichage du fichier journal.

Mortel / critique : défaillance globale de l'application ou du système qui doit être examinée immédiatement. Oui, réveillez le SysAdmin. Puisque nous préférons notre alerte SysAdmins et bien reposée, cette gravité doit être utilisée très rarement. Si cela se produit quotidiennement et que ce n'est pas un BFD, il a perdu son sens. En règle générale, une erreur fatale ne se produit qu'une seule fois dans la durée de vie du processus. Par conséquent, si le fichier journal est lié au processus, il s'agit généralement du dernier message du journal.

Erreur : définitivement un problème qui doit être étudié. SysAdmin doit être notifié automatiquement, mais n'a pas besoin d'être traîné hors du lit. En filtrant un journal pour examiner les erreurs et au-dessus, vous obtenez une vue d'ensemble de la fréquence des erreurs et pouvez rapidement identifier l'échec de déclenchement qui aurait pu entraîner une cascade d'erreurs supplémentaires. Le suivi des taux d'erreur par rapport à l'utilisation des applications peut produire des métriques de qualité utiles telles que MTBF qui peuvent être utilisées pour évaluer la qualité globale. Par exemple, cette métrique peut aider à informer les décisions sur la nécessité ou non d'un autre cycle de test bêta avant une version.

Avertissement : cela POURRAIT être un problème, ou peut-être pas. Par exemple, les conditions environnementales transitoires attendues, telles que la courte perte de connectivité au réseau ou à la base de données, doivent être enregistrées en tant qu'avertissements et non en tant qu'erreurs. L'affichage d'un journal filtré pour n'afficher que les avertissements et les erreurs peut donner un aperçu rapide des premiers indices de la cause première d'une erreur ultérieure. Les avertissements doivent être utilisés avec parcimonie afin qu'ils ne perdent pas leur sens. Par exemple, la perte d'accès au réseau doit être un avertissement ou même une erreur dans une application serveur, mais peut être simplement une info dans une application de bureau conçue pour les utilisateurs d'ordinateurs portables déconnectés occasionnellement.

Info : Il s'agit d'informations importantes qui doivent être enregistrées dans des conditions normales telles qu'une initialisation réussie, le démarrage et l'arrêt de services ou la réussite de transactions importantes. L'affichage d'un journal contenant des informations et plus devrait donner un aperçu rapide des principaux changements d'état dans le processus, fournissant un contexte de premier niveau pour comprendre les avertissements ou les erreurs qui se produisent également. Ne pas avoir trop de messages Info. Nous avons généralement <5% de messages d'information par rapport à Trace.

Trace : la trace est de loin la gravité la plus couramment utilisée et doit fournir un contexte pour comprendre les étapes menant aux erreurs et aux avertissements. Le fait d'avoir la bonne densité de messages Trace rend le logiciel beaucoup plus facile à gérer mais nécessite une certaine diligence car la valeur des instructions Trace individuelles peut changer au fil du temps à mesure que les programmes évoluent. La meilleure façon d'y parvenir est de donner à l'équipe de développement l'habitude de consulter régulièrement les journaux dans le cadre du dépannage des problèmes signalés par les clients. Encouragez l'équipe à éliminer les messages de trace qui ne fournissent plus de contexte utile et à ajouter des messages si nécessaire pour comprendre le contexte des messages suivants. Par exemple, il est souvent utile de consigner les entrées utilisateur telles que la modification des affichages ou des onglets.

Debug : Nous considérons Debug <Trace. La différence étant que les messages de débogage sont compilés à partir des versions Release. Cela dit, nous déconseillons l'utilisation des messages de débogage. Autoriser les messages de débogage a tendance à entraîner de plus en plus de messages de débogage ajoutés et aucun jamais supprimé. Avec le temps, cela rend les fichiers journaux presque inutiles car il est trop difficile de filtrer le signal du bruit. Cela empêche les développeurs d'utiliser les journaux, ce qui continue la spirale de la mort. En revanche, l'élagage constant des messages Trace encourage les développeurs à les utiliser, ce qui se traduit par une spirale vertueuse. En outre, cela élimine la possibilité de bogues introduits en raison des effets secondaires nécessaires dans le code de débogage qui n'est pas inclus dans la version. Oui, je sais que cela ne devrait pas se produire dans un bon code, mais mieux vaut prévenir que guérir.

Voici une liste de ce que "les enregistreurs" ont.

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] événements d'erreur très graves qui entraîneront vraisemblablement l'arrêt de l'application.

   [ v2.0 : ..] erreur grave qui empêchera l'application de continuer.

2. ERROR:

   [ v1.2 : ..] événements d'erreur susceptibles de permettre à l'application de continuer à fonctionner.

   [ v2.0 : ..] erreur dans l'application, éventuellement récupérable.

3. WARN:

   [ v1.2 : ..] situations potentiellement dangereuses.

   [ v2.0 : ..] événement qui pourrait [ sic ] entraîner une erreur.

4. INFO:

   [ v1.2 : ..] messages d'information qui mettent en évidence la progression de l'application au niveau grossier.

   [ v2.0 : ..] événement à des fins d'information.

5. DEBUG:

   [ v1.2 : ..] événements d'information à granularité fine qui sont les plus utiles pour déboguer une application.

   [ v2.0 : ..] événement de débogage général.

6. TRACE:

   [ v1.2 : ..] événements informationnels plus fins que le DEBUG.

   [ v2.0 : ..] message de débogage à granularité fine, capturant généralement le flux dans l'application.

Apache Httpd (comme d'habitude) aime aller trop loin: §

1. émergence :

   Urgences - le système est inutilisable.

2. alerte :

   Des mesures doivent être prises immédiatement [mais le système est toujours utilisable].

3. critique :

   Conditions critiques [mais aucune action ne doit être entreprise immédiatement].

   • " socket: impossible d'obtenir un socket, sortie de l'enfant "

4. erreur :

   Conditions d'erreur [mais pas critiques].

   • " Fin prématurée des en-têtes de script "

5. avertir :

   Conditions d'avertissement. [proche de l'erreur, mais pas de l'erreur]

6. remarque :

   Condition normale mais significative [ notable ].

   • " httpd: pris SIGBUS, essayant de vider le noyau dans ... "

7. info :

   Information [et imperceptible].

   • [" serveur fonctionne depuis x heures. "]

8. débogage :

   Au niveau des messages de débogage [, soit des messages enregistrés pour le bien de de-mise sur écoute )].

   • " Ouverture du fichier de configuration ... "

9. trace1 → trace6 :

   Tracer des messages [, c'est-à-dire des messages enregistrés pour traçage ].

   • " proxy: FTP: connexion de contrôle terminée "
   • " proxy: CONNECT: envoi de la demande CONNECT au proxy distant "
   • " openssl: Poignée de main: démarrer "
   • " lu à partir d'une brigade SSL tamponnée, mode 0, 17 octets "
   • " recherche de carte ÉCHEC:map=rewritemap key=keyname "
   • " Échec de la recherche dans le cache, forçant une nouvelle recherche de carte "

10. trace7 → trace8 :

    Tracer des messages, vider de grandes quantités de données

    • "| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache commons-logging: §

1. fatal :

   Erreurs graves entraînant une résiliation prématurée. Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.

2. erreur :

   Autres erreurs d'exécution ou conditions inattendues. Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.

3. avertir :

   Utilisation d'API obsolètes, mauvaise utilisation de l'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.

4. 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.

5. déboguer :

   des informations détaillées sur le flux dans le système. Attendez-vous à ce qu'ils soient écrits dans les journaux uniquement.

6. trace :

   des informations plus détaillées. Attendez-vous à ce qu'ils soient écrits dans les journaux uniquement.

Apache commons-logging "meilleures pratiques" pour une utilisation en entreprise fait une distinction entre le débogage et les informations fonction du type de frontières qu'elles franchissent.

Les limites comprennent:

• Limites externes - Exceptions attendues.

• Limites externes - exceptions inattendues.

• Limites internes.

• Limites internes importantes.

(Voir le guide de journalisation des biens communs pour plus d'informations à ce sujet.)

Si vous pouvez vous remettre du problème, c'est un avertissement. S'il empêche l'exécution continue, c'est une erreur.

Je recommande l' adoption de niveaux de gravité Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Voir http://en.wikipedia.org/wiki/Syslog#Severity_levels

Ils devraient fournir suffisamment de niveaux de gravité fins pour la plupart des cas d'utilisation et sont reconnus par les analyseurs de journaux existants. Bien que vous ayez bien sûr la liberté de n'implémenter qu'un sous-ensemble, par exempleDEBUG, ERROR, EMERGENCY fonction des exigences de votre application.

Normalisons quelque chose qui existe depuis des siècles au lieu de proposer notre propre norme pour chaque application différente que nous fabriquons. Une fois que vous avez commencé à agréger les journaux et que vous essayez de détecter des modèles dans différents, cela aide vraiment.

Avertissements dont vous pouvez récupérer. Des erreurs que vous ne pouvez pas. C'est mon heuristique, d'autres peuvent avoir d'autres idées.

Par exemple, disons que vous entrez / importez le nom "Angela Müller"dans votre application (notez le tréma sur le u). Votre code / base de données peut être uniquement en anglais (bien qu'il ne devrait probablement pas l' être de nos jours) et pourrait donc avertir que tous les caractères "inhabituels" ont été convertis en caractères anglais normaux.

Comparez cela avec essayer d'écrire ces informations dans la base de données et de récupérer un message de panne de réseau pendant 60 secondes. C'est plus une erreur qu'un avertissement.

Comme d'autres l'ont dit, les erreurs sont des problèmes; les avertissements sont des problèmes potentiels.

Dans le développement, j'utilise fréquemment des avertissements où je peux mettre l'équivalent d'un échec d'assertion mais l'application peut continuer à fonctionner; cela me permet de savoir si ce cas se produit réellement ou si c'est mon imagination.

Mais oui, cela revient aux aspects de récupérabilité et d'actualité. Si vous pouvez récupérer, c'est probablement un avertissement; si quelque chose échoue, c'est une erreur.

Je pense que les niveaux SYSLOG NOTICE et ALERT / EMERGENCY sont largement superflus pour la journalisation au niveau de l'application - tandis que CRITICAL / ALERT / EMERGENCY peut être un niveau d'alerte utile pour un opérateur qui peut déclencher différentes actions et notifications, pour un administrateur d'application, c'est la même chose que FATAL. Et je ne peux tout simplement pas faire suffisamment de distinction entre recevoir un avis ou certaines informations. Si l'information n'est pas remarquable, ce n'est pas vraiment une information :)

J'aime mieux l'interprétation de Jay Cincotta - le suivi de l'exécution de votre code est quelque chose de très utile dans le support technique, et la mise à disposition des instructions de trace dans le code devrait être encouragée - en particulier en combinaison avec un mécanisme de filtrage dynamique pour enregistrer les messages de trace à partir de composants d'application spécifiques. Cependant, le niveau DEBUG pour moi indique que nous sommes toujours en train de comprendre ce qui se passe - je vois la sortie de niveau DEBUG comme une option de développement uniquement, pas comme quelque chose qui devrait jamais apparaître dans un journal de production.

Il y a cependant un niveau de journalisation que j'aime voir dans mes journaux d'erreurs lorsque je porte le chapeau d'un administrateur système autant que celui du support technique, ou même du développeur: OPER, pour les messages OPÉRATIONNELS. J'utilise cela pour enregistrer un horodatage, le type d'opération invoqué, les arguments fournis, éventuellement un identifiant de tâche (unique) et l'achèvement de la tâche. Il est utilisé lorsque, par exemple, une tâche autonome est déclenchée, ce qui est une véritable invocation depuis l'application plus longue. C'est le genre de chose que je veux toujours enregistrer, peu importe que quelque chose se passe mal ou non, donc je considère que le niveau d'OPER est supérieur à FATAL, donc vous ne pouvez le désactiver qu'en passant en mode totalement silencieux. Et c'est bien plus que de simples données de journal INFO - un niveau de journal souvent abusé pour les journaux de spam avec des messages opérationnels mineurs sans aucune valeur historique.

Comme le cas l'exige, ces informations peuvent être dirigées vers un journal d'invocation distinct, ou peuvent être obtenues en les filtrant à partir d'un grand journal enregistrant plus d'informations. Mais il est toujours nécessaire, en tant qu'informations historiques, de savoir ce qui était fait - sans descendre au niveau de AUDIT, un autre niveau de journal totalement distinct qui n'a rien à voir avec des dysfonctionnements ou le fonctionnement du système, ne correspond pas vraiment aux niveaux ci-dessus ( car il a besoin de son propre commutateur de contrôle, pas d'une classification de gravité) et qui a définitivement besoin de son propre fichier journal distinct.

De RFC 5424, le protocole Syslog (IETF) - Page 10:

Chaque priorité de message a également un indicateur de niveau de gravité décimal. Celles-ci sont décrites dans le tableau suivant avec leurs valeurs numériques. Les valeurs de gravité DOIVENT être comprises entre 0 et 7 inclus.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

G'day,

En corollaire à cette question, communiquez vos interprétations des niveaux de journal et assurez-vous que toutes les personnes sur un projet sont alignées dans leur interprétation des niveaux.

Il est pénible de voir une grande variété de messages de journal où les gravités et les niveaux de journal sélectionnés ne sont pas cohérents.

Si possible, fournissez des exemples des différents niveaux de journalisation. Et soyez cohérent dans les informations à enregistrer dans un message.

HTH

Je suis totalement d'accord avec les autres et je pense que GrayWizardx l'a dit le mieux.

Tout ce que je peux ajouter, c'est que ces niveaux correspondent généralement à leurs définitions de dictionnaire, donc ça ne peut pas être si difficile. En cas de doute, traitez-le comme un puzzle. Pour votre projet particulier, pensez à tout ce que vous voudrez peut-être enregistrer.

Maintenant, pouvez-vous comprendre ce qui pourrait être fatal? Vous savez ce que signifie fatal, n'est-ce pas? Alors, quels éléments de votre liste sont fatals.

Ok, c'est fatal traité, regardons maintenant les erreurs ... rincer et répéter.

En dessous de Fatal, ou peut-être Error, je dirais que plus d'informations valent toujours mieux que moins, donc errer "vers le haut". Vous ne savez pas si c'est Info ou Avertissement? Faites-en ensuite un avertissement.

Je pense que Fatal and error devrait être clair pour nous tous. Les autres sont peut-être plus flous, mais il est sans doute moins vital de les corriger.

Voici quelques exemples:

Fatal - impossible d'allouer de la mémoire, une base de données, etc. - ne peut pas continuer.

Erreur - pas de réponse au message, transaction abandonnée, impossible d'enregistrer le fichier, etc.

Avertissement - l'allocation des ressources atteint X% (disons 80%) - c'est un signe que vous voudrez peut-être redimensionner votre.

Info - utilisateur connecté / déconnecté, nouvelle transaction, fichier créé, nouveau champ d / b ou champ supprimé.

Débogage - vidage de la structure de données interne, niveau Anything Trace avec nom de fichier et numéro de ligne.
Trace - action réussie / échouée, d / b mis à jour.

Une erreur est quelque chose qui ne va pas, qui est tout à fait faux, aucun moyen de la contourner, elle doit être corrigée.

Un avertissement est le signe d'un modèle qui pourrait être faux, mais qui pourrait aussi ne pas l'être.

Cela dit, je ne peux pas donner un bon exemple d'avertissement qui ne soit pas également une erreur. Ce que je veux dire par là, c'est que si vous vous donnez la peine de consigner un avertissement, vous pouvez tout aussi bien résoudre le problème sous-jacent.

Cependant, des choses comme "l'exécution sql prend trop de temps" peuvent être un avertissement, tandis que "les blocages d'exécution sql" sont une erreur, donc peut-être qu'il y a des cas après tout.

J'ai toujours envisagé d'avertir le premier niveau de journalisation qui signifie à coup sûr qu'il y a un problème (par exemple, un fichier de configuration n'est peut-être pas là où il devrait être et nous allons devoir exécuter avec les paramètres par défaut). Une erreur implique, pour moi, quelque chose qui signifie que l'objectif principal du logiciel est désormais impossible et nous allons essayer de fermer proprement.

J'ai déjà construit des systèmes qui utilisent les éléments suivants:

1. ERREUR - signifie que quelque chose ne va vraiment pas et que ce thread / processus / séquence particulier ne peut pas continuer. Une intervention de l'utilisateur / administrateur est requise
2. AVERTISSEMENT - quelque chose ne va pas, mais le processus peut continuer comme avant (par exemple, un travail sur un ensemble de 100 a échoué, mais le reste peut être traité)

Dans les systèmes que j'ai construits, les administrateurs avaient pour instruction de réagir aux ERREURS. D'autre part, nous surveillerions les AVERTISSEMENTS et déterminerions pour chaque cas si des changements, des reconfigurations, etc. du système étaient nécessaires.

Btw, je suis un grand fan de tout capturer et de filtrer les informations plus tard.

Que se passerait-il si vous capturiez au niveau de l'avertissement et que vous vouliez des informations de débogage liées à l'avertissement, mais que vous ne pouviez pas recréer l'avertissement?

Capturez tout et filtrez plus tard!

Cela est vrai même pour les logiciels intégrés, sauf si vous constatez que votre processeur ne peut pas suivre, auquel cas vous voudrez peut-être reconcevoir votre traçage pour le rendre plus efficace, ou le traçage interfère avec le timing (vous pouvez envisager de déboguer sur un processeur plus puissant, mais qui ouvre une toute autre boîte de vers).

Capturez tout et filtrez plus tard !!

(btw, capturer tout est également bon car il vous permet de développer des outils pour faire plus que simplement afficher la trace de débogage (je dessine des diagrammes de séquence de messages à partir du mien et des histogrammes d'utilisation de la mémoire. Cela vous donne également une base de comparaison si quelque chose ne va pas dans futur (conservez tous les journaux, qu'ils réussissent ou échouent, et assurez-vous d'inclure le numéro de build dans le fichier journal)).

Mes deux cents environ FATALet TRACEles niveaux du journal des erreurs.

ERROR c'est quand une FAUTE (exception) se produit.

FATAL est en fait DOUBLE FAULT: lorsque l'exception se produit lors de la gestion de l'exception.

C'est facile à comprendre pour le service Web.

1. Demande venir. L'événement est enregistré en tant queINFO
2. Le système détecte un espace disque insuffisant. L'événement est enregistré en tant queWARN
3. Une fonction est appelée pour gérer la demande. Pendant le traitement, la division par zéro se produit. L'événement est enregistré en tant queERROR
4. Le gestionnaire d'exceptions du service Web est appelé pour gérer la division par zéro. Le service / framework Web va envoyer des e-mails, mais il ne le peut pas car le service de messagerie est actuellement hors ligne. Cette deuxième exception ne peut pas être gérée normalement, car le gestionnaire d'exceptions du service Web ne peut pas traiter l'exception.
5. Gestionnaire d'exceptions différent appelé. L'événement est enregistré en tant queFATAL

TRACEc'est quand nous pouvons suivre l'entrée / la sortie d'une fonction. Il ne s'agit pas de journalisation, car ce message peut être généré par un débogueur et votre code n'a pas appelé du logtout. Les messages qui ne proviennent pas de votre application sont donc marqués comme TRACEniveau. Par exemple, vous exécutez votre application avecstrace

Donc , en général dans votre programme que vous faites DEBUG, INFOet l' WARNexploitation forestière. Et seulement si vous écrivez un service / cadre Web que vous utiliserez FATAL. Et lorsque vous déboguez une application, vous obtiendrez une TRACEjournalisation à partir de ce type de logiciel.

Je suggère d'utiliser seulement trois niveaux

1. Fatal - Qui casserait l'application.
2. Info - Info
3. Débogage - Informations moins importantes