[RESOLU] installation d'un database broker

[Seb-Solon]

A la louche, si on considère une louche standard, genre 5/8 cm de diametre, c'est pour la semaine prochaine

Problème d'ordonnancement? Nah... C'est juste la différence entre la théorie et la pratique.
En theorie on a des beaux algos de scheduling et puis en pratique on utilise pas la bonne théorie quoi. On préfère utiliser Einstein avec un peu de procrastination en amont. Un max de chose a faire en un minimum de temps, si on va assez vite ca passe (Ouais relativité du temps, des longueurs toussa toussa)

Ouais pour les vrais questions j'ai pas de réponses, c'est peut être mieux pour toi cela dit

[naparuba]

Le hic sera qu'un tel module ne servira à rien pour les très gros environnements car il va générer trop d'I/O disques. Pour eux ils ne faut sauvegarder que des informations agrégées (quand on voit certains environnements qui font plusieurs Go de log par jour, tu imagine l'activité de logger tous les checks...).

De plus, ce travail de recréation des agrégations/intervalles va être à refaire dans ta moulinette et ne va pas être si facile que ça :
* changement d'état : ok simple
* passage en downtime : déjà c'est plus rigolo à gérer
* qui des acks?
* changement d'importance : un même problème peu être important 80% du temps et pas les 20% restant, et ce dans le même état
* quid des périodes de non checks? (pas downtime, check_period autre que 24x7?)

Bon après ça dépends de ce qu'on te demande comme infos. si c'est du simple SLA basé sur les états avec un peu de downtime voir ack, ça peu le faire, mais un truc un peu costau qui pourra être utilisé par tous là c'est plus tendu, et il faut batir un vrai cube OLAP et non pas se baser sur du transactionnel (je gueule tous les jours sur des dev qui le font car ça plombe les perfs des machines pendant le calcul, là où un outil de BI serait bien plus adapté...).

Donc faire un tel module c'est sans soucis, mais j'ai des doutes sur sa pérennité et je ne peux pas te garantir qu'il restera c'est ça le soucis.

[Httqm]

Le hic sera qu'un tel module ne servira à rien pour les très gros environnements car il va générer trop d'I/O disques. Pour eux ils ne faut sauvegarder que des informations agrégées (quand on voit certains environnements qui font plusieurs Go de log par jour, tu imagine l'activité de logger tous les checks...).

On est d’accord, c’est pour ça que je parlais dans un de mes messages précédents de la possibilité d’activer ou non cette fonctionnalité via une directive de config de service du genre :

Code: [Sélectionner]

define service {
    host_name               ...
    use                     ...
    check_command           ...
    log_to_mongodb          o,w,c,u # log every ok/warning/critical/unknown check return
    }

Dans mon cas, ce n’est requis que pour une dizaine de services.


Pour le reste, je comprends tes objections, mais en fait, je cherche quelque chose de nettement moins sophistiqué ;-) Prenons un exemple concret pour fixer les choses : je dois fournir des stats de dispo pour un service web. J’ai un plugin (dont le fonctionnement est HS ici) qui me retourne des résultats : ok/warning/critical/unknown. Shinken me permet de lancer un check toutes les 5 minutes, ce qui, d’un point de vue « historique » va donner un truc du genre :

JJ-MM-AAAA-11h55, hostname, service1, ok, perfdata
JJ-MM-AAAA-11h57, hostname, service2, ok, perfdata
JJ-MM-AAAA-12h00, hostname, service1, ok, perfdata
JJ-MM-AAAA-12h03, hostname, service2, warning, perfdata
JJ-MM-AAAA-12h05, hostname, service1, critical, perfdata
JJ-MM-AAAA-12h08, hostname, service2, warning, perfdata
JJ-MM-AAAA-12h10, hostname, service1, warning, perfdata
JJ-MM-AAAA-12h13, hostname, service2, ok, perfdata

Et c’est tout ce dont j’ai besoin : avoir les données brutes dans une base de données, mais TOUTES les données, même si le statut ne change pas par rapport au statut précédent. A partir de là, je dois faire une analyse en interne qui n’est pas liée à Shinken. Les services à superviser sont censés être dispos 24/7, donc pas de downtimes prévus. Les downtimes relevés seront soit dus à un problème applicatif, soit à un problème côté hébergeur.
Re-exemple : si les mesures sur une période donnée sont toutes en critical parce que je me suis ch*é dessus sur une conf serveur, c’est de l’applicatif, on les garde (et tant pis pour mon SLA). Mais si la cause est un incident côté hébergeur (panne réseau, panne matérielle, …) dans ce cas, j’exclus les points de mesure concernés (puisque je fournis un SLA concernant ma propre activité).
Une fois que j’ai tous les points de mesure à prendre en compte, il me suffit de faire le ratio du nombre de « ok » par rapport au nombre de mesures pour chaque service pour obtenir le taux de disponibilité attendu.

Donc :
- les downtimes : dispo prévue 24/7 de l’ensemble d’un service (archi web redondée, donc pas de downtime du service, même si des serveurs peuvent être arrêtés)
- « ack » ou pas « ack » : non significatif ici
- changement d’importance : je comprends où tu veux en venir dans un cas général. Mais ici, l’importance est fixe par rapport à un état.
- période de non checks : le taux de dispo étant calculé à partir du nombre de OK par rapport aux nombres de mesures, le calcul reste le même. Là, c’est à moi d’indiquer dans les petites lignes qui accompagneront mon % final : « basé sur les mesures du ../../…. au ../../…., période du ../../…. au ../../…. exclue pour cause de … »

En résumé, ce dont j’ai besoin, c’est de compter des évènements, d’en exclure 2 ou 3 par-ci par-là (sur la base d’infos que Shinken ne peut pas me fournir) et de faire une division. Donc si j’ai des données brutes, ça marche !

[naparuba]

Je pense que rajouter un tel paramètre dans les hôtes/services ne serait pas une bonne chose (surtout un paramètre lié à un module particulier, c'est pas maintenable ni générique ) mais plus un paramètre sur le module en lui même. Genre là c'est surtout pour tes trucs importants non? donc pourquoi ne pas avoir un paramètre qui ne loggues que les hotes/services avec une business_importance >=4 par exemple? Simple, efficace

Bref, ça peut être fait après la 1.0 assez rapidement sous la forme d'un module one shot pour ton cas. Vu qu'il est petit, ça ne sera pas la mort à maintenir (j'en ais d'autres des modules one host, dont certains sont pour mon install de prod). On release la 1.0 puis je me penche là dessus, ou si tu es un peu codeur je te file les billes sur comment faire si tu veux

[Httqm]

Je pense que rajouter un tel paramètre dans les hôtes/services ne serait pas une bonne chose (surtout un paramètre lié à un module particulier, c'est pas maintenable ni générique ) mais plus un paramètre sur le module en lui même. Genre là c'est surtout pour tes trucs importants non? donc pourquoi ne pas avoir un paramètre qui ne loggues que les hotes/services avec une business_importance >=4 par exemple? Simple, efficace

En fait, je cherche à logguer les résultats de certains services checks uniquement (et pas tous, sinon, je vais pourir ma base avec des données dont je n'ai pas besoin). Mais ce qu'il me faut, surtout, c'est que TOUS les résultats (ok/warning/critical/unknown) soient là. Si je te suis bien, il "suffit" que je configure les services concernés en leur affectant une "business_importance=n", et le module viendra stocker en DB tous les résultats pour les services ayant une importance >= n ? J'ai tout bien tout compris

Bref, ça peut être fait après la 1.0 assez rapidement sous la forme d'un module one shot pour ton cas. Vu qu'il est petit, ça ne sera pas la mort à maintenir (j'en ais d'autres des modules one shot, dont certains sont pour mon install de prod). On release la 1.0 puis je me penche là dessus, ou si tu es un peu codeur je te file les billes sur comment faire si tu veux

C'est pas l'envie qui manque, mais j'ai à peine dépassé le stade du "Hello World" en Python...

[naparuba]

C'est bien ça. On ne loguerait que ce qui concerne les trucs importants

Pour le hello world, bah on ne peux pas connaitre tous les langages :p