Supervision : Créer des objets et des hôtes

I. Présentation

Dans ce billet, nous allons voir comment définir des objets dans un système de supervision open source. Je me suis basé sur la configuration de Naemon, mais ce que nous allons voir ici est parfaitement applicable sur d’autres systèmes comme Nagios, Inciga ou Shinken.


II. Les objets

Dans ces systèmes, les objets peuvent être définis dans un ou plusieurs fichiers de configuration. Dans le répertoire où est installé votre système de supervision, vous devriez retrouver ces fichiers :

  • timeperiods.cfg
  • contacts.cfg
  • contactgroups.cfg
  • hosts.cfg
  • services.cfg

Vous remarquerez qu’ils portent chacun un nom bien précis. Sachez que si vous créez un objet de type host dans le fichier timeperiods.cfg cela marchera tout pareil. Le nom des fichiers est juste pour vous retrouver dans votre configuration. Ce qui compte, c’est que tous vos fichiers soient bien déclarés dans le fichier de configuration principal. On rentrera en détail là-dessus dans un autre article.

Donc pour créer un objet, on se met dans un des fichiers de configuration. Dans ces fichiers tout est structuré de la même manière. Un objet, quel que soit son type sera défini par :

define type_de_mon_objet { }

Entre les {}, on va créer tous les paramètres de l’objet. Voici les différents types d’objets :

Les indispensables :

  • Host
  • Hostgroup
  • Service
  • Servicegroup
  • Contact
  • Contactgroup
  • Timeperiod
  • Command

Les "plus" :

  • Servicedependency
  • Serviceescalation
  • Hostdependency
  • hostescalation

Suivant votre système de supervision, vous pourrez trouver encore d’autres objets. En ce qui concerne les indispensables, ce sont les mêmes partout. Ça tombe bien ce sont ceux que nous allons utiliser 🙂
Pour créer un objet de type hôte, je vais donc inscrire dans mon fichier ceci :

define host { }
# Le caractère # nous permet de mettre des commentaires (n’hésitez pas à en abuser !)

Avant de commencer, je fais une petite note sur les objets de groupe (Hostgroup, Servicegroup, Contactgroup). Ils sont très utiles de manière générale. Vous verrez que l'on fait souvent référence aux mêmes objets plusieurs fois. Du coup, quand on créer un nouvelle objet, plutôt que de parcourir tous les fichiers de configurations, si on a fait un groupe, on rajoute notre objet dans le groupe et hop ! Il est inscrit partout d’un seul coup ! Génial non ? (vous n’avez pas compris, ce n’est pas grave. Ça va venir 😉 )

Bon, maintenant que vous savez créer un objet, on va mettre des paramètres dedans. Les paramètres, il y en a des dizaines par objets. Pour l’instant, nous allons nous intéresser uniquement aux hôtes. Nous verrons les autres plus tard.

III. Les objets hôtes

Les hôtes, ce sont vos équipements à superviser. Ils possèdent donc une adresse IP. L’hôte en soit aura un contrôle par défaut pour contrôler qu’il est « vivant ». En général, c’est un ping. Ce contrôle permettra de définir 3 états pour nos hôtes :

  • OK : tout va bien.
  • DOWN : l’hôte ne répond pas.
  • UNREACHEABLE : l’hôte n’est pas joignable.

Voici les paramètres à utiliser sur un hôte.

  • host_name : C’est le nom de l’objet, on utilisera ce nom pour faire référence à l’objet.
  • alias : Une petite description de notre objet.
  • address : Adresse IP de votre équipement.
  • hostgroups : Nom de l’objet groupe auxquels appartiens l’hôte.
  • check_command : Nom de l’objet command qui sera utilisé pour contrôler l’état de l’hôte (en général c’est un ping. Mais j’insiste, ici on fait référence à un objet command qu’on va créer)
  • max_check_attempts : Nombre de fois que l’hôte sera vérifié pour valider son état.
  • check_interval : Temps en minute entre chaque contrôle de l’hôte.
  • retry_interval : Temps en minute entre chaque contrôle dans un état non OK.
  • check_period : Nom de l’objet timeperiod sur laquelle sera contrôlé l’hôte.
  • contacts : Nom de l’objet contact à notifier lors d’un problème.
  • contact_groups : Même chose, mais avec groupe de contact. (Au moins un des deux est nécessaire)
  • notification_interval : Intervalle en minutes entre deux notifications pour l’hôte.
  • notification_period : Nom de l’objet timeperiod de temps sur laquelle sera notifié un problème sur l’hôte.

Les paramètres en gras définissent les paramètres obligatoires pour un hôte :

define host {
    host_name SRV-MAIL
    alias Windows 2012 R2 – Exchange 2013
    address 192.168.1.100
    hostgroups Windows, Antivirus
    check_command check_ping
    max_check_attempts 3
    check_interval 5
    retry_interval 2
    check_period 24x7
    contacts michel, pascal, beatrice
    contact_groups administrateurs
    notification_interval 30
    notification_period 24x7
}

Voilà c’est aussi simple que ça! Vous pouvez revenir à la ligne et en créer un 2ème. Hop attention, je vous vois venir. Avant de faire des copier-coller dans tous les sens, soyez sur d’avoir déjà entendu parler des templates… (À venir).

IV. Les groupes d’hôtes

Les objets hostgroup regroupent un ensemble d’objet hôte.

  • hostgroup_name : C’est le nom de l’objet, on utilisera ce nom pour faire référence à l’objet.
  • alias : Une petite description de notre objet.
  • members : Ici nous mettrons les noms d’objet hôte membre du groupe.
  • hostgroup_members : Nom d’un autre objet hostgroup membre du groupe.
define hostgroup {
    hostgroup_name Windows
    alias Les serveurs Windows
    members SRV-MAIL, SRV-AD, SRV-IMP
}
define hostgroup {
    hostgroup_name Serveurs
    alias Les serveurs
    hostgroup_members Windows, Linux
}

Si vous avez été attentif, vous aurez peut être remarqué que nous avons deux manières de mettre un hôte dans un groupe d’hôte.

La première directement dans l’objet hôte avec le paramètre hostgroups. La deuxième dans l’objet de groupe avec le paramètre members. Si vous avez utilisé une des deux manières, ce n’est pas nécessaire d’utiliser la seconde. D’ailleurs, je vous conseille d’utiliser qu’une seule des deux possibilités et de n’utiliser que celle-ci. C’est beaucoup plus simple de s’y retrouver par la suite.

Personnellement, je n’utilise pas le paramètre members. Simplement parce que quand je modifie un hôte, c’est plus simple de voir de quels groupes il fait partie dans le paramètre hostgroups. Plutôt que de parcourir tous les groupes et vérifier le paramètre members (surtout si vous avez 100 hôtes par groupe). Après c’est ma méthode, l’important c’est d’avoir celle qui vous permettra de vous y retrouver.

Ne créez pas de groupe pour créer des groupes et parce que j’ai dit que c’était cool. Créez un groupe pour son intérêt, il faut qu’il vous soit utile. Par exemple, avec le groupe Windows nous aurons toutes les machines Windows. Qu’elle est l’intérêt ? On peut se dire qu’ils ont tous un lecteur C : on pourra alors créer un contrôle d’espace disque C : qui s’applique sur ce groupe ! J’ai un nouveau serveur Windows, je créer donc un nouvel objet que j’ajoute dans le groupe Windows et il aura directement l’espace du lecteur C : de contrôlé. Vous voyez mieux l’intérêt maintenant :).

Bien ! On a des hôtes. On a fait une configuration bien structurée avec des groupes. On va pouvoir passer à l’étape ultime : créer des contrôles ! Vous allez adorer ça ! 🙂

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Cyprien Santana

Geek raisonnable, passionné par le "bidouillage" et les nouvelles technologies. Je viens ici pour partager mes connaissances avec vous ! Je travaille beaucoup sur les réseaux et la sécurité, avec une petite touche supervision. Je viens aussi en tant que lecteur sur IT-Connect pour augmenter mon capital connaissance ;)

    cyprien has 9 posts and counting.See all posts by cyprien

    4 pensées sur “Supervision : Créer des objets et des hôtes

    • Je teste personnellement Icinga2 et sa nouvelle interface web. Très bon système de supervision qui permet aussi grâce à l’agent Icinga2 de créer les fichiers de configuration automatiquement des hôtes et services.(Windows et Linux) et de plus la communication se fait à l’aide de certificats.

      Répondre
      • Effectivement suivant l’interface utilisée il est possible de directement gérer ses fichiers de configuration. J’aborde ici la configuration « à la main » car pour moi une fois que l’on maîtrise cette méthode, il est possible d’utiliser toutes interfaces et surtout comprendre ce qu’il se passe réellement.

        Je n’ai pas encore testé Inciga, j’ai découvert Naemon juste avant de m’y mettre. Mais je ne devrais pas tarder 😉

        Répondre
    • Bonjour,

      Est-ce que tu as déjà testé Centreon ?
      Si oui, qu’en penses-tu par rapport aux autres outils que tu as pu testé ?
      Si non, est-ce que tu serais intéressé pour le tester ?

      Merci et bonne journée !

      Répondre
      • Bonjour,

        J’utilise régulièrement l’interface Centreon sur une ditrib FAN. Globalement ce que je trouve appréciable c’est la partie configuration. Dans mon cas elle me permet également de gérer plusieurs serveurs Nagios d’un coup. Plutôt utile mais surement moins adapté en comparaison à d’autres outils dans mon cas.

        Après je ne me suis jamais penché sur la solution CES, c’est envisageable que ça passe sur le banc de test un jour 😉

        Répondre

    Laisser un commentaire

    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.