Configuration des ressources

1. Modèle de données

Centreon vérifie la disponibilité des hôtes et la performance des services qui leur sont rattachés. Les contrôles s’effectuent via des commandes de vérification qui exécutent les sondes appropriées avec les paramètres adéquats (adresse du serveur, seuils d’alerte, etc.) et pendant des périodes de contrôle définies. En cas d’anomalie détectée, les contacts liés au service sont notifiés pendant les périodes de notification définies à l’aide d’une commande de notification.

Modèle de données

Le modèle de données des objets de configuration de Centreon est calqué sur celui de Nagios. Il est très permissif.

Les liaisons des modèles d’hôtes et de services sont surchargeables par les hôtes et services qui en héritent. Ces liaisons ne sont pas représentées sur le schéma pour davantage de lisibilité.

Bonnes pratiques

L’utilisation de services liés à un groupe d’hôtes est fortement déconseillée, comme il le sera rappelé dans la suite.

Il est également déconseillé de lier directement des contacts aux modèles d’hôtes et de services ou aux hôtes et services. L’utilisation de groupes de contacts apporte davantage de souplesse.

Ordre de configuration

Le modèle relationnel impose un ordre de configuration des objets qui va de ceux avec le moins de relations à ceux avec le plus de relations :

Cet ordre de configuration est respecté dans ce chapitre...

1. Macros : les variables de Centreon

Avant de présenter les commandes, il convient de présenter le mécanisme de variables utilisé par Centreon tout au long de la configuration de la supervision. Ces variables sont appelées macros.

Les macros respectent une nomenclature particulière permettant leur identification dans les commandes : elles commencent et se terminent toujours par le caractère $. Par exemple : $_SERVICE_MA_MACRO$.

Les macros sont définies à plusieurs endroits de la configuration de Centreon et sont utilisées dans la définition des commandes. Les macros sont remplacées par leur valeur au moment de l’appel système de la ligne de commande.

Cinq types de macros sont utilisés dans Centreon :

1. Définition

Les périodes temporelles servent à activer ou limiter certaines fonctionnalités sur des périodes de temps définies. Elles s’appliquent au contrôle des ressources et aux notifications, sans être spécifiques à l’un ni aux autres.

Les périodes temporelles ont une précision à la minute et peuvent être combinées.

Quelques exemples d’utilisation

Notification par SMS sur les horaires d’astreinte uniquement, par mail sur les heures ouvrées. Arrêt des vérifications de l’AS400 toutes les nuits de 23h à 2h pour maintenance.

2. Configuration

Présentation

Quatre périodes temporelles sont préconfigurées par Centreon :

1. Modèles et héritage

Définition

Un modèle d’hôtes ou de services est une configuration prédéfinie d’hôtes ou de services. Il sert de base à la création des hôtes ou des services en définissant des valeurs par défaut pour leurs attributs. Dans un paradigme Objet, les modèles sont l’équivalent des classes, les hôtes et les services l’équivalent des instances.

L’objectif des modèles est d’éviter les redondances et d’accélérer la création des hôtes et services similaires. Leur utilisation permet une cohérence accrue des configurations. L’utilisation systématique des modèles fait partie des bonnes pratiques de configuration de Centreon.

Seul le nom d’un modèle est obligatoire. Les autres attributs peuvent être laissés vides ou par défaut. Il n’y a pas de contrôle de cohérence sur les modèles.

Principe d’héritage des modèles

Les hôtes et services héritent de leurs modèles. Les modèles peuvent également hériter d’autres modèles. L’héritage consiste à utiliser les attributs du modèle comme attributs par défaut de configuration. Les attributs peuvent toutefois être redéfinis au niveau de l’objet héritant. On parle alors de surcharge ou d’écrasement des attributs hérités.

Les attributs des modèles sont identiques à ceux des hôtes et services. La seule différence est la liaison avec les groupes d’hôtes ou de services, qui n’est pas possible sur les modèles (se référer à la configuration des hôtes et services dans ce chapitre).

Exemple d’arborescence d’héritage d’hôtes

1. Hôtes

Tous les attributs d’un hôte, excepté les liaisons avec les groupes d’hôtes, peuvent être hérités des modèles d’hôtes auxquels il est lié. Un champ laissé vide ou à la valeur Défaut prendra la valeur héritée, si elle existe.

La configuration des hôtes s’effectue via le menu Configuration - Hôtes. L’écran par défaut affiche la liste des hôtes configurés sur la plateforme.

Cette liste est filtrable par nom d’hôte (3 caractères minimum en recherche full-text), collecteur, groupe d’hôtes, modèle d’hôtes ou encore par état Activé ou Désactivé.

La configuration des attributs d’un hôte s’effectue à travers quatre onglets :

1. Services

Tous les attributs d’un service, excepté les liaisons avec les groupes de services, peuvent être hérités du modèle de services lié. Un champ laissé vide ou à la valeur Défaut prendra la valeur héritée, si elle existe.

La configuration des services se déroule dans Configuration - Services :

Cette liste est filtrable par nom d’hôte et de service (3 caractères minimum en recherche full-text), modèle de services et statut Activé ou Désactivé.

1. Spécificités de configuration des services passifs

Les ressources supervisées de manière passive possèdent plusieurs spécificités dans Centreon :

Ces paramètres sont précisés au niveau des interfaces de configuration des services. 

Configuration standard d’un service passif

Les services passifs ont typiquement la configuration présentée dans le tableau ci-dessous, saisis à travers les écrans de configuration des services.

La commande App-Monitoring-Centreon-Service-Dummy ne sera appelée que si aucune alerte passive n’est reçue pendant 24 heures, durée définie via le seuil de fraîcheur du résultat. Le service retrouvera alors automatiquement un état OK.

Par défaut, Centreon met à disposition un modèle de services qui fournit déjà ce paramétrage : generic-passive-service-custom.

2. Traps SNMP

Le protocole SNMP propose un mécanisme d’envoi d’alertes appelées traps. Les traps SNMP sont envoyés par l’élément en alerte vers le serveur de supervision.

Un trap SNMP est défini par un identifiant unique pour l’ensemble des constructeurs, appelé OID....