Avis sur un script d'analyse de logs - Codes et scripts - Linux et OS Alternatifs
Marsh Posté le 03-06-2015 à 18:44:23
Je suis intéressé pour sa lecture et pour voir comment tu fais, mais je suis plutôt sur Perl donc pour le débug pur et dur faudra pas compter sur moi
Je suis intéressé pour la partie "présentation", car on trouve surtout de la mise en page au format HTML à exposer via un serveur web, or je suis plutôt à la recherche de quelque chose qui soit capable de basculer sur du XML, voire d’interagir automatiquement par l'envoi d'un mail suivant l'option choisie par l'admin.
Il pourrait être intéressant d'avoir un "mini forum" dédié, avec accès réservé pour pouvoir discuter entre testeurs et développeur
Marsh Posté le 03-06-2015 à 19:18:57
Fous le sur Github, et balance
Par contre, j'suis plus testeur, que dev.
du coup, j'te renvoie mes apprioris etc.
Je ne peux pas te donner de lecon ;P
Marsh Posté le 04-06-2015 à 11:51:23
sans être intéressé par le script en lui meme, je vais quand meme poser la question : pourquoi réinventer la roue, et au passage la rendre carrée ? logwatch fait ça très bien deja.
si tu veux aller un peu plus loin qu'une machine, aujourd'hui le pattern classique des logs c'est celui du pipeline unique, et les consommateurs qui viennent se plugger dessus (analyzer, stockage, etc)
Marsh Posté le 04-06-2015 à 13:38:27
Tu dis:
"pourquoi réinventer la roue, et au passage la rendre carrée ?"
C'est faut.
il existe multiple OS Linux. Pourtant, chacun à réinventer la roue. Partant du noyau, on a du Debian, du Arch, du BSD... Parfois, les roues sont plus ronde. Et souvent, plus adapter a différent type de personne.
(Pneu neige, pluie, course.. Ce sont tous des pneus, non? )
Marsh Posté le 04-06-2015 à 15:29:12
feliwyn a écrit : Tu dis: C'est faut. |
Ton analogie est foireuse
Ce que je veux dire c'est qu'il y a fort à parier que son script est moins versatile et plus buggé que l'existant. Je n'ai meme pas parlé de portabilité du script entre les différents OS.
BTW, je fais juste part de mon XP, pour avoir pratiqué un peu la gestion de logs à des volumes "raisonnables"
edit : je dis pas que c'est mal d'écrire son propre soft, je le fais régulièrement pour répondre à des besoins précis non couverts par les différents softs existants
Marsh Posté le 04-06-2015 à 16:30:26
Merci de vos retours.
bardiel et feliwyn je met le script directement ici finalement, il tourne mieux maintenant
Si le script est vraiment utile (automatisable), je rajouterai l'XML en sortie.
Ce n'est pas assez mature pour être mis sur GitHub, d'autant que c'est la première fois que j’utilise du python, le code est donc immonde et probablement non conforme à la philosophie du langage. Mais ça tourne pour le "proof of concept", c'est déjà ça.
Pour répondre à la question de l'utilité (je me suis posé la même, et je pose sur le forum aussi pour voir si ça peux servir), disons que j'utilise Logwatch quotidiennement, mais qu'il n'est pas capable de gérer certaines logs exotiques. Exemple : sur l'un des serveurs, nous avons du système de fichier Lustre. C'est particulièrement verbeux, et pour retrouver une erreur là dedans lorsque nous en suspectons une, c'est la croix et la bannière car le type d'erreur peut être différent à chaque fois (ce qui exclus le grep). De plus, logwatch nécessite l'installation d'un package et de ses quelques dépendances, ce qui est proscrit sur certaines de nos nodes, alors que python y est nativement dans sa version basique, d'où l'usage d'un script de ce type, que je peux pousser et utiliser à la volée par ssh sans avoir à rajouter autre chose.
J'ai donc bien conscience que l'outil n'a pas vocation à remplacer les existants, mais plutôt à s'adapter aux situations inhabituelles et répondre à une niche d'utilisateurs (dont je fait parti dans ce cas) pour une niche d'utilisation.
Voilà comment ça marche, le code suit :
Lancer le script avec la commande "python test.py" (en supposant que le fichier est nommé test.py).
Renseigner la position du log à lire (en supposant que le fichier est lisible, attention aux droits), et ne pas oublier les "" autour de la chaine.
Renseigner la valeur de sensibilité. Je recommande de tester 0.6 à 0.7 pour commencer, sinon ca fait trop de lots.
Ca mouline un peu.
Et ensuite le rapport affiche les lignes identifiées par lots de similarité et rangé dans l'ordre du plus présent au moins présent. Chaque ensemble se voit donner un numéro (tag). Dans cette vue là, il est déjà possible de voir si quelque chose de particulier se niche dans le log.
Ensuite plusieurs possibilités :
La fonction 0 (refaire l'analyse) ne marche pas, inutile d'essayer.
La fonction 1 (expand en lvl 2) n'est pas très intéressante, mais est fonctionnelle.
La fonction 2 (suppression de tags) est plus utile, dans mon usage en tous cas.
Chaque bloc affiché s'est vu donné un tag. Il est possible ainsi de supprimer certains blocs, notamment les plus gros qui correspondent souvent aux messages d'utilisation normale, et ainsi réduire à ce qui nous intéresse. Ensuite on écrit le log résultant. Et après, et bien si besoin, on peut refaire une analyse sur ce log (pour trier plus finement, en changeant le facteur de sensibilité (plus grand)), ou étudier le log à la main puisque qu'il est nettement plus court.
Attention aux yeux, c'est pas ergonomique et c'est moche
Marsh Posté le 04-06-2015 à 16:31:44
Le code :
Code :
|
edit coloration syntaxique // black_lord
Marsh Posté le 04-06-2015 à 16:50:26
zaft a écrit : ce qui est proscrit sur certaines de nos nodes, alors que python y est nativement dans sa version basique, d'où l'usage d'un script de ce type, |
Comme Black_Lord, généralement les logs ça s'exporte. Les analyses se font sur d'autre machines faites pour cela avec les apps et les ressources pour cela.
Marsh Posté le 04-06-2015 à 17:44:43
C'est surtout une des bases. une des raisons est que si ta machine crashe, t'es content d'avoir les logs ailleurs. Tu as plein d'autres raisons de le faire : remplissage des disques locaux, leur utilisation (== perfs), la centralisation des infos, la sécurité (machine compromise). Cette liste c'est juste les premiers trucs qui me viennent à l'esprit.
Syslog fait ça très, et je ne connais aucun admin qui ne fasse pas ça.
Dans un cas comme le tien, c'est encore plus utile. tu n'as ton script à deployer qu'une fois (par collecteur on va dire). du coup tu peux te permettre des choses plus fancy au niveau des deps aussi. Bref, au delà du sujet du script, tu devrais penser à envoyer tes logs en remote.
Marsh Posté le 04-06-2015 à 22:06:35
Ce n'est pas moi qui ai déployé ces machines, mais aujourd'hui les logs sont éparpillées sur les nodes (à noter qu'il y a des centaines de nodes). Sur une autre machine, a été utilisé un montage NFS, mais personnellement ca m'a semblé délirant.
Pour le moment, je rapatrie les logs par ssh, avec un user particulier qui fait un sudo cat sur les logs. Mais j'ai commencé à réaliser qu'il existe de nombreux outils (souvent plus viables que les scripts maisons) et qu'il est dommage de s'en priver.
Le fonctionnement de syslog répond effectivement parfaitement et simplement à ce problème. Je vais soumettre l'évolution et le déployer.
Bon et ce script d'analyse alors, ca vous semble utile ? Pour tracker un évènement particulier dans des logs non prises en charge par logwatch ?
Edit : d'ailleurs je pense que je ne vais pas tarder à soumettre un topic où j'exposerai comment je fait pour administrer mes machines, et où vous pourrez vous donner à coeur joie de démonter mon oeuvre et de m'indiquer des solutions plus propres.
Marsh Posté le 05-06-2015 à 12:11:02
zaft a écrit : Ce n'est pas moi qui ai déployé ces machines, mais aujourd'hui les logs sont éparpillées sur les nodes (à noter qu'il y a des centaines de nodes). Sur une autre machine, a été utilisé un montage NFS, mais personnellement ca m'a semblé délirant. |
des centaines de nodes, rassure moi : (tu|vous) utilise(s|z) un système de config management ?
zaft a écrit : |
C'est désigné pour
zaft a écrit : Edit : d'ailleurs je pense que je ne vais pas tarder à soumettre un topic où j'exposerai comment je fait pour administrer mes machines, et où vous pourrez vous donner à coeur joie de démonter mon oeuvre et de m'indiquer des solutions plus propres. |
par curiosité, tu as quelle XP en tant que sysadmin ?
Marsh Posté le 05-06-2015 à 14:12:10
Je suggère que l'on discute de ça par MP, ca sort du cadre du topic.
Je te répond de suite par MP.
Marsh Posté le 05-06-2015 à 14:14:22
ok
Marsh Posté le 03-06-2015 à 10:58:12
Bonjour,
Je cherche 2 ou 3 testeurs pour un petit script d'analyse de logs (en python).
Ca marche chez moi, mais je souhaiterais une vérification par un tiers avant de développer plus le concept. Le mieux serait de tester /var/log/message ou /var/log/auth.log, et tout autre type de logs.
Le script est concu pour aider à l'analyse de logs de tout types, et se veut générique. Il regroupe les informations par lots, selon un paramètre de sensibilité défini par l'utilisateur, puis fait un compte rendu.
C'est tout con, mais ca semble prometteur
Les versions à venir doivent pouvoir extraire les contenus désirés pour les écrire dans un fichier, et/ou faire une seconde analyse plus fine sur un lot particulier (2ieme voir 3ieme niveau d'analyse). Une fois fonctionnel, et si ca à un intérêt, je mettrais les sources en ligne.
Une bonne âme pour tester ? Je donne le script par MP, contre promesse de ne pas diffuser pour le moment.
Zaft
Edit : petite précision, ce script a pour vocation de pouvoir être utilisé à distance sur un serveur, sans ajout de paquets/modules. Il tourne donc avec un python de base.
Message édité par zaft le 03-06-2015 à 11:11:10