Le topic de la programmation, string, chaînes, cuir et compagnie

[William Vaurien]

Il y a des experts en logstash+kibana par ici ?

Je me heurte à un gros mur. Un de nos projets (java + log4j) doit intégrer la pile logstash+kibana pour ses logs.
En gros c'est "tu vas voir c'est génial", mais ils n'expliquent pas grand chose et pour l'instant j'ai l'impression que ce n'est pas super adapté à des logs applicatifs.

En gros tout nos log doivent aller dans cette grosse moulinette, et autant pour les logs d'alertes au niveau de la surveillance des serveurs et éventuellement les erreurs techniques dans le code, je vois l'intérêt, autant je suis plutôt septique pour les logs applicatifs.

J'ai l'impression que c'est très compliqué de retracer le parcours de quelqu'un dans l'application, et que logstash n'est pas forcément prévu pour. L'impression aussi que les dashboard que mes équipiers ont construit sont très 'opérationnels' : ils permettent effectivement de monitorer des dizaines d'applications, mais dans les grandes lignes (utilisation cpu/mémoire), requêtes/minutes, temps de réponse, mais ne permettent absolument pas de faire du monitoring fonctionnel.

Je suis donc à la recherche de conseils, tutoriels et autres pour comprendre comment utiliser le bouzin et je sature des blogs copié/collé qui montre comment se faire une installation.
Et si vous connaissez bien ce truc, est-ce que vous l'utilisez pour gérer les logs applicatifs et faire du support, si oui comment ?

Merci les canards.

[Charmide]

J'ai beaucoup usé de Kibana+ES, out-of-the-box c'est assez puissant mais comme tu l'as vu fortement orienté sur, disons, de l'analyse de métriques, des statistiques, du quantitatif, c'est beaucoup moins magique pour du "quali", du tracking d'utilisateur ou d'objets métiers précis, des KPI business, ou ce genre de choses.

Reste que personnellement je l'ai utilisé très majoritairement pour ce cas là et sur d'assez gros projets mais ça m'a demandé de 1) bien comprendre ES, sa façon de gérer des queries et d'indexer entre autre. 2) Modifier significativement l'applicatif, ce qui était envoyé à ES, quand et comment. Et j'imagine qu'il faut mentionner le 3) énormément de boulot pour ça.
Un peu incompatible avec l'ensemble ELK qu'ils vendent comme plug and play.

Contrairement à mon expérience personnelle, j'ai jamais vu d'use case propres du full stack ELK dans l'optique d'avoir autre chose que les dashboard très "opérationnels" que tu cites, ce que j'ai toujours trouvé bien dommage, du coup je serais bien incapable de te filer des ressources. Mais si tu as des questions précises, je peux tenter de répondre.

[Mayalabielle]

Il y a des experts en logstash+kibana par ici ?

Je me heurte à un gros mur. Un de nos projets (java + log4j) doit intégrer la pile logstash+kibana pour ses logs.
En gros c'est "tu vas voir c'est génial", mais ils n'expliquent pas grand chose et pour l'instant j'ai l'impression que ce n'est pas super adapté à des logs applicatifs.

En gros tout nos log doivent aller dans cette grosse moulinette, et autant pour les logs d'alertes au niveau de la surveillance des serveurs et éventuellement les erreurs techniques dans le code, je vois l'intérêt, autant je suis plutôt septique pour les logs applicatifs.

J'ai l'impression que c'est très compliqué de retracer le parcours de quelqu'un dans l'application, et que logstash n'est pas forcément prévu pour. L'impression aussi que les dashboard que mes équipiers ont construit sont très 'opérationnels' : ils permettent effectivement de monitorer des dizaines d'applications, mais dans les grandes lignes (utilisation cpu/mémoire), requêtes/minutes, temps de réponse, mais ne permettent absolument pas de faire du monitoring fonctionnel.

Je suis donc à la recherche de conseils, tutoriels et autres pour comprendre comment utiliser le bouzin et je sature des blogs copié/collé qui montre comment se faire une installation.
Et si vous connaissez bien ce truc, est-ce que vous l'utilisez pour gérer les logs applicatifs et faire du support, si oui comment ?

Merci les canards.

Peux-tu préciser les metrics que tu cherches à mesurer ?

[William Vaurien]

En fait je ne cherche rien précisément. Le projet est un projet web assez classique avec tout son foutoir de logs redirigé via slf4j.

La nouvelle version doit être déployé via un nouveau système et nous n'aurons plus de log fichier classique. A la place tout doit aller dans logstash et consulté via Kibana.
A la première impression c'était un peu : où sont mes logs ? c'est quoi ces tableaux de bord un peu pourrave ?

Je viens de passer un petit moment avec l'admin et il m'a montré une autre facette de kibana qui, une fois configuré, permet de retrouver ses logs sous une forme presque complète.

Du coup je suis un peu moins septique, mais je trouve quand même que c'est pas super ergonomique comme interface...

Je dois rencontrer un autre dev qui a migré sur cette infra il y a quelques mois et qui parait-il a "complètement changé sa façon de logguer".
Je dois dire que vu comme l'admin me l'a présenté ça m'inquiète un peu...

La promesse c'est d'être capable de réagir rapidement en cas d'anomalie (avec des alertes, tiens plus 50% d'erreur par ici, une fatale par là), mais aussi de pouvoir rapidement investiguer sur les causes des problèmes.
C'est là que j'ai un petit doute.

J'ai beaucoup usé de Kibana+ES, out-of-the-box c'est assez puissant mais comme tu l'as vu fortement orienté sur, disons, de l'analyse de métriques, des statistiques, du quantitatif, c'est beaucoup moins magique pour du "quali", du tracking d'utilisateur ou d'objets métiers précis, des KPI business, ou ce genre de choses.

Reste que personnellement je l'ai utilisé très majoritairement pour ce cas là et sur d'assez gros projets mais ça m'a demandé de 1) bien comprendre ES, sa façon de gérer des queries et d'indexer entre autre. 2) Modifier significativement l'applicatif, ce qui était envoyé à ES, quand et comment. Et j'imagine qu'il faut mentionner le 3) énormément de boulot pour ça.
Un peu incompatible avec l'ensemble ELK qu'ils vendent comme plug and play.

Contrairement à mon expérience personnelle, j'ai jamais vu d'use case propres du full stack ELK dans l'optique d'avoir autre chose que les dashboard très "opérationnels" que tu cites, ce que j'ai toujours trouvé bien dommage, du coup je serais bien incapable de te filer des ressources. Mais si tu as des questions précises, je peux tenter de répondre.

Voilà, c'est l'impression que j'ai et tes propos confirme qu'il y aura potentiellement un appender secret vers une base de donnée en plus, pour faire toute la partie "quali" / "business" / "applicatif" / "tracking" / "big brother" / "audit".

L'admin d'ELK est très sympa mais je vois bien qu'on ne parle pas le même langage...
Il s'est décomposé quand je lui ai demandé où étaient les stacktraces: "mais, mais, c'est pas bô les stacktraces, il faut pas les garder".
De la même manière le concept des nom de logger n'est pas vu pareil, et l'utilisation du MDC non plus... bref c'est devop mais à la fin c'est un ingé système parle avec un dev...

[Teocali]

L'admin d'ELK est très sympa mais je vois bien qu'on ne parle pas le même langage...
Il s'est décomposé quand je lui ai demandé où étaient les stacktraces: "mais, mais, c'est pas bô les stacktraces, il faut pas les garder".
De la même manière le concept des nom de logger n'est pas vu pareil, et l'utilisation du MDC non plus... bref c'est devop mais à la fin c'est un ingé système parle avec un dev...

En même temps, il a pas tort : une stacktrace en prod, c'est généralement une bad practice. Idéalement t'as suffisamment d'élément via les logs pour reproduire le probleme en environnement de dev, et là, si besoin est, t'active la stack trace.
Mais bon, ça c'est la situation idéale...

[Mayalabielle]

En même temps, il a pas tort : une stacktrace en prod, c'est généralement une bad practice. Idéalement t'as suffisamment d'élément via les logs pour reproduire le probleme en environnement de dev, et là, si besoin est, t'active la stack trace.
Mais bon, ça c'est la situation idéale...

Normalement c'est ton Sentry qui te les remonte, les stacktraces.

[William Vaurien]

Je vois pas trop la bad practice des stack en prod... A part celle de les envoyer à la figure des utilisateurs.
Le fait d'avoir cette trace dans les logs permet de comprendre plus rapidement d'où vient le problème, si c'est un framework au milieu qui déconne ou une exception lancée ailleurs et propagée plus loin dans la pile.
C'est quand même pas mal le cas en Java avec les exceptions checkées qui sont "rhabillées" en non-checkée et attrapées plus tard par un handler générique.

Pas mal de frameworks fonctionnent comme ça. Si tu n'as pas la trace tu vas devoir passer un peu (beaucoup?) de temps à essayer de reproduire le scénario.
Avec la stack tu vois directement d'où vient la merde...

[Tramb]

Ouais, je vois pas trop le problème d'exposer un core dump ou une backtrace au user en plus d'un log quand ça merde.
Le user, ce qui le gêne, c'est que ça merde.

[William Vaurien]

le coup de la stack exposée est problématique car:
1) Ca fait peur, il vaut mieux mettre un gentil chaton qui dit "oups" qu'un grosse stack
2) Un vilain hacker pourrait voir que tu utilise le framework "supervieux2000" connu pour ses 12.000 trous de sécurité.

A partir de là si les logs sont suffisamment à l'abri des regards, je vois pas en quoi avoir les stacks (on parle des log de niveau "erreur" ici) est gênant...

Et dans la tête de mon admin ELK, une stacktrace c'est une exception non catchée...

[Tramb]

Ouais ou alors faire des applis qui crashent pas. Ca, ça leur fait encore moins peur.

Si tu mises sur ça pour que les "vilains hackers" ne tentent pas d'exploiter ton truc, tu risques d'avoir des déconvenues

A la limite tu la chiffres, pour qu'on te la reporte mais ça me semble complètement fou

[William Vaurien]

ou alors des applis sans aucun utilisateur (ni humain, ni machine), c'est le mieux

[Mayalabielle]

Je vois pas trop la bad practice des stack en prod... A part celle de les envoyer à la figure des utilisateurs.

C'est le but de Sentry, c'est lui qui surveille les logs et c'est lui qui te remonte les choses importantes (et ça peut aller loin, limite ça va te créer le ticket de bug sur ta forge)

Pour ELK et consort (telegraf/influxdb/grafana pour le monitoring), mon ressenti c'est plutôt : "oui, créer les dash ça demande du temps, beaucoup de temps mais la visibilité que ça apporte n'est clairement pas comparable à grep / cut / sort pour la partie logging et htop / atop / snmp pour la partie monitoring", ceci dit avoir un accès aux logs quand "ça crash" c'est une demande assez compréhensible.

[ducon]

Bon, qui ferme pour ouvrir à nouveau ?

[Patate]

A toi l'honneur

[ducon]

Ha non, déjà que quand je garde un fil de ma création, des pisse-froids me les brisent…

[Sangoon]

@William Vaurien:
Est-ce que tu as déjà regarder des trucs comme les beats pour charger tout et n'importequoi dans logstash, dans ton cas par exemple une combinaison de metrics beat et de jolokia devrait pouvoir déjà de permettre de faire des choses non ? Ensuite pour kibana, tu peut partir de modules existants plutot que de 0 aussi.

Une autre solution à tester et d'utiliser metrics (de dropwizard) dans ton projet java couplé à un beat pour uper tes métriques dans logstash et ce genre de module pour kibana

edit : Et pour la question des stacks dans les logs, si c'est bien un aggrégateur de logs que tu mets en place, de mon point de vue, ce n'est pas une bad practice, c'est plutôt obligatoire et ton admin est un guignol

edit2: Et, en passant, si c'est "juste" un aggrégateur de logs que tu mets en place tu peux aussi directement utiliser un filebeat configurer pour parser les fichiers logs de ton appli, tu devrait en trouver sur le net.
Ou sinon y a aussi moyen de proposer à ton admin d'ajouter un graylog peut-être ?

[William Vaurien]

En fait je n'ai pas la main du tout sur cette chaîne (et tu parles un peu un langage que je ne comprends pas aussi; je me sens vieux et moche maintenant).
Les logs partent directement via un appender logstash. Je ne peux rien installer ni sur Logstash ni sur kibana. Du coup j'ai pas des masses envie de m'investir, un peu comme un Jira ou un Confluence fermé.

J'ai déjà du me battre pour avoir le nom des loggers dans kibana et qu'il ne filtre pas les logs pour ne garder que les "fatales" (oui oui; je veux mes erreurs et mes warning aussi, et les info ce serait pas mal tant qu'à faire).
Et essayer de faire comprendre que d'utiliser le MDC pour paramétrer TOUS les messages de log c'était pas toujours top. Surtout quand ils doivent s'appeler param1... param10...

En fait toute discussion avec cette personne est délicate. A chaque fois il a un point de vue assez tranchée (et diamétralement opposée au mien) sur comment les choses doivent être (ou ne pas être).
Sauf que j'ai l'impression qu'il n'a jamais écrit de code applicatif et qu'il ne voit les choses que de son point de vue "sysadmin". C'est un peu comme quand je parle avec des dba en fait ou des experts réseaux...

Heureusement c'est un mec sympa, il ne s'énerve pas et revient souvent sur ce qu'il dit (les niveaux de log et le nom des loggers). Je crois que j'aurais mes stacktrace bientôt.
Mais du coup je vois l'outil sous un jour un peu défavorable.

[SetaSensei]

Je ne peux pas lock le thread, mais la V2 est déjà dispo :

http://forum.canardpc.com/threads/11...r-et-compagnie