Journal Centralisation des logs, interface de consultation

Posté par  . Licence CC By‑SA.
Étiquettes :
13
8
avr.
2011

(C'est vendredi, mais ça n'en fait pas une obligation de troller.)

Si comme moi vous avez à gérer plusieurs serveurs Linux, si vous avez fait de la virtualisation ou si vous utilisez LTSP, vous vous retrouvez avec pleins de machines qui produisent chacune leurs logs. La gestion par fichiers dans /var/log arrive rapidement à ses limites.

Heureusement, les systèmes syslog modernes permettent facilement de centraliser les logs sur une machine et de les placer dans une base de données. La base permettant de rechercher, de filtrer, de purger et de brancher tout un tas de module (synthèse, alerte par email...) très facilement.

Sur une debian moderne, on trouve dsyslog, rsyslog et syslog-ng qui sont tous trois capables d'enregistrer les données dans une base PostgreSQL ou MySQL.

Par contre, pour ce qui est de l'exploitation, la seule application que j'ai trouvé est php-syslog-ng, (qui n'est pas packagé dans debian), et qui est devenu récemment logzilla, logiciel propriétaire incompatible avec mon association humanitaire. La branche opensource a été soigneusement masquée (documentation et sources masqués).
La démo montre en prime une interface lourde, bien loin de ce que l'on peut faire à coup de grep dans des fichiers.

Connaissez-vous une application web, de préférence PHP, capable de consulter la base et d'y faire des tris et des recherches ?

  • # Octopussy?

    Posté par  . Évalué à 6.

    Un truc comme ça ne pourrait pas convenir?

    http://www.8pussy.org/

    • [^] # Re: Octopussy?

      Posté par  . Évalué à 10.

      J'étais pourtant sur de tomber sur du pron!

      • [^] # Re: Octopussy?

        Posté par  . Évalué à 9.

        Octopussy, c'est plutôt pour du Bond.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Octopussy?

        Posté par  (site web personnel) . Évalué à 8.

        J'étais pourtant sur de tomber sur du pron!

        Mauvais pr0n, astique !

  • # backend NoSQL

    Posté par  . Évalué à 7.

    Et la je dégaine https://code.google.com/p/logstash/ et http://www.graylog2.org/ Qui peuvent servir de serveur syslog et s'appuient sur des backend nosql (mongodb uniquement pour graylog2, preférablement ElasticSearch pour logstach) pour une très grande scalabilité et tolérance aux pannes.
    Avec une interface de recherche livrée clé en main. L'interface de logstach par exemple propose toute la souplesse du langage d'interrogation de l'indexeur Lucene.

    À tester.

  • # Loganalyzer & Splunk

    Posté par  . Évalué à 1.

    J'avais regardé les solutions il y a quelques mois et vu un concurrent à php-syslog-ng : loganalyzer, développé par les gens qui font rsyslog (même si l'interface n'a pas l'air d'être beaucoup développée...) Par contre, il ne faut pas avoir des giga de logs comme dans mon cas venant de boites plus ou moins noires et donc difficile à parser.
    Un produit qui est fort intéressant est Splunk, pas libre mais gratuit jusqu'à un certain nombre de logs et disponible sous différents paquets, pratique pour simplement tester.

  • # loganalyzer

    Posté par  . Évalué à 3.

    J'utilise loganalyzer pour l'analyse avec petites et grosses bases (150Go) sous prostresql. De base c'est vrai que c'est lent, mais c'est surtout parce qu'il n'y a pas d'index créés par défaut. Le mieux est de les rajouter à la création de la base (je l'ai fait ensuite, mais sans arrêter la prod c'est galère et lent), mais après ça devient tout a fait utilisable.

    Ceci dit, je préconnise de ne mettre en base que ce qui est pertinent (virer les MARK/cron pollueurs...) et sur une durée de limitée ( 1 -2 mois ?) dépendant du volume à absorber, et de TOUT centraliser sous forme de fichier à plat pour 2 raisons : un fichier est plus facile à backuper et faire tourner, et en plus la BDD n'est pas valable pour des besoins légaux puisqu'on transforme l'info au passage.

    Pour en revenir à loganalyzer, on peut facilement se créer des "parsers" et vues associées, par exemple pour avoir les différents champs de firewall, et faire des recherches sur ces éléments.

    • [^] # Re: loganalyzer

      Posté par  . Évalué à 0.

      Bonjour kengiskan,

      j'aimerais bien avoir ton avis sur les points suivants :

      • Performances : après ajout d'index, quel est le volume "absorbable" par LogAnalyzer (nombre de messages stockables en BdeD)
      • LogAnalyzer est-il compatible avec Postgres ?
      • LogAnalyzer ne semble pas être compatible avec une authentification externe LDAP, est-il difficile de réaliser cela ?

      Je suis également assez déçu par LogZilla et les rapports fournis ne semblent pas personnalisables (alors que LogAnalyzer semble le proposer, à confirmer)

      et puis bon LogAnalyzer est gratuit !!

      Merci.

Suivre le flux des commentaires

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