Projet Lumberjack

Posté par (page perso) . Édité par Florent Zara, NeoX, Xavier Teyssier, olivierweb et Nÿco. Modéré par Florent Zara. Licence CC by-sa
33
7
mar.
2012
Linux

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.
Logo Lumberjack
NdA : Merci à Nÿco, olvierweb et Neox pour leur aide lors de la rédaction de cette dépêche.

  • # Du XML ?

    Posté par . É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 . É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 . É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 . Évalué à  6 .

          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?

          1. ça ne sera plus du CSV valable (dans le sens où les outils qui bouffent du CSV vont pas le reconnaitre)
          2. pourquoi réinventer un format alors qu'on en a 2 existant qui permettent de faire exactement ce dont on a besoin (JSON et XML) ?

          D'autre part comme dit plus loin dans les commentaires, quid de l'écriture dans le cas du xml avec sa balise root?

          Voir ma réponse au commentaire en question.

          • [^] # Re: Du XML ?

            Posté par . Évalué à  5 .

            ça ne sera plus du CSV valable (dans le sens où les outils qui bouffent du CSV vont pas le reconnaitre)

            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.

            pourquoi réinventer un format alors qu'on en a 2 existant qui permettent de faire exactement ce dont on a besoin (JSON et XML) ?

            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 (page perso) . Évalué à  2 .

              diminuer la lisibilité directe

              Tu peux justement utiliser des outils qui pourront facilement mettre en évidence les informations qui t'intéressent.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Du XML ?

              Posté par . Évalué à  3 . Dernière modification : le 07/03/12 à 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 :

              "2001-12-31T12:00:00","WARN","HTTPD10001","File does not exist: /usr/local/apache/htdocs/favicon.ico"
              "2001-12-31T12:00:00",,,,"login","500","/sbin/unix_chkpwd","pts/0","example.com","keith","success"
              "2001-12-31T12:00:00",,,,"login",,"/bin/java",,,"keith","success","Tomcat","https://www.example.com/login.do" 
              
              

              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 . É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 . Évalué à  2 .

        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.

        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 (page perso) . Évalué à  3 .

          À vrai dire, je préfère encore du JSON/XML à ça:

              <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
              - BOM'su root' failed for lonvick on /dev/pts/8
          
          In this example, the VERSION is 1 and the Facility has the value of
          4.  The Severity is 2.  The message was created on 11 October 2003 at
          10:14:15pm UTC, 3 milliseconds into the next second.  The message
          originated from a host that identifies itself as
          "mymachine.example.com".  The APP-NAME is "su" and the PROCID is
          unknown.  The MSGID is "ID47".  The MSG is "'su root' failed for
          lonvick...", encoded in UTF-8.  The encoding is defined by the BOM.
          There is no STRUCTURED-DATA present in the message
          
          

          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 . É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 . É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 . É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 (page perso) . Évalué à  -1 .

            Ta RFC, elle dit exactement pareil que moi : il n'y a pas de spécifications formelles pour le CSV.

            Ben la, il y en a une, justement!

            • [^] # Re: Du XML ?

              Posté par . Évalué à  3 .

              C'est une informational, pas une Standard Track. Donc pas normatif.

              • [^] # Re: Du XML ?

                Posté par . Évalué à  3 .

                Exactement. Suffit de lire le premier paragraphe de la RFC :

                This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

                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 . Évalué à  -1 . Dernière modification : le 07/03/12 à 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 . Évalué à  9 .

        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.

        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 . É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 (page perso) . Évalué à  4 .

      Il n'y a pas que tu XML mais du JSON aussi comme précisé dans la news.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Du XML ?

      Posté par (page perso) . Évalué à  9 . Dernière modification : le 07/03/12 à 11:47

      c'est quand même plus léger et lisible.

      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 . É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 (page perso) . Évalué à  8 .

          Même si les fichiers de logs sont en XML, il y aura des outils pour faire logs show apache2 | grep 404 qui 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 . Évalué à  6 .

            Tiens, pourquoi /usr se monte plus ?

            # logs kernel
            sh: logs: command not found
            
            

            Oups…

            • [^] # Re: Du XML ?

              Posté par . Évalué à  8 .

              T'es au courant pour redhat qui veut tout mettre dans /usr/bin ?

            • [^] # Re: Du XML ?

              Posté par . É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 . É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 (page perso) . É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.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Du XML ?

                  Posté par (page perso) . Évalué à  5 .

                  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.

                  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 (page perso) . Évalué à  6 .

                    Et ils disparaissent quand ils sont écrit en Json?

                    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Du XML ?

          Posté par (page perso) . Évalué à  2 .

          Avec XML la taille de tes logs va exploser… parce que grossomodo c'est 90% de balises et 10% d'informations utiles

          Un simple zip et le problème est réglé. Qui dit redondance dit facile à compresser.

    • [^] # Re: Du XML ?

      Posté par . É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 . É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 (page perso) . Évalué à  6 .

        Et magie, je cite la dépêche

        Pour cela, les développeurs vont suivre les spécifications Common Event Expression (CEE).

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Du XML ?

          Posté par . Évalué à  -1 . Dernière modification : le 09/03/12 à 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 . É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 (page perso) . Évalué à  7 .

    date hôte service[pid]: message

    Mes deux cents
    Joris

    • [^] # Re: Le but est de standardiser le contenu des logs

      Posté par (page perso) . É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:methodname
      Ha tiens, si j'écrivais classname#methodname
      Oups

    • [^] # Re: Le but est de standardiser le contenu des logs

      Posté par . É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 (page perso) . Évalué à  10 .

      date hôte service[pid]: message

      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 (page perso) . É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.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Le but est de standardiser le contenu des logs

          Posté par (page perso) . Évalué à  8 .

          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.

          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 (page perso) . É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.

            Tu veux dire qu'on va se fader du xml

            Ou pas, faut lire.

            éviter d'écrire un parser en awk/perl/cut par programme

            Ce serait un grand pas en avant.

            Je pense que les gens qui font ça n'aiment tout simplement pas Unix.

            Lapincompris le rapport.

            • [^] # Re: Le but est de standardiser le contenu des logs

              Posté par (page perso) . Évalué à  10 .

              Lapincompris le rapport.

              Désormais, dès qu'on change le comportement du moindre outil, on n'aime pas Unix.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Le but est de standardiser le contenu des logs

              Posté par (page perso) . Évalué à  10 .

              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.

              man syslog.conf

              *.err /var/log/error.log
              *.warn /var/log/warn.log
              
              
            • [^] # Re: Le but est de standardiser le contenu des logs

              Posté par . Évalué à  6 .

              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.

              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.

              Lapincompris le rapport.

              « É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 (page perso) . Évalué à  10 .

                man rsyslog.conf

                C'est tellement efficace que le développeur de rsyslog participle à Lumberjack.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Le but est de standardiser le contenu des logs

                Posté par . Évalué à  2 .

                « Écrivez des programmes qui traitent des flux de texte car c'est l'interface universelle »

                Et le xml c'est ?

                Universelle, dans le sens : je peux utiliser la puissance d’outils comme sed/awk/grep/perl et des centaines d’autres,

                perl sait très bien parser du xml

                testés, éprouvés depuis des dizaines d’années,

                Donc par défaut tu rejette toute nouveauté tant qu'elle n'a pas plusieurs dizaines d'années ?

                enseignés dans les plus mauvaises écoles d’administration système,

                Du nivellement par le bas ?

                installés sur virtuellement tous les systèmes,

                Ça veut dire quoi ?

                et qui ne me feront jamais faux bond

                Sauf quand tu te rendras compte que tu passe ton temps à utiliser des extensions GNU. Tu ne le fais pas ? Ben beaucoup le font.

                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.

                branlette intellectuelle

                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).

                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.

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                • [^] # Re: Le but est de standardiser le contenu des logs

                  Posté par . Évalué à  1 .

                  Universelle, dans le sens : je peux utiliser la puissance d’outils comme sed/awk/grep/perl et des centaines d’autres,

                  perl sait très bien parser du xml

                  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.

                  Opera le fait depuis 10 ans.

                • [^] # Re: Le but est de standardiser le contenu des logs

                  Posté par (page perso) . Évalué à  5 .

                  perl sait très bien parser du xml

                  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 . Évalué à  1 .

                    Je ne vois pas le lien entre le fait d'écrire un parseur en perl et ce que tu dis ?

                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: Le but est de standardiser le contenu des logs

                    Posté par (page perso) . É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 . É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é :

                      • java l'utilise encore autant, mais il s'est doté de techniques pour mieux le gérer avec les annotations
                      • les formats iso s'en servent de plus en plus avec l'odf et l'ooxml
                      • en réseaux xmpp l'utilise massivement, rss et atome aussi
                      • des outils comme maven et ant utilisent xml et son très populaires
                      • gnome se configure via du xml

                      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.

                      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                      • [^] # Re: Le but est de standardiser le contenu des logs

                        Posté par (page perso) . Évalué à  5 .

                        java l'utilise encore autant, mais il s'est doté de techniques pour mieux le gérer avec les annotations

                        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…)

                        en réseaux xmpp l'utilise massivement

                        ç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.

                        des outils comme maven et ant utilisent xml et son très populaires

                        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.

                        Ce ne sont que quelques exemples

                        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 . É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.

                          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                          • [^] # Re: Le but est de standardiser le contenu des logs

                            Posté par (page perso) . Évalué à  4 .

                            oulala, je crois que c'est l'heure de la camomille…

                            Relis ce que j'écris avant d'inutiler

                            Ca tombe bien j'ai même pas inutilé.

                            Je n'ai pas dire que les usages étaient bons

                            Justement, ce que j'en dis c'est que la majorité des usages d'xml sont mauvais.

                            Que le xml te plaise ou non il est très employais

                            Ha mais le xml me plait. Mais surtout pas n'importe où.

                            Donc ce n'est pas un effet de mode contrairement à ce qui était sous entendu

                            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 (page perso) . É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 . É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?

                          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                          • [^] # Re: Le but est de standardiser le contenu des logs

                            Posté par (page perso) . Évalué à  6 .

                            Tu semblais affirmer que xml, on en reparle tout les 10 ans et qu'entre temps il ne fait plus parler de lui.

                            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)

                            utilisé par l'administration (ils font toujours de mauvais choix, n'est ce pas ?)

                            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 :-(

                            SOAP

                            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)

                            Personnellement j'apprécie en xml le fait d'avoir des noeuds typés ce que l'on a pas en json.

                            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…

                            il peux être intéressant de se demander ce à qu'il se passe et de se remettre en question.

                            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 . É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.

                              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                              • [^] # Re: Le but est de standardiser le contenu des logs

                                Posté par (page perso) . Évalué à  3 .

                                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.

                                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 (page perso) . Évalué à  4 .

                            Je ne vais pas recopier les réponses de CrEv, on est manifestement sur la même fréquence.

                            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.

                            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 . Évalué à  1 .

                              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.

                              Avec des phrases comme cela, on serait tous sous Windows…

                              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.

                              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                              • [^] # Re: Le but est de standardiser le contenu des logs

                                Posté par (page perso) . É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 (page perso) . É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

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Le but est de standardiser le contenu des logs

            Posté par . Évalué à  3 .

            Je pense que les gens qui font ça (sans remettre en cause leur compétence de dev) n'aiment tout simplement pas Unix

            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 (page perso) . Évalué à  6 .

              simplifier la vie de sysadmin

              Toi tu t'es jamais tapé du grep dans des logs multilignes

              • [^] # Re: Le but est de standardiser le contenu des logs

                Posté par (page perso) . Évalué à  7 .

                Comment ça multiligne? Qui te dit que les outils ne vont pas permettre sur un truc comme

                readlog --type WARN --from 4242 | grep "Lacets défaits"
                
                

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Le but est de standardiser le contenu des logs

                Posté par . É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 (page perso) . Évalué à  7 .

                  Justement si, je suis sysadmin.

                  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 . É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 . Évalué à  1 .

            Tu veux dire qu'on va se fader du xml

            Il n'y a rien de bien compliqué à cela. Faut juste apprendre.

            et du log multiligne

            C'est déjà ce que fait Xorg.

            pour éviter d'écrire un parser en awk/perl/cut par programme ?

            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 les gens qui font ça (sans remettre en cause leur compétence de dev) n'aiment tout simplement pas Unix.

            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.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Le but est de standardiser le contenu des logs

              Posté par . Évalué à  1 .

              C'est déjà ce que fait Xorg.

              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 . Évalué à  2 .

                le raccourci Ctrl + Alt + BackSpace

                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.

                bon courage pour en écrire un à la main

                Comme avant ?

                Xorg est un bon exemple de truc devenu totalement moisi sous prétexte d'amélioration

                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é » ? :)

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Le but est de standardiser le contenu des logs

              Posté par (page perso) . Évalué à  3 .

              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.

              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 (page perso) . Évalué à  4 .

                Personnellement je n'en vois pas l'utilité. D'autant plus qu'un parser de logs c'est 20mn de perl à coder.

                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 (page perso) . É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 . É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 (page perso) . Évalué à  -3 .

      Comme pour l'article précédent "HTTPS Everywhere en version 2.0.1",

      Oui, encore…

      quel intérêt de ce gros logo au milieu de cette news ?

      Quel est l’intérêt de la couleur sur ce site? Des formes graphiques? (le CSS, vraiment, ça pue)

      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.

      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 (page perso) . Évalué à  5 .

        Quel est l’intérêt de la couleur sur ce site? Des formes graphiques? (le CSS, vraiment, ça pue)

        Sinon, tu as Lynx, n'hésite pas à t'en servir.

        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 (page perso) . É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 . Évalué à  2 .

    Le but est de standardiser le contenu des logs et d'améliorer leur création par les applications qui les génèrent.

    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 . É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 (page perso) . Évalué à  4 .

        En ça rend le truc illisible, ça donnerait un truc du genre

        tail -n 1 /var/log/kern.log
        "p:Event":[{"p:time": "2001-12-31T12:00:00", "p:level": "INFO","p:app": "kernle", "p:msg": "New USB device "}]

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: But

          Posté par . É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 . É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 . É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 . Évalué à  3 . Dernière modification : le 07/03/12 à 15:58

                On se demande pourquoi SQL a eu autant de succès si on pouvait tout faire avec grep,sed et awk.

                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 . É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 (page perso) . Évalué à  10 .

        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".

        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"

        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".

        Assertion sans aucune preuve. Aucun rapport entre le format des logs et le bon fonctionnement d'un système.

        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..).

        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 . Évalué à  2 .

          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…).

          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 . Évalué à  1 .

            mais en donnant de vrais critères et pas via grep avec une regexp ad hoc

            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 (page perso) . É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.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: But

              Posté par . É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 . É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 . Évalué à  10 .

          Mais pourquoi ces idiots te moinssent alors que ce que tu dis est pertinent ? :|

          "Savoir administrer, c'est savoir lire des logs cryptique car dans un format pourri datant de 1970 donc avec les limites de l'époque"

          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.

          Assertion sans aucune preuve. Aucun rapport entre le format des logs et le bon fonctionnement d'un système.

          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.

          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..).
          

          Ouais, un truc d'élite qui veut rester élite sans que la masse ne puisse regarder elle aussi… Argumentation bof.

          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.

          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.

          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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à  2 .

                  C'est triste, ton avis sur les gens.

                  Bah… Tu dois bien me connaitre maintenant, moi et mon avis sur les gens (surtout français) ;-)

              • [^] # Re: But

                Posté par (page perso) . É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 . É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 . É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 . Évalué à  7 .

              Ensuite l'opération d'accession des logs, il n'y a pas de raison de mettre de barrières technique artificielles à ça.

              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 (page perso) . É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?

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: But

                  Posté par . Évalué à  10 . Dernière modification : le 07/03/12 à 20:10

                  Pourquoi dire que le JSON est illisible avec un bête éditeur de texte?

                  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 (page perso) . É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.

                    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                  • [^] # Re: But

                    Posté par . É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 . É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 ?

                      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 (page perso) . Évalué à  4 .

                        Non, c'était mieux quand le système donnait aux petits enfants l'envie de bidouiller.

                        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 . Évalué à  4 .

                          ben ton logiciel actuel de lecture

                          C’est cat, less, gedit. Bref, des commandes que toute personne curieuse connaît.

                          juste un format qui change pour être plus structuré

                          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.

                          Je comprend ton envie de bidouiller

                          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 (page perso) . É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 . Évalué à  6 .

                      sous prétexte que le format CSV c'est vieux et archaique

                      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.

                      on décide soudain qu'il faut le changer

                      C'est utiliser le CSV dans les logs ? Moi j'en ai jamais vu.

                      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                    • [^] # Re: But

                      Posté par (page perso) . É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 (page perso) . É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 . Évalué à  3 .

                          Tu as déjà eu a debug init ?

                          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                          • [^] # Re: But

                            Posté par (page perso) . É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 . É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 (page perso) . Évalué à  1 .

                          Pour affirmer cela, tu peux me garantir que systemd n'aura aucun bogue

                          Et tu peux m'affirmer que y'a aucun bug dans le binaire de bash ?

                          • [^] # Re: But

                            Posté par . É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 (page perso) . Évalué à  2 .

                              Et qui te dis que y'a pas un bug dans dash ?

                              • [^] # Re: But

                                Posté par . É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 . Évalué à  3 .

                    Je ne comprend vraiment pas le problème du XML. On nous explique qu'il est lourd et illisible :

                    • lourd : ça dépend fortement du schemas choisi, le gain important c'est d'avoir un format robuste : a plus de liberté sur les caractères que l'on insère sans avoir à se soucier des séparateurs
                    • illisible : ça ne je comprend vraiment pas. D'une part toutes les informations sont nommées (que ce soit par une balise ou un attribut) et d'autre part même un document sur une seule ligne, peut facilement être reformatté pour la lecture. Enfin petit plus de ce formattage, j'ai plus souvent des difficultés de lectures du a un log trop long que multiligne. Le formattage permet de limiter la taille les des lignes.

                    Je ne vois pas ce qui t'aurais gênait à faire tes bidouilles dans tes jeux avec un fichier comme ça :

                    <?xml version="1.0" encoding="UTF-8"?>
                    <ea:mygame version="1.0" xmlns:ea="http://ea.com/xml">
                        <ea:sav difficulty="3" curLevel="12">
                           <ea:name>Ma sauvegarde à moi</ea:name>
                           <ea:munition>90</ea:munition>
                           <ea:invotory>
                               <ea:stone/>
                           </ea:invotory>
                        </ea:sav>
                    </ea:mygame>
                    
                    

                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                    • [^] # Re: But

                      Posté par . Évalué à  3 .

                      • Lourd: Le ratio entre donnée utile et bruit n'est quand même pas terrible.
                      • Illisible: Ça dépend ! Disons qu'une fois indenté correctement. Je trouve pas forcément cela illisible. Après le problème, souvent, on va supprimer l’indentation et le sauts de lignes pour gagner quelques Ko. Après, il est toujours possible d'utiliser un outil dédié mais dès que le XML dépasse les 100Mo …
                      • [^] # Re: But

                        Posté par . Évalué à  0 .

                        Lourd: Le ratio entre donnée utile et bruit n'est quand même pas terrible.

                        Oui mais il inclus la description des données. Au final la quantité de données est plus importantes.

                        dès que le XML dépasse les 100Mo …

                        Sans logrotate c'est sur que ça marche moins bien.

                        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                        • [^] # Re: But

                          Posté par . Évalué à  5 .

                          Oui mais il inclus la description des données. Au final la quantité de données est plus importantes.

                          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 …

                          Sans logrotate c'est sur que ça marche moins bien.

                          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 . É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 (page perso) . Évalué à  1 . Dernière modification : le 08/03/12 à 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 . É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 (page perso) . Évalué à  4 .

                  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.

                  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 . Évalué à  3 .

        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".

        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 (page perso) . Évalué à  5 .

          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.

          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 . Évalué à  6 .

        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".

        ça n'empêche en rien l'administrateur qui sait administrer de continuer son administration.

        si les logs passent d'un format lisible par un humain, à "des trucs exploitables par une GUI
        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.

        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.

        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..).

        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 ?

        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.

        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 . Évalué à  2 .

          Trop tard pour éditer, mais un trois lignes de texte à moi ce sont retrouvés dans une quote.
          il fallait lire :

          si les logs passent d'un format lisible par un humain, à "des trucs exploitables par une GUI

          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 . Évalué à  7 .

          Et ??? si on te dit qu'il faut lancer "plop -atchoum /var/log/my_plop" à la place, ça changera quoi pour toi ?

          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 . É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 . Évalué à  4 .

              mais je ne connais pas d'équivalent ztail

              ztail() {
                  f="$1"; shift
                  zcat "$f" | tail $@
              }
              
              
        • [^] # Re: But

          Posté par (page perso) . Évalué à  2 .

          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 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 :

          /usr/bin/xmlstarlet sel -t -m "//node[@class='system']" -v "concat(vendor,' ',product)" -i "serial!=''" -v "concat(' serial : ',serial)" -b -m "configuration/setting[@id='uuid']" -v "concat(' uuid :',@value)" -b -n $1
          
          

          pour aller chercher la moindre petite info, je préfère largement le fichiers à plat!

  • # Les standards

    Posté par . Évalué à  9 .

    XKCD

  • # Intérêt ?

    Posté par (page perso) . Évalué à  8 . Dernière modification : le 07/03/12 à 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 :

    31 Dec 2001 12:00:00 WARN  HTTPD10001 File does not exist: /usr/local/apache/htdocs/favicon.ico
    
    

    => 97 octets

    à (JSON)

    "p:Event":   [
    {
      "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 "
    }
    ]
    
    

    => 173 octets

    Et (XML)

    <p:Event>
        <p:time>2001-12-31T12:00:00</p:time>
        <p:level>WARN</p:level>
        <p:id>HTTPD10001</p:id>
        <p:msg>File does not exist: /usr/local/apache/htdocs/favicon.ico </p:msg>
    </p:Event>
    
    

    => 184 octets

    • [^] # Re: Intérêt ?

      Posté par (page perso) . Évalué à  7 .

      En même temps, on peut déjà retirer les retour à la ligne et l'indentation.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Intérêt ?

      Posté par . É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 . Évalué à  0 . Dernière modification : le 08/03/12 à 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 (page perso) . É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:

      cat mon_log.json | json2log | less
      
      

      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 . É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 ?

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Intérêt ?

      Posté par (page perso) . É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

      <Event>
          <time>2001-12-31T12:00:00</time>
          <level>WARN</level>
          <id>HTTPD10001</id>
          <msg>File does not exist: /usr/local/apache/htdocs/favicon.ico </msg>
      </Event>
      
      

      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 :

      <Event time="2001-12-31T12:00:00" level="WARN" id="HTTPD10001">
          <msg>File does not exist: /usr/local/apache/htdocs/favicon.ico </msg>
      </Event>
      
      

      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 (page perso) . É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 (page perso) . Évalué à  3 .

          Et il me semble (je me trompe peut-être) que les attributs doivent-être fixes

          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 . Évalué à  3 .

        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…)

        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 . É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 (page perso) . Évalué à  3 .

            Quitte à faire quelque chose de nouveau, autant que ça soit au top, non ?

            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 (page perso) . Évalué à  4 .

              les solutions moins optimales mais plus souples fonctionnent mieux

              En quoi Systemd n'est pas souple?

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Intérêt ?

              Posté par (page perso) . Évalué à  3 .

              Il n'y a qu'à voir aussi les xkcd (ok, toujous le même) qui est balancé ci et là sur les standards).

              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 (page perso) . Évalué à  1 .

        D'un point de vue "philosophie XML", c'est aussi plus cohérent.

        Le jour où on m'expliquera cette philosophie… Parce que bon, je ne comprend cette "différentiation", pourquoi n'as-tu pas fait:

         <Event time="2001-12-31T12:00:00" level="WARN" id="HTTPD10001" msg="File does not exist: /usr/local/apache/htdocs/favicon.ico" />
        
        

        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 :

         <Event time="2001-12-31T12:00:00" level="WARN" id="HTTPD10001" msg="File does not exist" filename="/usr/local/apache/htdocs/favicon.ico" />
        
        

        (et sinon la date sans la time zone, ça va être folklo :) )

        • [^] # Re: Intérêt ?

          Posté par (page perso) . Évalué à  8 .

          Le jour où on m'expliquera cette philosophie… Parce que bon, je ne comprend cette "différentiation", pourquoi n'as-tu pas fait:

          Il l'explique. Parce que le message peut contenir des balises, ce qui n'est pas possible dans les attributs.

          (et sinon la date sans la time zone, ça va être folklo :) )

          Il suffit de dire que tout est en UTC.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Intérêt ?

            Posté par (page perso) . Évalué à  2 .

            Il l'explique. Parce que le message peut contenir des balises, ce qui n'est pas possible dans les attributs.

            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.

            Il suffit de dire que tout est en UTC.

            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 (page perso) . Évalué à  5 .

              Mais je ne vois toujours pas pourquoi ne pas mettre msg en attribut, et laisser les extensions pour Event par exemple.

              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.

              Bref, ça me parait bien arbitraire, et pas facile de dire que les autres ont tord.

              Comme dis plus haut, le but est de pouvoir traduire facilement du XML au Json.

              Et on a une norme pour les dates, autant l'utiliser.

              S'il faut respecter des normes quand on fait des normes, où va-t'on? ;)

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Intérêt ?

              Posté par . Évalué à  3 . Dernière modification : le 08/03/12 à 16:04

              Mais je ne vois toujours pas pourquoi ne pas mettre msg en attribut

              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é.

              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.

              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 . Évalué à  1 .

                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.

                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 (page perso) . Évalué à  5 .

                  J'ai vraiment l'impression que vous prenez les mecs qui bossent là dessus pour des lapins de 3 jours.

                  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 (page perso) . É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 (page perso) . Évalué à  4 .

      ils ne seront lisibles qu’avec des parseurs dédiés

      Comme actuellement, à moins que

      "p:Event":[{"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 "}]
      
      

      Ne soit pas considéré comme lisible.

      et en cas de plantage, la structure du fichier va exploser

      Pourquoi? Il n'y a pas les FS journalisé pour ça?

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Et en cas de plantage, on lit comment ?

        Posté par (page perso) . É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 . É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 . É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 (page perso) . É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 (page perso) . Évalué à  4 .

          Je n’étais pas au courant que les FS journalisés permettaient de refermer tout seul les balises XML ou JSON.

          Je n'était pas au courant qu'on était obligé de flushé au milieu des balises

          Aujourd'hui, il « suffit d’ouvrir un fichier en append et de faire un sync de temps à autre – bon, à chaque ligne en fait.

          En mettant une info par ligne, c'est le même comportement

          Et pour le suivi en direct ? Aujourd'hui, un petit tail -F fait l’affaire

          On pourra toujours le faire.

          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…

          Il y a des bibliothèque pour lire en xml en flux, sinon xmpp aurait de sacré problèmes.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Et en cas de plantage, on lit comment ?

            Posté par (page perso) . Évalué à  1 .

            Je n'était pas au courant qu'on était obligé de flushé au milieu des balises

            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…

            On pourra toujours le faire.

            Tu as déjà essayé un tail -F sur un fichier en insertion ?

            • [^] # Re: Et en cas de plantage, on lit comment ?

              Posté par (page perso) . Évalué à  0 .

              rien ne te garantit que les balises seront correctement fermées…

              Et on s'en fout, il y a plein d'outils qui gèrent bien des balises non fermées.

              Tu as déjà essayé un tail -F sur un fichier en insertion ?

              Pourquoi le fichier serait-il en insertion?

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Et en cas de plantage, on lit comment ?

                Posté par (page perso) . Évalué à  1 .

                on s'en fout

                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 . É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 (page perso) . É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 (page perso) . É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.

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                      • [^] # Re: Et en cas de plantage, on lit comment ?

                        Posté par (page perso) . É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 (page perso) . É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.

                          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                          • [^] # Re: Et en cas de plantage, on lit comment ?

                            Posté par (page perso) . Évalué à  2 .

                            Il va falloir vous mettre d’accord alors, parce que là, ce n’est plus clair du tout…

                            • Dans la dépêche, on a des liens vers des fichiers complets XML ou JSON, pas des fragments
                            • On me dit un peu plus bas que en fait, ce qui est présenté, ce n’est pas le format des fichiers de log, mais des messages logs (donc envoyés par les applis)
                            • Là, tu me dis que l’API syslog ne change pas et que c’est juste le démon syslog qui enregistre des fragments XML.

                            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 . É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 (page perso) . É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 ?

                                zcat /var/log/mail.log*.gz |wc -l
                                14235136

                                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 (page perso) . Évalué à  3 .

                              n me dit un peu plus bas que en fait, ce qui est présenté, ce n’est pas le format des fichiers de log, mais des messages logs (donc envoyés par les applis)
                              Là, tu me dis que l’API syslog ne change pas et que c’est juste le démon syslog qui enregistre des fragments XML.

                              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.

                              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                    • [^] # Re: Et en cas de plantage, on lit comment ?

                      Posté par . É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 . É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.

                      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: Et en cas de plantage, on lit comment ?

                Posté par (page perso) . Évalué à  2 .

                Pourquoi le fichier serait-il en insertion?

                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 (page perso) . Évalué à  3 .

                  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…

                  En quoi les fragments XML ne sont pas structurés?

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Et en cas de plantage, on lit comment ?

              Posté par . É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 . Évalué à  2 .

              Tu as déjà essayé un tail -F sur un fichier en insertion ?

              Si on utilise less puis « F », ça compte ?

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: Et en cas de plantage, on lit comment ?

            Posté par . Évalué à  4 .

            Il y a des bibliothèque pour lire en xml en flux, sinon xmpp aurait de sacré problèmes.

            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 . Évalué à  6 .

          2 choses :

          • le XML (ou JSON) proposé ici décrit les messages, pas forcément la forme que ça prendra sur le disque. On peut imaginer que le stockage sur disque se fasse dans un format différent, plus efficace.
          • en XML, il n'y a pas que les documents complets, on a aussi les fragments XML. Ça évite d'avoir la contrainte d'une racine unique. On pourrait donc avoir un élément XML par entrée, sans tag qui entoure le tout. Ça garde une bonne partie des propriétés intéressantes du XML, et ça fait disparaitre d'un coup tous les problèmes que tu mentionnes.
  • # Utile pour les grosses infras

    Posté par (page perso) . É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 (page perso) . É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 :

      # templates
      $template auth_log,"insert into auth_log (Message, Facility,FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%' ,%syslogpriority%, '%timereported:::date-pgsql%', '%timegenerated:::date-pgsql%', %iut%, '%syslogtag%')",sql
      
      # rules
      :syslogtag, contains, "pf_block"                        :ompgsql:localhost,Syslog,rsyslog,mon_password;pf_block_log
      :syslogtag, contains, "pf_block"                        ~
      
      

      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 . É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 (page perso) . Évalué à  -1 .

      Bha vous installez un serveur de log … c'est pas plus difficile que ça …

  • # I'm a lumberjack

    Posté par . Évalué à  4 .

    And I'm ok !

    Le FN est un parti d'extrême droite

  • # C'est une bonne idée ça de structurer les logs

    Posté par . É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.

  • # Performance et intégrité ?

    Posté par . Évalué à  -2 .

    Tout est dans le titre !

  • # XLM LA FAUSSE BONNE IDéE

    Posté par (page perso) . É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 . É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 (page perso) . É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.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Wahou

      Posté par (page perso) . Évalué à  -1 . Dernière modification : le 08/03/12 à 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 (page perso) . Évalué à  2 .

        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.

        Ca tombe bien : ils parlent du stockage, pas de l'interface homme machine.

        • [^] # Re: Wahou

          Posté par (page perso) . É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 (page perso) . Évalué à  8 .

            Ben c'est peut-être là, au fond, le vrai problème…

      • [^] # Re: Wahou

        Posté par (page perso) . Évalué à  5 .

        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 …

        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 . Évalué à  2 .

      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é.

      Dit il sans nous abreuver de sa science.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: Wahou

        Posté par . É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 . É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 ?

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # Pas une super idée

    Posté par . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.