NexTool Solutions

Grafana n'apporte de la valeur que lorsque les tableaux de bord répondent aux questions de ceux qui opèrent et de ceux qui décident. Dans le support de GLPI et d'infrastructure que nous assurons pour des clients B2B, c'est la couche de visualisation que nous plaçons à côté du service desk : elle lit les métriques de SLA et de tickets directement dans la base de données de GLPI, les croise avec des séries de disponibilité venant de Zabbix ou Prometheus et affiche le tout sur un écran que le NOC et la direction peuvent interpréter sans exporter de tableur.

Comment nous positionnons Grafana à côté de GLPI

L'architecture que nous utilisons est délibérément légère : un conteneur Grafana sur le même hôte qui exécute déjà GLPI, derrière le même reverse proxy avec TLS, consommant trois sources de données distinctes. La première est le MariaDB/MySQL de GLPI lui-même, via un utilisateur en lecture seule, pour les indicateurs de service desk (tickets ouverts, SLA dépassé, temps moyen de réponse). La deuxième est Zabbix ou Prometheus, pour la disponibilité et la capacité de l'infrastructure. La troisième, lorsque le client dispose du plugin NexTool, ce sont les métriques de synchronisation et d'intégration que l'écosystème expose.

L'erreur courante que nous voyons chez ceux qui montent cela seuls est de pointer Grafana vers l'utilisateur administratif de GLPI. Nous ne le faisons jamais. Un tableau de bord n'a besoin que de lire, et une source de données compromise ne doit pas devenir une porte d'écriture dans la base de production. Nous créons un utilisateur dédié avec SELECT restreint aux tables concernées, et Grafana ne reçoit jamais plus de droits que nécessaire pour tracer un graphique.

Artefact : utilisateur en lecture seule et source de données

Voici le couple que nous provisionnons à chaque déploiement. D'abord l'utilisateur de lecture sur la base de GLPI, avec privilège minimal :

-- utilisateur en lecture seule pour que Grafana lise GLPI
CREATE USER 'grafana_ro'@'%' IDENTIFIED BY '${MOT_DE_PASSE_FORT}';
GRANT SELECT ON glpi.glpi_tickets           TO 'grafana_ro'@'%';
GRANT SELECT ON glpi.glpi_slas              TO 'grafana_ro'@'%';
GRANT SELECT ON glpi.glpi_tickets_users     TO 'grafana_ro'@'%';
GRANT SELECT ON glpi.glpi_itilcategories    TO 'grafana_ro'@'%';
FLUSH PRIVILEGES;
-- pas de GRANT ALL : le tableau de bord ne fait que dessiner, jamais ecrire

Et le provisionnement de la source de données par fichier, pour que le tableau de bord démarre versionné avec le conteneur et ne dépende pas d'un clic manuel dans l'interface :

# /etc/grafana/provisioning/datasources/glpi.yaml
apiVersion: 1
datasources:
  - name: GLPI (lecture seule)
    type: mysql
    access: proxy
    url: glpidb:3306
    database: glpi
    user: grafana_ro
    secureJsonData:
      password: ${MOT_DE_PASSE_FORT}   # injecte par variable d'environnement
    jsonData:
      maxOpenConns: 5                  # n'etouffe pas la base de production
      timeInterval: "1m"

Requête réelle : SLA dépassé par catégorie

Un tableau de bord exécutif que nous livrons systématiquement est celui des tickets dont le SLA de résolution est échu, regroupés par catégorie. C'est la vue que la direction ouvre le lundi matin. La requête s'exécute directement sur GLPI, en respectant le format de série temporelle attendu par Grafana :

SELECT
  c.completename                             AS categorie,
  COUNT(*)                                   AS tickets_depasses
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.status NOT IN (5, 6)                 -- exclut resolu et clos
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()             -- l'echeance de resolution est passee
  AND t.is_deleted = 0
GROUP BY c.completename
ORDER BY tickets_depasses DESC;

Un détail que seuls ceux qui opèrent GLPI connaissent : les statuts 5 et 6 correspondent à résolu et clos dans le schéma par défaut, et is_deleted = 0 est obligatoire parce que GLPI pratique la suppression logique - ignorer cette colonne gonfle le chiffre avec des tickets déjà à la corbeille. En support, nous avons déjà vu un tableau de bord tiers rapporter le double de SLA dépassé simplement en oubliant is_deleted. C'est le genre de bug qui mine la confiance de la direction dans tout le tableau de bord.

Tableau de bord par audience : ce que nous séparons

Nous ne mélangeons pas le NOC et la direction sur le même écran. L'opération a besoin de granularité pour agir maintenant ; la direction a besoin de tendance pour décider. La séparation que nous standardisons :

Alertes : où déclencher sans dupliquer

La règle que nous appliquons est simple et évite le pire problème d'observabilité : le même événement alertant par deux voies. La disponibilité et la capacité de l'infrastructure alertent à la source (Zabbix ou Prometheus), qui détient déjà l'historique et le contexte de l'hôte. Grafana n'alerte que sur des indicateurs métier qui n'existent que dans le croisement des sources - par exemple, le SLA d'un contrat précis sur le point d'être dépassé. Chaque tableau de bord que nous livrons porte, dans sa description, la définition de la métrique et l'action attendue en cas d'écart. Un tableau sans cette documentation devient une décoration, et personne ne regarde une décoration.

Autre point de support : nous plafonnons maxOpenConns sur la source de données précisément parce qu'un tableau de bord exécutif avec un rafraîchissement agressif et plusieurs requêtes lourdes peut ouvrir trop de connexions et concurrencer le GLPI de production. Nous avons déjà corrigé une lenteur de tickets que l'équipe imputait à GLPI et qui était, en réalité, un Grafana mal configuré épuisant le pool de connexions de la base.

Lorsque le client utilise le plugin NexTool, nous exposons aussi sur le même tableau de bord les métriques de synchronisation des modules - statut d'intégration, files de webhook et santé des jobs - de sorte que l'opération du service desk et la santé de l'écosystème se lisent au même endroit, sans changer d'outil.

Si votre opération GLPI dépend encore de l'export d'un tableur pour savoir où en est le SLA, NexTool déploie et maintient cette couche d'observabilité à côté de votre service desk, avec des tableaux de bord déjà intégrés à GLPI et à votre infrastructure. Parlez-nous du support GLPI avec observabilité intégrée.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.