Le projet Lumberjack est une initiative de plusieurs développeurs de système de logs pour améliorer l'enregistrement d'événements par le système. Il a débuté lors d'une conférence dans les bureaux de Red Hat en République Tchèque avec un entretien entre Steve Gibbs (auditd), Lennart Poettering (systemd, journald), Rainer Gerhards (rsyslog), William Heinbockel (CEE, Mitre) et plusieurs autres développeurs Red Hat.
Le but est de standardiser le contenu des logs et d'améliorer leur création par les applications qui les génèrent. Pour cela, les développeurs vont suivre les spécifications Common Event Expression (CEE). Sur leur site, on peut déjà trouver le schéma XML des logs, ainsi qu'un exemple en XML et un autre en JSON.
NdA : Merci à Nÿco, olvierweb et Neox pour leur aide lors de la rédaction de cette dépêche.
Aller plus loin
- Le projet Lumberjack (684 clics)
- Schéma XML des logs (312 clics)
- Lumberjack : Exemple en XML (209 clics)
- Lumberjack : Exemple en JSON (327 clics)
# Du XML ?
Posté par cdvddt . Évalué à 10.
Du XML pour des logs … C'est un peu Overkill non ?
Un bon vieux format CSV, c'est quand même plus léger et lisible.
[^] # Re: Du XML ?
Posté par Buf (Mastodon) . Évalué à 10.
CSV, c'est la fausse bonne idée par excellence. Le format a l'air simple à générer et à parser, mais en pratique, c'est une véritable horreur, parce que le format n'a pas de spécifications formelles (en particulier pour la gestion des caractères spéciaux). Un fichier CSV avec des entrées qui contiennent des retours à la ligne est très rarement bien géré, par exemple.
Le XML a le défaut d'être très verbeux, mais il a quand même l'immense avantage d'avoir une syntaxe stricte et bien définie.
[^] # Re: Du XML ?
Posté par exolin . Évalué à 1.
Pourquoi ne pas se baser sur le csv et convenir d'un en-tête pour la structure (séparateur de colonne & ligne) à la manière du shebang (#!) des scripts?
D'autre part comme dit plus loin dans les commentaires, quid de l'écriture dans le cas du xml avec sa balise root?
[^] # Re: Du XML ?
Posté par Buf (Mastodon) . Évalué à 6.
Voir ma réponse au commentaire en question.
[^] # Re: Du XML ?
Posté par exolin . Évalué à 5.
Certes, on pourrait imaginer mettre le séparateur de ligne en indicatif de dernière colonne. Autrement si l'on part du principe que l'on essaie de mettre en place un standard pour la structure des logs on n'est pas non plus obligé de se dire que l'outil CSV qui parse la compta doit lire les logs du serveur de production.
Le format ne me semble pas adapté au besoin justement.
Ajouter 50% d'informations supplémentaires à écrire sur le disque et diminuer la lisibilité directe c'est loin d'être une solution convenable pour moi.
[^] # Re: Du XML ?
Posté par claudex . Évalué à 2.
Tu peux justement utiliser des outils qui pourront facilement mettre en évidence les informations qui t'intéressent.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du XML ?
Posté par Buf (Mastodon) . Évalué à 3. Dernière modification le 07 mars 2012 à 16:55.
Tiens, en parlant de la lisibilité du CSV, voici ce que pourrais donné les messages d'exemple une fois passés en CSV :
C'est vraiment plus lisible que du XML ou du JSON ? Plus compact, certainement, mais pour ce qui est de la lisibilité, j'ai comme un doute…
[^] # Re: Du XML ?
Posté par Buf (Mastodon) . Évalué à 5.
J'ajouterais encore que CSV n'a pas la souplesse requise. En CSV, on définit un certain nombre de colonnes, on donne un sens à chacune, et c'est fini. Possibilités d'extensions : proche de zéro.
Dans les exemples donnés, on voit bien qu'on peut définir des schémas pour des données spécifiques à un type d'application. C'est beaucoup plus souple.
[^] # Re: Du XML ?
Posté par neil . Évalué à 2.
Euh, il y a déjà un(e proposition de) standard pour les systèmes de log, c'est la RFC 5424. C'est étrange qu'il ne soit pas mentionné dans le projet, vu que c'est Rainer Gerhards qui en est l'auteur.
Enfin, avec Poettering on ne peut s'attendre qu'à un nouveau standard.
[^] # Re: Du XML ?
Posté par Damien Thébault . Évalué à 3.
À vrai dire, je préfère encore du JSON/XML à ça:
Et je parle même pas du "format structuré" et des combinaisons possibles entre les deux.
Disons que je veuille récupérer des données du fichier de log (en général gros), je préfèrerais me faire un petit xsl ou xmlstarlet ou xpath plutôt que de faire une regexp sed qui marchera seulement 80% du temps.
[^] # Re: Du XML ?
Posté par ckyl . Évalué à 10.
http://blog.gerhards.net/2012/02/announcing-project-lumberjack.html
Ce sur quoi ils bossent est un complément de la RFC 5424. Ils essaient d'étendre ce qu'il y a autour:
- API userland
- Payload des messages plus évoluée et structurée
- Comment on stock tout ca intelligemment
La RFC 5424 c'est très cheap sur la payload mais ca marche bien comme protocole de transport. Ce qu'il manque c'est des données structurées. Alors on garde le même transport mais on standardise la payload pour y inclure des données structurées plutôt qu'une bête string. Ce qui fonctionnait marche encore, et il suffit de proposer des API alternatives pour générer une jolie payload structurée plutôt qu'une string.
Après le deuxième problème c'est comment stocker ces données. Si tu ne changes rien au stockage actuel te retrouves avec une payload json par ligne, c'est deja mieux que rien. Tu peux toujours grepper comme avant, et les outils d'analyse peuvent enfin faire des trucs moins con que regexper au petit bonheur la chance. Mais il y a surement à réfléchir pour trouver des stockages plus adaptés à l'exploitation des données structurées.
Bref ce qui est bien avec les mecs qui font; c'est qu'ils ne vivent pas dans l'idéalisme du passé et qu'ils comprennent ce qui existe. Pour les meilleurs, ils arrivent à reconnaitre les limites actuelles, et des fois ils tentent d'améliorer les choses sans tout péter. C'est le cas ici.
[^] # Re: Du XML ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
et la RFC4180 ? http://tools.ietf.org/html/rfc4180
ça reste de la grosse merde comme format de données structuré, XML c'est mieux
[^] # Re: Du XML ?
Posté par Buf (Mastodon) . Évalué à 2.
Ta RFC, elle dit exactement pareil que moi : il n'y a pas de spécifications formelles pour le CSV.
[^] # Re: Du XML ?
Posté par Zenitram (site web personnel) . Évalué à -1.
Ben la, il y en a une, justement!
[^] # Re: Du XML ?
Posté par ham . Évalué à 3.
C'est une informational, pas une Standard Track. Donc pas normatif.
[^] # Re: Du XML ?
Posté par Buf (Mastodon) . Évalué à 3.
Exactement. Suffit de lire le premier paragraphe de la RFC :
C'est juste un récapitulatif de ce qui se fait, à aucun moment ça ne prétend définir une norme.
[^] # Re: Du XML ?
Posté par visualstation . Évalué à -1. Dernière modification le 07 mars 2012 à 11:23.
C'est surtout en java pour le moment et donc ça ne sera pas adapté à une application autre que le java (à l'heure actuelle).
Mais le concept d'avoir une manière de faire et pas une centaine, devrait permettre d'avoir une meilleur vue sur les événements, les erreurs et consort.
Chaque application a son système d'historique/log. Un bibliothèque qui permettrait d'avoir toujours la même sortie est un plus (pour moi).
Prenons l'exemple de Asterisk, FreeSWITCH et Apache, sur 2 applications similaires (ayant le même but), nous avons 2 types de fichier de log et Apache pas le même but, un troisième.
Avec cette bibliothèque commune, nous aurions certe 3 logs, mais ayant les mêmes champs et pouvant être analysés de la même manière.
[^] # Re: Du XML ?
Posté par Didrik Pining . Évalué à 9.
Super idée ! Et en plus on pourrait imaginer que tous les programmes qui utilisent cette librairie/API envoient en réalité leur logs à un autre programme qui se chargerait de les filtrer et de les écrire sur le disque.
Et on appellerait ça syslog, parce que ca gère les logs du système.
[^] # Re: Du XML ?
Posté par visualstation . Évalué à 1.
Oui oui je sais (je travaille assez avec rSyslog pour le savoir :)).
Et même les syslogs sont pas standards (Cisco, HP et Co).
Cependant ceci n'empèche en rien le fait d'avoir une structure X ou y bien définie pour les logs. Ce qui n'est hélas pas le cas à l'heure actuelle.
[^] # Re: Du XML ?
Posté par claudex . Évalué à 4.
Il n'y a pas que tu XML mais du JSON aussi comme précisé dans la news.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du XML ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9. Dernière modification le 07 mars 2012 à 11:47.
Ouai, alors, ou tu es un super admin de la mort qui tue, et que des millions de lignes de CSV ne te font pas peur. Ou alors tu n'as jamais administré de vrais serveurs.
Parce que CSV ou XML, dans un vrai contexte de production (un serveur relativement chargé, ou pas d'ailleurs), les logs sont de toutes manières illisibles, tellement il y a d'enregistrement, et nécessite donc des outils pour analyser et chercher quelque chose.
[^] # Re: Du XML ?
Posté par MTux . Évalué à 9.
Avec XML la taille de tes logs va exploser… parce que grossomodo c'est 90% de balises et 10% d'informations utiles. Moi perso ça ne me tente pas trop, c'est humainement très pénible à lire le XML.
[^] # Re: Du XML ?
Posté par Dorian . Évalué à 8.
Même si les fichiers de logs sont en XML, il y aura des outils pour faire
logs show apache2 | grep 404qui retourneront une liste lisible.C'est comme dire que les bases de données SQL sont difficiles à lire, alors que tout le monde utilise une jolie interface (l'appli web) pour y accéder.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Du XML ?
Posté par Moonz . Évalué à 6.
Tiens, pourquoi /usr se monte plus ?
Oups…
[^] # Re: Du XML ?
Posté par Thomas Douillard . Évalué à 8.
T'es au courant pour redhat qui veut tout mettre dans /usr/bin ?
[^] # Re: Du XML ?
Posté par zebra3 . Évalué à 7.
Ben il suffirait de mettre logs dans /bin.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Du XML ?
Posté par MTux . Évalué à 2.
Bien dit, l'intérêt des logs unix actuellement c'est que ça te dépanne même si tu as un accès minimal de chez minimal au système. Je ne suis pas partisan des logs illisibles qui te remplissent ta partition /var en 3 jours…
[^] # Re: Du XML ?
Posté par claudex . Évalué à 3.
Si tu as un accès minimal de chez minimal, syslog ne tourne pas non plus. Donc je ne vois pas ce que ça change.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du XML ?
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
Les logs sont la et tu peux les ouvrir avec un simple pager, grep, cat, tail, head, pour comprendre ce qui t'as mis dans cet état minimal
[^] # Re: Du XML ?
Posté par claudex . Évalué à 6.
Et ils disparaissent quand ils sont écrit en Json?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du XML ?
Posté par oinkoink_daotter . Évalué à 1.
Nan, mais ça va compliquer le boulot à busybox …
[^] # Re: Du XML ?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
Un simple zip et le problème est réglé. Qui dit redondance dit facile à compresser.
[^] # Re: Du XML ?
Posté par Damien Thébault . Évalué à 4.
Surtout qu'avec logrotate c'est déjà fait automatiquement en .gz
[^] # Re: Du XML ?
Posté par zebra3 . Évalué à 5.
Avec quel encodage ? Quel séparateur de champs ? Quel séparateur de texte ?
CSV en soi n'a pas plus de sens que XML, il faut aussi définir une norme.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Du XML ?
Posté par vjm . Évalué à -2.
Sinon il y a un truc standard existant déjà depuis un moment qui s'appelle Common Event Format qui est en cours de remplacement par Common Event Expression. Il y a déjà pas mal d'acteurs réputés dans le domaine qui travaille dessus…
http://www.arcsight.com/solutions/solutions-cef/
http://blogs.splunk.com/2007/12/06/common-event-format-add-on/
http://cee.mitre.org/
http://chuvakin.blogspot.com/2006/08/on-common-event-format-cef.html
http://raffy.ch/blog/2007/04/19/standard-logging-format-common-event-exchange-cee/
[^] # Re: Du XML ?
Posté par claudex . Évalué à 6.
Et magie, je cite la dépêche
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du XML ?
Posté par vjm . Évalué à -1. Dernière modification le 09 mars 2012 à 13:30.
En effet, j'ai lu un peu vite la dépêche et réagit directement aux commentaires. Par contre, pour travailler avec CEF, j'avais vraiment tilter que c'était du XML.
[^] # Re: Du XML ?
Posté par ckyl . Évalué à 4.
Je crois qu'ils sont au courant puisque William Heinbockel (CEE Technical Lead) participe à lumberjack et que CEE est utilisé comme idée de base ;)
# Le but est de standardiser le contenu des logs
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
date hôte service[pid]: messageMes deux cents
Joris
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . Évalué à 7.
Et le premier truc qui manque, immédiatement, c'est le niveau de log (debug, warn, etc).
Hop, faut en rajouter.
Après, standardiser classname/methodname c'est aussi une très bonne chose.
Hop, faut en rajouter.
Le truc c'est qu'on peut continuer comme ça longtemps.
Ha tiens, si j'écrivais
classname:methodnameHa tiens, si j'écrivais
classname#methodnameOups
[^] # Re: Le but est de standardiser le contenu des logs
Posté par zebra3 . Évalué à 4.
Si tu ne définis pas le format de date, ça n'est pas un standard.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
Pour ceux qui n'auraient pas compris, il s'agit du format utilisé par syslog actuellement. Ce que pointait mon message c'est que ce format est déja standard de fait.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par claudex . Évalué à 5.
Non, parce que tu te retrouve à parser la partie "message" pour y trouver des informations qui ne sont pas stocker de la même façon en fonction du programme.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Tu veux dire qu'on va se fader du xml et du log multiligne pour éviter d'écrire un parser en awk/perl/cut par programme ? Je pense que les gens qui font ça (sans remettre en cause leur compétence de dev) n'aiment tout simplement pas Unix.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . Évalué à 2.
Et tu t'es jamais dit qu'on pouvait vouloir monitorer l'ensemble des programmes ?
Genre si j'ai un log avec une structure unifiée et que j'ai 10 services différents sur ma machine, ben je peux monitorer les 10 de manière unifiée et sortit tous les error sur une période donnée par exemple. Et si je rajoute un 11° service ? Ben ça ne changera rien du tout. Et d'ailleurs je m'en fout du service qu'on vient de rajouter, je veux juste qu'il respecte un tant soit peu une structure correcte qui fait que si mon serveur crash je peux remonter tous les warnings 5 minutes avant. Ha mais attends, comment je sort les warnings et erreurs (mais pas debug, info) de apache, postfix, système, etc sur une plage de temps facilement ? Ben je peux pas.
Ou pas, faut lire.
Ce serait un grand pas en avant.
Lapincompris le rapport.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par claudex . Évalué à 10.
Désormais, dès qu'on change le comportement du moindre outil, on n'aime pas Unix.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
man syslog.conf
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Moonz . Évalué à 6.
man rsyslog.conf
Personne ne nie qu’un standard soit une bonne idée. Simplement, il existe déjà (c’est syslog), et vouloir utiliser du XML pour des logs, c’est, pour le dire poliment, pas particulièrement attirant.
« Écrivez des programmes qui traitent des flux de texte car c'est l'interface universelle »
Universelle, dans le sens : je peux utiliser la puissance d’outils comme sed/awk/grep/perl et des centaines d’autres, testés, éprouvés depuis des dizaines d’années, enseignés dans les plus mauvaises écoles d’administration système, installés sur virtuellement tous les systèmes, et qui ne me feront jamais faux bond, en les combinant d’une manière à laquelle personne d’autre n’a pensé parce que tout le monde s’en fout tellement mon problème est spécifique. Si tu me dis que je dois écrire un programme en Java avec un parser SAX pour résoudre mon problème spécifique, je te ris au nez (encore une fois, c’est la version polie).
[^] # Re: Le but est de standardiser le contenu des logs
Posté par claudex . Évalué à 10.
C'est tellement efficace que le développeur de rsyslog participle à Lumberjack.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 2.
Et le xml c'est ?
perl sait très bien parser du xml
Donc par défaut tu rejette toute nouveauté tant qu'elle n'a pas plusieurs dizaines d'années ?
Du nivellement par le bas ?
Ça veut dire quoi ?
Sauf quand tu te rendras compte que tu passe ton temps à utiliser des extensions GNU. Tu ne le fais pas ? Ben beaucoup le font.
branlette intellectuelle
Il existe des tas d'outils en ligne de commande qui vont te permettre de faire des requêtes XPath si tu veut avoir quelque chose de puissant (dans le sens où tu utilise tout la puissance d'XML), si tu veut rester avec les outils POSIX ou GNU ça fonctionne toujours.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Astaoth . Évalué à 1.
Je ne sais pas manier perl, et il n'est pas installé sur ma machine, au contraire de grep qui est un outil standard (il me semble), avec un manuel simple.
Emacs le fait depuis 30 ans.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
S'il y du XML, il doit y avoir une DTD ou mieux un XMLschema qui donne la grammaire du document et les entités référencées.
Ensuite, il y a XSLT qui permet toutes les transformations imaginables. Cela s'appelle travailler proprement.
Pour ceux qui le désirent, avec du XSLT on peut même produire du CSV en sortie et l'ouvrir dans un tableur que l'on nomme "base de données"… Bon je ne vais pas insister car là ça commence à devenir du grand n'importe quoi ! Malheureusement je vois ça très souvent.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 1.
Je ne vois pas le lien entre le fait d'écrire un parseur en perl et ce que tu dis ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je crois qu'il faut arrêter avec le XML partout, c'était il y a 10 ans en arrière. Des évènements qui arrive de manière temporelle et régulière, on sens bien qu'une écriture en mode append ligne à ligne, c'est vachement adapté.
Quand au XSLT, c'est de la merde en boite… Cela date encore de l'époque ou on voulait tout faire rentrer dans du XML. C'est vraiment vouloir faire du LISP en moins bien, on est capable de faire un langage à moteur d'inférence un peu plus humain je pense ;-)
Au vu de ce que j'ai vu lors de cette discution, il me semble qu'un envoi vers un serveur central type syslog d'une structure normalisé type JSON, YAML… me semble effectivement mieux qu'une simple chaine. Le mieux est de prendre un format rapide, simple et peu verbeux, c'est la partie réseau qui sera interchangeable…
Ensuite, coté syslog, plusieurs backend sont possible et par défaut, un système compatible avec l'actuel d'un append ligne à ligne dans un fichier d'une structure JSON semble relativement efficace à tout point de vue. Le syslog pourrait rajouter au mesage son timestamp d'écriture en début de structure pour avoir l'ordre chronologique.
Bref, le retour à la ligne gère le temps et chaque ligne est une structure JSON indépendante. Ainsi l'analyse de celles-ci ne prends pas trop de ressource mémoire…
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 2.
Je ne comprends pas l'intérêt de json ou de yaml sur xml. yaml je ne connais pas mais en json tu es fortement dépend de la suciez du document pour faire du requetage.
Pour ce qui est du xml et de la sois disant périodicité de sa popularité c'est tout simplement faux. Entre il y a 10 ans et aujourd' hui, le xml n'est pas moins utilisé, il est mieux maîtrisé :
Ce ne sont que quelques exemples. Tu n'aime peut être pas mais sous-entendre que le xml a disparu pendant 10 ans pour réapparaître c'est faux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . Évalué à 5.
Oué enfin (l'écosystème) java l'utilise toujours pour tout et n'importe quoi. Par exemple entre une configuration de servlets dans un web.xml et un module servlet de guice mon choix est très vite fait (en plus du fait que c'est beaucoup plus puissant…)
ça tombe bien c'est souvent ce qui lui est reproché. Il ne faut pas confondre le fait qu'ils l'utilisent et la pertinence de son usage.
Oué, sauf qu'on fait absolument pas du maven pour le côté xml. Si on pouvait d'ailleurs faire du maven sans la lourdeur intrinsèque à l'xml on s'en porterait beaucoup mieux.
Oui mais le problème c'est que dans ces exemples il n'y en a aucun qui donne envie de faire du xml.
Pour odf/ooxml et rss/atome c'est bien les seuls cas que je trouve intéressant. Mais le reste…
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 0.
Relis ce que j'écris avant d'inutiler. Je n'ai pas dire que les usages étaient bons, la mauvaise foie linuxfrienne est trop importante pour ça juste qu' xml est très utilisé par un grand nombre de gens divers. Donc ce n'est pas un effet de mode contrairement à ce qui était sous entendu dans le message auquel je répondais.
Que le xml te plaise ou non il est très employais. J'aime pas le javscript, c'est pas pour ça que je vais affirmer des contre vérités, je ne suis pas un politique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . Évalué à 4.
oulala, je crois que c'est l'heure de la camomille…
Ca tombe bien j'ai même pas inutilé.
Justement, ce que j'en dis c'est que la majorité des usages d'xml sont mauvais.
Ha mais le xml me plait. Mais surtout pas n'importe où.
Je pense que si, par certains côtés, c'est un effet de mode.
Il y a un temps, tout le monde faisait du xml, pour tout et n'importe quoi. Là c'était vraiment la mode. D'ailleurs il n'y a qu'à voir un certain nombre de frameworks java qui utilisent beaucoup trop le xml pour s'en rendre compte.
Aujourd'hui on l'utilise beaucoup moins et c'est beaucoup mieux (enfin sauf dans pas mal de projets java qui n'évoluent malheureusement pas dans le bon sens). On arrive alors à un usage à peu près raisonné et intelligent de l'xml. Mais c'est pas encore le cas partout.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Ou ai je dis que le XML avait disparu ;-)
Je sais bien que Java en met partout, peut être pour cela que j'évite au maximum ce langage… Quant à GNOME, je ne suis pas du tout enchanté par sa direction depuis pas mal de temps…
Mais revenons sur le sujet, on parle de message sur une même machine ou sur son réseau local. On parle donc de sérialisation. Il s'agit de message court mais très nombreux (des log). Le traitement tout en RAM semble donc la bonne voie (plutôt que du SAX). En gros, il faut sérialisé une structure de manière efficace et légère.
Le JSON (utilisé par la mouvance NoSQL) ou le YAML sont plus adapté à cela que le XML. Il s'agit ici juste de transport. C'est pas moi qui est contre le XML, c'est toi qui veut le mettre partout ;-)
Pour le XMPP et les flux RSS, on est clairement sur un usage internet, proche du HTML pour les flux RSS. Partir sur du XML n'est pas forcément idiot.
On a vu ce qu'a donné le XML pour les RPC (SOAP), on peux dire que la soupe n'a pas super bien prise avec le temps, les services basculant sur des API souvent plus simple à base de REST de nos jours. De plus, les navigateurs prenant le JSON de base, les services NoSQL vont finir par se passer en grand partie du XML.
Bref, les choses évoluent avec le temps et c'est pas plus mal. Quand au format ISO de fichier un peu statique, un schéma XML est pas plus mal qu'une grammaire BNF ;-) En //, Perl6 se définit via des regex Perl6 !
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 1.
Tu semblais affirmer que xml, on en reparle tout les 10 ans et qu'entre temps il ne fait plus parler de lui. Je voulais simplement montrer qu'il me semble être de plus en plus employé.
Pour ce qui est de SOAP, il est utilisé par l'administration (ils font toujours de mauvais choix, n'est ce pas ?), mais il me semble que l'avantage de soap c'est que les wsdl sont très utilisés là où wadl est très rarement utilisé avec rest. Je crois que SOAP est aussi utilisé pour l'UPnP (encore un mauvais choix je présume).
Quand tant de monde font de mauvais choix venant d'origine aussi varié et pas nécessairement en entreprise, il peux être intéressant de se demander ce à qu'il se passe et de se remettre en question.
Personnellement j'apprécie en xml le fait d'avoir des noeuds typés ce que l'on a pas en json.
Pour ce qui est de perl6 je ne comprends pas très bien tu veux dire que sa grammaire se défini part des expressions régulières?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . Évalué à 6.
Non, ce qu'il dit est que le moment de gloire d'XML c'était il y a 10 ans. Maintenant c'est has been dans la majorité des cas (j'exagère un peu, mais au moins il ne devrait pas y avoir d'ambiguïtés)
Heu… aucun rapport entre administration et bon ou mauvais choix. D'ailleurs, peu de différence au final entre administration et "grand compte" ou ssii, c'est en général plutôt mauvais dans tous les cas :-(
Le problème de SOAP c'est juste que c'est imbitable comme techno et que beaucoup tente à tout prix de l'éviter et s'en portent beaucoup mieux (à moins de vouloir jouer uniquement avec des générateurs de code dans tous les sens)
Oui pour ce point. Malheureusement vu le nombre de fois où on touche du XML sans avoir de schéma ou dtd, le typage ne sert pas à grand chose…
Oui, il faudrait.
XML a de bons avantages, mais il à l'inconvénient majeur d'être implanté. Il est devenu, de fait, un standard dans la sérialisation texte. Donc la majorité des gens utilisent, lorsqu'ils veulent du texte, du .ini ou dès que le .ini ne suffit pas, du xml. D'ailleurs sans forcément réfléchir.
Et, par méconnaissance essentiellement, les gens ne vont pas chercher plus loin, des parseurs existes, et hop xml.
Pour le côté méconnaissance : si je prend les développeurs que je connais, il n'y en a pas la moitié qui a déjà entendu parlé de YAML par exemple.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 2.
Tu as tout à fait raison, mais je pense que, dans un projet, multiplier les formats n'est pas forcément un avantage. Il vaut mieux, selon les contraintes, utiliser quelque chose de mal adapté mais assez bien maîtrisé qu'un format spécifique.
Faudra que je regardé plus en détail yaml, je ne m'en suis jamais servis pour faire autre chose que ce que peux faire ini.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . Évalué à 3.
Ca dépend vraiment des cas.
Un projet qui aurait par exemple sa conf en yaml, qui sérialiserait un certain nombre de données en json (stockées par exemple en base, renvoyées au client web, etc), voir même qui boufferait du json directement depuis postgresql, et qui aurait aussi de l'xml à certains endroit, juste pour pouvoir utiliser du xsl et faire des transformations intéressantes ne me choque pas plus que ça.
La critique était valable, il me semble, il y a quelque temps, lorsque les libs n'étaient pas là.
Mais si on a un parseur/lib correct pour les différents format alors il n'y a aucun soucis, d'ailleurs à ce moment le format devient quasiment transparent. Par exemple, dernièrement j'ai utilisé gson pour sérialiser différentes informations, ben y'a pas à chier c'était bien plus rapide que de le faire en xml.
D'ailleurs, json a un avantage certain sur xml : plus personne ne fait d'ajax, quasiment tout le monde fait de l'ajaj (oué on pourrait aussi juste dire aj), les données sont de plus en plus envoyées / reçues en json. L'XML était peut-être une bonne idée, mais lorsqu'on voit le coup d'un parse xml / xsl côté client, on oublie vite.
Et donc si on dialogue en json, on a tout intérêt à stocker / cacher / etc les données en json pour pouvoir dialoguer à moindre coût.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je ne vais pas recopier les réponses de CrEv, on est manifestement sur la même fréquence.
Avec des phrases comme cela, on serait tous sous Windows…
On sait tous que c'est rarement le meilleur choix qui gagne ! Je ne vais pas refaire l'histoire car je dois aller faire manger mes stroumpfs mais juste un exemple sur un autre sujet : en 80, il y avait trois processeurs, le x86, le 6502 et le Z80… C'est le x86 qui a gagné a l'époque alors que c'était la pire daube des trois !
Il a donc des pièges un peu partout, certains sont certainement évitable…
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 1.
Ou pas. Je n'ai pas dis de faire comme tout le monde, mais de se remettre en question. Il est toujours bon d'aller voir ce qui se fait ailleurs, quels sont les points positifs et négatifs, plutôt que de s'enfermer dans un « c'est parce qu'il est installé par défaut » comme le font certains.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Personnellement, j'ai des idées sur beaucoup de chose (mais pas sur tout) mais j'ai assez souvent changé d'avis par le passé pour le refaire encore une fois si on me donne des bons arguments ;-)
Il y a 10 ans, j'ai acheté des bouquins de XML (dont j'ai mis une partie à la poubelle la semaine dernière), j'ai même fait pas mal de weberie avec un pipeline XML en Perl qui était franchement bien. C'est à partir du XSLT que j'ai commencé à avoir vraiment des doutes si mes souvenirs sont bons. J'ai même cru dans le SOAP !
D'ailleurs, je n'ai jamais compris pourquoi le W3C n'avait pas poussé la logique jusqu'au bout et fait un schéma XML pour le CSS !
Ceci dis, je ne me fais jamais chié avec les fichiers de conf au format .ini (blocage psychologique ?). Tous mes fichiers de conf sont en YAML qui est vraiment très bien pour cela, ou alors, c'est du bash à sourcer… Mais avec du YAML, tu te retrouve dans ton programme avec une variable CONF qui est l'exacte copie en terme d'arbre du YAML, c'est idéal et souvent suffisant dans beaucoup de cas.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par claudex . Évalué à 5.
Ce n'est pas pratique pour afficher les dernier message d'erreurs, ou ceux de warning et d'erreur pour tout le système. (ce n'est qu'un exemple)
Sinon, ça n'a pas l'air d'être la journée pour aimer Unix
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le but est de standardiser le contenu des logs
Posté par zebra3 . Évalué à 3.
Ou peut-être qu'ils ont autre chose à faire ? Si un programme peut leur simplifier la vie de sysadmin, c'est forcément une mauvaise idée ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Toi tu t'es jamais tapé du grep dans des logs multilignes
[^] # Re: Le but est de standardiser le contenu des logs
Posté par claudex . Évalué à 7.
Comment ça multiligne? Qui te dit que les outils ne vont pas permettre sur un truc comme
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Christophe Bliard . Évalué à -6.
D'où peut-on télécharger cet outil readlog ?
[^] # Re: Le but est de standardiser le contenu des logs
Posté par claudex . Évalué à 6.
Alors, aucun logiciel de log n'utilise se format, le projet n'est même pas fini mais il faut déjà les outils pour lire ces logs inexistant. Ça devient vraiment n'importe quoi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Batchyx . Évalué à -2.
C'est pourtant comme ça que le libre est censé fonctionner, non ? C'est le meilleur code qui gagne, pas la meilleure idée.
Mais c'est sûr que après s'être fait imposé le code crade de Lennart et d'autres (bien que les idées ne soit pas toutes mauvaises), on tolère un peu trop …
[^] # Re: Le but est de standardiser le contenu des logs
Posté par zebra3 . Évalué à 3.
Justement si, je suis sysadmin.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
Je suis adminsys également. Franchement au niveau des logs tu as le sentiment de manquer d'outils (c'est une vrai question pas un troll) ? Que ce soit pour des recherches à la main, des remontées automatiques, de la collecte centralisée, l'archivage, du stockage en bdd avec interface clic-clic, du traitement statistique … certains outils sont certes perfectibles mais le fonctionnement général est quand même globalement satisfaisant. Et la souplesse est vraiment au rendez-vous.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Buf (Mastodon) . Évalué à 6.
Le XML (ou JSON), c'est le format des messages. Ensuite, la façon dont c'est enregistré sur le disque importe peu. Si tu veux garder tes logs parsables à coup de grep/cut/awk, on peut sans doute imaginer un outil qui va aplatir la structure et virer les 3/4 des infos pour que ça rentre dans le format syslog et stocker ça dans des fichiers exactement tel que c'est fait aujourd'hui, et consulter ça avec des scripts qui cassent parce qu'on a une nouvelle version du logiciel qui introduit un champ supplémentaire dans ses logs.
Mais on peut aussi vouloir quelque chose de plus souple et plus pratique…
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 1.
Il n'y a rien de bien compliqué à cela. Faut juste apprendre.
C'est déjà ce que fait Xorg.
Entre un parseur qui sait gérer toutes tes appli et N parseur, il n'y a que ceux qui n'écrivent pas ces dit parseurs pour préférer le second cas.
Je pense que ceux qui sont contre un standard pointu de log (sans remettre en cause leur compétence) n'aiment tout simplement pas le libre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Grunt . Évalué à 1.
Xorg est un bon exemple de truc devenu totalement moisi sous prétexte d'amélioration : le raccourci Ctrl + Alt + BackSpace désactivé par défaut (bon sang que c'est pratique ce truc), le fichier de conf qui a disparu (bon courage pour en écrire un à la main).
Bon, ceci dit ça va être remplacé par Wayland, on verra si Wayland marche au moins aussi bien que Xorg.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par barmic . Évalué à 2.
Alt + Impr + k est pas mal, mais sinon 1 minute + vi et c'est terminé (si tu veut plus simple il existe un utilitaire dontzap).
Si c'est un si gros problème remonte un bug au mainteneur du paquet dans ta distribution, mais d'avis que la majorité ne s'en porte pas plus mal.
Comme avant ?
Et donc on fait quoi ? On se dote d'outils pour gérer même les logiciels les plus pourris du globe ou on reste entre AOC « bon logiciel sous philosophie unix et libre copylefté » ? :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Je ne suis pas contre un standard dans le format des message. Si certains trouvent ça utile soit. Personnellement je n'en vois pas l'utilité. D'autant plus qu'un parser de logs c'est 20mn de perl à coder.
Par contre personne ici n'a pu m'expliquer ce qui justifiait vraiment la nécessité de tout péter.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Michaël (site web personnel) . Évalué à 4.
Tu as bien raison, mais s'il fait apprendre à utiliser une bibliothèque XML pour écrire ce parser, cela va sensiblement compliquer le problème.
# suis-je le seul à penser ça ?
Posté par Jiel (site web personnel) . Évalué à 0.
Comme pour l'article précédent "HTTPS Everywhere en version 2.0.1", quel intérêt de ce gros logo au milieu de cette news ? Ca donne l'impression d'être sur un site web de débutant avec des couleurs et des GIF animées dans tous les sens.
[^] # Re: suis-je le seul à penser ça ?
Posté par samo . Évalué à 0.
M'est avis que ce genre de logo aurait sa place en remplacement du pingouin.
Au lieu de "Linux" (quantité d'information assez faible), la rubrique aurait pu carrément être "Lumberjack", avec le logo qui l'illustre…
[^] # Re: suis-je le seul à penser ça ?
Posté par claudex . Évalué à 2.
On ne va pas créer une catégorie pour chaque dépêche non plus.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: suis-je le seul à penser ça ?
Posté par samo . Évalué à 2.
Mais avoue que "Linux" comme catégorie sur DLFP ça fait un peu trop large.
[^] # Re: suis-je le seul à penser ça ?
Posté par BAud (site web personnel) . Évalué à 4.
Cela pourrait être déplacé dans la catégorie supervision au besoin…
[^] # Re: suis-je le seul à penser ça ?
Posté par Zenitram (site web personnel) . Évalué à -3.
Oui, encore…
Quel est l’intérêt de la couleur sur ce site? Des formes graphiques? (le CSS, vraiment, ça pue)
GIF animé, rien que ça… Faut arrêter le délire.
Sinon, tu as Lynx, n'hésite pas à t'en servir.
[^] # Re: suis-je le seul à penser ça ?
Posté par Jiel (site web personnel) . Évalué à 5.
Il y a plusieurs CSS et on peut choisir celle qui nous plait. D'ailleurs, globalement, mis à part les avatars, les charte graphique par défaut de LinuxFR me plait. Je faisais cette remarque pas pour râler, mais simplement parce que je trouvais que ce type de grosse image au bon milieu de l'article, ça pollue plus les yeux qu'autre chose et ça gêne la lecture. Après si je suis le seul que ça dérange, t'inquiète pas, effectivement il y a Lynx et plus simplement la possibilité de ne pas afficher les images.
# I'm OK
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à -1.
Suis-je le seul à avoir pensé qu'il y avait un rapport avec Python? :)
La gelée de coings est une chose à ne pas avaler de travers.
# But
Posté par Buf (Mastodon) . Évalué à 2.
Pas seulement. Le gros intérêt du truc à mon avis, c'est pour les outils qui vont lire les logs.
En standardisant le format pour les évènements qui sont loggés, on facilite aussi grandement la création d'outils qui vont utiliser ces logs. Je pense par exemple à des systèmes d'alerte, de statistiques ou simplement un outil de consultation de log qui permette de trier et filtrer simplement tout ça, et qui présenterait les données sous une forme lisible.
[^] # Re: But
Posté par Grunt . Évalué à 8.
L'idée serait alors de passer de "l'administration par un administrateur qui sait administrer" à "la bidouille par un utilisateur qui installe une interface Web censée permettre d'administrer".
En tout cas c'est l'impression que ça me fait, comme si on se dirigeait vers un modèle "à la Windows", où les interfaces, les outils, utilisés pour administrer la machine et pour l'exploiter sont destinés à une seule et même personne. Le conducteur devient garagiste.
À la limite, pourquoi pas : si les utilisateurs d'Ubuntu ont envie, comme sous Windows, de faire des clics pour lire des logs dans une interface graphique et avoir l'impression de comprendre et d'administrer, c'est cool pour eux. Le problème c'est que ça menace de casser le bon fonctionnement du système, si les logs passent d'un format lisible par un humain, à "des trucs exploitables par une GUI".
Exemple tout simple, quand un périphérique USB semble ne pas être détecté mon premier réflexe est de lancer un "tail /var/log/kern.log -f" dans un shell root, de brancher le périphérique et de regarder ce qu'en fait le noyau (s'il le voit, s'il le reconnaît, s'il lui met un pilote..).
Si, demain, pour permettre à Claude Michu d'avoir une jolie fenêtre qui présente les logs comme sous Windows, je suis obligé moi aussi de me fader une application chiante qui va me compliquer la tâche, j'aurai le sentiment qu'ils auront cassé Unix, oui. Enfin, cassé Linux, restent les BSD qui ne semblent pas décidés à prendre la pente descendante.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par claudex . Évalué à 4.
En ça rend le truc illisible, ça donnerait un truc du genre
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: But
Posté par Thomas Douillard . Évalué à 1.
À comparer avec les grep chainés sur des critères mystérieux pour choper la colonne n°N qui récupère je ne sais quelle information, excellent exemple. Sans compter la possibilité de structurer le message de log de la même manière.
[^] # Re: But
Posté par Moonz . Évalué à 9.
Effectivement, si tu utilises grep pour choper la colonne N, je comprend que tu aies quelques soucis avec le système actuel.
[^] # Re: But
Posté par Thomas Douillard . Évalué à 5.
Non je voulais dire faire une sélection sur une colonne en particulier, et il faut dégainer awk pour faire ça potablement, grep ou sed c'est pas idéal pour ça et cut … fait un cut.
Et là avec awk niveau complexité tu te retrouves à faire des choses qui sont pas loin de ressembler à la requête de claudex, sauf que tu travailles avec des numéros de colonnes crytiques.
On se demande pourquoi SQL a eu autant de succès si on pouvait tout faire avec grep,sed et awk.
[^] # Re: But
Posté par Grunt . Évalué à 3. Dernière modification le 07 mars 2012 à 15:58.
Au hasard : performances, authentification ? C'est les deux premiers qui me viennent à l'esprit…
Et, sinon, SQL nécessite au moins autant d'apprentissage que grep, sed et awk. Avec cette différence que SQL nécessite un "environnement" spécifique, alors que l'apprentissage des outils shell se fait en douceur depuis celui-ci : on commence par faire un bête "grep" depuis la ligne de commande, on se retrouve à enchaîner les commandes, puis à écrire des scripts. Mais l'étape de départ c'est le bon vieux shell depuis lequel on lance également son ssh, son screen -r ou son irssi. Ça rend les outils de base immédiatement accessibles, c'est pas rien.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par Thomas Douillard . Évalué à 3.
Oui alors un équivalent de PHPmyadmin pour parcourir les logs en cli c'est immédiatement accessible aussi.
Et une commande log --lasts qui formaterait serait pas moins accessibles qu'un "tail -f". Et des paramètres pour les critères les plus courant, une regexp pour filtrer le message, c'set pas plus compliqué à mettre qu'un paragraphe dans un manuel d'intro à Unix immédiatement après la présentation du shell.
[^] # Re: But
Posté par Zenitram (site web personnel) . Évalué à 10.
Oh le bel élitisme… "Savoir administrer, c'est savoir lire des logs cryptique car dans un format pourri datant de 1970 donc avec les limites de l'époque"
Assertion sans aucune preuve. Aucun rapport entre le format des logs et le bon fonctionnement d'un système.
Ouais, un truc d'élite qui veut rester élite sans que la masse ne puisse regarder elle aussi… Argumentation bof.
Sinon, rien n’empêche tail (ou une autre commande) de reformater la sortie pour qu'elle soit comme tu veux (c'est pas ce qu'il y a de plus dur…). ** Personne** ne t’empêchera de continuer à faire à l'ancienne.
C'est beau la résistance au changement.
PS : je n'ai pas d'avis sur le changement proposé à part le questionnement sur le doublement de la taille des logs sur le disque, et encore une fois en tar.gz ça devrait pas trop se voir.
[^] # Re: But
Posté par Buf (Mastodon) . Évalué à 2.
Et c'est exactement ce genre d'outils que j'avais en tête, avant même de penser à une GUI.
Un truc qui permettent de filtrer les logs en ligne de commande, mais en donnant de vrais critères et pas via grep avec une regexp ad hoc, et qui sortirait les entrées dans un format lisible.
[^] # Re: But
Posté par Grunt . Évalué à 1.
je sais pas à quoi tu penses, mais j'ai du mal à imaginer des "vrais critères" qui dépassent la puissance d'une regexp. T'as un exemple de truc qu'une regexp n'attrape pas, et qui pourrait être implémenté dans une GUI ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par claudex . Évalué à 2.
Sauf que la regexp tu dois la modifier à chaque mise à jour (sans compter que tu peux attraper des trucs non prévu sans le vouloir), avec le format proposer les outils pour attraper ce que tu veux sont bien plus robustes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: But
Posté par Buf (Mastodon) . Évalué à 3.
Les entrées de log peuvent être vues comme des objets, les critères auxquels je pense se rapportent aux attributs de ces objets. Des trucs genre "level=WARN" ou "srcIP in 192.168.0.0/16" (j'invente complètement, mais c'est l'idée)
Des trucs de haut niveau quoi, pas un bête pattern matching sur une chaine de caractères. Rien n'empêcherait même d'avoir comme critère une regexp, mais sur un attribut (ou groupe d'attributs) particulier au lieu d'être sur une ligne complète.
[^] # Re: But
Posté par Grunt . Évalué à 3.
Ce que tu dis me fais fortement penser à une base SQL..
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par Grunt . Évalué à 10.
Mais pourquoi ces idiots te moinssent alors que ce que tu dis est pertinent ? :|
Nan. Savoir administrer, c'est différent de savoir utiliser. On ne demande pas à l'administrateur de la machine de savoir faire des beaux trucs avec Gimp, il n'y a aucune raison de souhaiter que le graphiste qui fait du Gimp soit automatiquement censer savoir administrer son Linux. C'est deux métiers différents, deux domaines différents.
Pour le "datant de 1970" je vois pas où est le problème. Le système écrou-vis date de plus longtemps, et dans certains cas il est toujours le meilleur. À mes yeux les "flat logs" des systèmes Unix est l'équivalent des écrous et des vis : ça fait ce qu'on lui demande et dans la plupart des cas c'est le meilleur système inventé. KISS.
Oui, j'aurais du dire "fonctionnement visible par un être humain". Comme l'était par exemple le format du fichier de conf de GRUB, par opposition à ceux de GRUB2. T'es un humain, tu ouvres les fichiers, tu comprends, tu peux modifier, tu peux prendre un outil simple (une clef) pour modifier ou trier quelque chose (un écrou sur une vis) d'une façon simple. Sans avoir GTK ou mysql-client comme dépendance.
Heu nan, ça n'a rien d'élitiste, je suis désolé. Du reste, qu'est-ce qu'on veut comme solution ? L'erreur est de croire qu'il existe une solution "miracle" qui va magiquement transformer le gus qui veut rien apprendre en administrateur compétent, via une interface simple et complète qui va anticiper ce qu'il veut faire en faisant exactement ce qu'il décide (oui, c'est contradictoire et c'est pour ça que ça n'existera jamais).
C'est la grosse "maladie" ces temps-ci dans le monde du libre : on s'imagine qu'un système pourra être à la fois bien conçu et stable, administrable par un utilisateur non-administrateur, résistant à l'erreur humaine, adapté à l'administrateur avancé (qui va demander des trucs précis, potentiellement dangereux et vouloir qu'ils soit exécutés tels quels) comme au débutant (qui va vouloir que l'interface anticipe sa demande et le protège des erreurs), avec pas trop d'informations pour celui qui est pressé mais plein d'informations pour celui qui est curieux ou veut résoudre un problème très subtil.. et le tout, gratuit, libre, ne dépendant pas d'une grosse méchante entreprise, codé par une dizaine de bénévoles.
Ben non, faudra sacrifier un truc. Par exemple le "libre et gratuit", et ça donne MacOS. Ou alors la confusion entre administrateur et utilisateur, et ça donne Debian. Ou alors le "stable", et ça donne Ubuntu.
La solution "tail /var/log/kern.log -f" elle marche.
L'autre solution c'est quoi ? À la Windows ? "tididim (petite musique), un nouveau périphérique USB a été détecté". "twimp (bruit stressant), le périphérique a été détecté correctement mais ne semble pas fonctionner. Un pilote par défaut a été chargé mais peut ne pas permettre d'accéder à toutes les fonctionnalités. Cliquez ici pour plus de détails." Là tu cliques et tu te retrouves dans le ClickReich, avec plein de boutons pour tout casser, et la nécessité d'aller lire la doc de Microsoft en ligne, ou demander de l'aide aux gens qui s'y connaissent, pour faire quelque chose d'intelligent (c'est à dire, trouver pourquoi y'a un problème, le résoudre, tout en ayant appris des trucs utiles pour le cas où ça se reproduirait). Donc, dans les deux cas : lire la doc (man tail ou documentation Microsoft, sans jugement de valeur entre les deux) et/ou demander de l'aide aux gourous. Windows ajoute en plus la possibilité de faire plein de conneries et tout péter, là où Linux te met pas le bouton rouge sous le nez. Je doute que ça soit un avantage réel.
Chat échaudé craint l'eau froide : "ils" ont cassé GRUB (GRUB2 n'est de fait plus éditable/bidouillable, faut s'en remettre à des outils magiques qui masquent le fonctionnement réel), Xorg (plus de fichier de config). J'espère que tu as raison et que le nouveau format de log sera transformable en quelque chose de simple sur lequel c'est un humain qui va mettre du sens.
Personnellement, l'intelligence je la préfère entre la chaise et le clavier, et la machine qui fait des trucs idiots de l'autre côté des interfaces.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par Grunt . Évalué à -2.
Et, au lieu de me plusser parce que vous êtes d'accord, plussez Zenitram parce qu'il dit des choses pertinentes, même si vous êtes pas d'accord. merci.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est gentil :).
Mais pas sûr que les gens arrivent à supprimer leur façon de faire "je suis d'accord / pas d'accord".
[^] # Re: But
Posté par Grunt . Évalué à 1.
C'est triste, ton avis sur les gens.
(Et hop, running gag, +10. Donc -10 car j'ai prédit le +10. LinuxFR est une machine avec très peu d'entropie, finalement).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par Zenitram (site web personnel) . Évalué à 2.
Bah… Tu dois bien me connaitre maintenant, moi et mon avis sur les gens (surtout français) ;-)
[^] # Re: But
Posté par Prae . Évalué à 1.
Déjà à l'époque (2004) j'avais initié le changement des liens de votation par "pertinent" et "inutile" pour changer ce mauvais réflexe. Rien n'a changé. Les gens votent toujours "inutile" s'ils ne sont pas en accord avec le message. Dommage.
[^] # Re: But
Posté par Anonyme . Évalué à 0.
Donc les commentaires qui répètent ce qu'un autre a déjà dit un peu plus haut sans rien y ajouter de vraiment nouveau doivent être dégradés ?
Si je suis cette logique, on pourrait très bien détruire après un certains temps les contenus ayant une note négative pour ne garder que le meilleur et réduire le bruit dans les recherche de contenus archivés.
[^] # Re: But
Posté par Thomas Douillard . Évalué à 6.
Non, l'erreur c'est de croire que quelque chose d'accessible à quelqu'un de moins expériementé est nuisible à l'administrateur compétent qui s'en sortira toujours.
Et de confondre les concepts avec leurs implémentation, pour savoir ce que devient un périphérique l'important c'est de savoir qu'on peut consulter les logs, pas qu'il faut faire "tail -f /var/log/messages" ou whatever.
Ensuite l'opération d'accession des logs, il n'y a pas de raison de mettre de barrières technique artificielles à ça.
[^] # Re: But
Posté par Grunt . Évalué à 7.
Je sais pas ce que tu veux dire, mais pour moi, passer de "logs plats" à "fichiers XML lisibles avec un outil dédié" est une barrière technique artificielle.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par claudex . Évalué à 4.
Pourquoi se focaliser sur le XML, il y a aussi du JSON? Pourquoi dire que le JSON est illisible avec un bête éditeur de texte?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: But
Posté par Grunt . Évalué à 10. Dernière modification le 07 mars 2012 à 20:10.
Oui, c'est lisible.. en fait, à force d'en discuter, je me rends compte d'où vient précisément ma réticence. Et pour ça (désolé) va falloir que je raconte un peu ma vie.
Au début j'étais sous Windows. Je m'intéressais pas plus que ça à l'informatique. Les rares bidouilles que je faisais c'était par exemple modifier des fichiers de conf plats dans des jeux, et mettre des trucs du genre "difficulty=0" ou "difficulty=4" là où la GUI permettait de sélectionner entre 1 et 3, et regarder ce que ça faisait.
Mais y'avait pas vraiment moyen de bidouiller, l'interface était trop lissée pour attiser la curiosité, et dès qu'on grattait un peu le système était au contraire trop "obfusqué". Aucune accroche pour l'envie naturelle d'apprendre.
Pis je suis passé sous Linux, et là c'était la révélation, parce qu'on voyait les rouages. On les voyait au boot (le kernel qui charge son bordel), on les voyait dès qu'on ouvrait un fichier un peu au hasard dans /etc ou /var (la plupart du temps le fichier était lisible). Ça donne envie d'apprendre, de tester, de casser et de bidouiller. Je moulerais pas sur LinuxFR si c'était pas foutu comme ça.
Et, à force de voir débarquer sur Linux des choses comme un splashscreen au boot, des fichiers de conf en XML (voire des bases de registre, cf gnome..), des fichiers de logs avec une syntaxe qui va se complexifier, j'ai peur qu'on perde cet esprit-là. Qu'on perde la possibilité de faire envie avec de la mécanique qui dépasse. Un peu comme les voitures ont évolué, avec maintenant la présence systématique d'un cache en plastique par dessus le moteur. Y'a 20 ans, un gamin regardait un de ses parents bricoler la voiture, il voyait des choses complexes qui ont des liens logiques entre elles. Maintenant y'a un mur de plastique avec un logo. J'ai pas envie que Linux devienne ça, et que les gamins de maintenant et du futur qui ont, potentiellement, la curiosité excitable par les rouages de l'informatique, passent à côté de quelque chose.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par claudex . Évalué à 5.
Je trouve que justement pour continuer à donner envie, Linux est bien. Il y a un splash screen mais il suffit d'appuyer sur Esc (la plupart du temps) pour qu'il affiche les messages de boot. Tu râle contre la disparition du fichier de conf de Xorg mais il y a Xorg.conf.d qui est justement pour moi un meilleur moyen de bidouiller parce qu'on est face à des fichiers plus petit, donc plus abordable.
De plus, quand on parle des fichiers XML de configuration, on cite souvent policykit mais ces fichiers ne sont censé être modifié, ceux qui le sont, sont des fichiers simpes. (D'ailleurs, je trouve que raler contre ces fichiers fait plus de mal qu'autre chose, cachant le fait que ça configure simplement).
Bref, même s'il y a des trucs qui cache la configuration, ce n'est pas trop mal au final. Et si on veut continuer à attirer les utilisateurs qui s'intéresse au fonctionnement, il faut les intéresser à la base, et pour ça, il faut répondre à un maximum de besoin.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: But
Posté par gik . Évalué à 5.
T'as raison, peut-être que c'était mieux a vent "quand les hommes étaient des durs et écrivaient eux-même les pilotes pour leur matériel ? Êtes vous sans projet intéressant et avez vous envie de mettre les mains dans le cambouis d'un OS que vous pouvez adapter à vos besoins ? Est-ce que ça vous énerve quand tout marche bien sous minix ? Ne passez vous plus de nuits blanches à essayer de faire marcher un super programme ? Alors ce message est sûrement pour vous."
Sauf que de l'eau à coulé sous les ponts et à présent l'auteur de ce message se demande s'il ne doit pas changer de distribution parce que des menus disparaissent sous gnome. Il explique aussi sur un réseau social à la mode qu'il a donné sa chance à OpenSUSE parce que l'installation c'est super bien passé sur son Macbook Air, mais qu'il en a assez de taper son mot de passe pour changer de réseau wifi.
https://plus.google.com/u/0/102150693225130002912/posts/1vyfmNCYpi5
Du coup je ne sais plus quoi penser…
Personnellement, je n'oppose pas la simplicité à la facilité d'utilisation, mais il y a des gens plus malins et certes moins nostalgiques qui font des choix à ma place.
Quoi qu'il en soit, je ne suis pas à ce point pessimiste que de n'avoir à clamer que GNU/Linux se windowise. Ou alors ne suis-je pas assez démagogue.
[^] # Re: But
Posté par Grunt . Évalué à 5.
Non, c'était mieux quand le système donnait aux petits enfants l'envie de bidouiller. Rien à voir avec les "durs", donc. Au contraire. L'idée c'est d'avoir une pente douce entre l'usage normal et l'apprentissage de l'administration. Cette pente douce elle existe sous Linux, par la simplicité du système (tu sais lire => tu peux apprendre). J'ai peur qu'on la perde et qu'on se retrouve comme sous Windows avec un gouffre entre l'usage simple et l'administration efficace.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par Zenitram (site web personnel) . Évalué à 4.
Linus T. est un bidouilleur (je pense que tu auras du mal à affirmer le contraire), mais ça ne l’empêche pas d'avoir envie d'une distro simple pour la vie de tous les jours.
Être bidouillable != être illisible et devoir se farcir une ligne de commande pour lire des logs non structurés juste parce qu'on aime souffrir (ça ne s'appelle pas être bidouilleur, mais être masochiste).
Je comprend ton envie de bidouiller. Mais je ne vois absolument pas le rapport avec le changement proposé qui est de structurer un log (si tu as envie, ben ton logiciel actuel de lecture, tu le modifies pour qu'il détecte le format de log et le transforme "à l'ancienne" pour ton plaisir d'être à l'ancienne non structuré, c'est possible)
Bref, ne pas confondre bidouilleur et résistance au changement, ici le changement proposé n’empêche pas la bidouille (il n'y a pas un bout de plastique sur le moteur "pas touche", juste un format qui change pour être plus structuré)
[^] # Re: But
Posté par Moonz . Évalué à 4.
C’est cat, less, gedit. Bref, des commandes que toute personne curieuse connaît.
Du coup, il faut :
- savoir que c’est un format spécial
- connaître les logiciels nécessaires pour pouvoir le lire
Aujourd’hui, tu connais ls, cd, et cat, tu peux découvrir 90% de ton système. Avec une telle logique (c’est pas grave, suffit d’écrire un logiciel qui parse le format structuré), ce n’est plus le cas.
Ce n’est pas mon envie de bidouiller. C’est l’envie de bidouiller du moi d’il y a dix ans. Et celle d’éventuels futurs curieux qui seront demain dans le même état d’esprit que j’étais il y a dix ans.
[^] # Re: But
Posté par Xavier Teyssier (site web personnel) . Évalué à 6.
une syntaxe qui va se complexifier, j'ai peur qu'on perde cet esprit-là.
Je ressens un peu la même chose : j'ai le sentiment que l'on complexifie tellement certaines briques que cela risque de repousser des contributeurs potentiel, la marche à franchir pour comprendre le système devenant trop élevé.
Pour prendre un exemple récent : j'avais une machine sous CentOS 4 qui ne démarrait plus. Écran noir pendant la phase de boot. J'ai mis les mains dans le cambouis, et comme je n'ai pas trop de souci avec le Bash, j'ai trouvé la partie de l'init qui merdait, l'ai corrigé, et la machine a pu repartir. Avec le remplacement de l'init System V par le blob systemd, pour faire la même chose, il m'aurait fallut analyser un machin en C, ce dont je suis incapable. Et de manière général, les gens qui gèrent des problèmes de boot, ce sont souvent des admin sys, et les admin sys, pour ceux que je connais, ils connaissent bien mieux Bash que le C.
Pour les logs, on se dirige vers la même chose : sous prétexte que le format CSV, c'est vieux et archaique, on décide soudain qu'il faut le changer et on va mettre en place une structure bien plus complexe qui nécessitera, pour les exploiter, des outils de plus haut niveau que les grep/sed/awk habituels.
Je trouve cela d'autant plus dommage que les logs, sur mon réseau de machines, c'est bien l'un des rares domaines où je n'ai pas eu de souci, ni en terme de fonctionnement, ni en terme d'outil pour les exploiter !
[^] # Re: But
Posté par barmic . Évalué à 6.
Le nombre de collonne, les caractères séparateurs de tuples et de champs sont un vrai problème, même si tu te contente de les ignorer.
C'est utiliser le CSV dans les logs ? Moi j'en ai jamais vu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: But
Posté par gnumdk (site web personnel) . Évalué à 2.
Bon, il serait peut être temps de regarder ce que fait systemd au lieu de raconter n'importe quoi…
Ca va rien changer, tu vas pas avoir à débuger systemd si ton systeme boot pas, tu vas vérifier la conf, vérifier les scripts BASH de pre-init de service…
[^] # Re: But
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
tu vas pas avoir à débuger systemd si ton systeme boot pas
Ah bon ? Pour affirmer cela, tu peux me garantir que systemd n'aura aucun bogue, et/ou alors qu'un plantage complet de systemd n'empêchera pas mon systême de booter ?
Parce que sinon, je ne suis pas à l'abri d'un bogue de systemd qui bloquera mon système, et pour lequel je risque fort de ne pas avoir les compétences nécessaires pour le réparer.
[^] # Re: But
Posté par barmic . Évalué à 3.
Tu as déjà eu a debug init ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: But
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
Tu as déjà eu a debug init ?
De ce point de vue, le truc le plus "profond" que j'ai eu à débugguer, c'est rc.sysinit.
[^] # Re: But
Posté par Moonz . Évalué à 5.
Vouloir pouvoir débugger rc.sysinit ne signifie pas forcément avoir un bug dans rc.sysinit, mais ça peut vouloir dire que c’est le meilleur endroit pour ajouter un trace de debug (cat /proc/modules > /tmp/log) quand tu as un problème bizarre
Et oui, ça m’est arrivé il y a pas plus tard qu’un mois (pas le bug dans init, mais le fait d’avoir à ajouter des traces de debug très tôt dans la phase de boot qui est heureusement en shell)
[^] # Re: But
Posté par gnumdk (site web personnel) . Évalué à 1.
Et tu peux m'affirmer que y'a aucun bug dans le binaire de bash ?
[^] # Re: But
Posté par Batchyx . Évalué à 1.
Si tu trouve que bash est trop gros et a trop de bug, tu le change. Je t'ai même pas attendu pour le faire.
[^] # Re: But
Posté par gnumdk (site web personnel) . Évalué à 2.
Et qui te dis que y'a pas un bug dans dash ?
[^] # Re: But
Posté par Batchyx . Évalué à 3.
S'il y en a un et que les mainteneurs de dash en ont rien à foutre, j'en utiliserait un autre. Il doit y avoir au moins 5 implems qui savent respecter le standard. On peut espérer qu'il y en a au moins un qui ne soit pas trop buggé. Alors que systemd, il n'y qu'une implem et aucune spec. Si jamais il y a un gros bug la dedans ou une grosse limitation que Lennart trouve normale, t'as le choix entre crever, tout migrer ou tout réimplémenter
[^] # Re: But
Posté par barmic . Évalué à 3.
Je ne comprend vraiment pas le problème du XML. On nous explique qu'il est lourd et illisible :
Je ne vois pas ce qui t'aurais gênait à faire tes bidouilles dans tes jeux avec un fichier comme ça :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: But
Posté par sifu . Évalué à 3.
[^] # Re: But
Posté par barmic . Évalué à 0.
Oui mais il inclus la description des données. Au final la quantité de données est plus importantes.
Sans logrotate c'est sur que ça marche moins bien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: But
Posté par sifu . Évalué à 5.
Honnêtement dès que la quantité de données à gérer est conséquente, la description des données devient un fardeau. Tu te retrouves à faire des trucs comme limité le nom des balises, des attributs etc. pour essayer de gratter où tu peux …
C'est sûr qu'ont peut limiter la taille. Après, je considère qu'un log de 100Mo sur un serveur qui a de l'activité doit se faire assez rapidement (au doigt mouillé).
Personnellement, j'ai rien contre le XML, ce qui m'ennuie par contre, c'est que l'on considère qu'il idéal pour stocker des moyens/gros volumes de données.
Un gros fichier XML reste difficile à manipuler.
- DOM et Xpath nécessite que l'ensemble du document soit en mémoire.
- SAX offrira de meilleur performance mais pas la même facilité d'usage.
Après, j'ai lu en diagonale, mais j'ai l'impression qu'on s'enflamme un peu car on parle surtout de la façon de transmettre les informations au serveur et non du stockage.
Voilà. Je suis pê rouillé en XML mais j'ai souvenir d'avoir souffert un peu avec des gros fichiers …
[^] # Re: But
Posté par ckyl . Évalué à 6.
XPath nécessite de monter le document en mémoire par ce tu as des accesseurs qui peuvent revenir en arrière dans le document.
Maintenant si tu regardes ce que les admins font avec grep/cut/awk/sed, je pense que si tu le traduis en XPath on peut parier qu'ils ne se servirait que d'un ensemble de XPath avec des accesseurs vers les noeuds suivants uniquement. Avec un tel sous ensemble tu peux très bien ne pas monter le document en mémoire mais bosser sur un flux Sax/Stax. Tu peux aussi faire comme VTD-XML qui permet déjà d'aller chatouiller des grosses volumétries.
Le gros problème de XML, c'est le manque de bon outil spécialisés en CLI et la méconnaissance du XML et des outils associés par les personnes devant le manipuler. Et aussi d'être souvent utilisé à très mauvais escient :p
[^] # Re: But
Posté par darkleon (site web personnel) . Évalué à 1. Dernière modification le 08 mars 2012 à 16:14.
@sifu
Techniquement, je suis d'accord avec toi, la manipulation de fichiers XML, c'est lourd et inefficace.
Qui des outils de filtres directement sur cette DTD/XMLSchéma spécifique, parce que se palucher un fichier XSLT pour faire un "grep INFO", ça va un peut me casser les pieds.
Et tous les outils graphiques d'analyse de ces logs vont passer par DOM ou XPath, si les logs sont trop gros, ils ne seront plus possibles de les ouvrir (je sais logrotate toutça, mais c'est un paramètre en amont de la production des logs, je fais comment si les logs ont été mal paramétrés).
Heureusement, le format XML choisit est assez simple et permettrait l'utilisation de SAX pour le traitement en "flux".
En fait, c'est la balise racine qui nous emm..de, comme elle crée un conteneur autour des événements, il faut tout charger.
Il faudrait un format 1/2 XML, pas de balise racine, mais uniquement une succession de blocs pour un événement formaté, mais rien n'est prévu dans ce sens par XML ou SGML, ce qui fait que ce ne sont pas les formats plus adaptés.
Et comme dit un autre message plus bas, le format XML est très fragile quand on insère un XML dans un autre XML, je peux vous dire que dés qu'on commence à taquiner du [CDATA[ ]] ou qu'on applique plusieurs XSLT à la suite, je ne vous dis pas les résultats sur les & transformés en & amp; et autres joyeusetés (déjà je n'ai pas réussi à écrire la syntaxe exacte CDATA dans la saisie de post, et je ne peux pas écrire & amp; collé).
Les transformations ne sont pas consistantes, on ne peut pas protéger une balise contre l'extension par rapport à un autre. C'est un joyeux merdier.
Formater les logs pour les rendre résilients aux conneries : OUI (mais comment, la chasse au troll est lancée)
Utiliser le XML qui par définition est résilient aux conneries (sauf autre langage ..ML inséré dans une balise): mouais, y a du mieux par rapport au vieux système, mais on perd beaucoup trop en KISS (outils de filtrages spécialisés à ajouter à l'OS ou paluchage XSLT)
[^] # Re: But
Posté par Thomas Douillard . Évalué à 2.
Avoir une visualisation adaptée, qui permet de trier, de sélectionner, de formater de manière lisible à l'aide d'un outil dédié n'a rien d'une barrière technique.
Les logs plats c'est très bien pour faire un tail -f, mais en pratique c'est quasi la seule application de tail -f … avoir une commande dédiée à la visualisation en console un peu plus riche ne change rien à l'efficacité du bousin. C'est certe souple, mais rien que tu ne puisse faire de manière plus efficace avec d'autres technos manipulant des données un poil plus structurées, et ça ouvre des possibilités.
Ensuite sur tail/sed/grep c'est des outils génériques qui manipulent du texte mais qui sont pas toujours très efficaces comparés à d'autres méthodes du fait qu'ils manipulent des trucs pas ou peu structurés. En gros c'est bien pour … manipuler des fichiers de conf et des fichiers de logs. Tu remarqueras que ces dernières années même sous Unix on s'est éloigné de la configuration uniquement à base de fichier textes, c'est à mon avis lié à ces problèmes.
[^] # Re: But
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
C'est lié à RH et Suse qui vendent du support et des formations ;-)
Avec Java et Tomcat, on a eu droit a du XML partout, NetwokManager au début était très très lié à l'interface graphique… Bref, ils ont développé des trucs qui était conçu pour être manipulés par IHM uniquement.
Combien de boite installe RH sans X11 comme serveur ? Je viens d'acheter un gros NAS, bing, X11 (première chose que j'ai viré) !
Je pense que c'est une culture d'une partie des développeurs d'aujourd'hui qui font l'hyhopthèse X11 ou Web2 à la base de leur produit.
Autre travers que j'ai vu dans les applications web. Par exemple avec TRAC en mode SQLite, les sessions sont gérées dans la même base SQLite que les données ! Donc dès qu'une personne navigue dans ton TRAC, la base SQLite est modifiée. C'est un design pourris, on ne devrait pas stocker la configuration, les données, les sessions et les logs dans la même base. Je fais du lsyncd pour faire un backup RAID1 en temps réel de ma forge pour du PRA simplifié, j'en ai rien à foutre de conserver les sessions en cas de crash… Le fait de tout mélangé est une énorme surcharge réseau qui en pratique complexifie tout et ne sers à rien.
On est en train de suivre l'approche toute pourris de Windows avec sa base de registre ou tout est mélangés… et ou sans IHM, c'est un merdier pour s'y retrouver.
[^] # Re: But
Posté par zebra3 . Évalué à 3.
Et l'administrateur qui sait administrer mais qui a autre chose à faire que devoir fouiller à coup de grep dans de multiples fichiers ? On peut aussi juste vouloir gagner du temps.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: But
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
Oui enfin entre chercher à coup de grep ou avec un ctrl-F, je choisis la première solution qui a le mérite d'être efficace. Pour mettre de côté des logs caractéristiques et faire un premier trie automatique, je te conseilles de regarder du côté de syslog-ng.
[^] # Re: But
Posté par moi1392 . Évalué à 6.
ça n'empêche en rien l'administrateur qui sait administrer de continuer son administration.
Et puis je pense qu'on verra assez vite un démon qui parsera le nouveau format et écrira des logs dans l'ancien pour pouvoir toujours utiliser ses scripts si vraiment on est dans le besoin.
Et ??? si on te dit qu'il faut lancer "plop -atchoum /var/log/my_plop" à la place, ça changera quoi pour toi ? Peut-être qu'en tant qu'administrateur qui sait administrer ses administrations, tu as perdu la faculté d'être un humain qui sait apprendre et changer ?
Je suis dans le même cas, et ça me ferai bien chier que ça soit ce qui arrive, mais c'est n'est pas du tout l'impression que j'ai. Et c'est peut-être ce point qu'il est intéressant de discuter en fait.
[^] # Re: But
Posté par moi1392 . Évalué à 2.
Trop tard pour éditer, mais un trois lignes de texte à moi ce sont retrouvés dans une quote.
il fallait lire :
Perso, je n'ai jamais réussi à lire les données magnétiques d'un disque dur, peut-être que les administrateurs qui savent administrer leur administration ont une meilleur vue que moi et savent faire, mais pour l'instant, j'ai encore besoin de logiciels, qu'ils soient dans une gui ou pas, pour lire mes logs.
Moi ce que je vois dans cette news, c'est que ces logiciels et la façon de les utiliser pourra peut-être être différente. Mieux ? j'en sais rien, mais différente.
[^] # Re: But
Posté par Grunt . Évalué à 7.
Donc, j'utiliserai "tail" pour les fichiers plats, "plop" pour les logs du kernel, "znort" pour les logs d'apache et "grumpf" pour la fin d'une liste de fichiers triés par taille ?
Ça changera qu'avant j'utilisais la brique "tail" qui fait juste ce qu'on lui demande et le fait bien. Me semble que c'est la base d'unix, ce découpage en outils élémentaires qui font chacun une seule chose et qu'on met bout à bout, comme des Lego, pour faire une chose plus complexe. Là où sous Windows, par exemple, faut prendre le freeware Bidule qui a été conçu pour "détecter pourquoi les trucs USB ils marchent pas", l'installer, et en prendre un autre quand c'est un truc PCI qui marche pas.
Exemple de tel freeware, TreeSize. Un logiciel Windows dont la seule raison d'être est d'indiquer quels dossiers et fichiers bouffent de la place sur un disque dur.
Sous Linux, je préfère avoir le même résultat que TreeSize en combinant intelligemment une demi-douzaine de commandes (find, ls, tail, grep, wc, du..). Autrement dit, apprendre ces commandes, les maîtriser, les intégrer à mon utilisation habituelle, et les avoir sous la main pour résoudre un problème inédit. C'est pour ça que j'aime les systèmes de type Unix.
Si on se dirige vers une solution "à la Windows", avec "une commande pour lire les logs", je trouve ça dommage d'un point de vue technique.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: But
Posté par moi1392 . Évalué à 3.
Sauf si ce standard est efficace, intéressant et bien fait (ce que je ne prétends pas du tout), dans ce cas là, on peut expérer que apache et les autres s'y mettent.
Et la commande universelle plop les lira tous :)
J'ai pas spécialement envie non plus d'avoir 15 logiciels différents pour lire mes logs.
mais pour l'instant, j'en ai au moins 2 : less et zless (oui, zless sait lire les fichiers non compressés, mais je ne connais pas d'équivalent ztail)
du coup, je vois bien un unxml_the_log que je pourrai tuber avec mes autres outils pour faire le même travail qu'avant.
Sauf qu'en plus, peut-être qu'avec de la chance, j'aurai des outils automatisés que je n'aurais pas à écrire et maintenir moi même (je ne suis pas administrateur à la base, mais plutôt développeur, et j'ai plus tendance à sortir de ma trousse c++/qt et g++ pour résoudre un problème simple que du tail, grep, awk, même si je m'en sers tout de même régulièrement) qui m'éviterons d'avoir à aller mettre mon nez là dedans pour des broutilles ou des soucis qui ne sont pas encore visible depuis mon interface.
Typiquement, un matos qui déconne et des messages bizarre de temps en temps dans mes logs, avec de la chance, j'aurais une alerte avant que ma machine ne me plante à la tête.
[^] # Re: But
Posté par Moonz . Évalué à 4.
[^] # Re: But
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 2.
Je n'ai qu'une petite expérience en xml, mais pour avoir eu besoin de jouer avec lshw -xml, je me suis bien gratter la tête pour récupérer les infos nécessaires. Je n'utilisais peut-être pas l'outil le plus adapté, mais si on doit se taper des lignes de commandes du style :
pour aller chercher la moindre petite info, je préfère largement le fichiers à plat!
# Les standards
Posté par chaispaquichui . Évalué à 9.
# Intérêt ?
Posté par AhmetD (site web personnel) . Évalué à 8. Dernière modification le 07 mars 2012 à 12:51.
Sur des gros serveurs, tu te retrouves avec des milliers de lignes et ce qui me dérange ce n'est pas l'exploitation de ces données car je pense que si on passe à une standardisation (de ce genre), on aura un loggrep etc., mais la taille de celles-ci.
On passe quand même de :
=> 97 octets
à (JSON)
=> 173 octets
Et (XML)
=> 184 octets
[^] # Re: Intérêt ?
Posté par claudex . Évalué à 7.
En même temps, on peut déjà retirer les retour à la ligne et l'indentation.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt ?
Posté par zebra3 . Évalué à 2.
Et la compression, c'est pour les chiens.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Intérêt ?
Posté par gik . Évalué à 0. Dernière modification le 08 mars 2012 à 01:57.
Non c'est pour le gaz. Mais oé, à coup de lzo, je dirais que c'est pas la mer à boire, surtout quand c'est le système de fichier qui s'en occupe.
[^] # Re: Intérêt ?
Posté par JoeltheLion (site web personnel) . Évalué à 3.
Rien, mais rien n'empêche de faire un petit outil json2log qui fasse la traduction. Et là, on a le meilleur des deux mondes: les logs sont exploitables de manière automatique et robuste, et faciles à lire à la main:
L'argument de la taille du fichier ne tient pas, on peut compresser en zip et le problème est réglé.
[^] # Re: Intérêt ?
Posté par Tonton Th (Mastodon) . Évalué à 10.
UUOC
[^] # Re: Intérêt ?
Posté par JoeltheLion (site web personnel) . Évalué à 1. Dernière modification le 07 mars 2012 à 20:50.
Revendiqué :)
[^] # Re: Intérêt ?
Posté par barmic . Évalué à 3.
Tu peux aussi imaginer utiliser du BSON si ça te fait plaisir.
En principe avec un gros serveur tu va utiliser un serveur de log, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Ouai enfin là, celui qui a pondu les exemples, il n'a pas vraiment compris l’intérêt des namespace. Plutôt que de définir un prefix p xmlns:p="http://lumberjack.org", il suffit juste de déclarer directement xmlns="http://lumberjack.org" (au pire tu laisse aussi xmlns:p="http://lumberjack.org" pour les balises lumberjack imbriqué dans d'autres namespaces, et, oh, miracle, tu as un fichier plus leger et plus lisible
Ensuite, j'ai l'impression que ceux qui ont pondu le schema, ne connaissent pas vraiment XML (comme beaucoup de développeur d'ailleurs, faut voir les formats xml de certains autres logiciels libres…)
Par exemple, dans une balise level, à priori, on ne risque pas d'avoir autre chose que le nom du niveau donc pas d'autres balises à l'interieur. Idem, pour time, on ne va pas avoir autre chose que la date. Idem pour id. Pourquoi donc ne mettent-ils pas ça dans des attributs ??
Parce que tout de suite, ça deviendrait plus concis, et peut-être plus lisible pour certains :
Hop, 30% d'espace économisé.
D'un point de vue "philosophie XML", c'est aussi plus cohérent.
On laissera toutefois msg comme ça, on sait jamais, si il y a besoin à l'avenir de faire évoluer le format du message du genre File does not exist: /usr/local/apache/htdocs/favicon.ico, ou pour permettre aux programmes de rajouter d'autres balises à coté dans Event.
Bon et puis pour leur format en json, c'est d'un total ridicule, de vouloir finalement imiter le XML (avec lerus declarations de namespace ou autre) sans faire de XML. On tue finalement les avantages du JSON. aucun intérêt.
[^] # Re: Intérêt ?
Posté par AhmetD (site web personnel) . Évalué à -4.
Oui mais nan. A une époque j'ai manipulé jdom pour faire mumuse avec du xml. Et il me semble (je me trompe peut-être) que les attributs doivent-être fixes. Sauf que tu n'as pas tout le temps id, msg, level par contre time oui. Donc la structure est bonne.
[^] # Re: Intérêt ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
tu te trompes carrément. Un getAttribute() sur un element ne va pas broncher si l'attribut n'existe pas. Il renverra null dans ce cas et c'est tout.
D'ailleurs le getAttribute est plus performant (les attributs sont stockés dans une table de hash) que d'aller essayer de chercher un element fils puis son contenu textuel (il faut parcourir le sous arbre…).
[^] # Re: Intérêt ?
Posté par Buf (Mastodon) . Évalué à 3.
J'ai plutôt l'impression qu'ils ont conçu le truc pour qu'il y ait un mapping 1:1 entre JSON et XML, et que le passage de l'un à l'autre soit trivial.
Après, ok, ça donne du JSON un peu bizarre et du XML sous-optimal, mais ça me semble finalement assez secondaire, le truc important étant qu'on peut travailler indifféremment avec les 2 représentations. Ça me semble être un compromis acceptable.
[^] # Re: Intérêt ?
Posté par zebra3 . Évalué à 5.
Je dois dire que j'ai du mal à voir l'intérêt d'un nouveau standard s'il n'est pas optimal. C'est dommage de devoir faire des compromis parce qu'on n'a pas su faire le choix entre JSON et XML, surtout que ça n'a ici rien à voir avec la préservation de l'existant, seul cas qui mérite souvent des compromis.
Quitte à faire quelque chose de nouveau, autant que ça soit au top, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Intérêt ?
Posté par CrEv (site web personnel) . Évalué à 3.
Sur le principe oui.
En pratique, non, surtout pas.
Surtout pas, car c'est dans ce genre de quête qu'on se perd souvent, qu'on perd beaucoup de temps et au final on a rien. Surtout si on vise cette perfection initialement.
Il y a pas mal de maximes sur le sujet, la plus connue étant "le mieux est l'ennemi du bien".
On peut ensuite parler de worse is better.
Et dans les faits on se rend compte que, souvent, les solutions moins optimales mais plus souples fonctionnent mieux et sont plus adoptées car au final elles correspondent à beaucoup plus de cas, et pour les cas limites sont suffisamment malléables pour s'adapter.
Il n'y a qu'à voir aussi les xkcd (ok, toujous le même) qui est balancé ci et là sur les standards).
Oué je sais, j'ai tiqué sur un point de détail, mais malheureusement ce type de raisonnement "autant faire parfait tout de suite" est extrêmement contre-productif, c'est même un véritable fléau en entreprise et plus généralement quelque soit le projet.
[^] # Re: Intérêt ?
Posté par claudex . Évalué à 4.
En quoi Systemd n'est pas souple?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt ?
Posté par Michaël (site web personnel) . Évalué à 3.
The nice thing about standards is that you have so many to choose from.
(Ce qui est sympa avec les standards, ce qu'il y en a tellement parmi lesquels choisir.)
Andy Tanenbaum.
[^] # Re: Intérêt ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Le jour où on m'expliquera cette philosophie… Parce que bon, je ne comprend cette "différentiation", pourquoi n'as-tu pas fait:
Qui est encore plus léger au passage
mais bon, j'aurai plutôt fait, même si c'est plutôt de la masturbation intelectuelle car ce n'est pas moi qui spécifie :
(et sinon la date sans la time zone, ça va être folklo :) )
[^] # Re: Intérêt ?
Posté par claudex . Évalué à 8.
Il l'explique. Parce que le message peut contenir des balises, ce qui n'est pas possible dans les attributs.
Il suffit de dire que tout est en UTC.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Oups. Ca doit être l’inconscience, j'ai zappé cette ligne. Mais je ne vois toujours pas pourquoi ne pas mettre msg en attribut, et laisser les extensions pour Event par exemple. Un message est un message, on ne va pas mettre autre chose que le message :).
Bref, ça me parait bien arbitraire, et pas facile de dire que les autres ont tord.
Norme ISO! 2001-12-31T12:00:00Z
Un caractère de plus… "Il suffit", juste que dans ce cas ce sera "oublié" à un moment… Et on a une norme pour les dates, autant l'utiliser.
[^] # Re: Intérêt ?
Posté par claudex . Évalué à 5.
Pour moi, un attribut doit être court (c'est une notion variable mais je pense qu'on peut dire que les messages ne sont pas forcément court). Et puis, on peut vouloir ajouter des balises pour différencier certains éléments du message.
Comme dis plus haut, le but est de pouvoir traduire facilement du XML au Json.
S'il faut respecter des normes quand on fait des normes, où va-t'on? ;)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt ?
Posté par Buf (Mastodon) . Évalué à 3. Dernière modification le 08 mars 2012 à 16:04.
D'un point de vue pratique, un attribut est pas terrible pour un texte potentiellement assez long. Dès que ça fait plus de 2-3 mots, c'est plus lisible dans un élément séparé.
Le schéma définit le champ comme étant de type xs:dateTime, qui permet justement de préciser avec la syntaxe ISO dont tu parles. Donc on peut sans problème spécifier explicitement le fuseau horaire (et j'espère qu'en pratique, ça sera le cas), et si c'est pas précisé, je pense que ça doit être l'heure locale.
[^] # Re: Intérêt ?
Posté par ckyl . Évalué à 1.
C'est pas comme si les timezones manquantes étaient un problème depuis toujours dans syslog et qui avait déjà été adressé dans la RFC 5424.
Les veilles implémentations sont capables d'envoyer des message sans timezone, ce qui est une énorme connerie mais qu'il faut prendre en compte. Pour tout ce qui est nouveau la timezone doit être spécifiée on peut faire sans. Dans syslog comme partout l'heure locale ca n'existe pas et c'est toujours une connerie de ne pas mettre de timezone dans une date. Toujours.
J'ai vraiment l'impression que vous prenez les mecs qui bossent là dessus pour des lapins de 3 jours.
[^] # Re: Intérêt ?
Posté par Zenitram (site web personnel) . Évalué à 5.
Euh… L'exemple est celui mis en dépêche, lien qui va vers le projet officiel.
Voudrais-tu dire que les mecs la sont des lapins de 3 jours? Parce mettre un tel exemple officiel, c'est vraiment une énorme connerie qui montre qu'ils n'ont pas appris de leurs erreurs passée. Ne jamais mettre un champs de temps sans time zone. Jamais. Y compris dans un exemple.
# Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 10.
C’est génial de transformer de simples lignes de texte indépendantes contenant 99% d’information utile en fichiers structurés contenant au minimum 10% de balises, la taille des logs va exploser, ils ne seront lisibles qu’avec des parseurs dédiés, et en cas de plantage, la structure du fichier va exploser, et il deviendra tout simplement illisible…
Je pense même qu’ils pourraient appeler leur parser « eventvwr.msc »…
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par claudex . Évalué à 4.
Comme actuellement, à moins que
Ne soit pas considéré comme lisible.
Pourquoi? Il n'y a pas les FS journalisé pour ça?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par mornik . Évalué à 3.
En même temps c'est pas le type de format qui va rendre certaines logs plus intéressantes.
Et augmenter la taille des logs, va rendre les interventions à distance avec des lignes bas débit (genre depuis une connexion edge poussive) encore plus délicate.
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par zebra3 . Évalué à 4.
Et si un programme se charge de t'envoyer juste les informations utiles à partir de ce que tu cherches ? Ça ne sera pas bénéfique ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Badeu . Évalué à 3.
bof … entre les données générées, les données stockées et les données transmises on peut toujours faire ce que l'on veut. S'il faut écrire un parser d'évènements au format JSON/XML vers du fichier texte à la papa pour s'assurer la rétrocompatibilité avec des admins sys, c'est du domaine du possible.
On perd aucune information utile, on ne fait que la compléter et l'inscrire dans un schéma standard, pas de quoi être tant réactionnaire.
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 5.
Je ne trouve pas ça particulièrement lisible non, il y a trop de fioritures pour mes yeux…
Je n’étais pas au courant que les FS journalisés permettaient de refermer tout seul les balises XML ou JSON.
D’ailleurs, ils font comment pour écrire les logs ? Aujourd'hui, il « suffit d’ouvrir un fichier en append et de faire un sync de temps à autre – bon, à chaque ligne en fait. Là, il faut ouvrir en écriture, et insérer les lignes à écrire… Et pour le suivi en direct ? Aujourd'hui, un petit tail -F fait l’affaire, là, il va falloir quoi pour que ça reste performant ? Du inotify + on enregistre la position du dernier message avant les balises fermantes pour y faire un seek, en espérant qu’on a bien conservé tout le contexte, sinon, il faut se retaper le parsing de tout l’arbre à chaque insertion…
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par claudex . Évalué à 4.
Je n'était pas au courant qu'on était obligé de flushé au milieu des balises
En mettant une info par ligne, c'est le même comportement
On pourra toujours le faire.
Il y a des bibliothèque pour lire en xml en flux, sinon xmpp aurait de sacré problèmes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
Tu n’est jamais le seul à flusher, si ton insertion n’est pas atomique, rien ne te garantit que les balises seront correctement fermées…
Tu as déjà essayé un tail -F sur un fichier en insertion ?
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par claudex . Évalué à 0.
Et on s'en fout, il y a plein d'outils qui gèrent bien des balises non fermées.
Pourquoi le fichier serait-il en insertion?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
Effectivement, vu sous cet angle, on garde le fichier en append, on écrit juste les lignes de log qui rentrent et ce n’est qu’au moment de la rotation qu’on ferme les balises histoire de…
Bon, en cas de plantage, il faudra commencer par une rotation pour être sûr de repartir sur une racine propre…
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Buf (Mastodon) . Évalué à 1.
On peut carrément se passer de racine aussi, et obtenir un fragment XML (au lieu d'un document). Ça reste tout à fait utilisable, et l'insertion ligne par ligne devient aussi facile qu'avec syslog.
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Du coup, pourquoi vouloir tout réinventer, et ne pas étendre syslog en proposant cette structure (fragment XML ou JSON) pour la partie message du format actuel ? Ainsi, on n’est pas obligé de tout casser, on laisse les programmeurs s’adapter en douceur, les outils actuels continuent à fonctionner et on peut commencer à sortir de beau parseurs qui vont extraire les méta-données, les filtrer etc…
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par claudex . Évalué à 3.
Parce que les outils actuels parse aussi la partie message, et si tu la change, les outils actuels ne marcheront plus non plus. Mais pourquoi ne pas vouloir des outils qui tranformerons le xml vers le format actuel pour pouvoir continuer à utiliser les outils anciens tout en permettant l'usage d'outils nouveaux.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
De toute façon, les parseurs vont devoir être réécrits, en ne modifiant que la partie message du format actuel, on continue de ne garder qu’un démon de log, pour les programmes qui logguent, ce n’est qu’une adaptation du format des messages, il n’y a pas à changer tout le système. Pour les parseurs, ils suivent déjà les évolutions du format des messages d’une version à l’autre des programmes pour lesquels ils sont écrits, ça ne fera qu’une mise à jour un peut plus grosse.
En cassant tout, on va se retrouver pendant au moins 10 ans avec 2 démons de log sur le système, il va être difficile de savoir quel programme utilise quel démon, bref, je pense que ça ne peux qu’empirer la situation actuelle et augmenter la fragmentation. Très bien illustré par l’image xkcd un peu plus haut d’ailleurs…
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par claudex . Évalué à 3.
Pourquoi avoir 2 démons? Le nouveau format est compatible avec l'ancien. On peut très bien avoir rsyslog qui reçoit les informations de log et les écrit dans deux fichier, un dans chaque format. Les outils actuels ne seraient pas cassé comme ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Il va falloir vous mettre d’accord alors, parce que là, ce n’est plus clair du tout…
Autant pour :
{ "p:time": "2001-12-31T12:00:00", "p:level": "WARN", "p:id": "HTTPD10001", "p:msg": "File does not exist: /usr/local/apache/htdocs/favicon.ico " }Je vois bien rsyslog pouvoir faire ça – il doit d’ailleurs déjà pouvoir le faire.
Autant pour :
{ "p:time": "2001-12-31T12:00:00", "p:op": "deny", "p:app": "iptables", "tns:IPTablesDeny": { "@xmlns:tns": "http://www.netfilter.org/projects/iptables/cee", "p:schema": { "@xmlns:p": "http://lumberjack.org", "#text": "http://www.netfilter.org/projects/iptables/cee" }, "p:ver": { "@xmlns:p": "http://lumberjack.org", "#text": "1.0" }, "tns:rule": "DMZ blacklist", "tns:ifName": "eth0", "tns:srcIP": "192.168.1.10", "tns:srcPort": "22534", "tns:destIP": "192.168.1.15", "tns:destPort": "80", "tns:HWAddr": "52:54:00:70:82:5E" }, "p:results": "success" }On fait comment avec l’API syslog ? C’est le démon de log qui parse et remplit les champs ? Le programme envoie dans le message une chaîne formatée JSON ou un fragment XML contenant tout ce qui n’est pas facility, level etc…
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Thomas Douillard . Évalué à 2.
Tu n'as pas compris, le nouveau système implémentera l'API syslog si j'ai bonne mémoire. C'est à dire que les applications ancienne qui utilisent l'infrastructure syslog pour que ça marche avec la nouvelle infra.
Ce qui pourrait changer éventuellement c'est le format de stockage, ce qui permettrait de stocker d'autres choses ou des choses plus structurées, notamment avec la nouvelle API.
Par contre, ce qu'on peut imaginer c'est que la nouvelle infrastructure écrive, en plus d'un nouveau format, les messages aussi dans l'ancien format à des fins de compatibilité et en faisant au mieux avec les messages qui sont pas vraiment compatibles avec l'ancien format.
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
J’attends de voir alors, mais niveau stockage, j’ai un tout petit peu peur.
Les analyseurs XML et JSON aujourd’hui sont-ils suffisamment performants pour dépasser grep sur de la prod ?
Ou alors, il va falloir penser au stockage en DB, mais avec les extensions de schémas, on fait quoi ? Une table par programme en entrée ? Du NO-SQL ?
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par claudex . Évalué à 3.
De ce que j'ai compris, il n'y a aura pas une seule API mais une ancienne et une nouvelle. Les anciens programmes utiliseront l'ancienne et les nouveaux auront le choix de l'API à utiliser.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Thomas Douillard . Évalué à 2.
Ben l'API syslog actuelle n'a pas disparu, et pour la phase de transistion il suffit de cracher les logs dans le format actuel éventuellement en doublon, rien d'impossible.
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par barmic . Évalué à 3.
Parce qu'il n'existe aucune bibliothèque qui gère un format semi-XML, semi-syslog ? Alors que passer à du XML complet (même si c'est de fragment) il existe des tonnes de bibliothèques pour le faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Ajouter une ligne dans un fichier avant la dernière ligne, ça s’appelle comment ?
À moins que comme tu disait, on se foute de la structure du fichier, du coup, on n’écrit les balises fermantes qu’au moment de la rotation du fichier ou de l’arrêt du démon de log. Du coup, je vois encore moins l’intérêt de se prendre la tête à définir des fichiers structurés qui ne le seront pas 99% du temps…
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par claudex . Évalué à 3.
En quoi les fragments XML ne sont pas structurés?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Thomas Douillard . Évalué à 2.
Pourquoi l'insertion serait pas atomique ? C'est au rôle du système de log en entier de gérer ça, une insertion pas atomique et concurrente avec syslog ça poserait le même type de problèmes, et ça n'arrive pas.
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par barmic . Évalué à 2.
Si on utilise less puis « F », ça compte ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par forty . Évalué à 4.
XMPP a de sacrés problèmes. La plupart des implémentations sont obligées d'écrire leur propre parser XML ou d'en modifier un existant pour pouvoir parser le "presque XML" des XML Stream de XMPP. Mais c'est une autre histoire :)
[^] # Re: Et en cas de plantage, on lit comment ?
Posté par Buf (Mastodon) . Évalué à 6.
2 choses :
# Utile pour les grosses infras
Posté par paulez (site web personnel) . Évalué à 6.
Vous qui faites du sed/cut/awk/grep sur vos fichiers de log et lisez les messages du kernel consciencieusement, vous faites comment si vous avez un parc de plusieurs centaines de machines, avec des dizaines d'applicatifs différents ?
Normaliser le format des logs permettrait de remonter tout cela sur un serveur central, qui permettrait d'obtenir tous les évènements survenus sur le parc sur des critères bien précis.
Le rêve quoi !
Pas mal de logiciels essaient déjà de faire ça, mais c'est toujours très difficile à généraliser à cause de la multitude de formats. Si on crée une norme à ce niveau, cela permettrait de simplifier grandement ce type d'analyse.
[^] # Re: Utile pour les grosses infras
Posté par Fabien . Évalué à 3.
J'avais centralisé tous les logs (et pour seulement une trentaine de serveurs - mix OpenBSD , Debian) vers un rsyslog qui insérait tout dans une base de données dédiées.
Ca donnait une conf du genre :
La base de données était un "gros" Postgresql utilisant des tables partitionnées (sur le champ ReceivedAt) pour chaque type de log ( table partitionnée auth_log dans le cas de l'exemple).
Perso, ça ne me dérange pas qu'ils changent le format des logs tant qu'on garde une telle souplesse de configuration.
Par exemple, configurer le format d'écriture des logs reçus (on reçois du json, on écris dans un fichier dans le vieux style de log).
[^] # Re: Utile pour les grosses infras
Posté par steph1978 . Évalué à 1.
On met des niveaux de log, du syslog, une console de supervision qui fait du rouge pour "error" et du orange pour "warning".
Quel rapport avec le format de log ?
[^] # Re: Utile pour les grosses infras
Posté par Kwiknclean . Évalué à -1.
Bha vous installez un serveur de log … c'est pas plus difficile que ça …
# I'm a lumberjack
Posté par hercule_savinien . Évalué à 4.
And I'm ok !
Le FN est un parti d'extrême droite
[^] # Re: I'm a lumberjack
Posté par LeMagicien Garcimore . Évalué à 2.
I sleep all night and I work all day!
[^] # Re: I'm a lumberjack
Posté par Frank-N-Furter . Évalué à 2.
He's a lumberjack, and he's okay.
Depending on the time of day, the French go either way.
[^] # Re: I'm a lumberjack
Posté par claudex . Évalué à 3.
He sleeps all night and he works all day.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: I'm a lumberjack
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 0.
All work and no play makes Jack a dull boy
[^] # Re: I'm a lumberjack
Posté par Frank-N-Furter . Évalué à 2.
All play and no work makes Jack a mere toy.
Depending on the time of day, the French go either way.
# C'est une bonne idée ça de structurer les logs
Posté par Kaane . Évalué à 3.
Il faut juste une structure XML/JSON qui accepte
- Les blobs binaires (pas trop dur, c'est pas si compliqué que ça à échapper/convertir en ascii)
- des erreurs avec des morceaux de XML/JSON dedans (Une fois de plus on peut toujours échapper, à moins que le caractère d'échapemment ne soit lui aussi dans l'erreur auquel cas on le double échappe à moins que le double échappement ne soit aussi dans ….)
- des trames réseaux brutes (cf blobs binaires) qui soient analysables par un outil genre tcpdump (ben on a qu'à convertir les logs à la volée si c'est accédé via une certaine option du parser) et rejouables (gna gna gna) en mode parallèle (tee et cat tu connais ?) en spoofant/modifiant un paramètre (tu prend ton log, tu le parse comme tu veux, tu rediriges le résultat vers un fichier que tu appelles vieux_format.log et tu fais pas chier !)
- Un système qui dise que le message précédent a été répété 27 fois (ça ça devrait passer)
Ensuite je veux un parseur qui puisse parser tout ça en traitant les éléments par ordre chronologique réel système y compris quand l'horloge corrige un drift NTP de 40 minutes juste avant le passage à l'heure d'été mais après que le système ait corrigé la date bios en date UTC.
Bien entendu il faut que le parseur soit linké statiquement et utilisable en mode mono utilisateur pour l'analyse après panne, sans pour autant occuper trop de mémoire (si ça se trouve c'est une barrette qui déconne qui est à l'origine de la panne).
Je plaisante bien sur, même si vous me donnez tout ça je vais rester sur mes vieux outils, mais si vous passez sous ce système un jour je veux bien que vous me racontiez comment vous analysez les logs d'une authentification SIP qui foire au niveau de la gateway pour cause de SSO/Kerberos/SASL qui déconne.
[^] # Re: C'est une bonne idée ça de structurer les logs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Super, des trames réseaux over log, on va pouvoir faire des tunnels avec ça ;-)
[^] # Re: C'est une bonne idée ça de structurer les logs
Posté par Batchyx . Évalué à 2.
Tu pourra toujours faire des tunnels avec n'importe quoi, même avec des pings. Ce n'est pas vraiment nouveau.
# Performance et intégrité ?
Posté par sifu . Évalué à -2.
Tout est dans le titre !
# XLM LA FAUSSE BONNE IDéE
Posté par Kwiknclean . Évalué à -4.
Ces messieurs ont-il déjà eu à mettre le nez dans des fichiers de configuration formatés en XML ?!! C'est strictement "imbitable" certes c'est parfait pour structurer, ordonnée normé et je suis d'accord que la question est effectivement à poser dans ce sens et est que l'initiative est louable, mais alors utiliser XML pour structurer ça c'est une très très mauvaise idée …
Alors après exit le bon vieux cat fichier de log et obligé de se munir d'un parseur configuré pour lire les log ?!
C'est pas un peu too much et anti ITIL ça ?!
# Wahou
Posté par ckyl . Évalué à 9.
Je pense que la dépêche est très mal rédigée pour que 99% des commentaires soient complétement à côté de la plaque et montre l'incompréhension totale de ce qui existe et de ce qui est proposé.
On constate juste des réponses basées sur le fantasme impliqué par le mot XML, et un mépris complet des gens bossant sur ce projet. C'est d'autant plus ironique que dans ces gens, y'en a quelques uns qui ont fait les RFC syslog et les démons qui sont encensés ici même. Ils ne sont pas devenus soudainement schizophrènes et proposent des améliorations backward compatibles de ce que vous aimez tant, pas de tout exploser.
Bref un peu trop de réaction primaires à mon gout…
[^] # Re: Wahou
Posté par claudex . Évalué à 5.
À partir du moment où on écrit XML ou Lennart (les deux, ça fait un combo), les gens ne lisent plus et en disent du mal. Ici je parle d'un projet qui n'a pas encore finit son travail et aucun logiciel ne l'implémente mais tout le monde crie déjà au scandale comme si ça allait arriver dans les mises à jour des distribs demain matin.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Wahou
Posté par Kwiknclean . Évalué à -1. Dernière modification le 08 mars 2012 à 14:24.
Bha écoutez … je clique sur les exemples et je tombe sur des fichiers de logs formats XML, je n'invente pas et ce n'est pas de la mauvaise foi … il suffit d'avoir bossé 5 minutes avec Tomcat pour comprendre que le XML c'est parfait à tout les points de vues sauf pour être lu par un humain … et d'ailleurs ça n'a jamais été fait pour, c'est un format de stockage.
[^] # Re: Wahou
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca tombe bien : ils parlent du stockage, pas de l'interface homme machine.
[^] # Re: Wahou
Posté par Hobgoblins Master (Mastodon) . Évalué à 0.
Ça tombe mal, la principale interface homme-machine de syslog, c’est justement le fichier de stockage des logs… ;-)
[^] # Re: Wahou
Posté par CrEv (site web personnel) . Évalué à 8.
Ben c'est peut-être là, au fond, le vrai problème…
[^] # Re: Wahou
Posté par Michaël (site web personnel) . Évalué à 5.
Un autre gros défaut d'XML est la complexité des analyseurs et validateurs. Si on n'est pas interessé par la validation des formats beaucoup plus simples, comme par exemple les S-expressions, permettent d'implémenter des mécanismes de persistance incomparablement plus rapides que XML. Le point intéressant du format XML est la validation du document faite par l'analyseur, si on ne se sert pas de cette fonction, on a fait un choix plutôt malheureux.
[^] # Re: Wahou
Posté par barmic . Évalué à 2.
Dit il sans nous abreuver de sa science.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Wahou
Posté par ckyl . Évalué à 2.
J'ai déjà posté un bon lien plus haut et plus généralement tu peux lire le blog d'un des affreux crétins qui n'aime pas Unix et ne comprend rien aux logs: http://blog.gerhards.net/
Ce crétin c'est aussi le mec qui écrit les specs de syslog et écrit le démon utilisé par défaut dans Debian/Fedora/Suse.
Quand tu arrêtes d'extrapoler sur 2 fichiers d'exemple donnés sans aucun contexte et que tu te renseignes sur ce qu'ils sont en train d'essayer de faire; ca devient d'un seul coup plus clair et plus logique. C'est très rationel et ils ne cherchent pas à tout péter. Je suis un peu biaisé par ce que je connais très bien syslog et ses subtilités, mais je pense que les propos de Rainer sont accessibles à tout le monde.
Tout ce que je demande c'est d'essayer de comprendre de quoi on parle avant de donner son avis ou d'asséner que les mecs qui bossent sont de sombres crétins alors que nous on a tout compris.
[^] # Re: Wahou
Posté par barmic . Évalué à 2.
Ce n'est pas parce que je trouve que ton message était donneur de leçon et péremptoire que je n'ai pas approuvé dans mes commentaires ce travail, tu sais ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pas une super idée
Posté par benoar . Évalué à 2.
Bon, puisque chacun donne son avis…
Moi, j'ai souvent vu dans les différentes formes de standardisation qu'on trouve à droite à gauche, que quand il existe déjà un système complexe et pas vraiment standardisé mais dont on arrive généralement à bien s'accommoder, ça ne sert à rien de tout foutre en l'air pour inventer un nouveau système : il y aura tellement de choses à changer et à remplacer que le travail sera encore plus gigantesque que d'essayer d'améliorer l'existant (ce qui est certes un travail énorme). Par exemple, je suis sûr que 50% des softs qui écrivent dans les logs qui sont dans Debian (c'est à dire un paquet) ne passeront jamais à ce nouveau système par manque de main-d'œuvre. Que devra-t-on faire de ceux-ci ?
Et pour ceux qu'on veut faire changer, pourquoi ne pas plutôt essayer d'adapter le système actuel, en l'améliorant ? Pourquoi vouloir foutre une couche de XML _à la base_ ? On peut très bien essayer de faire une bibliothèque des différents formats utilisés par tous les softs (ce qui revient à peu près au même que de faire un schéma XML pour chaque soft) et normaliser ça pour en extraire les infos qu'on veut. On pourra très bien générer du XML à partir de ça.
Ceux qui disent de manière condescendante « mais pour vous les vieux y'aura toujours des softs pour sortir une version texte » savent très bien que ce n'est pas eux qui la coderont et qui se la taperont, donc ils s'en foutent. Et ça n'est pas parce qu'on est contre passer en XML comme format source qu'on est contre trouver un standard pour faciliter le traitement des logs : arrêtez vos hommes de paille !
Alors oui, quand c'est Lennart qui s'y met, je ne peux pas m'empêcher d'avoir quelque appréhension, même si je suis plutôt d'accord avec les critiques qu'il émet, en général (mais moins avec les solutions qu'il propose). Mais j'espère qu'ils ne vont pas tout foutre en l'air dans la tradition du « je sais mieux que tout le monde ce dont ils ont besoin ».
[^] # Re: Pas une super idée
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 0.
Pas grave, on va demander à LiNuCe (expert XML en slip 3e dan) de nous faire un package (que s'appelorio logcoincoin) de conversion à la volée syslog « - » lumberjack.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.