Les fichiers journaux sont une partie essentielle de toute application sérieuse: si la journalisation dans l'application est bonne, ils vous permettent de voir quels événements clés sont survenus et quand; quelles erreurs se sont produites; et l’intégrité générale de l’application qui va au-delà de ce que la surveillance a été conçue. Il est courant d’entendre parler d’un problème, de vérifier les diagnostics intégrés de l’application (ouvrez sa console Web ou d’utiliser un outil de diagnostic tel que JMX), puis de vérifier la configuration. les fichiers journaux.
Si vous utilisez un format autre que texte, vous vous trouvez immédiatement face à un obstacle: comment lire les journaux binaires? Avec l'outil de lecture de journaux, qui n'est pas sur vos serveurs de production! Ou alors, mais oh mon Dieu, nous avons ajouté un nouveau champ et voici l'ancien lecteur. N'avons-nous pas testé cela? Oui, mais personne ne l'a déployé ici. Pendant ce temps, votre écran commence à s'allumer et les utilisateurs vous envoient une requête ping.
Ou peut-être que ce n'est pas votre application, mais vous apportez un soutien et vous pensez savoir que c'est cet autre système, et WTF? les journaux sont au format binaire? Ok, commencez à lire les pages du wiki et par où commencez-vous? Maintenant, je les ai copiées sur mon ordinateur local, mais - elles sont corrompues? Ai-je fait une sorte de transfert non binaire? Ou bien l'outil de lecture de journaux est-il foiré?
En bref, les outils de lecture de texte sont multi-plateformes et omniprésents, et les journaux ont souvent une longue durée de vie et doivent parfois être lus rapidement . Si vous inventez un format binaire, vous êtes coupé de tout un monde d'outils bien compris et faciles à utiliser. Perte sérieuse de fonctionnalité au moment où vous en avez besoin.
La plupart des environnements de journalisation trouvent un compromis: garder les journaux actuels lisibles et présents, et compresser les plus anciens. Cela signifie que vous bénéficiez de la compression, d'autant plus qu'un format binaire ne réduirait pas les messages du journal. Dans le même temps, vous pouvez utiliser less et grep , etc.
Alors, quels sont les avantages possibles de l’utilisation du binaire? Une petite quantité d'efficacité de l'espace - de plus en plus sans importance. Moins (ou plus petit) écrit? En fait, le nombre d'écritures dépendra du nombre de validations de disque. Par conséquent, si les lignes de journal sont nettement plus petites que la taille du bloc de disque, un disque SSD affectera de nouveaux blocs de toute façon. Donc, le binaire est un choix approprié si:
- vous écrivez d'énormes quantités de données structurées
- les journaux doivent être créés particulièrement rapidement
- il est peu probable que vous ayez besoin de les analyser dans des "conditions d'assistance"
mais cela ressemble moins à la journalisation d'application; ce sont des fichiers de sortie ou des enregistrements d'activité. Les mettre dans un fichier ne représente probablement qu'une étape de leur écriture dans une base de données.
MODIFIER
Je pense qu'il y a une confusion générale entre "journaux de programme" (selon les cadres de journalisation) et "enregistrements" (comme dans les journaux d'accès, les enregistrements de connexion, etc.). Je soupçonne que la question se rapporte le plus étroitement à la dernière, et dans ce cas la question est beaucoup moins bien définie. Il est parfaitement acceptable qu'un enregistrement de message ou un journal d'activité soit dans un format compact, d'autant plus qu'il est susceptible d'être bien défini et utilisé pour l'analyse plutôt que pour le dépannage. Les outils qui font cela incluent tcpdump
et le moniteur système Unix sar
. Les journaux de programme, d’autre part, ont tendance à être beaucoup plus ponctuels.