Bonjour,
Je cherche un outil capable d'analyser mes logs (si possible en temps réel), de filtrer le "bruit" et de remonter les éléments de type "alerte" ou "inconnus" et KISS-compliant
J'utilise actuellement logcheck, il remplit bien son rôle, mais la modification, l'ajout et la maintenance des règles (basées sur des regexp) est particulièrement pénible et chronophage.
J'ai regardé du coté logstash. C'est sympa, c'est joli, pratique pour recherches des infos dans les logs, mais à priori, ça ne remonte pas d'alerte.
J'ai également testé octopussy. Je n'ai pas accroché (il faut installer la moitié de cpan, la doc est inexistante, le travail de mise en place / adaptation des règles existantes semble important…)
Vous les admins qui trainez dans le coin, qu'utilisez vous pour analyser les logs de vos serveurs ?
Merci de vos retour
# Ca m'intéresse aussi
Posté par Pouetpouet . Évalué à 1.
J'ai rien vu où il ne fallait définir des regex ou équivalent (patterndb)
rsyslog + mysql peut suffire, j'ai joué un peu avec elasticsearch et j'me demande ce que vaut ELSA (https://code.google.com/p/enterprise-log-search-and-archive/)
Mais c'est vrai que niveau corrélation/maintenance simple….
# systeme de monitoring
Posté par NeoX . Évalué à 2.
c'est pas le role d'un systeme de monitoring ?
regardes nagios/shinken/centreon/pom
qui vont avoir des sondes pour a peu pres tout,
et qui vont te permettre de filtrer un log à intervalles de temps regulier pour determiner un seuil et envoyer une alerte par email/sms/etc
[^] # Re: systeme de monitoring
Posté par ranDom (site web personnel) . Évalué à 2.
J'ai déjà un nagios. Je le trouve complémentaire à ma solution recherchée. Comment nagios (ou autre) peut-il détecter l'évenement nouveau qui vient de perturber le ronron habituel de mes machines ?
[^] # Re: systeme de monitoring
Posté par NeoX . Évalué à 2.
En effet, ce n'est pas le but de nagios, qui pressuppose que tu saches quel evenement tu attends.
Detecter un nouvel evenement, non prévu, dans un "ronron", c'est le boulot d'un IDS (Intrusion Detection System)
il a une "image" de l'activité normale, et si quelque chose change il rale.
[^] # Re: systeme de monitoring
Posté par Paf . Évalué à 1.
On utilisait fut en temps logstash -> elasticsearch.
Mais logstash avait du mal a suivre la charge. Apache Flume s'en sortait beaucoup mieux (du genre 10x mieux). Du coup on utilise maintenant Apache Flume avec morphlines qui envoie le tout dans un cluster elasticsearch.
Concernant les alertes on se dirige vers des alertes nagios qui font des requetes sur elasticsearch et alertent en fonction.
[^] # Re: systeme de monitoring
Posté par Ambroise . Évalué à 1.
Une question : sachant que les syslog sont envoyé avec les priorités suivantes :
Pour les alertes, je penses que tu peux directement t'envoyer par mails les événements de priorité supérieur à 2.
Par contre, comment est défini pour toi un événement inconnu dans syslog ?
Est-ce un événement que tu n'as encore jamais reçu dans tes logs ?
[^] # Re: systeme de monitoring
Posté par ranDom (site web personnel) . Évalué à 1.
Bonne idée, je n'avais pas penser à trier en fonction du niveau de gravité du message. Je suis en train de tester, histoire de voir si c'est exploitable.
C'est exactement ça.
# Loganalyzer
Posté par Adminrezo (site web personnel) . Évalué à 1.
J'avais le même besoin et j'ai fais quelques recherches.
Dans le domaine, il y a beaucoup de non libre.
J'ai fini par choisir LogAnalyzer. C'est une interface Web (Php) pour du syslog-ng ou rsyslog.
Pas de remontée d'alerte a priori. L'interface n'est pas très belle mais chacun est libre de la modifier.
Logstash est très beau mais c'est tout ce qu'il y a de moins KISS (charge CPU et MEM importante). Pas adapté à une petite structure.
Si quelqu'un a une autre idée, je suis preneur.
Dis nous ce que tu choisis finalement.
[^] # Re: Loganalyzer
Posté par Paf . Évalué à 1.
Pour la partie analyse ou remontee de logs?
As-tu essaye lumberjack pour la remontee de logs?
# graylog2
Posté par fredix . Évalué à 2.
je crois que http://www.graylog2.org fait ce que tu demandes.
[^] # Re: graylog2
Posté par ranDom (site web personnel) . Évalué à 1.
D'après mes recherches graylog ressemble plus à logstash (recherche et présentation). Je ne vois pas comment faire remonter les trucs "inhabituels".
En plus, dans le genre "KISS", on peut mieux faire.
[^] # Re: graylog2
Posté par Sufflope (site web personnel) . Évalué à 2.
On a logstash + graylog au boulot et il nous envoie des alertes mail (par exemple en cas d'erreur 500 (on fait du web)). Par contre ce n'est pas moi qui l'ai mis en place donc je pourrais pas en dire beaucoup plus, juste témoigner qu'il peut faire de la remontée. Je dirais que ça consiste à créer un stream avec les filtres qui vont bien (genre "server == front1 && severity == ERROR") et d'y activer les notifications.
Par contre pour le peu que j'ai vu des procédures d'install, ça doit être le truc le plus compliqué que j'ai jamais vu (même des bousins genre oVirt s'installent en moins de commandes).
[^] # Re: graylog2
Posté par ranDom (site web personnel) . Évalué à -1.
Pas besoin d'une usine à gaz pour détecter des erreurs 500 dans un log.
Je veux juste détecter le truc dans mes logs qui sortent de l'ordinaire.
[^] # Re: graylog2
Posté par Sufflope (site web personnel) . Évalué à 4. Dernière modification le 19 février 2014 à 10:56.
Bah si c'est si simple, démerde-toi et fais-le tout seul, hein.
Ravi d'avoir aidé.
[^] # Re: graylog2
Posté par ranDom (site web personnel) . Évalué à -1.
Détends-toi,
J'essaie de m'expliquer un peu mieux:
Mes serveurs génèrent des évènements, consignés dans les logs:
AAAABABBABBCCDACBECDAAABBCCCDDDD
A ET B: sont des évènements de routine (connexion d'un user, envoi/réception d'un mail, lancement d'une tâche cron, etc.
C: sont des évènements anormaux mais connus, et surveillés (par exemple par nagios) (tentative de connexion ssh en root, service qui s'arrête, …). C'est ton erreur 500.
E: c'est l'évènement inconnu, qui apparaît 1 fois tous les 36 du mois
En résumé, A et B devront être ignorés par la solution, C devra être détecté par la solution et surtout E doit pouvoir être remonté.
En espérant avoir été plus clair.
# Echofish syslog filter
Posté par j . Évalué à 2.
Echofish est plus efficant quand il s'agit de pattern matching.
lien: http://www.echothrust.com/projects/echofish
[^] # Re: Echofish syslog filter
Posté par ranDom (site web personnel) . Évalué à 1.
Ça semble prometteur. Il parle un peu de remonter d'alerte, mais c'est pas très clair, je teste ça dès que je peux.
Merci
[^] # Re: Echofish : retour rapide d'expérience
Posté par ranDom (site web personnel) . Évalué à 1.
Encore un peu tôt de parler d'expérience.
Je viens de mettre l'application en place, sur la Fedora 20 qui me sert de loghost. Mon serveur SQL est sur une autre machine. On configure syslog pour écrire dans une table. Des triggers vont ensuite traiter l'info à chaque insertion.
Très intéressant au premier abord: Une interface web très simple permet de visualiser l'ensemble des logs. On peut très facilement créer une règle permettant d'ignorer tel ou tel évènement, faire des recherches, etc. L'idée étant de ne présenter que les évènements "marquants", en filtrant tous les truc habituels, ce qui est exactement ce que je cherche à faire.
Bémol #1, contrairement à logcheck, qui est livré avec une base de filtres préexistant, avec echofish on part de 0, il faut créer tous les filtres manuellement. Mais cela peut être fait relativement rapidement via l'interface.
Bémol #2: pas de possibilité de faire remonter une alerte. Mais j'ai l'impression que tous les évenements non filtrés se retrouvent dans une table à part. Un cronjob envoyant par mail le contenu de cette table pourrait faire l'affaire.
En tout cas une application qui (imho) mérite un peu de pub
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.