L' approche structurée présente deux avancées fondamentales qui ne peuvent pas être émulées à l'aide de journaux de texte sans effort supplémentaire (parfois extrême).
Types d'événements
Lorsque vous écrivez deux événements avec log4net comme:
log.Debug("Disk quota {0} exceeded by user {1}", 100, "DTI-Matt");
log.Debug("Disk quota {0} exceeded by user {1}", 150, "nblumhardt");
Ceux-ci produiront un texte similaire:
Disk quota 100 exceeded by user DTI-Matt
Disk quota 150 exceeded by user nblumhardt
Mais, en ce qui concerne le traitement par machine, ce ne sont que deux lignes de texte différent.
Vous souhaiterez peut-être rechercher tous les événements "quota de disque dépassé", mais le cas simpliste de recherche d'événements like 'Disk quota%'
tombera dès qu'un autre événement se produisant ressemblant à ceci:
Disk quota 100 set for user DTI-Matt
La journalisation de texte supprime les informations dont nous disposions initialement sur la source de l'événement. Cette information doit être reconstituée lors de la lecture des journaux, généralement avec des expressions de correspondance de plus en plus élaborées.
En revanche, lorsque vous écrivez les deux événements Serilog suivants :
log.Debug("Disk quota {Quota} exceeded by user {Username}", 100, "DTI-Matt");
log.Debug("Disk quota {Quota} exceeded by user {Username}", 150, "nblumhardt");
Celles-ci produisent une sortie texte similaire à la version log4net, mais en coulisse, le "Disk quota {Quota} exceeded by user {Username}"
modèle de message est porté par les deux événements.
Avec un récepteur approprié, vous pouvez ultérieurement écrire des requêtes where MessageTemplate = 'Disk quota {Quota} exceeded by user {Username}'
et obtenir exactement les événements pour lesquels le quota de disque a été dépassé.
Il n'est pas toujours pratique de stocker le modèle de message entier avec chaque événement de journal. Par conséquent, certains puits modifient le modèle de message en une EventType
valeur numérique (par exemple 0x1234abcd
) ou vous pouvez ajouter un enrichisseur au pipeline de journalisation pour le faire vous-même .
C'est plus subtile que la différence suivante, mais elle est extrêmement puissante lorsqu'il s'agit de traiter de gros volumes de journaux.
Données structurées
Toujours en considérant les deux événements relatifs à l'utilisation de l'espace disque, il peut être assez simple d'utiliser des journaux de texte pour interroger un utilisateur particulier like 'Disk quota' and like 'DTI-Matt'
.
Mais les diagnostics de production ne sont pas toujours aussi simples. Imaginez qu'il soit nécessaire de trouver des événements où le quota de disque dépassé était inférieur à 125 Mo?
Avec Serilog, cela est possible dans la plupart des éviers en utilisant une variante de:
Quota < 125
Construire ce type de requête à partir d'une expression régulière est possible, mais cela fatigue vite et finit généralement par être une mesure de dernier recours.
Ajoutez maintenant à cela un type d'événement:
Quota < 125 and EventType = 0x1234abcd
Vous commencez à voir ici comment ces fonctionnalités se combinent de manière simple pour que le débogage de la production à l'aide de journaux ressemble à une activité de développement de premier ordre.
Un autre avantage, peut-être moins facile à éviter au début, mais une fois que le débogage de la production est sorti du domaine du piratage des expressions rationnelles, les développeurs commencent à valoriser davantage les journaux et à faire preuve de plus de soin et de considération lorsqu'ils les écrivent. De meilleurs journaux -> des applications de meilleure qualité -> plus de bonheur tout autour.