ETL¶

Modes d’exécution¶

La base de données de reporging ou « Data Warehouse » est mise à jour tous les jours avec les données agrégées par l’ETL. En fonction de la taille du périmètre supervisé, cela peut représenter de quelques milliers à plusieurs millions de lignes par jour. De ce fait, la base de données de reporting et l’ETL sont deux composants critiques de Centreon MBI que vous devez comprendre. Deux modes de fonctionnement sont disponibles pour l’ETL:

• Daily mode ou mode journalier : C’est le fonctionnement normal de l’ETL lorsque la plateforme de reporting est en place. Les données de Centreon sont importées tous les jours, de manière différentielle. Plus précisemment:

• les données de la table “data_bin” de la veille sont importées et les calculs ne se font que sur ces données
• toutes les données des tables servicestatevents et hoststateevents sont importées mais les calculs se font de manière différentiels

Elles sont ensuite agrégées puis insérées dans le datawarehouse. Cela peut prendre de quelques secondes à quelques minutes en fonction du périmètre de monitoring.

Le mode journalier est configuré comme un cron que vous pouvez consulter dans /etc/cron.d/centreon-bi-engine:

#30 4 * * * root /usr/share/centreon-bi//etl/centreonBIETL --daily >> /var/log/centreon-bi/centreonBIETL.log 2>&1

• Rebuild mode ou mode de reconstruction: C’est le mode souvent utilisé après l’installation de la plateforme de reporting, en cas de corruption des données. Ce mode permet d’importer les données brutes de Centreon et de recalculer toutes les statistiques sur une période donnée ou en utilisant les paramètres de rétention.

Exemple:

/usr/share/centreon-bi/bin/centreonBIETL -r

Afin d’obtenir des temps d’exécution raisonnables, la configuration matérielle, l’espace de stockage disponible et les optimisations MySQL doivent avoir été bien positionnés lors de l’installation.

Toutes les recommandations matérielles, logicielles et d’optimisations peuvent être trouvées sur le site de documentation.

Performance¶

Si les traitements de l’ETL vous semblent anormalement long, en mode journalier ou en mode reconstruction, veillez à optimiser votre serveur de reporting. Cela peut être fait en :

• améliorant la configuration MySQL
• s’assurant que les disk performance (pas d’I/O wait par exemple)
• ajouant de la mémoire physique (+ optimisation MySQL)
• veillant à ne pas mutualiser la base de données ni le stockage

Options d’exécution¶

Différentes options peuvent être passées en paramètre de l’ETL afin de lancer des actions spécifiques d’import ou de reconstruction:

-c  Create the reporting database model
-d  Daily execution to calculate statistics on yesterday
-r  Rebuild mode to calculate statitics on a historical period. Can be used with:
    Extra arguments for options -d and -r (if none of the following is specified, these one are selected by default: -IDEP):
-I  Extract data from the monitoring server
    Extra arguments for option -I:
    -C  Extract only Centreon configuration database only. Works with option -I.
    -i  Ignore perfdata extraction from monitoring server
    -o  Extract only perfdata from monitoring server

-D  Calculate dimensions
-E  Calculate event and availability statistics
-P  Calculate perfdata statistics
    Common options for -rIDEP:
    -s  Start date in format YYYY-MM-DD.
        By default, the program uses the data retention period from Centreon MBI configuration
    -e  End date in format YYYY-MM-DD.
        By default, the program uses the data retention period from Centreon MBI configuration
    -p  Do not empty statistic tables, delete only entries for the processed period.
        Does not work on raw data tables, only on Centreon MBI statistics tables.

Si les paramètres “start” et “end” ne sont pas précisés, les dates de début et fin pour chaque étapes sont automatiquement calculées en fonction de la rétention des données paramétrées dans les options générales de l’ETL.

Gestion de l’historique des changements¶

Centreon MBI enregistre chaque changement qui concernent les relations entre les hôtes, les services, les groupes et les catégories.

Par exemple :

• Un hôte « H1 » appartient à un groupe d’hôtes « G1 » en janvier 2012
• L’hôte « H1 » n’appartient plus au groupe « G1 » le 1er février 2012
• Après ce changement, si un rapport est généré pour le groupe « G1 » sur la période de reporting de janvier 2012, les statistiques de l’hôte « H1 » seront prises en compte dans les statistiques du groupe « G1 »
• Les statistiques de l’hôte « H1 » ne seront pas prises en compte pour le groupe « G1 » si la période de rapport sélectionnée est février 2012
• Si la période de rapport démarre le 15 janvier et finit le 15 février, les statistiques de l’hôte « H1 » seront intégrées à celle du groupe « G1 » seulement du 15 janvier au 31 janvier

La configuration initiale de Centreon et la relation entre les objets doit être clairement définie avant l’installation de Centreon MBI sur une plate-forme de production. Chaque modification de configuration d’un hôte, groupe ou catégorie est considérée comme une évolution normale dans le cycle de vie du composant.

Purge automatique des données¶

Une purge des données peut être activée dans les options générales Centreon MBI afin de s’assurer que le contenu de la base de reporting respecte bien la configuration de la rétention. Ce mécanisme doit être activé dans l’interface ET au niveau du cron /etc/cron.d/centreon-bi-purge .

Les dimensions de reporting (combinaisons groupes / catégories host / services / metrics) sont automatiquement supprimées de la base si plus aucune données n’est lié à la combinaison en question.

Centile¶

Pour être en mesure d’utiliser le rapport “Monthly Network Percentile” vous devez activer le calcul et le stockage des centiles.

Pour cela, rendez vous sur la page Reporting > Business Intelligence > General Options | ETL Tab et configurez la section “Centile Parameters” comme décrit ci-dessous. Le combinaison centile/timeperiod est donnée à titre d’exemple, n’hésitez pas à créer votre/vos propres combinaisons. Si vous n’êtes pas intéressé par ce rapport, laissez les valeurs par défaut.

Exemple :

Seules les categories de services sélectionnées dans la partie “Reporting perimeter selection” apparaîtront dans les catégories de services disponibles pour les statistiques de centile.

Vous pouvez créer autant de combinaison que vous souhaitez mais il faut savoir que l’impact sur les temps de traitements est fort. A titre d’exemple, l’agrégation au mois de ces statistiques peut prendre de quelques secondes à plusieurs dizaines de minutes.

Commencez par configurer les centiles sur un petit perimètre puis étendez le au fur et à mesure si les temps de calculs ne deviennent pas problématiques. (peut prendre de quelques secondes à plusieurs dizaine de minutes).

Sur le serveur de reporting, executez la commande suivante pour importer les données de configuration:

/usr/share/centreon-bi/bin/centreonBIETL -rIC

Ensuite, exécutez la commande suivante pour intégrer la configuration des centiles dans le datawarehouse:

/usr/share/centreon-bi/etl/dimensionsBuilder.pl -d

Enfin, exécutez la commande suivante afin de calculer les statistiques (cela peut prendre de quelques secondes à plusieurs dizaines de minutes selon votre configuration):

/usr/share/centreon-bi/etl/perfdataStatisticsBuilder.pl -r --centile-only

Comment appliquer la dernière configuration Centreon aux données de reporting ?¶

En période de mise en place de reporting, il est normal d’avoir à relancer les calculs des statistiques relativement souvent puisque la configuration dans Centreon est amenée à changer. Une fois le travail de groupement / catégorisation terminé, lancer les commandes suivantes sur le serveur de REPORTING, de préférence le matin (cela peut prendre plusieurs heures). Cette procédure n’inclut pas la reprise des données de logs et de métrologie brutes, assurez vous que les données provenant de Centreon sont à jour. Pour cela, exécutez la commande suivante::

#/usr/share/centreon-bi/etl/centreonbiMonitoring.pl --db-content

Et vérifiez que le message “ETL OK - Database is up to date” apparaît ou qu’aucune de ces tables n’apparaît dans la liste :

• data_bin
• hoststatevents
• servicestateevents

Les commandes d’agrégation proposées ci-dessous sont lancées sans précision de date de début et fin, le calcul se basera alors sur la rétention configurée dans Centreon MBI. Si vous êtes en période d’installation/test de Centreon MBI, vous pouvez modifier cette rétention AVANT le traitement pour la diminuer puis de la remettre par défaut (365 jours) APRES le traitement. Les calculs seront de ce fait plus rapides.

Se rendre à la page : Reporting > Business Intelligence > General Option | Onglet Data Retention Options

#/usr/share/centreon-bi/etl/importData.pl -r --centreon-only

#/usr/share/centreon-bi/etl/dimensionsBuilder.pl -r

#nohup /usr/share/centreon-bi/etl/eventStatisticsBuilder.pl -r > /var/log/centreon-bi/rebuildAllEvents.log &

#nohup /usr/share/centreon-bi/etl/perfdataStatisticsBuilder.pl -r > /var/log/centreon-bi/rebuildAllPerf.log &

Comment reprendre partiellement les données de reporting ?¶

Cette procédure vous est utile lorsque le plugin de monitoring donnant l’état de la base de reporting vous remonte un état non-OK. Cela peut être dû à des problèmes rencontrés lors des traitements journaliers (données Centreon qui ne sont pas à jour, manque d’espace sur le serveur de reporting, traitements coupés manuellement etc..).

Dans ce cas, le plugin de reporting renvoie que la base de données n’est pas à jour. Exemple du retour du plugin lorsque la base de données n’est pas à jour :

#/usr/share/centreon-bi/etl/centreonbiMonitoring.pl --db-content

[Table mod_bam_reporting, last entry: 2015-07-01 00:00:00] [Table mod_bi_ba_incidents, last entry: 2015-07-01 00:00:00] [Table hoststateevents, last entry: 2015-07-01 00:00:00]
[Table servicestateevents, last entry: 2015-07-01 00:00:00] [Table mod_bi_hoststateevents, last entry: 2015-07-01 00:00:00]
[Table mod_bi_servicestateevents, last entry: 2015-07-01 00:00:00] [Table mod_bi_hostavailability, last entry: 2015-07-01 00:00:00]
[Table mod_bi_serviceavailability, last entry: 2015-07-01 00:00:00] [Table data_bin, last entry: 2015-08-01 00:00:00] [Table mod_bi_metricdailyvalue, last entry: 2015-08-01 00:00:00]
[Table mod_bi_metrichourlyvalue, last entry: 2015-08-01 23:00:00]

• Si vous ne voyez que les tables mod_bi_* cela signifie que le problème se situe uniquement sur les données agrégées et pas les données provenant de Centreon.

  Dans ce cas, ignorez la partie “Importer les données manquantes” dans la procédure qui suit.

• Si vous voyez également les tables ci dessous, cela signifie qu’il y a un problème avec les données importées de Centreon :

• hoststatevents
• servicestateevents
• Les tables mod_bam_reporting* tables
• data_bin

Dans ce cas, vous devez vous assurer qu’il n’y a pas de problème du côté Centreon avant d’éxécuter la procédure suivante. Dans ce cas, exécutez la procédure qui suit.

Centreon BAM¶

Si vous avez récemment mis à jour Centreon BAM en version 3.0 ou que vous venez de reconstruire les statistiques de BAM, vous devez ré-importer les données de BAM sur les serveur de reporting. Pour cela, exécutez la commande suivante :

/usr/share/centreon-bi/etl/importData.pl -r --bam-only

Cela aura pour effet de n’importer que les tables de reporting du module BAM.

/usr/share/centreon/www/modules/centreon-bam-server/engine/centreon-bam-rebuild-events --all