Bug dans Tactical Overview avec Centreon 2.3.9 et Centreon-broker
![broker](broker.png)
![bug-tactical01](bug-tactical01.png)
On remarque bien la différence entre la page Tactical Overview et la page Monitoring des services. Ce problème n'existe pas avec le broker NDOutils. J'ai donc regardé de plus près le code de Centreon. La requête SQL pour récupérer l'état des services se trouve dans le fichier /usr/local/centreon/www/include/home/tacticalOverview/xml/broker/tacticalOverviewXml.php. Dans notre exemple, la requête nous donnera ce résultat :
mysql> SELECT DISTINCT s.state,s.acknowledged,s.scheduled_downtime_depth FROM services s, hosts h WHERE h.host_id = s.host_id AND (s.acknowledged = 1 OR s.scheduled_downtime_depth > 0) AND s.enabled = 1 AND s.state_type = 1 AND h.name NOT LIKE '_Module_%' ;
+-------+--------------+--------------------------+
| state | acknowledged | scheduled_downtime_depth |
+-------+--------------+--------------------------+
| 2 | 1 | 0 |
+-------+--------------+--------------------------+
1 row in set (0.00 sec)
La requête ne retourne qu'un seul enregistrement, car l'option DISTINCT est activée et le résultat est identique pour les trois services en défaut. Deux solutions sont possibles pour corriger l'erreur, soit de supprimer l'option DISTINCT, soit d'ajouter un champ ayant une valeur unique pour chaque enregistrement. J'ai préféré la deuxième solution pour garder une certaine cohérence du code en ajoutant le champ service_id de la table services dans la base Centstorage. Le résultat donne ceci :
mysql> SELECT DISTINCT s.state,s.acknowledged,s.service_id,s.scheduled_downtime_depth FROM services s, hosts h WHERE h.host_id = s.host_id AND (s.acknowledged = 1 OR s.scheduled_downtime_depth > 0) AND s.enabled = 1 AND s.state_type = 1 AND h.name NOT LIKE '_Module_%' ;
+-------+--------------+------------+--------------------------+
| state | acknowledged | service_id | scheduled_downtime_depth |
+-------+--------------+------------+--------------------------+
| 2 | 1 | 21 | 0 |
| 2 | 1 | 27 | 0 |
| 2 | 1 | 30 | 0 |
+-------+--------------+------------+--------------------------+
3 rows in set (0.00 sec)
La requête indique bien trois acquittements. Voici la modification sur le fichier /usr/local/centreon/www/include/home/tacticalOverview/xml/broker/tacticalOverviewXml.php :
/* * Get Service Acknowledgements and Downtimes OK(0), WARNING(1), CRITICAL(2), UNKNOWN(3) */ if (!$is_admin) { $rq1 = " SELECT DISTINCT s.state, " . " s.acknowledged, s.service_id, " . " s.scheduled_downtime_depth " . " FROM services s, centreon_acl, hosts h" . " WHERE h.host_id = s.host_id " . " AND (s.acknowledged = 1 OR " . " s.scheduled_downtime_depth > 0) " . " AND s.enabled = 1 " . " AND s.state_type = 1 ". " AND s.host_id = centreon_acl.host_id ". " AND s.service_id = centreon_acl.service_id " . " AND centreon_acl.group_id IN (".$acl_access_group_list.") " . " AND h.name NOT LIKE '_Module_%' "; } else { $rq1 = " SELECT DISTINCT s.state, " . " s.acknowledged, s.service_id, " . " s.scheduled_downtime_depth " . " FROM services s, hosts h" . " WHERE h.host_id = s.host_id " . " AND (s.acknowledged = 1 OR " . " s.scheduled_downtime_depth > 0) " . " AND s.enabled = 1 " . " AND s.state_type = 1 ". " AND h.name NOT LIKE '_Module_%' "; }Le fichier modifié, nous retournons vers notre interface graphique et nous constatons la bonne cohérence de l'état des services.
![bug-tactical02](bug-tactical02.png)
Pour info, l'équipe de Centreon a bien pris en compte ce problème. Il devrait être réglé lors d'une prochaine mise à jour, à priori la version 2.4
![Happy](../../rw_common/plugins/blog/smiley_smile.png)