Non, Centreon n’autorise pas de hostgroup pour les modèles d’hôtes

Posted by

Ce post met en avant un manque dans Centreon, outil que j’utilise par ailleurs en production depuis plusieurs années. A part ces fameux manques que je vais détailler, c’est un très bon outil.

Il permettra aux personnes qui découvrent Nagios ou Centreon d’avoir une meilleure approche des deux outils sur les problématiques d’industrialisation et de mutualisation de la configuration.

Disclaimer : ce n’est pas parce que je rencontre des difficultés pour réaliser certaines opérations que je connais toutes les manières de gérer une configuration Centreon de manière optimale. J’ai des habitudes qui me viennent de l’utilisation d’autres outils (de supervision ou non) qui biaisent peut être mon jugement.

[Edit] Dans les commentaires j’ai reçu une réponse de Laurent Pensivy (apparemment) de Centreon. Il propose d’utiliser un mécanisme de Centreon qui contourne le problème, selon lui. Voilà ce que j’en pense. [/Edit]

Industrialisation/mutualisation : de quoi parle t-on ?

Dans la supervision Nagios et les outils compatibles/similaires, les templates (modèles) permettent de gagner du temps. On définit X modèles qui permettent eux mêmes de définir une bonne fois pour toutes les paramètres communs à plusieurs hôtes ou à des services. Cette façon de penser est héritée de la programmation orientée objet.

C’est très utile pour les contacts de nos hôtes/services (les problèmes sur les hôtes windows génèrent des alertes pour les administrateurs windows) ou les fréquences de vérifications (on vérifie le ping des serveurs toutes les 5 minutes, quelque soit le serveur), mais pas seulement.

On peut aussi vouloir affecter au modèle « serveurs windows » toutes les vérifications (checks) d’usage qui sont normalement attendues pour la supervision minimale d’un serveur windows. On définit ainsi un socle commun (ping, disque C:, et RAM par exemple).

Dans Nagios, je peux lier un service à des hôtes ou des groupes d’hôtes (ou les deux). Mais pour ce qui est des modèles d’hôtes, ajouter un service à un modèle d’hôte n’a strictement aucun effet.

Et en fait c’est logique : je me répète, mais Nagios a une configuration orienté objet. Du coup, un « service » doit être vu comme un « objet réel » (i.e. qui existe), contrairement à modèle qui est lui un objet abstrait. On ne peut pas affecter un objet réel à un objet abstrait. En réalité, il faut passer par un modèle de service, si on souhaite affecter automatiquement des services à un groupe.

Ce que moi je souhaite faire

Concrètement, si je souhaite affecter un même service à un ensemble donné d’hôtes, les premières solutions simples qui me viennent à l’esprit sont :

  • affecter le service serveur par serveur (ou une liste de serveur)
  • lier le service à un groupe d’hôtes : si j’ajoute ou je supprime un serveur du groupe, je n’ai pas de modification à apporter sur le service
  • lier un modèle de service à un modèle d’hôte, puis affecter ce modèle aux hôtes concernés. Idem

Les trois solutions sont parfaitement valides dans une configuration Nagios.

Cependant, vous conviendrez que la première méthode est difficilement maintenable sur un parc important avec de nombreux services, et on préfèrera généralement utiliser les deux suivantes.

En outre, la dernière à l’avantage de permettre de créer des sous-modèles (qui héritent eux même de modèles) et ainsi gérer certains cas particuliers.

Les cas particuliers: parlons en !

Imaginons que j’ai un groupe d’hôte hostgroup-linux, qui contient mes 200 serveurs Linux, et que j’ai lié 5 services communs à ce groupe d’hôtes. Cependant, pour des besoins qui me sont propres, j’ai 3 serveurs dont je vérifie l’état de la RAM via SNMP dont les seuils diffèrent de la grande majorité.

En ne résonnant qu’avec des hostgroups, je pourrais :

  • soit créer deux groupes distincts (hostgroup-linux et hostgroup-linux-specific-RAM) pour gérer les deux seuils, mais cela m’obligerait à dupliquer l’ensemble des autres services communs aux deux groupes.
  • soit de garder un groupe mutualisant tous les services communs, et créer deux groupes contenant juste le service avec les deux seuils distancts.

Dans tous les cas, je multiple les services et les groupes à gérer, ce qui multiplie également le risque d’erreurs.

Si maintenant j’utilise des modèles d’hôtes. Je vais :

  • créer un modèle d’hôte host-linux sur lequel j’affecte les modèles de services avec les seuils qui vont bien pour mes 5 services
  • créer un module d’hôte host-linux-specific-RAM qui hérite du modèle host-linux, et auquel je n’ajoute qu’un seul modèle de service (la RAM avec le seuil spécifique)

Ainsi, je n’ai dupliqué que ce qui est nécessaire pour gérer mes deux cas et je limite les erreurs possibles.

Comment Centreon gère sa configuration

Un des avantages de Centreon par rapport à un serveur Nagios simple (ou même d’autres outils similaires/compatibles avec la configuration Nagios) est qu’il vous permet de gérer la configuration de votre supervision et de votre parc depuis l’interface graphique web. C’est un gros point positif pour les équipes techniques qui ne disposent pas d’un « Nagios Guru » et qui veulent s’affranchir de la maintenance de la configuration par fichier plat.

Cependant, comme Centreon n’est ni plus ni moins qu’une surcouche à Nagios (un peu moins vrai aujourd’hui puisque Merethis développe de plus en plus, et notamment son propre moteur), ce choix implique la gestion d’un référentiel à part (MySQL) qui est ensuite utilisé pour générer une configuration texte « Nagios-compatible » à la demande.

Cela a impliqué des choix, notamment en terme de simplification de la configuration générée. Les possibilités offertes par Nagios en terme de configuration sont très riches, et tout implémenter aurait probablement conduit à des erreurs de configuration lors de la génération. La configuration générée est donc un peu simplifiée par rapport à ce que Nagios peut gérer.

Par exemple, alors qu’un seul service (1 seul objet) peut être défini pour X hôtes et Y groupes d’hôtes, Centreon génère un service pour chaque hôtes et chaque groupes d’hôtes concernés, ce qui simplifie grandement la génération de la configuration texte pour Centreon mais la rend illisible pour un administrateur habitué à lire sa conf Nagios.

Mais ce n’est pas tout, car comme je le martèle depuis le début, toutes les possibilités ne sont pas possibles, et certaines sont beaucoup plus visibles!

Les bests pratices de Centreon

Pour permettre à tout le monde de s’en sortir, Centreon fourni une liste de best practices sur l’utilisation des templates pour expliquer leur fonctionnement spécifiquement dans Centreon.

https://blog.centreon.com/good-practices-host-templates-and-service-templates-how-they-work-together/

(ou la version Française https://blog.centreon.com/40/?lang=fr)

On y apprend grosso modo la même chose que ce que je viens de dire, à savoir qu’il est plus malin de créer des templates pour associer les services à des hôtes que de le faire à la main.

Pourquoi ça me gène de ne pas pouvoir mettre d’hostgroup dans mon template

L’article et ses commentaires montre bien que les équipes de Centreon et leur communauté ont bien conscience de l’importance des templates, de l’ordonnancement des templates lors de la création d’un hôte et du besoin de donner accès à le plus de mécaniques de Nagios possible pour industrialiser la gestion d’un parc (qui évolue dans le temps).

Bien ! Pourtant, il me semble qu’ils ne sont pas allés au bout de la démarche. Comme on peut le voir lors dans l’article de Centreon (ou en réalité), la modification d’un modèle d’hôte permet d’affecter à la création les services liés aux modèles d’hôtes (UNIQUEMENT!!!).

Si pour une raison ou pour une autre, vous avez besoin d’ajouter un nouveau service à un template (et donc l’ajouter pour l’ensemble des hôtes qui héritent de se template), vous devrez donc retourner sur tous les hôtes qui héritent de ce template pour cliquer sur le bouton de création des services liés. On perd dont l’intérêt du template (flexibilité/évolutivité).

centreon_template_1Un moyen de contourner cette limitation serait de pouvoir affecter des groupes d’hôtes à des modèles d’hôtes. C’est possible dans Nagios, c’est même plutôt recommandé pour définir des icônes ou des contacts par défaut.

Ici, plutôt que d’affecter le modèle de service à un modèle d’hôte, on passe par l’intermédiaire d’un groupe d’hôte. Concrètement, le service service-XXX est lié au groupe d’hôtes hostgroup-XXX, et les membres du groupes d’hôtes sont définit dynamiquement par l’héritage des hôtes au template host-template-XXX.

Ainsi, si on enlève ou ajoute des hôtes avec le bon template, les services seront créés/supprimés dynamiquement. Idem si on lie/délie des services au groupe d’hôtes. Cependant, cette fonctionnalité est absente de Centreon. Il n’est à date pas possible de définir des groupes d’hôtes sur un modèle d’hôtes (alors que l’écran dans l’interface graphique web semble prête pour).

centreon_template_2Comme dirait Dark Vador

Sense : the absence of this feature makes none

DarthVaderintheocean

[Edit] Dans les commentaires j’ai reçu une réponse de Laurent Pensivy (apparemment) de Centreon. Il propose d’utiliser un mécanisme de Centreon qui contourne le problème, selon lui. Voilà ce que j’en pense. [/Edit]

5 comments

  1. Bonjour,

    Ton article est intéressant mais tu es passé à côté d’une fonctionnalité très intéressante qui est le « massive change » (ou « changement massif »).

    En effet, si tu modifie pour une raison X ou Y un modèle d’hôte (ajout d’un modèle de service par exemple), il te suffit d’aller sur la page de configuration des hôtes, de filtrer (via le filtre de recherche) sur le bon modèle d’hôte, de sélectionner l’ensemble des objets (via la checkbox globale), de choisir « massive change » dans la liste des actions puis de cocher la fameuse case « Create Services linked to the Template too » et de valider le changement.

    Ainsi la modification sera apportée à tous les hôtes héritant du modèle ;)

    Bonne continuation et merci d’utiliser Centreon ;)

  2. Merci pour ce retour et la précision : je testerai et mettrai l’article à jour en conséquence.

    Cependant, à première vue, ça me semble tout de même moins pratique à utiliser que de mettre à jour un groupe d’hôte ou un modèle, puisque je dois effectuer l’action supplémentaire de sélectionner mes hôtes et de réaliser ce « changement massif ».

  3. Bonjour,

    As-tu pu tester cette fonctionnalité ? Sinon, est-ce que via CLAPI il ne serait pas possible d’automatiser une régénération des modèles d’hôtes ?

  4. J’avais fais un article « follow up » où je détaillais la solution proposée par Laurent Pinsivy de Centreon, mais visiblement je n’ai pas mis le lien dans l’article. Oubli que je vais corriger de ce pas ;).

    Pour faire (relativement) court, je reste sur ma faim. Oui ça « fonctionne » mais finalement on ne fait que forcer unitairement une mise à jour manuelle des modèles.
    Sans compter qu’il faut bien cocher tous les serveurs concernés et bien prendre garde à ne pas en oublier un.
    Bref pour moi, ce n’est pas super satisfaisant car comme tout ce qui est manuel, on peut oublier de le faire ou on peut le faire mal.
    Avec les modèles d’hôtes et de services, c’est automatique, on ne peut pas se tromper.

    Et pour CLAPI, j’avoue ne jamais m’être penché sur le sujet. Je jetterai un œil à l’occasion pour voir ce qu’on peut faire avec.

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.