Forum général.cherche-logiciel Solution visualisation de logs centralisés

Posté par .
Tags : aucun
2
8
juil.
2010
Bonjour,

Je suis désespérément à la recherche d'une solution robuste de visualisation de logs qui tourne sur linux.

Je ne trouve malheureusement pas de comparatif et je me perd dans la multitude de solutions (commerciales ou non).
il y a bien Kiwi cattools mais il ne tourne que sur windows.

Y a t-il une solution open-source robuste ? J'ai regardé logzilla mais il risque de devenir payant incessamment sous peu et pas de détails sur la licence prévue.

Sinon un investissement est envisageable...

Quelle solution utilisez vous ?

Cordialement,
KageBunshin
  • # Nous c'est ssh + less... :o)

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

    Pas lourd, bouffe les gros fichiers, recherche, robuste.....
    J'ajouterai tail -F et egrep et y a tout ce qu'il faut...
    Quelle fonctionnalité exactement cherches-tu ?

    Fuse : j'en Use et Abuse !

    • [^] # Re: Nous c'est ssh + less... :o)

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

      En plus less contient déjà « tail -f » ( en faisant « F » lors de la visualisation) ; pour le grep, j'ai vu certaines versions qui le proposaient avec le raccourci « & »

      Je trouve ça beaucoup plus pratique que vi utilisé par des collègues !!
      • [^] # Re: Nous c'est ssh + less... :o)

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

        Vi pour lire des log.... Sacrilège ! Ou est mon fouet ! brûlez les tous ! :)

        L'éditeur crée un fichier swap qui est généralement un poil plus gros que le fichier original... Utiliser vi sur un log est une très très mauvaise habitude contre laquelle je lutte car :
        => ça pénalise la machine en IO
        => faire ça sur un log de 1Go ou plus, outre le fait que de toute façon on arrive pas a l'ouvrir, on bouffe en ram et en espace disque conséquent... J'ai pulvérisé un développeur l'autre jour pour un vi sur un fichier de 3Go qui a résulté en fs full....

        Fuse : j'en Use et Abuse !

        • [^] # Re: Nous c'est ssh + less... :o)

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

          Je partage totalement ton avis…
          Entre ça et faire un « cd » pour chaque niveau de sous répertoire avant d'arriver au fichier (vive l'historique bash bousillé…), j'ai aussi des envie de meurtre !
        • [^] # Re: Nous c'est ssh + less... :o)

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

          Et on inventa view (ou vim -n si c'est juste le fichier d'échange qui gêne).

          Après je ne sais pas si le vieux vi supporte les flags -n ou -R.
      • [^] # Re: Nous c'est ssh + less... :o)

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

        Après mon coup de sang sur vi petite réponse...

        - Le shift + f dans less ca revient à peu près à un tail -f, mais tu ne peux pas pipper des commandes derrière ( grep / cut / awk... ).

        - Sinon pour le tail je préfère -F <=> --follow car en cas de rotation de log ca continue de tourner ! :)

        Fuse : j'en Use et Abuse !

        • [^] # Re: Nous c'est ssh + less... :o)

          Posté par . Évalué à 2.

          Je cherche une interface "user-friendly" destinée à l'équipe d'exploitation.
          • [^] # Dialog ?

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

            Je verrai bien un script dialog pour ca....

            Pour donner une idée, ça donne des choses comme l'interface d'un $>make menuconfig ou les fenêtres de décision en bleu que tu peux voir sur certains upgrade debian... Un menu dialog pour tous les opérations récurantes style "morning check" / "check habituel de log" ...etc... depuis que j'y ai gouté ben je trouve que c'est bien sympa !

            Ca donnerai un "interface graphique" relativement user-friendly ( clavier ou souris ) dans une console, qui derrière lancera les ssh / les tail -f ou less / scripts qui vont bien...

            Fuse : j'en Use et Abuse !

          • [^] # Re: Nous c'est ssh + less... :o)

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

            Y multitail pour remplacer tail
            Multitail, c'est beau, avec des couleurs, des regexp, la possibilité d'ajouter des logs en cours de route (dans la même fenêtre ou dans une séparés), plein de raccourcis clavier avec l'aide kivabien...
            C'est vraiment le remplaçant idéal de tail pour consulter les logs en ligne de commande.

            Par contre, c'est pas un truc comme ksystemlog qui te sépare les jours, tout ça.

            It's a fez. I wear a fez now. Fezes are cool !

  • # logstalgia

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

    http://code.google.com/p/logstalgia/ c'est beau, mais uniquement beau :-)

    Moi je l'utilise comme ça :
    sudo apt-get install logstalgia
    ssh monserveur sudo tail -f /var/log/apache2/access.log | logstalgia --sync
  • # ksystemlog

    Posté par . Évalué à 1.

    Tu as ksystemlog mais j'ai jamais essayé …
  • # php-syslog-ng

    Posté par . Évalué à 1.

    syslog-ng pour centraliser dans une DB et php-syslog-ng pour consulter ?
    Php-syslog-ng fourni une interface web pour consulter tes logs avec des fonctions de stats/recherches. C'était pas parfait la derniere fois que je l'ai installer mais assez facile a customiser.
    Je l'utilisais pour centraliser environ 4/5 Go de log par jour. La recherche dans les logs était parfois un peu longue, mais je pense qu'avec ces volumes c'est normal. (dans une VM en plus ...)

    Sylvain Floury
    • [^] # Re: php-syslog-ng

      Posté par . Évalué à 1.

      Salut,

      php-syslog-ng est justement la solution que nous utilisions précédement. Ce projet n'existe plus (en tout cas en full open source), il est devenu logzilla. Ils ont un peu la folie des grandeurs au niveau des tarifs annoncés.
      Bref j'ai exactement les mêmes remarques vis à vis de php-syslog-ng et j'aurai souhaité une solution plus récente.

      KageBunshin
  • # loganalyzer

    Posté par . Évalué à 1.

    C'est ce que rsyslog recommande

    http://loganalyzer.adiscon.com/

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.