Forum GLPI-Project

mrdje

Member

Registered: 2016-05-02

Posts: 40

Bug acquittements GLPI Monitoring

Bonjour!

GLPI 0.90.3 et plugin monitoring +1.1

Il semble que les acquittements ne fonctionnent pas très bien (ah moins que je n'ai pas compris le principe) sur le plugin monitoring :-(

Lorsque je créé un acquittement pour un service il apparait convenablement et semble fonctionner mais au bout de quelques minutes il ne fonctionne simplement plus... Le service repasse dans son etat d'erreur et je recommence a recevoir les notifications (c'est surtout ce point qui est horrible).

Que je n'indique pas de date de fin ou que je mettes une date de fin très éloignée le resultat est toujours le meme, au bout de quelques minutes l'acquittement "saute". il existe toujours mais n'est pas effectif :-/

De plus sur la vue "ressources" si je clique sur un acquittement il ne me redirige pas vers l'acquittement en question mais vers la page de creation d'un acquittement vierge.

Du coup je suis obligé de désactiver les notifications mail (que j'ai eu bien du mal à configurer) le temps de trouver une solution :-/

mrdje

Member

Registered: 2016-05-02

Posts: 40

Re: Bug acquittements GLPI Monitoring

Est-ce que j'ai dit une betise? Je suis le seul à avoir ce probleme? :-(

keyser75

Member

Registered: 2016-05-02

Posts: 50

Re: Bug acquittements GLPI Monitoring

Généralement j'utilise la WebUI de Shinken pour gérer mes sondes (et parce que j'utilise pnp4nagios pour les graphes).

Du coup, là, j'ai testé via l'interface GLPI. J'ai "créé" un acquittement pour une sonde en erreur.
Je retrouve tes comportements :
Dans la vue ressources, le champ correspondant à ma sonde apparait bien en acquittement mais le statut repasse en critique quelques secondes après.
J'ai mis sans/avec date de fin, épinglé, persistant.

Rien dans le log glpi "sql-errors.log" mais dans php-errors.log j'ai ceci :

2016-06-15 16:01:12 [19@xxxxxxxx]
  *** PHP Notice(8): Undefined index: id
  Backtrace :
  inc/commondbtm.class.php:2153
  plugins/monitoring/inc/acknowledge.class.php:585   CommonDBTM->showFormHeader()
  plugins/monitoring/front/acknowledge.form.php:69   PluginMonitoringAcknowledge->showForm()

Dans les logs Shinken je voie bien l'acquittement.
arbiter.log :

[Wed Jun 15 16:00:43 2016] EXTERNAL COMMAND: [1465999243] ACKNOWLEDGE_SVC_PROBLEM;XXXXXXX;NTP;1;1;1;XXXXXX;TEST

et une erreur dans le scheduler.log :

[Wed Jun 15 16:00:43 2016] WARNING: [Shinken] A command was received for service 'NTP' on host 'XXXXXXX', but the service could not be found!

La redirection vers l'acquittement me renvoie aussi vers un formulaire vierge.
J'ai l'impression que la requête est exécutée deux fois dont la dernière "vide". Le debug me donne deux requête qaund je clique sur la redirection d'acquittement :

SELECT `glpi_plugin_monitoring_acknowledges`.*
FROM `glpi_plugin_monitoring_acknowledges`
WHERE `glpi_plugin_monitoring_acknowledges`.`itemtype` = 'PluginMonitoringService' AND `glpi_plugin_monitoring_acknowledges`.`items_id` = '8' AND `expired` = '0' LIMIT 1 

SELECT `glpi_plugin_monitoring_acknowledges`.*
FROM `glpi_plugin_monitoring_acknowledges`
WHERE `glpi_plugin_monitoring_acknowledges`.`itemtype` = 'PluginMonitoringHost' AND `glpi_plugin_monitoring_acknowledges`.`items_id` = '-1' AND `expired` = '0' LIMIT 1

---

(GLPI 9.1.6 / FusionInventory 9.1+1.1)

mrdje

Member

Registered: 2016-05-02

Posts: 40

Re: Bug acquittements GLPI Monitoring

J'avais pensé gerer les acquittements dans shinken directement... Le truc c'est qu'on à déjà un nagios configuré et fonctionnel mais j'aimais bien l'idée de centraliser notre gestion d"inventaire avec le monitoring sur le meme outil, si je dois passer par Shinken ca enleve tout l'avantage de la chose :-(

Je ne suis pas un pro de linux donc j'ai encore du mal avec les différents logs (entre MySQL/apache/Glpi et tous les logs shinken c'est dur de trouver ou chercher)

Ceci dit je viens de remarquer, le raccourci sur le service d'acquittement mène vers "http://xxxxxxxxxxxx/plugins/monitoring/front/acknowledge.form.php?itemtype=Service&items_id=587" alors que le raccourci pour accéder à l'acquittement est "http://xxxxxxxxxxxx/plugins/monitoring/front/acknowledge.form.php?id=22"

En cherchant un peu j'ai découvert que le "587" de l'"items_id" correspond au champ "ressource" qu'on peut trouver dans le detail du service sur la fiche du serveur...

Autre chose, je viens de créer des acquittements depuis la page "Etat des machines", il créé directement les acquittements pour tous les services de l'hote sélectionné....... Et certains de ces acquittements ne disparaissent pas!

Je vais voir si je trouve un denominateur commun à tout ca

EDIT: ah ben non en fait, les acquittement sont aussi disparus, ca à juste été bcp plus long que d'habitude...

Last edited by mrdje (2016-06-15 17:36:17)

keyser75

Member

Registered: 2016-05-02

Posts: 50

Re: Bug acquittements GLPI Monitoring

Je ferai un test demain avec l'acquittement d'un host et vérifierai les logs shinken.

---

(GLPI 9.1.6 / FusionInventory 9.1+1.1)

mrdje

Member

Registered: 2016-05-02

Posts: 40

Re: Bug acquittements GLPI Monitoring

Donc comme j'ai dit hier, acquitter un host génère aussi le probleme, c'est juste bcp plus long!

PAR CONTRE je me suis dit ce matin, je vais acquitter directement dans Shinken comme ca je pourrais continuer a travailler sur le monitoring des serveurs linux.... Eh bien j'ai exactement le meme probleme! Lorsque l'on va sur un service en erreur et que l'on selectionne "set ok", quelques secondes plus tard il se remet en erreur!

Le probleme pourrait venir de Shinken, je vais etudier cette possibilité...

keyser75

Member

Registered: 2016-05-02

Posts: 50

Re: Bug acquittements GLPI Monitoring

Je n'ai pas tester encore les hosts mais pour mon service, en l'acquittant dans Shinken, il le reste. Et il s'affiche ainsi dans GLPI.

Cette fois-ci, dans ce sens, je n'ai pas d'erreur dans les logs Shinken :
schedulerd.log

[Thu Jun 16 10:07:46 2016] SERVICE NOTIFICATION: xxx;xxxxxxxxxx;ntp;ACKNOWLEDGEMENT (CRITICAL);pm-detailled-service-by-email;NTP CRITICAL: No response from NTP server

brokerd.log

[Thu Jun 16 10:07:44 2016] INFO: [broker-master] [WebUI-actions] got command: ACKNOWLEDGE_SVC_PROBLEM with args: ['xxxxxxxxxx', 'ntp', '2', '1', '1', 'admin', 'Acknowledged from WebUI by admin.'].
[Thu Jun 16 10:07:44 2016] INFO: [broker-master] [WebUI-actions] external command: [1466064464] ACKNOWLEDGE_SVC_PROBLEM;xxxxxxxxxx;ntp;2;1;1;admin;Acknowledged from WebUI by admin.

arbiterd.log

[Thu Jun 16 09:00:00 2016] TIMEPERIOD TRANSITION: workhours;0;1
[Thu Jun 16 10:07:45 2016] EXTERNAL COMMAND: [1466064464] ACKNOWLEDGE_SVC_PROBLEM;xxxxxxxxxx;ntp;2;1;1;admin;Acknowledged from WebUI by admin.

Je vais voir avec un host.

---

(GLPI 9.1.6 / FusionInventory 9.1+1.1)

mrdje

Member

Registered: 2016-05-02

Posts: 40

Re: Bug acquittements GLPI Monitoring

Oui mais il y a une feinte

Dans shinken lorsque tu as un service en erreur tu mets "acknowledge" et effectivement il se met en acquittement de maniere tt à fait normale, et apparaît comme tel dans glpi!

Le hic c'est que glpi monitoring utilise il me semble une commande "check_dummy" pour forcer le service en "up", se qui correspond en fait dans shinken à l'option "set ok" et non a la commande "acknowledge"!

Cette fameuse option "set ok" à exactement le meme comportement dans Shinken que l'acquittement Glpi, cad que le service repasse en erreur quelques secondes après...

Y a t'il moyen de modifier la commande utilisée par Glpi monitoring pour l'acquittement?

mrdje

Member

Registered: 2016-05-02

Posts: 40

Re: Bug acquittements GLPI Monitoring

A noter d'ailleurs que l'acquittement Shinken "acknowledge" est remis à zéro à chaque redemarrage de Shinken :-/

En gros à chaque fois qu'on modifie une commande ou qu'une machine est ajoutée au catalogue de supervision on recoit toutes les notifications des services en erreur et il faut tous les ré-acquitter :-(

keyser75

Member

Registered: 2016-05-02

Posts: 50

Re: Bug acquittements GLPI Monitoring

A noter d'ailleurs que l'acquittement Shinken "acknowledge" est remis à zéro à chaque redemarrage de Shinken :-/

En gros à chaque fois qu'on modifie une commande ou qu'une machine est ajoutée au catalogue de supervision on recoit toutes les notifications des services en erreur et il faut tous les ré-acquitter :-(

Oui à chaque rechargement de l'arbiter, il relance une vérification de toutes les sondes. Mais bon ça je suis habitué, je fais un redémarrage de shinken chaque nuit.

---

(GLPI 9.1.6 / FusionInventory 9.1+1.1)

mrdje

Member

Registered: 2016-05-02

Posts: 40

Re: Bug acquittements GLPI Monitoring

J'ai trouvé une parade!

Pour les services en erreur (des disques durs full pour moi) sur la fiche de l'ordinateur on peut indiquer des paramétrages personnalisés de commande qui prendront le dessus sur les paramétrages par defaut (onglet ressources)

Pour les services en warning j'ai indiqué des valeurs bien supérieures (W99 et C100 pour le contrôle de disque dur par exemple) aux valeurs par défaut, ca règle mon problème et je n'ai plus à remettre tout le temps les services en acquitté dans Shinken à chaque redémarrage!

PS: Ceci dit un système d'acquittement fonctionnel ca serait plus pratique

keyser75

Member

Registered: 2016-05-02

Posts: 50

Re: Bug acquittements GLPI Monitoring

Bonjour,

Pour reprendre la partie acquittement, j'ai trouvé une solution.
L'acquittement GLPI --> Shinken ne fonctionnait effectivement pas alors que dans le sens Shinken --> GLPI cela fonctionnait.
En fait je me suis aperçu dans les logs de l'arbiter que mes hôtes n'étaient pas reconnus dans Shinken (alors qu'ils sont importés et fonctionnels).

EXTERNAL COMMAND: [1484831101] SCHEDULE_SVC_DOWNTIME;<SERVEUR>;Dns;1484831064;1484838000;1;0;14400;<USER>;
WARNING: [Shinken] Passive check result was received for host '<SERVEUR>', but the host could not be found!

En fait il semble que l'import vers Shinken mette en minuscule les serveurs. Alors que dans GLPI, les hostnames peuvent être en majuscule selon la remontée d'inventaire, notamment pour les Windows.
En forçant un nom en minuscule, la communication se fait. Et les périodes de Downtime et Aknowledgement sont bien transmises à Shinken.
Comme je suis sous Linux, la casse doit poser problème.
Plutôt que de forcer mes noms de machine en minuscule sous GLPI (script / trigger / règle), j'ai modifié la requête d'envoi via le webservice des données à Shinken.

Dans ./monitoring/inc/shinkenwebservice.class.php modifier pour les deux fonctions la variable $hostname qui est stockée dans le tableau $a_fields et forcer son contenu en minuscule.
Les deux fonctions sont sendAknowledge et sendDonwtime :

$a_fields = array(
          'action'               => empty($operation) ? 'add' : $operation,
//         'host_name'            => $hostname,
           'host_name'            => strtolower($hostname),

Concernant le recheck complet, et la perte des acquittements, il faut installer un module de rétention qui conserve en base les status des contrôles.
Ainsi en cas de redémarrage, Shinken ne repart pas avec toutes les sondes en PENDING. J'utilise mod-retention-mongodb.

---

(GLPI 9.1.6 / FusionInventory 9.1+1.1)