Quand utiliser les différents niveaux de journalisation
Il existe différentes manières de consigner les messages, par ordre de fatalité:
FATALERRORWARNINFODEBUGTRACE
Comment puis-je décider quand utiliser lequel?
Qu'est-ce qu'une bonne heuristique à utiliser?
Je souscris généralement à la convention suivante:
- Trace - Seulement quand je "tracerais" le code et essayerais d'en trouver un partie d'une fonction spécifique.
- Débogage - Informations utiles aux utilisateurs sur le plan du diagnostic, au-delà des développeurs (informatique, administrateurs système, etc.).
- Info - Informations généralement utiles à consigner (démarrage/arrêt du service, hypothèses de configuration, etc.). Info Je veux toujours être disponible, mais généralement, cela ne me dérange pas dans des circonstances normales. C'est mon niveau de configuration prêt à l'emploi.
- Warn - Tout ce qui peut potentiellement causer des problèmes d’application, mais pour lequel je récupère automatiquement. (Par exemple, passer d'un serveur principal à un serveur de secours, réessayer une opération, manquer des données secondaires, etc.)
- Erreur - Toute erreur fatale à l'opération opération, mais pas le service ou l'application (impossible d'ouvrir un fichier, des données manquantes, etc.). Ces erreurs forceront l'intervention de l'utilisateur (administrateur ou utilisateur direct). Celles-ci sont généralement réservées (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 empêcher la perte de données (ou la perte de données supplémentaire). Je ne les réserve que pour les erreurs les plus odieuses et les situations dans lesquelles la corruption ou la perte de données est garantie.
Souhaitez-vous que le message demande à un administrateur système de se lever au milieu de la nuit?
- oui -> erreur
- non -> avertir
Je trouve plus utile de penser aux sévérités du point de vue de la visualisation du fichier journal.
Fatal/Critical: défaillance globale de l’application ou du système qui doit faire l’objet d’une enquête immédiate. Oui, réveillez le SysAdmin. Puisque nous préférons que nos administrateurs système soient alertes et reposés, cette gravité doit être utilisée très rarement. Si cela se produit quotidiennement et que ce n'est pas une BFD, c'est perdu de sa signification. 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: Certainement un problème qui devrait être étudié. SysAdmin doit être notifié automatiquement, mais il n'est pas nécessaire de le faire glisser du lit. En filtrant un journal pour examiner les erreurs, vous obtenez une vue d'ensemble de la fréquence des erreurs et pouvez rapidement identifier l'échec initial susceptible d'avoir entraîné une cascade d'erreurs supplémentaires. Le suivi des taux d'erreur par rapport à l'utilisation des applications peut générer 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 à éclairer les décisions sur la nécessité ou non d'un autre cycle de test bêta avant la publication.
Avertissement: Cela pourrait être un problème ou ne pas l'être. Par exemple, les conditions environnementales transitoires attendues, telles qu'une perte brève de la connectivité du réseau ou de la base de données, doivent être consignées en tant qu'avertissements et non en tant qu'erreurs. L'affichage d'un journal filtré pour afficher uniquement les avertissements et les erreurs peut donner un aperçu rapide des indications précoces sur 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 devrait être un avertissement ou même une erreur dans une application serveur, mais peut-être simplement une information dans une application de bureau conçue pour les utilisateurs d'ordinateurs portables occasionnellement déconnectés.
Info: Il s'agit d'informations importantes qui doivent être consignées dans des conditions normales, telles qu'une initialisation réussie, le démarrage et l'arrêt des services ou la réussite de transactions importantes. L'affichage d'un journal indiquant les informations et les informations ci-dessus devrait donner un aperçu rapide des principaux changements d'état dans le processus, fournissant ainsi un contexte de niveau supérieur permettant de comprendre les avertissements ou les erreurs pouvant également se produire. Ne pas avoir trop de messages d'information. Nous avons généralement moins de 5% de messages d’information relatifs à la trace.
Trace: La trace est de loin la gravité la plus utilisée et doit fournir un contexte pour comprendre les étapes menant aux erreurs et aux avertissements. Avoir la bonne densité de messages Trace rend les logiciels beaucoup plus faciles à gérer, mais requiert une certaine diligence, car la valeur des instructions individuelles de Trace peut évoluer au fil du temps, en fonction de l'évolution des programmes. Le meilleur moyen d'y parvenir consiste à habituer l'équipe de développement à examiner régulièrement les journaux comme élément standard du dépannage des problèmes signalés par les clients. Encouragez l'équipe à supprimer 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 de l'utilisateur, telles que le changement d'affichage ou d'onglets.
Debug: Nous considérons Debug <Trace. La différence réside dans le fait que les messages de débogage sont compilés hors 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 l'ajout de plus en plus de messages de débogage et aucun autre à les supprimer. Avec le temps, cela rend les fichiers journaux presque inutiles car il est trop difficile de filtrer le signal du bruit. Cela oblige les développeurs à ne pas utiliser les journaux, ce qui prolonge la spirale de la mort. En revanche, l’élagage constant des messages Trace incite les développeurs à les utiliser, ce qui crée une spirale vertueuse. En outre, cela élimine la possibilité que des bogues soient introduits en raison des effets secondaires nécessaires dans le code de débogage qui ne sont pas inclus dans la construction de la version. Oui, je sais que cela ne devrait pas arriver dans un bon code, mais mieux vaut prévenir que guérir.
Voici une liste de ce que "les bûcherons" ont.
FATAL:[v1.2: ..] événements d'erreur très graves qui entraîneront probablement l'abandon de l'application.
[v2.: ..] erreur grave empêchant l'application de continuer.
ERROR:[v1.2: ..] événements d'erreur susceptibles de permettre à l'application de continuer à s'exécuter.
[v2.: ..] erreur dans l'application, éventuellement récupérable.
WARN:[v1.2: ..] situations potentiellement dangereuses.
L'événement [v2.: ..] qui pourrait provoquer [sic] pourrait conduire à une erreur.
INFO:[v1.2: ..] messages d'information qui mettent en évidence les progrès de l'application au niveau des grains grossiers.
[v2.: ..] événement à titre informatif.
DEBUG:[v1.2: ..] événements informatifs à grain fin qui sont les plus utiles pour déboguer une application.
[v2.: ..] événement général de débogage.
TRACE:[v1.2: ..] événements informatifs plus détaillés que la
DEBUG.[v2.: ..] message de débogage à grain fin, capturant généralement le flux dans l'application.
Apache Httpd (comme d'habitude) aime aller trop loin: §
émergent :
Urgences - le système est inutilisable.
alerte :
Des mesures doivent être prises immédiatement [mais le système est toujours utilisable].
crit :
Conditions critiques [mais aucune action ne doit être prise immédiatement].
- "socket: impossible d'obtenir un socket, sortie de l'enfant"
erreur :
Conditions d'erreur [mais non critiques].
- "Fin prématurée des en-têtes de script"
avertir :
Conditions d'avertissement. [proche de l'erreur, mais pas l'erreur]
remarque :
Condition normale mais significative [ notable ].
- "httpd: catch
SIGBUS, essayant de vider le noyau dans ..."
- "httpd: catch
info :
Informatif [et non notable].
- ["Le serveur fonctionne depuis x heures."]
debug :
Messages au niveau du débogage [ c.-à-d. Messages consignés dans le but de corriger les erreurs)].
- "Ouverture du fichier de configuration ..."
trace1 → trace6 :
Messages de trace [ c.-à-d. Messages consignés dans l’intérêt de traçage].
- "proxy: FTP: connexion de contrôle terminée"
- "proxy: CONNECT: envoi de la requête CONNECT au proxy distant"
- "openssl: Handshake: start"
- "lu dans la brigade SSL mise en mémoire tampon, mode 0, 17 octets]"
- "recherche de carte FAILED: _
map=rewritemap_ _key=keyname_" - "recherche de cache FAILED, forçant une nouvelle recherche de carte"
trace7 → trace8 :
Trace des messages, décharge 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: §
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.
erreur :
Autres erreurs d'exécution ou conditions inattendues. Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.
avertir :
Utilisation d’API obsolètes, mauvaise utilisation de l’API, erreurs "presque", 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, soyez prudent et limitez-vous à un minimum.
debug :
informations détaillées sur le flux dans le système. Attendez-vous à ce qu'ils soient écrits uniquement dans les journaux.
trace :
informations plus détaillées. Attendez-vous à ce qu'ils soient écrits uniquement dans les journaux.
Les "meilleures pratiques" de journalisation d'Apache pour l'utilisation en entreprise font la distinction entre déboguer et info en fonction du type de frontières qu’ils traversent.
Les limites comprennent:
Limites externes - Exceptions attendues.
Limites externes - Exceptions inattendues.
Limites internes.
Limites internes importantes.
(Voir guide de journalisation des communs) pour plus d'informations à ce sujet.
Si vous pouvez résoudre le problème, c'est un avertissement. Si cela empêche la poursuite de l'exécution, c'est une erreur.
Je vous recommande d'adopter les niveaux de gravité Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Voir http://en.wikipedia.org/wiki/Syslog#Severity_levels
Ils doivent fournir des niveaux de gravité suffisamment 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 ex. DEBUG, ERROR, EMERGENCY en fonction des besoins de votre application.
Standardisons sur quelque chose qui existe depuis des siècles au lieu de créer notre propre norme pour chaque application que nous créons. Une fois que vous commencez à agréger les journaux et que vous essayez de détecter des modèles parmi différents, cela aide vraiment.
Avertissements que 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, supposons que vous entrez/importiez le nom "Angela Müller" dans votre application (notez le tréma sur la u). Votre code/base de données peut être uniquement en anglais (bien qu'il soit probablement ne devrait pas être de nos jours) et peut donc avertir que tous les caractères "inhabituels" ont été convertis en caractères anglais normaux.
Comparez cela à 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 d'affilée. 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.
En développement, j'utilise fréquemment des avertissements dans lesquels je pourrais mettre l'équivalent d'un échec d'assertion mais où l'application peut continuer à fonctionner; cela me permet de savoir si cela se produit réellement ou si c'est mon imagination.
Mais oui, cela concerne les aspects de récupération et d’actualité. Si vous pouvez récupérer, c'est probablement un avertissement; si cela fait échouer quelque chose, c'est une erreur.
Je pense que les niveaux SYSLOG AVIS 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 susceptible de déclencher des actions et des notifications différentes. FATAL. Et je ne peux tout simplement pas distinguer suffisamment entre recevoir un avis ou une information. Si les informations ne sont pas remarquables, ce n'est pas vraiment des informations :)
J'aime mieux l'interprétation de Jay Cincotta - le suivi technique de l'exécution de votre code est quelque chose de très utile pour le support technique. Il est également conseillé de placer des instructions de trace dans le code de manière libérale - en particulier en combinaison avec un mécanisme de filtrage dynamique pour la journalisation des messages de trace de composants d'application spécifiques. Cependant, pour moi, le niveau DEBUG indique que nous sommes toujours en train de déterminer ce qui se passe. Je vois la sortie du niveau DEBUG comme une option réservée au développement, et non comme quelque chose qui ne devrait jamais figurer 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 autant le chapeau d'un administrateur système que celui du support technique, voire du développeur: OPER, pour les messages OPERATIONAL. Je l’utilise pour consigner un horodatage, le type d’opération invoqué, les arguments fournis, éventuellement un identificateur de tâche (unique) et l’achèvement de la tâche. Il est utilisé par exemple une tâche autonome est déclenchée, ce qui constitue une véritable invocation à partir de l'application longue et longue. C’est le genre de chose que je veux toujours consigner, peu importe si quelque chose ne va pas ou pas, je considère donc que le niveau d’opération est supérieur à FATAL. Vous ne pouvez donc l’éteindre 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 contenant des messages opérationnels mineurs sans valeur historique.
Selon le cas, ces informations peuvent être dirigées vers un journal d'appel distinct ou peuvent être obtenues en les filtrant dans un journal volumineux enregistrant plus d'informations. Mais il est toujours nécessaire, en tant qu’information historique, de savoir ce qui se passait - sans descendre au niveau de AUDIT, un autre niveau de journal totalement séparé qui n’a rien à voir avec les 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 certainement besoin de son propre fichier journal séparé.
De Ietf - Page 10
Each message Priority also has a decimal Severity level indicator.
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
Une erreur est quelque chose qui ne va pas, tout simplement faux, il n'y a pas moyen de la contourner, il faut la corriger.
Un avertissement est le signe d'un motif qui pourrait être erroné, mais qui pourrait ne pas l'être.
Cela dit, je ne peux pas proposer un bon exemple d’avertissement qui ne soit pas aussi une erreur. Ce que je veux dire par là, c'est que si vous prenez la peine de vous connecter à un avertissement, vous pouvez tout aussi bien résoudre le problème sous-jacent.
Cependant, des choses comme "l'exécution de SQL prend trop de temps" peuvent être un avertissement, alors que "les blocages de l'exécution de SQL" sont une erreur, alors peut-être qu'il y a des cas après tout.
Je suis tout à fait d'accord avec les autres et je pense que GrayWizardx l'a dit.
Tout ce que je peux ajouter, c'est que ces niveaux correspondent généralement à la définition de leur dictionnaire, ce qui ne peut pas être si difficile. En cas de doute, traitez-le comme un casse-tête. Pour votre projet particulier, pensez à tout ce que vous voudrez peut-être consigner.
Maintenant, pouvez-vous comprendre ce qui pourrait être fatal? Vous savez ce que fatale signifie, n'est-ce pas? Alors, quels éléments de votre liste sont fatals.
Ok, c'est fatal, maintenant regardons les erreurs ... rincez et répétez.
Au-dessous de Fatal, ou peut-être d'Erreur, je suggérerais que plus d'informations sont toujours meilleures que moins, alors err "vers le haut". Vous ne savez pas si c'est Info ou Avertissement? Alors faites-en un avertissement.
Je pense que Fatal et l'erreur devraient être clairs pour nous tous. Les autres sont peut-être plus confus, mais il est sans doute moins essentiel de les corriger.
Voici quelques exemples:
Fatal - ne peut pas allouer de la mémoire, une base de données, etc. - ne peut pas continuer.
Error - pas de réponse au message, transaction annulée, impossible de sauvegarder le fichier, etc.
Attention - l'allocation des ressources atteint X% (disons 80%) - c'est un signe que vous pourriez vouloir redimensionner votre.
Info - utilisateur connecté/déconnecté, nouvelle transaction, fichier créé, nouveau champ d/b ou champ supprimé.
Debug - sauvegarde de la structure de données interne, niveau de trace Anything avec nom de fichier et numéro de ligne.
Trace - action réussie/échouée, d/b mis à jour.
J'ai toujours envisagé d'avertir le premier niveau de journal, ce qui signifie certainement qu'il y a un problème (par exemple, un fichier de configuration n'est peut-être pas ce qu'il devrait être et nous allons devoir fonctionner avec les paramètres par défaut). Une erreur implique, pour moi, quelque chose qui signifie que l'objectif principal du logiciel est maintenant impossible et nous allons essayer de fermer proprement.
G'day
En corollaire à cette question, communiquez vos interprétations des niveaux de journalisation et assurez-vous que toutes les personnes participant à un projet sont alignées sur leur interprétation des niveaux.
Il est pénible de voir une grande variété de messages de journal où les sévérités et les niveaux de journal sélectionnés sont incohérents.
Fournissez si possible des exemples des différents niveaux de journalisation. Et soyez cohérent dans les informations pour être connecté dans un message.
HTH
J'ai déjà construit des systèmes qui utilisent les éléments suivants:
- ERREUR - signifie que quelque chose ne va pas du tout et que ce processus/processus/séquence ne peut pas continuer. Une intervention de l'utilisateur/administrateur est requise
- AVERTISSEMENT - quelque chose ne va pas, mais le processus peut continuer comme avant (par exemple, un travail sur 100 a échoué, mais le reste peut être traité)
Dans les systèmes que j'ai construits, les administrateurs étaient sous l'instruction de réagir aux erreurs. D'autre part, nous surveillerions les AVERTISSEMENTS et déterminerions pour chaque cas si des modifications du système, des reconfigurations, etc. étaient nécessaires.
En passant, je suis un grand fan de tout capturer et de filtrer les informations plus tard.
Que se passerait-il si vous capturiez au niveau Avertissement et que vous vouliez des informations de débogage liées à l'avertissement, sans pouvoir recréer l'avertissement?
Capturez tout et filtrez plus tard!
Cela est vrai même pour les logiciels embarqués, sauf si vous constatez que votre processeur ne peut pas suivre le rythme. Dans ce cas, vous voudrez peut-être redéfinir votre traçage pour le rendre plus efficace, ou si le traçage interfère avec le minutage pourrait envisager de déboguer sur un processeur plus puissant, mais cela ouvre toute une boîte de Pandore).
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 montrer la trace de débogage (je dessine des graphiques 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 en cas de problème future (conservez tous les journaux, qu’ils soient réussis ou non, et assurez-vous d’inclure le numéro de build dans le fichier journal)).
Je suggère d'utiliser seulement trois niveaux
- Fatal - Ce qui casserait l'application.
- Info - Info
- Debug - Informations moins importantes