Pourquoi la plupart des fichiers journaux utilisent-ils du texte brut plutôt qu'un format binaire?
La journalisation est quelque chose de nécessaire mais qui est (relativement) rarement utilisée. En tant que tel, il peut être rendu beaucoup plus compact en termes de stockage.
Par exemple, les données les plus communément enregistrées, telles que l'adresse IP, la date, l'heure et d'autres données pouvant être représentées sous forme d'entier, sont stockées sous forme de texte.
Si la journalisation était stockée sous forme de données binaires, beaucoup d'espace pourrait être préservé, ce qui nécessiterait moins de rotation et augmenterait la durée de vie du disque, en particulier avec les SSD où les écritures sont limitées.
Certains peuvent dire que c'est une question tellement mineure qu'elle n'a pas vraiment d'importance, mais compte tenu des efforts nécessaires pour mettre en place un tel mécanisme, cela n'a aucun sens de ne pas le faire. N'importe qui peut faire ça pendant environ deux jours pendant son temps libre, pourquoi les gens ne font-ils pas ça?
systemd stocke ses fichiers journaux au format binaire. Les principaux problèmes que j'ai entendus sont les suivants:
- si le journal est corrompu, il est difficile de récupérer car il a besoin d'outils spécialisés
- ils ne sont pas lisibles par l'homme, vous ne pouvez donc pas utiliser d'outils standard tels que
vi,grep,tailetc. pour les analyser
La principale raison de l'utilisation d'un format binaire (à ma connaissance) était qu'il était jugé plus facile de créer des indices, etc., c'est-à-dire de le traiter plus comme un fichier de base de données.
Je dirais que l'avantage d'espace disque est relativement petit (et décroissant) dans la pratique. Si vous souhaitez stocker de grandes quantités de journalisation, la fermeture à glissière des journaux roulés est vraiment très efficace.
Dans l'ensemble, les avantages de l'outillage et de la familiarité se tromperaient probablement du côté de la journalisation de texte dans la plupart des cas.
Pourquoi la plupart des fichiers journaux utilisent-ils du texte brut plutôt qu'un format binaire?
Recherchez le mot "texte" dans l'article philosophie Unix Wikipedia, par exemple, vous trouverez des déclarations comme:
McIlroy, alors chef du Bell Labs CSRC (Computing Sciences Research Center), et inventeur de la pipe Unix, [9] a résumé la philosophie Unix comme suit: [10]
C'est la philosophie Unix: écrire des programmes qui font une chose et le font bien. Écrivez des programmes pour travailler ensemble. Écrivez des programmes pour gérer les flux de texte, car il s'agit d'une interface universelle.
Ou par exemple, de Basics of the Unix Philosophy ,
Règle de composition: concevoir des programmes à connecter avec d'autres programmes.
Il est difficile d'éviter de programmer des monolithes trop compliqués si aucun de vos programmes ne peut se parler.
La tradition Unix encourage fortement l'écriture de programmes qui lisent et écrivent des formats simples, textuels, orientés flux et indépendants de l'appareil. Sous Unix classique, autant de programmes que possible sont écrits sous forme de filtres simples, qui prennent un simple flux de texte en entrée et le transforment en un autre flux de texte simple en sortie.
Malgré la mythologie populaire, cette pratique n'est pas privilégiée car les programmeurs Unix détestent les interfaces utilisateur graphiques. C'est parce que si vous n'écrivez pas de programmes qui acceptent et émettent de simples flux de texte, il est beaucoup plus difficile de connecter les programmes ensemble.
Les flux de texte sont vers les outils Unix comme les messages vers les objets dans un cadre orienté objet. La simplicité de l'interface de flux de texte impose l'encapsulation des outils. Des formes plus élaborées de communication inter-processus, telles que les appels de procédure à distance, montrent une tendance à trop impliquer des programmes avec les internes des autres.
N'importe qui peut faire ça pendant environ deux jours pendant son temps libre, pourquoi les gens ne font-ils pas cela?
Le stockage du fichier journal en binaire n'est que le début (et trivial). Vous devrez alors écrire des outils pour:
- Afficher l'intégralité du fichier journal (
edit) - Affiche la fin du journal, sans en lire le début (
tail -f) - Rechercher des éléments dans le fichier (
grep) - Filtre pour afficher uniquement les éléments sélectionnés/intéressants (en utilisant une expression de filtre arbitrairement compliquée)
- Envoyez le journal à quelqu'un d'autre qui n'a pas votre logiciel de décodage de fichier journal
- Copiez-collez un fragment du fichier journal
- Lire le fichier journal pendant que le programme (qui crée le fichier journal) est toujours en cours de développement et de débogage
- Lisez les fichiers journaux des anciennes versions du logiciel (qui sont déployées sur les sites des clients et en cours d'exécution).
De toute évidence, les logiciels peuvent utiliser et utilisent également des formats de fichiers binaires (par exemple pour les bases de données relationnelles), mais cela ne vaut pas la peine (dans un sens YAGNI ), cela ne vaut généralement pas la peine de le faire, car fichiers journaux.
Il y a beaucoup de présomptions discutables ici.
La journalisation fait partie intégrante de (presque) chaque travail que j'ai eu. Il est indispensable si vous souhaitez une visibilité sur la santé de vos applications. Je doute que ce soit une utilisation "marginale"; la plupart des organisations avec lesquelles j'ai participé considèrent les journaux comme très importants.
Le stockage des journaux sous forme binaire signifie que vous devez les décoder avant de pouvoir les lire. Les journaux de texte ont la vertu de simplicité et de facilité d'utilisation. Si vous envisagez la route binaire, vous pouvez également stocker des journaux dans une base de données, où vous pouvez les interroger et les analyser statistiquement.
Les disques SSD sont plus fiables que les disques durs actuels, et les arguments contre de nombreuses écritures sont largement sans objet. Si cela vous inquiète vraiment, stockez vos journaux sur un disque dur ordinaire.
Les fichiers journaux sont une partie critique de toute application sérieuse: si la journalisation dans l'application est bonne, ils vous permettent de voir quels événements clés se sont produits et quand; quelles erreurs se sont produites; et la santé générale de l'application qui va au-delà de la surveillance 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 utilisez un outil de diagnostic comme JMX), puis recourez à la vérification de fichiers journaux.
Si vous utilisez un format non textuel, vous êtes immédiatement confronté à un obstacle: comment lisez-vous les journaux binaires? Avec l'outil de lecture de journaux, qui n'est pas sur vos serveurs de production! Ou c'est le cas, mais oh mon cher, nous avons ajouté un nouveau champ et c'est 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 avec des utilisateurs qui vous cinglent.
Ou peut-être que ce n'est pas votre application, mais vous faites du support et vous pensez que vous savez que c'est cet autre système, et WTF? les journaux sont au format binaire? Ok, commencez à lire les pages wiki, et par où commencer? Maintenant, je les ai copiés sur ma machine locale, mais - ils sont corrompus? Ai-je fait une sorte de transfert non binaire? Ou l'outil de lecture des journaux est-il foiré?
En bref, les outils de lecture de texte sont multiplateformes et omniprésents, et les journaux sont souvent de longue durée et doivent parfois être lus à la hâte . Si vous inventez un format binaire, vous êtes alors coupé de tout un monde d'outils bien compris et faciles à utiliser. Grave perte 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, en fait, qu'un format binaire ne réduirait pas les messages du journal. Dans le même temps, vous pouvez utiliser moins et grep et ainsi de suite .
Alors, quels avantages potentiels pourraient découler de l'utilisation du binaire? Une petite efficacité spatiale - de plus en plus insignifiante. Moins (ou plus petit) écrit? Eh bien, peut-être - en fait, le nombre d'écritures se rapportera au nombre de validations de disque, donc si les lignes de log sont nettement plus petites que la taille de bloc du disque, alors un SSD attribuerait de nouveaux blocs encore et encore de toute façon. Le binaire est donc 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 des applications; ce sont des fichiers de sortie ou des enregistrements d'activité. Les mettre dans un fichier n'est 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 les "journaux de programme" (selon les cadres de journalisation) et les "enregistrements" (comme dans les journaux d'accès, les enregistrements de connexion, etc.). Je soupçonne que la question se rapporte le plus étroitement à ce dernier, 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, en revanche, ont tendance à être beaucoup plus ponctuels.
Un exemple de journal quelque peu binaire est très répandu: le journal des événements Windows. Du côté professionnel, cela permet aux messages de journal d'être assez verbeux (et donc, espérons-le, utiles) à peu près sans frais, peut-être quelque chose comme
Avertissement: La file d'attente de foobars à faire a augmenté de 517 éléments au cours des 90 dernières secondes. Si cela se produit environ une fois par jour, il n'y a rien à craindre. Si cela se produit plus souvent ou en succession rapide, vous souhaiterez peut-être vérifier la quantité de RAM disponible pour l'application foobar. Si cela se produit avec l'événement 12345, cependant, vous semblez utiliser un base de données obsolète et vous feriez mieux d'appeler le support au + 1-555-12345 afin d'éviter la perte de données.
La partie principale de ce message n'existe qu'une seule fois en tant que ressource installée avec l'application. Cependant, si cette ressource n'est pas installée correctement (par exemple, parce que pendant ce temps une version plus récente a été installée qui ne prend plus en charge ce message obsolète), tout ce que vous voyez dans le journal des événements est un message standard qui est juste une formulation de fantaisie pour
Je ne sais pas, quelque chose avec "517" et "90".
et ne sert plus en aucune façon.
TL; DR: La taille n'a pas vraiment d'importance, mais la commodité d'utilisation
Tout d'abord, bien que la comparaison des avantages respectifs des formats texte et binaire pour le stockage de journaux à court terme soit une question importante, la taille n'a pas vraiment d'importance. Les deux raisons à cela sont:
Les journaux sont des informations hautement redondantes qui se compressent très bien: d'après mon expérience, il n'est pas rare de voir des fichiers journaux compressés dont la taille est de 5% ou moins de la taille du fichier d'origine. Par conséquent, l'utilisation d'un texte ou d'un format binaire ne devrait pas avoir d'impact mesurable sur le stockage à long terme des journaux.
Quel que soit le format que nous choisissons, les journaux rempliront rapidement un disque de serveur si nous n'implémentons pas un "récepteur de fichiers journaux" qui compresse et envoie les fichiers journaux à une plate-forme de stockage à long terme. L'utilisation d'un format binaire pourrait ralentir un peu cela, mais même un changement d'un facteur 10 n'aurait pas beaucoup d'importance.
Formats de texte et journaux binaires
La promesse des systèmes Unix est que, si nous apprenons à utiliser l'ensemble d'outils standard travaillant sur des fichiers texte structurés en lignes - tels que grep , trier , joindre , sed et awk - nous serons en mesure de les utiliser pour assembler rapidement des prototypes effectuant tout travail que nous voulons, quoique lentement et grossièrement. Une fois que le prototype a démontré son utilité, nous pouvons choisir de le transformer en un logiciel vraiment conçu pour gagner en performances ou ajouter d'autres fonctionnalités utiles. C'est, du moins à mon sens, l'essence de la philosophie Unix.
En d'autres termes, si nous avons probablement besoin d'effectuer des traitements et des analyses, nous ne pouvons pas le savoir aujourd'hui, si nous ne savons pas qui devrait mettre en œuvre cette analyse, etc., nous sommes alors au stade où les prototypes devraient être utilisés et les formats de texte pour les journaux sont probablement optimaux. Si nous devons effectuer à plusieurs reprises un petit ensemble de traitements bien identifiés, nous sommes alors dans la situation où nous devons concevoir un système logiciel pérenne pour effectuer cette analyse et les formats binaires ou structurés pour les journaux, tels que les bases de données relationnelles, sont susceptibles d'être optimal.
(Il y a quelque temps, j'ai écrit un article de blog à ce sujet.)
Les deux principales questions que vous voudriez poser avant de choisir entre texte et binaire sont:
- Quel est mon public?
- Quel contenu dois-je transmettre?
Une opinion commune est que le public d'un message de journal est un être humain. Ce n'est évidemment pas une hypothèse parfaite, car il existe de nombreux scripts d'exploration de journaux, mais c'est un script courant. Dans ce cas, il est logique de transmettre les informations sur un support avec lequel les humains sont à l'aise. Le texte a une longue tradition d'être ce médium.
Quant au contenu, considérez qu'un journal binaire must a un format bien défini. Le format doit être suffisamment bien défini pour que d'autres personnes écrivent un logiciel qui fonctionne sur ces journaux. Certains journaux sont assez bien structurés (votre question en énumère plusieurs). D'autres journaux doivent pouvoir transmettre du contenu sous une forme en langage naturel moins bien définie. De tels cas de langage naturel ne correspondent pas aux formats binaires.
Pour les logs qui pourraient être bien décrits en binaire, il faut faire un choix. Parce que le texte fonctionne pour tout le monde, il est souvent considéré comme le choix par défaut. Si vous enregistrez vos résultats dans du texte, les gens peuvent travailler avec vos journaux. Cela a été prouvé des milliers de fois. Les fichiers binaires sont plus délicats. En conséquence, il se peut que les développeurs produisent du texte simplement parce que tout le monde sait à quoi cela va ressembler.
Les fichiers journaux sont au format texte car ils peuvent être facilement lus à l'aide de n'importe quel type d'éditeur de texte ou en affichant le contenu via la commande de la console.
Cependant, certains fichiers journaux sont au format binaire s'il y a beaucoup de données. Par exemple, le produit sur lequel je travaille stocke au maximum 15 000 enregistrements. Afin de stocker les enregistrements dans le moins d'espace possible, ils sont stockés en binaire. Cependant, une application spéciale doit être écrite pour afficher les enregistrements ou les convertir dans un format utilisable (par exemple, des feuilles de calcul).
En résumé, tous les fichiers journaux ne sont pas au format textuel. Le format textuel présente l'avantage que des outils personnalisés ne sont pas nécessaires pour afficher le contenu. Lorsqu'il y a beaucoup de données, le fichier peut être au format binaire. Le format binaire aura besoin d'une application (personnalisée) pour lire les données et les afficher dans un format lisible par l'homme. Plus de données peuvent être regroupées dans un format binaire. L'utilisation d'un format textuel ou binaire est une décision basée sur la quantité de données et la facilité de visualisation du contenu.
Un fichier texte corrompu est toujours lisible autour de la partie corrompue. Un fichier binaire corrompu peut être restaurable, mais il peut aussi ne pas l'être. Même s'il est restaurable, il faudrait un peu plus de travail. L'autre raison est qu'un format de journalisation binaire rend moins probable qu'au cours d'une ruée vers créer un "correctif temporaire" (alias "le plus permanent de tous les correctifs"), la solution de journalisation sera utilisée au lieu de quelque chose qui peut être créé plus rapidement.
Dans les systèmes embarqués où je n'ai peut-être pas de canal de sortie disponible pendant l'exécution, l'application ne peut pas se permettre le coup de vitesse imposé par la journalisation, ou la journalisation altérerait ou masquerait l'effet que j'essaie d'enregistrer, j'ai souvent recouru à bourrer des données binaires dans un tableau ou un tampon en anneau, et soit printf () ing à la fin de l'exécution de test ou le vider brut et écrire un interpréteur pour l'imprimer comme lisible. Quoi qu'il en soit, je veux me retrouver avec des données lisibles.
Dans les systèmes avec plus de ressources, pourquoi inventer des schémas pour optimiser ce qui n'a pas besoin d'être optimisé?
Les fichiers journaux sont destinés à faciliter le débogage des problèmes. En règle générale, l'espace sur le disque dur est beaucoup moins cher que le temps d'ingénierie. Les fichiers journaux utilisent du texte car il existe de nombreux outils pour travailler avec du texte (tels que tail -f). Même HTTP utilise du texte brut (voir aussi pourquoi n'envoyons-nous pas du binaire au lieu du texte sur http ).
En outre, il est moins coûteux de développer un système de journalisation en texte brut et de vérifier qu'il fonctionne, plus facile à déboguer en cas de problème et plus facile à récupérer toutes les informations utiles en cas de défaillance du système et de corruption d'une partie du journal.
Historiquement, les journaux étaient des enregistrements officiels, manuscrits et séquentiels d'événements. Lorsque les machines sont devenues capables d'enregistrer des événements, celles-ci ont été écrites sur un périphérique de sortie sur papier tel qu'une imprimante téléscripteur, qui produisait un enregistrement séquentiel permanent mais qui ne pouvait traiter que du texte et parfois sonner une cloche ...
À l'époque de mon mainframe, nous avons utilisé un format de journal binaire personnalisé. La raison principale n'était pas d'économiser de l'espace, c'était parce que nous voulions que le journal occupe un espace fini en remplaçant les anciennes entrées par de nouvelles; la dernière chose que nous voulions était de ne pas être en mesure de diagnostiquer les problèmes causés par la saturation des disques (en 1980, l'espace disque coûtait 1000 $/Mb, donc les gens n'achetaient pas plus que ce dont ils avaient besoin).
Maintenant, j'aime toujours l'idée d'un fichier journal circulaire, et si les systèmes d'exploitation offraient une telle bête, je l'utiliserais sans hésitation. Mais le binaire était une mauvaise idée. Vous ne voulez vraiment pas perdre de temps à trouver les bonnes commandes pour déchiffrer un fichier journal lorsque vous avez un problème critique à résoudre.
Nous comptons sur des tests unitaires pour atteindre et maintenir la robustesse de notre logiciel. (La plupart de notre code s'exécute sur un serveur, sans tête; l'analyse post-opération des fichiers journaux est une stratégie clé.). Presque chaque classe de notre implémentation effectue une journalisation. Une partie importante de nos tests unitaires est l'utilisation de faux enregistreurs qui sont utilisés lors des tests unitaires. Un test unitaire crée un faux enregistreur et le fournit à l'élément testé. Il analyse ensuite (lorsque cela est utile/approprié) ce qui a été enregistré (en particulier les erreurs et avertissements). L'utilisation d'un format de journal basé sur du texte rend cela beaucoup plus facile pour à peu près les mêmes raisons que les analyses effectuées sur des journaux "réels": il y a plus d'outils à votre disposition qui sont rapides à utiliser et à adapter.