Ce n’est pas une opposition binaire vs texte, c’est une opposition structuré vs non structuré.
Tu peux très bien avoir du binaire non structuré : schématiquement write(logFd, &logEntry, sizeof(logEntry)) (où LogEntry est une structure non documentée, non standardisée, variant d’un logiciel à l’autre et même d’une version à l’autre). Et dans cette situation, bonne chance pour « avoir la machine qui fait des regexp pour toi ».
Tu peux très bien avoir du texte structuré : JSON + json-schema, XML par exemple. Et dans ce cas tu peux avoir les mêmes outils d’aide à la recherche.
Sur le reste, je vais pas répondre point par point. Il suffit de regarder le début du billet pour voir où est le gros problème dans l’argumentattion :
My requirements here are simple:
I need one central place to store my logs.
I do not care - nor store - logs on each computer. They all send to a central server, and only hold logs themselves if the central is unreachable. If I lose a few messages here and there, that is no problem.
The central must be easy to change.
While on the go, possibly without internet access, I do not want my laptops to even try sending to central. So I want to be able to pull up a dummy node locally.
I don't care whether the temporary local collector node and the central one are mergeable. If need be, I can export my logs from the local one, and import it into central, but I rarely do that.
I want to preserve all logs in an efficient way.
I need historic data for experiments and some toy projects of mine.
I post-process data, and store a structured, processed version only.
I take all my logs, may they come from syslog, the Journal or any other source, and post-process them. I extract out key fields, correlate messages, and so on. I'm only interested in this part of the data, the original messages are discarded.
I want to do queries that span programs and machines.
One thing I reasonably frequently do, is follow the life of e-mail I send: the logs from Gnus that composed the message from my PC, through msmtpd on the same machine, through postfix on the raspberry pi, then postfix on my remote server. That spans three hosts and four programs.
I want to ask my system this: "Show me all the logs for the e-mail with message-id X!", or "Show me all the logs of e-mails I sent today that were delayed more than an hour!", and a number of similar questions.
I want reasonably fast and efficient ad-hoc queries.
While I post-process my logs, I want to be able to do queries that I came up with on the spot, that work on historic data without having to re-process past logs. Of course, this only has to work for fields that I actually extracted. If I want to introduce a new field, I'll either re-process old data, or only care about new logs.
Cette liste de requirements, ce n’est pas de l’écriture de logs, c’est de la gestion de base de données tout ce qu’il y a de plus classique ! De fait, journald ne fait pas le quart de ce qui est décrit dans cette liste. De fait,
People have been abusing SQL to store their logs for more than a decade
Je ne vois pas en quoi c’est de « l’abus », au vu de la liste. Le workflow qu’il décrit pour son système :
je réfléchis au schéma de mes données
j’écris un programme pour conformer (structurer) mes données à ce schéma
je stocke ces données structurées dans un format adapté au requêtage
je récupère mes données structurées par des opérations de requêtage
c’est exactement le workflow d’un développeur SQL.
On en vient au problème fondamental de l’article : cette méthode d’utilisation des logs, c’est '''une''' méthode d’utilisation des logs, pas '''la''' méthode d’utilisation des logs. Tout le monde ne traite pas ses logs comme une base de données à usage quotidien. C’est un usage totalement valide (dans quelques années dans ma boite, qui sait ? Mais actuellement non), mais c’est un usage spécifique, qui nécessite des outils spécifiques. Tu ne peux pas passer à cette liste de besoins à une conclusion type « c’est LA méthode de gestion de logs ». Un autre usage des logs, totalement valide, c’est un truc qu’on met de côté et qu’on ne ressort qu’en cas de problème pour savoir ce qu’il s’est passé. Et dans cette situation un grep global sur tout le log est infiniment plus pratique qu’un schéma structuré, si tu n’as qu’une poignée d’indices, sans parler de l’efficacité (on a pas à mettre en place tout ce process extraction-stockage-indexation juste pour aller inspecter les logs tous les 36 du mois).
Il y aurait encore plus à dire sur certains point de détails (le requêtage c’est bien gentil, mais encore faut-il savoir quoi requêter et comment, et la réponse est loin d’être triviale si tu n’as pas beaucoup réfléchi en amont à ta structure), mais j’ai assez nourri le troll pour le moment.
# Je sais qu’on est vendredi mais...
Posté par Moonz . En réponse au journal Vivent les journaux binaires !. Évalué à 10.
Même pour un vendredi c’est quand même trop gros.
Sur regexp texte vs querying :
Ce n’est pas une opposition binaire vs texte, c’est une opposition structuré vs non structuré.
Tu peux très bien avoir du binaire non structuré : schématiquement
write(logFd, &logEntry, sizeof(logEntry))(où LogEntry est une structure non documentée, non standardisée, variant d’un logiciel à l’autre et même d’une version à l’autre). Et dans cette situation, bonne chance pour « avoir la machine qui fait des regexp pour toi ».Tu peux très bien avoir du texte structuré : JSON + json-schema, XML par exemple. Et dans ce cas tu peux avoir les mêmes outils d’aide à la recherche.
Sur le reste, je vais pas répondre point par point. Il suffit de regarder le début du billet pour voir où est le gros problème dans l’argumentattion :
Cette liste de requirements, ce n’est pas de l’écriture de logs, c’est de la gestion de base de données tout ce qu’il y a de plus classique ! De fait, journald ne fait pas le quart de ce qui est décrit dans cette liste. De fait,
Je ne vois pas en quoi c’est de « l’abus », au vu de la liste. Le workflow qu’il décrit pour son système :
c’est exactement le workflow d’un développeur SQL.
On en vient au problème fondamental de l’article : cette méthode d’utilisation des logs, c’est '''une''' méthode d’utilisation des logs, pas '''la''' méthode d’utilisation des logs. Tout le monde ne traite pas ses logs comme une base de données à usage quotidien. C’est un usage totalement valide (dans quelques années dans ma boite, qui sait ? Mais actuellement non), mais c’est un usage spécifique, qui nécessite des outils spécifiques. Tu ne peux pas passer à cette liste de besoins à une conclusion type « c’est LA méthode de gestion de logs ». Un autre usage des logs, totalement valide, c’est un truc qu’on met de côté et qu’on ne ressort qu’en cas de problème pour savoir ce qu’il s’est passé. Et dans cette situation un grep global sur tout le log est infiniment plus pratique qu’un schéma structuré, si tu n’as qu’une poignée d’indices, sans parler de l’efficacité (on a pas à mettre en place tout ce process extraction-stockage-indexation juste pour aller inspecter les logs tous les 36 du mois).
Il y aurait encore plus à dire sur certains point de détails (le requêtage c’est bien gentil, mais encore faut-il savoir quoi requêter et comment, et la réponse est loin d’être triviale si tu n’as pas beaucoup réfléchi en amont à ta structure), mais j’ai assez nourri le troll pour le moment.