Comment est géré l’interface dans centreon

Préambule

Quand j’ai commencé linux la première phrase qu’on peut lire dans la littérature consacrée est : « tout est dans un fichier ».

Pour la gestion de l’interface de centreon on peut dire « tout est en base » 😀

Il m’est arrivé d’avoir des données corrompues ,en arrivant chez mes clients, parce que des personnes, certainement plus intelligentes que les autres, ont crues bon d’écrire directement en base 😛

Il m’a paru donc important d’expliquer :

Comment est gérée l’interface
Comment sont affichés les éléments de configuration

Dans cette suite d’article nous verrons :

Le lien entre la base de données et l’affichage des menus dans l’interface
Comment centreon affiche les informations dans l’interface depuis les vues
Menu Monitoring
L’état des services avec application de filtres
Menu Configuration
Liste des hôtes avec les différents filtres disponibles
Liste des services avec les différents filtres

Les forces en présence

Les fichiers

Les fichiers de mise à disposition de l’interface à apache sont présents dans le répertoire /usr/share/centreon/www du serveur web

Au premier niveau nous avons ci-dessous les répertoires les plus importants :

include -> Code php pour afficher les différents menus
modules -> Les différents modules opensource ou non installés
widgets -> Code des widgets utilisés dans les customviews

Les bases de données

Tous les éléments permettant le bon fonctionnement de l’interface sont dans la database centreon. Donc on ne modifie rien dedans par une commande mysql, que ce soit par un insert, drop, update ou tout autre commande farfelue qui pour passer par la tête d’un illuminé.

On ne fait que des « select » et rien de plus.

J’espère que c’est écrit suffisamment gros pour que le message soit clair 😀

Database centreon-storage

Avant-propos

Il est important de comprendre que la database centreon_storage est la table du temps réel.

Toutes les données affichées dans la console en dehors des vues configuration et administration proviennent de cette database.

Il y a un lien entre les databases centreon et centeon_storage ce sont les ID pour :

Les hôtes
Les différents regroupements
Services
Hosts
Services

Donc tous les vues temps réel s’appuient sur cette database en utilisant la durée de rétention pour afficher l’historique dans les différentes vues.

La structure de la database est sensiblement identique à celle de centreon.

Pour faire un raccourci dans la database centreon les tables sont au singulier et dans centreon-storage au pluriel.

Ainsi par exemple les tables on peut faire les relations suivantes :

centreon	centreon_storage
acl_group_contactgroups_relations	centreon_acl
host	hosts
hostgroup	hostgroups
host_service_relation
host_template_relation
Hostcategories
hostcategories_relation
hostgroup_hg_relation
hostgroup_relation	hosts_hostgroups
dependency
dependency_hostChild_relation	hosts_hosts_dependencies
dependency_hostParent_relation
host_service_relation
host_hostparent_relation	hosts_hosts_parents
servicegroup	servicegroups
service	services
servicegroup_relation	services_servicegroups
dependency_serviceParent_relation	services_services_dependencies
dependency_serviceChild_relation
dependency_servicegroupChild_relation
dependency_servicegroupParent_relation
service_categories
service_categories_relation
nagios_server	instances

Nous pouvons noter que certaines tables n’existent pas dans cetreon_storage. Donc la console aura besoin des 2 databases pour afficher les informations dans la console.

Relation entres les tables d’hôtes

Convention

Le mot clé « distinct » sera utilisé dans les requêtes pour éviter les lignes en doublons

Les tables en présence

Tables	Description
host	Liste les hôtes et leur templates
host _categories	Liste les catégories d’hôtes
host _categories_relation	Relation entre les tables service et host_categories
hostgroup	Liste les groupes d’hôtes
hostgroup_relation	Relation entre les tables hostgroup et hostgroup_relation

Les hosts

Nous allons commencer par le début : Lister les hosts de la plateforme

Comme pour les services le champ register détermine si nous avons à faire à un template ou non.

Requête

SELECT host_name,
  host_alias,
  host_address
FROM centreon.host
WHERE host_register="1"
AND host_activate='1';

SELECT host_name,
  host_alias,
  host_address
FROM centreon.host
WHERE host_register="1"
AND host_activate='1';

Relation entres les tables de services

Convention

Le mot clé « distinct » sera utilisé dans les requêtes pour éviter les lignes en doublons

Les tables en présence

Table	Description
service	Liste les services et templates de services
service_categories	Liste les catégories de services
service_categories_relation	Relation entre les tables service et service_categories
Servicegroup	Liste les groupes de services
servicegroup_relation	Relation entre les tables servicegroup et servicegroup_relation

Les services

Le schéma

Préambule

Dans cette suite d’article nous allons regarder la structure des données de centreon.

But des articles

Nous allons voir :

Les différentes relations à l’intérieur des databases :
Les tables de centreon (Eléments de configuration)
Les tables centreon_storage (Historisation de la supervision)
Entre les databases :
Relation entre les tables de centreon et centreon_storage

Nous ne rentrerons pas dans le détail de toutes les tables mais nous nous intéresserons aux tables principales pour comprendre le fonctionnement de base de l’application.

Convention de nommage

Afin de faciliter la lecture des requêtes et d’éviter les ambiguïtés pour MySQL, pour les différentes jointures, nous utiliserons un trigramme en alias de la table.

Quelques exemples :

HTR : Host Template Relation
HST : hosts
HTPL : Host Template
HTR : Host Template Relation
SVC : Service
STR : Service Template Relation
STPL : Service Templates
…