Quand utiliser les différents niveaux de journalisation

520

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?

raoulsson
la source
11
Question assez large. Ainsi, plusieurs réponses sont possibles, selon les circonstances réelles de la journalisation. Quelqu'un va manquer noticedans cette collection, quelqu'un ne va pas ...
Wolf
@Wolf où «remarquer» tomberait-il dans cette hiérarchie? Juste pour mémoire ...
pgblu
1
noticepourrait bien manquer car certains services de journalisation populaires comme log4j ne l'utilisent pas.
pgblu

Réponses:

750

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.
GrayWizardx
la source
2
Pourquoi ne pouvez-vous pas fusionner les informations et avertir! ??! N'est pas un avertissement sur quelque chose de réellement "info" ...
MP.
35
@mP Vous pouvez fusionner les informations et les avertir, je suppose qu'elles sont généralement séparées en raison du principe de "panique". Si j'ai un tas d'informations c'est une routine et que je ne fais que lister l'état, ça ne vaut pas vraiment la peine de regarder "en premier", mais s'il y a des tonnes "d'avertissements", je veux voir ceux qui sont prioritaires (après les erreurs et les fatals) afin que je puisse examiner leur. Je serais plus "paniqué" à beaucoup d'avertissements qu'à beaucoup de messages d'information.
GrayWizardx
3
@dzieciou cela dépend de vos besoins particuliers. Parfois, cela peut être fatal, parfois un avertissement grave. Si j'ai obtenu un 4xx d'un service critique dont je dépend et que je ne peux pas continuer, ce serait une erreur / fatal pour mes conceptions. Si j'essayais de mettre en cache certaines données pour une utilisation ultérieure, mais que je pouvais vivre sans, ce serait un avertissement. La seule fois où je vois qu'il s'agit d'informations serait pour quelque chose comme une application de surveillance qui signale l'état de ses vérifications d'URL. Je voudrais donc INFO enregistrer que j'ai obtenu un 4xx de l'URL et continuer.
GrayWizardx
2
@GrayWizardx, je pense que l'autre facteur est de savoir si c'est le client qui a reçu 4xx ou le serveur qui l'a envoyé. Dans le premier cas, je serais plus disposé à utiliser ERROR (OMG, c'est ma faute, je ne peux pas préparer la bonne demande), tandis que dans le dernier cas, je me connecterais WARN (c'est la faute des clients, ils ne peuvent pas formuler correctement les demandes)
dzieciou
4
Je soupçonne que c'est vrai - Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).. Logger.Debug est uniquement destiné aux développeurs pour détecter des problèmes très désagréables en production, par exempleIf you want to print the value of a variable at any given point inside a for loop against a condition
RBT
304

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

  • oui -> erreur
  • non -> avertir
pm100
la source
11
Sauf que la plupart des gens ne se soucient pas de sortir du lit la nuit. Nous avons demandé à des clients d'augmenter les niveaux de gravité 1 (destinés à 100% de pannes, c'est-à-dire nationaux) parce qu'un site ne pouvait pas faire leur travail (leur raisonnement était que c'était 100% de ce site). Nous les avons depuis «éduqués» sur ce point.
paxdiablo
53
FATALc'est quand l'administrateur système se réveille, décide qu'il n'est pas suffisamment payé pour cela et se rendort.
Mateen Ulhaq
135

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.

Jay Cincotta
la source
3
J'aime que cela souligne de penser au public. La clé de toute communication (et les messages du journal sont une forme de communication) est de penser à votre public et à ses besoins.
sleske
18
À propos de Debug <-> Trace: Notez qu'au moins en Java-land, l'ordre de priorité est "debug> trace". C'est la convention que tous les frameworks de journalisation que je connais utilisent (SLF4J, Logback, log4j, Apache Commons Logging, Log4Net, NLog). Debug <Trace me semble donc inhabituel.
sleske
1
@Jay Cincotta Excellente réponse. Je pense que Debug / Trace est une question de préférence, mais ce type de détails a tendance à être spécifique à l'application / à l'entreprise, donc il est bon de voir des opinions divergentes.
GrayWizardx
5
Je viens de faire une enquête sur 7 cadres de journalisation dans plusieurs langues. Sur les trois qui incluent un niveau de gravité "trace", tous le considèrent comme moins sévère que le débogage. c'est-à-dire, trace <debug; Je n'ai pas de cas concrets où l'inverse est vrai. @RBT Il n'est pas toujours possible de s'introduire dans un débogueur. Par exemple, les serveurs Web doivent répondre aux demandes dans un laps de temps limité, ou exister dans des environnements multithread et / ou serveur qui peuvent être difficiles à instrumenter, ou le bogue peut être suffisamment rare pour qu'un débogueur ne soit pas une option. Ou vous ne savez pas ce que vous cherchez.
Thanatos
5
@RBT Je travaille avec des systèmes Java depuis plus de 4 ans. Je peux vous dire que ce que vous demandez est totalement irréalisable. Le débogage IDE ne peut vous emmener jusqu'ici. À un certain moment, vous avez simplement besoin de journaux de débogage d' un autre système (souvent un serveur de production ) afin de comprendre ce qui se passe et de corriger le bogue. Vous pouvez penser qu'il devrait être reproductible dans votre IDE local, mais si vous travaillez avec de vrais systèmes, vous constaterez que souvent de nombreux bogues sont uniques au serveur de production.
ADTC du
30

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. trace1trace6 :

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

Pacerier
la source
24

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

Ignacio Vazquez-Abrams
la source
5
Mais alors, quelle est la différence entre l'erreur et l'erreur fatale?
user192472
37
Une erreur est quelque chose que vous faites (par exemple, lire un fichier inexistant), une erreur fatale est quelque chose qui vous est fait (par exemple, manque de mémoire).
Ignacio Vazquez-Abrams
@ IgnacioVazquez-Abrams J'aime votre façon de distinguer. Mais quel est votre commentaire est basé sur quoi? AFIAK chez les développeurs iOS, c'est la convention d'écrire une assertion qui se rapporte à fatalErrorquand un fichier n'existe pas. Fondamentalement, c'est le contraire de ce que vous avez dit.
Honey
@Honey: Dans une situation mobile, il est raisonnable de considérer un fichier manquant comme une erreur fatale.
Ignacio Vazquez-Abrams
23

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.

kvz
la source
1
J'ai besoin d'un journal de suivi car je veux voir comment les choses s'exécutent dans mon code. Que fait syslog pour résoudre ce problème?
K - La toxicité du SO augmente.
Les traces ne sont généralement pas quelque chose que vous voudriez transmettre via syslog et je pense que vous êtes libre d'ajouter ce niveau pour vos propres sessions de débogage interactif?
kvz
2
Tous ces niveaux étendus augmentent la complexité de la journalisation OMI. Il est préférable de s'en tenir à l'ensemble le plus simple répondant aux besoins de l'application spécifique. Pour moi, vous devriez commencer par DEBUG, INFO, WARNINGet ERROR. Les développeurs devraient voir tous les niveaux. Les administrateurs système INFOet les utilisateurs finaux peuvent voir les avertissements et les erreurs, mais uniquement s'il existe un cadre pour les alerter à ce sujet .
2017 ADTC
1
(suite) Au fur et à mesure que l'application grandit, vous pouvez étendre à d'autres niveaux si nécessaire. Comme les deux DEBUGet TRACEpour les développeurs de contrôler la granularité. Et ERRORétendus à d' autres niveaux comme CRITICAL, ALERT, EMERGENCYde distinguer la gravité des erreurs et déterminer l'action en fonction de la gravité.
2017 ADTC
17

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.

paxdiablo
la source
Si la base de données est dans un certain jeu de caractères qui n'inclut pas le tréma, cette entrée doit être rejetée.
Cochise Ruhulessin
Cochise, le monde est rarement aussi noir et blanc :-)
paxdiablo
6

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.

Michael Ekstrand
la source
5

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.

volkerk
la source
5

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
ThangTD
la source
4

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

Rob Wells
la source
4

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.

Mawg dit réintégrer Monica
la source
3

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.

Lasse V. Karlsen
la source
1
Un bon exemple d'avertissement est que dans MySQL, par défaut, si vous essayez d'insérer plus de caractères dans un varcharpour lequel il est défini, il vous avertit que la valeur a été tronquée, mais l'insère toujours. Mais l'avertissement d'une personne peut être une erreur d'une autre: dans mon cas, c'est une erreur; cela signifie que j'ai fait une erreur dans mon code de validation en définissant une longueur incongrue avec la base de données. Et je ne serais pas terriblement surpris si un autre moteur DB considérait cela comme une erreur, et je n'aurais pas vraiment le droit de m'indigner, après tout, c'est erroné.
Crast
Moi aussi, je considérerais cela comme une erreur. Dans certains cas, le contenu est du "texte" (pas dans le sens du type de données), ce qui signifie qu'il est peut - être OK de le tronquer. Dans un autre cas, c'est un code, où couper des bits le corrompra ou changera sa signification, ce qui n'est pas correct. À mon avis, ce n'est pas au logiciel d'essayer de deviner ce que je voulais dire. Si j'essaye de forcer une chaîne de 200 caractères dans une colonne qui ne prend que 150 caractères, c'est un problème que j'aimerais savoir. Cependant, j'aime la distinction faite par d'autres ici, que si vous pouvez récupérer, c'est un avertissement, mais alors ... devez-vous vous connecter?
Lasse V. Karlsen
Un exemple auquel je pourrais penser est: un message prenant un temps étonnamment plus long à traiter que d'habitude. Cela pourrait indiquer que quelque chose ne va pas (peut-être qu'un autre système est surchargé ou qu'une ressource externe est temporairement en panne).
Laradda
3

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.

dicroce
la source
1

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.

Brian Agnew
la source
1

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

Mawg dit réintégrer Monica
la source
1

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.

Eugen Konkov
la source
0

Je suggère d'utiliser seulement trois niveaux

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