3.X roadmap

[naparuba]

(en FR pour plus de facilité et de clarté, on changera de langue si besoin de membres externes)

NOTE: ce n'est pas (encore) une roadmap à proprement paré mais une proposition de direction dont découlera la roadmap. Merci de me faire un maximum de retours/propositions sur ces points afin qu'on soit sûr de tous être dans la même direction. Une fois qu'on aura les grands principes, découler la roadmap sera facile, ça sera qu'une question d'ordonnancement ^^

Après avoir pas mal appris sur l'expérience Enterprise sur de bons principes:
== Comprendre > puissance
Faire comprendre à un maximum de personnes la supervision est un travail colossal et la puissance n'est rien si les personnes ne le comprennent pas, et je dirais même jusqu'à dire que ça doit être trivial. (oui ce point va piquer vous vous en douter...)

== Si pas possible de faire comprendre, faire le choix pour l'utilisateur
C'est très, (très) long de faire tout comprendre correctement aux utilisateurs. Donc pendant ce temps faut faire des choix pour l'utilisateur. Chaque choix qu'il doit faire sans avoir tout ce qu'il faut pour comprendre implique une perte sur les utilisateurs. LESS is MORE en résumé.

== Revoir les priorités
L'outil a été pensé à l'origine pour avoir un DEBIT maximal. (aka nombre de checks lancés à la seconde), quitte à sacrifier la LATENCE (surtout d'un point de vue configuration).

Le cycle WHILE TRUE: création conf->vérif conf->application->vue dans les uis->changement de conf est trop long sur les gros environnements. Désormais les utilisateurs veulent un résultat immédiat. Or avec toutes les capacités qu'on a en terme d'héritage, dépendances and co, c'est juste injouable. Va falloir choisir entre les 2.

• L'héritage c'est surpuissant. Mais peu être trop. Peu être que moins d'héritage et plus de facilité de scripting/vérification.

== Clean divers et varié

• Certains objets hérités de Nagios sont obsolètes, et on devrait très clairement les droper (*extinfo par exemple).
• j'aurai du me péter une jambe le jour où j'ai pensé les triggers. Ca n'a rien à faire dans le framework, mais dans un outil tiers genre graphite.
• Je ne pense pas que mixer run et changement de configuration (par exemple disable check) est un bon mix. C'est pas comme si on avait des outils de gestion de configuration inutilisable désormais. C'est à eux à gérer ça, pas au framework de tenter de les suppléer.
• Je pense qu'un bon gros clean des features inutilisées ne fera pas de mal ^^

== Optimisation/performances

• les liens entre les objets sous forme de pointeurs c'est cool, mais bon à maintenir entre les changements de configuration bof bof. Des simples strings c'est plus facile même si ça implique une légère consommation de CPU en plus sur le scheduler
• ceci permettra aussi de ne pas avoir à updater tous les éléments, on pourrait les pousser 1 par un si on peux gérer les erreurs de liens (genre pas un soucis si le parent n'est pas encore dispo, on le skip et puis c'est tout).
• Certains daemons sont trop limités en terme de capacité d'utilisation des ressources systèmes (CPU par exemple pour l'arbiter et le scheduler, et réseaux pour l'arbiter)
• Les objets Pythons sont trop "gros", et complexes. En gros par facilité on a mélangé ce qui dépends de la configuration et de l'état des éléments. Or ça n'a pas le même cycle de vie (un est stable l'autre non). C'est je pense un changement important qui pourra faciliter beaucoup après ^^
• je pense que les schedulers d'un realm R devraient avoir TOUS les hôtes de son royaume et de ses sous royaumes. Bien sûr un scheduler ne devrait toujour gérer qu'un seul shard des hôtes, mais ça devrait être facile à déterminer par lui, et pas de l'arbiter. Ceci nécessite que les schedulers se connaissent par contre
• on devrait échanger automatiquement les état des éléments entre les schedulers. Ainsi les bp rules pourront être lancées locament dans un scheduler, mais sur tous les éléments à jour. C'est LA grosse limitation actuelle des bp_rules.

[olivierHa]

Coté technique et support :

• Je pense que la version 3.X doit supporter Python 3.x (définir le bon X)
• Le point précédent doit/peut impliquer un passage à Requests
• Generaliser les UUIDs (actuellement que les hosts/services)
• Faire un sondage sur les features les plus utilisés parmi la masse de features, et voir comment les supporter mieux (cela rejoint le point des BP_rules multi sched par exemple)
• La 'mode' c'est le reporting et l'analyse d'incidents (voire la prédiction). Même si ce n'est pas dans le framework lui-même, il faut essayer d'avoir un "bon" support dans les modules des différents outils existants (Elasticsearch/ElastAlert par exemple ou autre, export vers Kafka etc ... ).
• Etudier la pertinence (et l'impact sur les performances, la lisibilité.... ) d'avoir un support dans les configurations d'un langage de templating (type Jinja2)

[NicolasLM]

"Le cycle WHILE TRUE: création conf->vérif conf->application->vue dans les uis->changement de conf est trop long sur les gros environnements"
Effectivement sur ce point Shinken peine à s'adapter à un environement cloud où il n'est pas rare d'ajouter et supprimer des dizaines de hosts par minute.

[achaussier]

Hello,

Tout d'abord, je ne peux qu'approuver la réflexion sur la compréhension de la supervision par les utilisateurs 👍 et je trouve géniale l'initiative de ce ticket pour la définition de la direction du projet.

Je pense que l'un des points les plus délicats(de mon point de vue) est celui qui concerne l'héritage. Il faut en effet réussir à rester suffisament flexible pour permettre de minimiser la configuration lors de l'ajout de nouveaux éléments de configuration, tout en essayant de ne pas trop impacter les performances de la génération.

Personnellement, je gère actuellement mes configurations via un role Ansible, et l'ajout d'un nouvel élément référencé est extrèmement rapide à faire, ce qui est un point fort de l'héritage actuellement en place. Un nouveau bloc de YAML et c'est fini.

@naparuba : Lorsque tu dis "plus de facilité de scripting/vérification.", ce serait à quel niveau/moment ? Car même si cela serait en effet mieux d'avoir une gestion de configuration plus performante, pour moi le réel interêt serait de pouvoir la gérer à la volée, via un endpoint d'API par exemple, où l'on ne veut/peut pas forcément attendre trop longtemps le résultat, celui-ci pouvant en effet bloquer un processus en cours.

[geektophe]

Je pense aussi que casser le modèle actuel de liens entre les objets pour mettre en place un mécanisme de résolution à la demande, quitte à reparser des dépendances ou des règles (donc augmenter la charge sur le CPU) et le partage de l'état global des objets entre les schedulers est une avancée majeure.

Ça ouvre plein de possibilités, entre autre l'ajout ou la suppression dynamique d'objets, ce qui est à mon sens notre prochain gros chalenge avec l'avènement des environnements cloud.

Il faudrait aussi avancer sur le lazy loading, qui permettrait de n'affecter une valeur à une propriété que si elle set lue ou écrite. On peut attendre une économie de mémoire substantielle, et ça améliorerait aussi largement de temps de parse de la configuration. Là aussi, y'a du boulot :)

Concernant la remarque sur l'héritage, c'est à mon sens une feature très importante, car c'est elle qui permet de factoriser efficacement la conf. Il y a sans doute des choses à revoir et simplifier, mais il faut faire attention de pas supprimer ce qui fait la puissance de Shinken.

[hahahafr]

cela serait en effet mieux d'avoir une gestion de configuration plus performante, pour moi le réel interêt serait de pouvoir la gérer à la volée, via un endpoint d'API par exemple

GLPI_monitoring fait un peu ça, en utilisant l'xmlrpc

[achaussier]

Hello, merci, n'utilisant pas GLPI je ne connaissais pas le plugin.

Jje vais regarder l'implémentation histoire de me faire une idée.