NexTool Solutions

Grafana porta valore solo quando i pannelli rispondono alle domande di chi opera e di chi decide. Nel supporto di GLPI e infrastruttura che offriamo a clienti B2B, è lo strato di visualizzazione che collochiamo accanto al service desk: legge le metriche di SLA e ticket direttamente dal database di GLPI, le incrocia con serie di disponibilità provenienti da Zabbix o Prometheus e mostra tutto in una schermata che il NOC e la dirigenza possono interpretare senza esportare un foglio di calcolo.

Come posizioniamo Grafana accanto a GLPI

L'architettura che usiamo è volutamente snella: un contenitore Grafana sullo stesso host che già esegue GLPI, dietro lo stesso reverse proxy con TLS, che consuma tre origini dati distinte. La prima è lo stesso MariaDB/MySQL di GLPI, tramite un utente in sola lettura, per gli indicatori di service desk (ticket aperti, SLA violato, tempo medio di risposta). La seconda è Zabbix o Prometheus, per disponibilità e capacità dell'infrastruttura. La terza, quando il cliente ha il plugin NexTool, sono le metriche di sincronizzazione e integrazione che l'ecosistema espone.

L'errore comune che vediamo in chi lo monta da solo è puntare Grafana all'utente amministrativo di GLPI. Non lo facciamo mai. Un pannello deve solo leggere, e un'origine dati compromessa non può diventare una porta di scrittura sul database di produzione. Creiamo un utente dedicato con SELECT limitato alle tabelle di interesse, e Grafana non riceve mai più permessi di quanti gliene servano per disegnare un grafico.

Artefatto: utente in sola lettura e origine dati

Questa è la coppia che predisponiamo in ogni implementazione. Prima l'utente di lettura sul database di GLPI, con privilegio minimo:

-- utente in sola lettura affinche Grafana legga GLPI
CREATE USER 'grafana_ro'@'%' IDENTIFIED BY '${PASSWORD_FORTE}';
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;
-- niente GRANT ALL: il pannello disegna soltanto, non scrive mai

E il provisioning dell'origine dati tramite file, affinché il pannello si avvii versionato insieme al contenitore e non dipenda da un clic manuale nell'interfaccia:

# /etc/grafana/provisioning/datasources/glpi.yaml
apiVersion: 1
datasources:
  - name: GLPI (sola lettura)
    type: mysql
    access: proxy
    url: glpidb:3306
    database: glpi
    user: grafana_ro
    secureJsonData:
      password: ${PASSWORD_FORTE}   # iniettata da variabile d'ambiente
    jsonData:
      maxOpenConns: 5               # non soffoca il database di produzione
      timeInterval: "1m"

Query reale: SLA violato per categoria

Un pannello esecutivo che consegniamo sempre è quello dei ticket con SLA di risoluzione scaduto, raggruppati per categoria. È la vista che la dirigenza apre il lunedì mattina. La query gira direttamente su GLPI, rispettando il formato di serie temporale che Grafana si aspetta:

SELECT
  c.completename                             AS categoria,
  COUNT(*)                                   AS ticket_violati
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.status NOT IN (5, 6)                 -- esclude risolto e chiuso
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()             -- la scadenza di risoluzione e passata
  AND t.is_deleted = 0
GROUP BY c.completename
ORDER BY ticket_violati DESC;

Un dettaglio che conosce solo chi opera GLPI: gli stati 5 e 6 sono risolto e chiuso nello schema predefinito, e is_deleted = 0 è obbligatorio perché GLPI usa la cancellazione logica - ignorare quella colonna gonfia il numero con ticket già nel cestino. Nel supporto abbiamo già visto un pannello di terzi riportare il doppio di SLA violato solo per aver dimenticato is_deleted. È il tipo di bug che mina la fiducia della dirigenza nell'intera dashboard.

Dashboard per pubblico: ciò che separiamo

Non mescoliamo NOC e dirigenza sulla stessa schermata. L'operatività ha bisogno di granularità per agire subito; la dirigenza ha bisogno di tendenza per decidere. La separazione che standardizziamo:

Avvisi: dove innescare senza duplicare

La regola che applichiamo è semplice ed evita il peggior problema di osservabilità: lo stesso evento che avvisa attraverso due percorsi. Disponibilità e capacità dell'infrastruttura avvisano alla fonte (Zabbix o Prometheus), che possiede già lo storico e il contesto dell'host. Grafana avvisa solo su indicatori di business che esistono unicamente nell'incrocio delle fonti - per esempio, lo SLA di un contratto specifico prossimo alla violazione. Ogni pannello che consegniamo porta, nella sua descrizione, la definizione della metrica e l'azione attesa in caso di scostamento. Un pannello senza quella documentazione diventa decorazione, e nessuno guarda una decorazione.

Altro punto di supporto: limitiamo maxOpenConns sull'origine dati proprio perché una dashboard esecutiva con aggiornamento aggressivo e diverse query pesanti può aprire troppe connessioni e competere con il GLPI di produzione. Abbiamo già corretto una lentezza dei ticket che il team attribuiva a GLPI ed era, in realtà, un Grafana mal configurato che esauriva il pool di connessioni del database.

Quando il cliente usa il plugin NexTool, esponiamo anche sulla stessa dashboard le metriche di sincronizzazione dei moduli - stato di integrazione, code dei webhook e salute dei job - in modo che l'operatività del service desk e la salute dell'ecosistema si leggano nello stesso posto, senza cambiare strumento.

Se la tua operatività GLPI dipende ancora dall'esportazione di un foglio di calcolo per sapere come va lo SLA, NexTool implementa e mantiene questo strato di osservabilità accanto al tuo service desk, con le dashboard già integrate con GLPI e la tua infrastruttura. Parla con noi di supporto GLPI con osservabilità integrata.

Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team di Nextool Solutions.