Je travaille avec des systèmes de sécurité en temps réel critiques et la journalisation est souvent le seul moyen d'attraper les bugs rares qui apparaissent une fois par lune bleue tous les 53 mardis, quand c'est la pleine lune, si vous voyez ce que je dérive. Cela vous rend obsédé par le sujet, alors je vais m'excuser si je commence à mousser à la bouche. Ce qui suit a été écrit pour les journaux de débogage de code natif, mais la plupart d'entre eux sont également applicables au monde géré ...
Utilisez des fichiers journaux de texte. Cela semble évident, mais certaines personnes essaient de générer des fichiers journaux binaires: c'est idiot, car je n'ai pas besoin de rechercher un outil de lecture lorsque je suis sur le terrain. De plus, si c'est du texte et que le débogage est prolixe, l'ingénieur de terrain a de bonnes chances de lire le fichier et de diagnostiquer le problème sans jamais revenir à moi. Tout le monde gagne.
Je conçois des systèmes capables de tout enregistrer, mais je ne les allume pas par défaut. Les informations de débogage sont envoyées à une boîte de dialogue de débogage masquée qui les horodate et les envoie dans une zone de liste (limitée à environ 500 lignes avant suppression). Cette boîte de dialogue me permet de les arrêter, de les enregistrer automatiquement dans un fichier journal ou de les rediriger vers un débogueur attaché. Ce détournement me permet de voir la sortie de débogage de plusieurs applications parfaitement sérialisées, ce qui peut parfois sauver la vie. J'avais l' habitude d'utiliser des niveaux de journalisation numériques (plus vous définissez le niveau, plus vous en capturez):
off
errors only
basic
detailed
everything
mais ceci est trop inflexible - au fur et à mesure que vous avancez vers un bogue, il est beaucoup plus efficace de pouvoir vous connecter en vous connectant exactement à ce dont vous avez besoin sans avoir à parcourir des tonnes de détritus, et il peut s'agir d'un type de transaction ou d'opération particulier cela cause l'erreur. Si cela vous oblige à tout activer, vous ne faites que rendre votre travail plus difficile. Vous avez besoin de quelque chose de plus fin.
Alors maintenant, je suis en train de passer à la journalisation basée sur un système de drapeau. Tout ce qui est consigné a un drapeau détaillant son type d’opération, et un ensemble de cases à cocher me permettant de définir ce qui est consigné. Typiquement cette liste ressemble à ceci:
#define DEBUG_ERROR 1
#define DEBUG_BASIC 2
#define DEBUG_DETAIL 4
#define DEBUG_MSG_BASIC 8
#define DEBUG_MSG_POLL 16
#define DEBUG_MSG_STATUS 32
#define DEBUG_METRICS 64
#define DEBUG_EXCEPTION 128
#define DEBUG_STATE_CHANGE 256
#define DEBUG_DB_READ 512
#define DEBUG_DB_WRITE 1024
#define DEBUG_SQL_TEXT 2048
#define DEBUG_MSG_CONTENTS 4096
Ce système de journalisation est livré avec la version validée, activée et sauvegardée dans un fichier par défaut. Il est trop tard pour savoir que vous auriez dû vous connecter APRÈS le bogue, si ce bogue ne se produit que tous les six mois en moyenne et que vous ne pouvez pas le reproduire. La journalisation qui fonctionne uniquement avec les versions de débogage est juste. plaine. stupide.
Le logiciel est généralement livré avec ERROR, BASIC, STATE_CHANGE et EXCEPTION activé, mais cela peut être modifié dans le champ via la boîte de dialogue de débogage (ou un paramètre registry / ini / cfg, où ces éléments sont enregistrés).
Oh et une chose - mon système de débogage génère un fichier par jour. Vos exigences peuvent être différentes. Mais assurez-vous que votre code de débogage commence chaque fichier avec la date, la version du code que vous utilisez, et si possible un marqueur pour l'ID client, l'emplacement du système ou autre. Vous pouvez obtenir un méli-mélo de fichiers journaux provenant du terrain, et vous avez besoin de savoir ce qui vient d'où et quelle version du système qu'ils utilisaient qui est réellement dans les données elles-mêmes, et vous ne pouvez pas faire confiance au client. / ingénieur de terrain pour vous dire quelle version ils ont - ils peuvent simplement vous dire quelle version ils pensent. Pire, ils peuvent signaler la version exe présente sur le disque, mais l'ancienne version est toujours en cours d'exécution car ils ont oublié de redémarrer après le remplacement. Demandez à votre code de vous dire lui-même.
Enfin, vous ne voulez pas que votre code génère ses propres problèmes, installez donc une fonction de minuterie pour purger les fichiers journaux après tant de jours ou de semaines (vérifiez simplement la différence entre l'heure actuelle et l'heure de création du fichier). Cela convient pour une application serveur qui fonctionne tout le temps. Sur une application côté client, vous pouvez vous en servir pour purger les anciennes données au démarrage. Nous purgeons généralement après 30 jours environ, sur un système ne nécessitant pas de visites d'ingénieur fréquentes, vous souhaiterez peut-être le laisser plus longtemps. Évidemment, cela dépend également de la taille de vos fichiers journaux.