Journalisation vs débogage

Question

Arrière-plan : j'ai hérité d'une application Web destinée à créer des connexions à la volée entre des équipements locaux et distants. Il y a récemment un très grand nombre de pièces mobiles: l'application elle-même a considérablement changé; la chaîne d'outils de développement vient d'être mise à jour; et les équipements locaux et distants ont été "modifiés". pour supporter ces changements.

Le bon côté des choses est qu’il dispose d’un système de journalisation raisonnable qui écrit les messages de débogage dans un fichier et se connecte à la fois au fichier et à un écran d’utilisateur en temps réel. J'ai l'occasion de retravailler tout le mécanisme de journalisation / débogage.

Exemples:

• Tous les messages sont horodatés et préfixés par un niveau de gravité.
• Les journaux sont pour le client. Ils enregistrent les réponses du système à ses demandes.
• Tout journal identifiant un problème suggère également une solution.
• Les débogues sont destinées aux développeurs et au support technique. Ils révèlent les éléments internes du système.
• Les debugs indiquent la fonction et / ou la ligne qui les a générés.
• Le client peut ajuster le niveau de débogage à la volée pour définir la verbosité.

Question: Quelles sont les meilleures pratiques que vous avez utilisées en tant que développeur ou vues en tant que consommateurs et qui génèrent des journaux et des débogages utiles?

Modifier: De nombreuses suggestions utiles à ce jour, merci! Pour clarifier: je suis plus intéressé par ce que consigner: le contenu, le format, etc .-- et les raisons de le faire - que par des outils spécifiques.

En quoi les meilleurs journaux que vous avez vus ont été les plus utiles?

Merci de votre aide!

Answer 1

La chose la plus utile avec n'importe quel cadre de journalisation est un "1 clic". outil qui rassemble tous les journaux et me les envoie même lorsque l'application est déployée sur une machine appartenant à un client.

Et faites des choix judicieux en matière de journalisation afin de pouvoir suivre en gros les principaux chemins de votre application.

En tant que frameworks, j'ai utilisé les standards (log4net, log4java, log4c ++)

N'implémentez PAS votre propre cadre de journalisation, lorsqu'il en existe déjà un bon. La plupart des gens qui réinventent simplement la roue.

Answer 2

Certaines personnes n'utilisent jamais de débogueur mais enregistrent tout. Ce sont des philosophies différentes, vous devez faire votre propre choix. Vous pouvez trouver de nombreux conseils comme ceux-ci , ou celui-ci . Notez que ces conseils ne sont pas liés à la langue ...

coder un type d'horreur a reçu un article intéressant sur le problème de journalisation et la raison pour laquelle une journalisation abusive pourrait être une perte de temps pour certains conditions.

Je pense simplement que la journalisation permet de rechercher des éléments susceptibles de rester en production. Le débogage est pour le développement. C’est peut-être une façon trop simple de voir les choses, car certaines personnes utilisent des journaux pour le débogage car elles ne supportent pas les débogueurs. Mais le mode débogueur peut aussi être une perte de temps: vous n’avez pas besoin de l’utiliser comme une sorte de test, car il n’est pas écrit et disparaîtra après la session de débogage.

Je pense donc que mon opinion à ce sujet est la suivante:

• enregistrement des traces nécessaires et utiles dans les environnements de développement et de production, avec niveaux de développement et de production, à l'aide d'un cadre de journalisation (outils de la famille log4 )
• mode de débogage pour les cas particuliers étranges où des choses deviennent incontrôlables
Les cas de test
• sont importants et permettent de gagner du temps lors de sessions de débogage labyrinthiques infernales, utilisées comme méthode anti-régression. Notez que la plupart des gens n'utilisent pas de cas de test.

L'horreur de codage a déclaré résister à la tendance à tout enregistrer . C'est vrai, mais j'ai déjà vu une application géniale qui fait exactement le contraire d'une jolie manière (et grâce à une base de données) ...

Answer 3

Ne confondez pas la journalisation, le traçage et le signalement des erreurs, certaines personnes que je connais connaissent bien, ce qui crée un fichier de log en diable à travers lequel grep pour obtenir les informations que je souhaite.

Si je veux que tout soit produit, je distingue les points suivants:

  

  
• Traçage - > Vide chaque action et chaque étape, horodaté, avec entrée et   données de sortie de cette étape (la plus moche et   le plus grand fichier)
  
• Journalisation - > Enregistrer uniquement les étapes du processus technique, le client interroge le client.   les critères d'interrogation et les données de sortie   rien de plus.
  
• Rapport d'erreurs / débogage - > Les exceptions enregistrées en détail où il   eu lieu, horodaté, entrée / sortie   données si possible, informations utilisateur, etc.
  

Ainsi, si des erreurs se produisaient et que le journal des erreurs / de débogage ne contenait pas assez d'informations à mon goût, je peux toujours faire un grep -A 50 -B 50 'timestamp' fichier de traçage pour obtenir davantage d'informations. détail.

MODIFIER: Comme il a également été dit, il est toujours bon de s'en tenir à des packages standard tels que le module de journalisation intégré pour Python. Rouler soi-même n'est pas une bonne idée à moins que le langage n'en ait pas dans sa bibliothèque standard. J'aime bien envelopper la journalisation dans une petite fonction prenant généralement le message et la valeur pour déterminer les journaux auxquels elle va, par exemple. 1 - traçage, 2 - journalisation, 4 - débogage afin d’envoyer une valeur de 7 chutes à tous les 3 etc.

Answer 4

Je voudrais simplement configurer votre système de journalisation pour qu'il comporte plusieurs niveaux de journalisation. Sur les services que j'écris, j'ai un journal / audit pour presque chaque action et un niveau d'audit 1-5 lui est attribué. Plus le nombre est élevé, plus vous obtenez d'événements d'audit .

1. La journalisation très basique: démarrer, arrêter et redémarrer
2. Journalisation: traitement x nombre de fichiers, etc.
3. Journalisation standard: début du traitement, traitement terminé, etc.
4. Journalisation avancée: début et fin de chaque étape du traitement
5. Tout: toutes les actions entreprises

vous définissez le niveau d'audit dans un fichier de configuration afin qu'il puisse être modifié à la volée.

Answer 5

Certaines règles générales que j'ai trouvées utiles dans les applications côté serveur:

• requestID : attribuez un identifiant de requête à chaque requête entrante (HTTP), puis enregistrez-le sur chaque ligne du journal afin de pouvoir facilement les graper ultérieurement par cet ID et rechercher toutes les lignes pertinentes. Si vous pensez qu’il est très fastidieux d’ajouter cet ID à chaque instruction de journal, alors au moins les infrastructures de journalisation Java l’ont rendue transparente avec l’utilisation de Contexte de diagnostic mappé (MDC).
• objectID - si votre application / service traite de la manipulation d'objets de gestion dotés d'une clé primaire, il est utile d'associer également cette clé primaire au contexte de diagnostic. Plus tard, si quelqu'un vient avec la question "Quand cet objet a-t-il été manipulé?" vous pouvez facilement grep par objectID et voir tous les enregistrements de journal liés à cet objet. Dans ce contexte, il est (parfois) utile d’utiliser le contexte de diagnostic imbriqué au lieu de MDC. .
• quand vous connecter? , vous devriez au moins vous connecter chaque fois que vous franchissez une limite importante de service / composant. De cette façon, vous pourrez reconstruire ultérieurement le flux d'appels et accéder au code source particulier qui semble provoquer l'erreur.

En tant que développeur Java, je vais également vous faire part de mon expérience avec les API et les frameworks Java.

API

Je vous conseillerais d'utiliser Façade de journalisation simple pour Java (SLF4J). est la meilleure façade pour la journalisation:

• complet: il n’a pas suivi l’approche du plus petit dénominateur commun (comme l’enregistrement commun); au lieu de cela, il utilise dégrader avec grâce
• possède des adaptateurs pour pratiquement tous les frameworks de journalisation Java courants (par exemple, log4j)
• a des solutions disponibles sur la manière de rediriger toutes les API de journalisation héritées (log4j, commons-logging) vers SLF4J

Mise en œuvre La meilleure implémentation à utiliser avec SLF4J est logback - écrite par le même gars qui a également créé l'API SLF4J.

Answer 6

Utilisez un format de journalisation existant, tel que celui utilisé par Apache, et vous pourrez ensuite utiliser les nombreux outils disponibles pour analyser le format.