NexTool Solutions

GLPI conserva tutto lo storico del service desk, ma i report nativi si fermano proprio dove il management inizia a chiedere "perché". Metabase e Grafana leggono lo stesso database MariaDB di GLPI e trasformano quello storico in dashboard - ma risolvono problemi diversi, e sbagliare scelta costa rilavorazione.

Cosa cambia quando colleghi un BI a GLPI

Prima di confrontare i due strumenti, bisogna capire che il database di GLPI non è stato progettato per il BI. Tre dettagli definiscono la maggior parte del lavoro su qualsiasi dashboard, sia in Metabase sia in Grafana:

• Stato, priorità e urgenza sono numeri, non testo. In glpi_tickets, la colonna status va da 1 (Nuovo) a 6 (Chiuso). Nessuno strumento lo sa da solo - se non traduci i codici, il gestore vede "status 2" sul grafico.
• Nulla viene cancellato davvero. GLPI usa la cancellazione logica: is_deleted = 1 marca il record come "nel cestino". Dimenticare il filtro is_deleted = 0 gonfia tutti i conteggi.
• È multi-entità. La colonna entities_id separa i dati per cliente o reparto. Una dashboard che il cliente vedrà deve filtrare il giusto sottoalbero di entità - e questo non è gratis in SQL puro.

Aggiungi un quarto punto, puramente operativo: puntare il BI direttamente al database di produzione, in orario lavorativo, con query che scorrono tutta la glpi_tickets in join con glpi_logs, è il modo più rapido per rallentare GLPI stesso. Ci torniamo più avanti.

Confronto diretto

Come connettersi senza far cadere GLPI

Indipendentemente dallo strumento, la connessione è la stessa: un utente di database in sola lettura, idealmente che punta a una replica o a una copia ripristinata di notte, mai al master di produzione con permesso di scrittura.

-- Utente in sola lettura per il BI (esegui sul MariaDB/MySQL di GLPI).
-- Punta, di preferenza, a una replica o a una copia ripristinata,
-- mai al master di produzione con permesso di scrittura.
CREATE USER 'bi_ro'@'10.0.0.%' IDENTIFIED BY '${PASSWORD_FORTE}';
GRANT SELECT ON glpi.* TO 'bi_ro'@'10.0.0.%';
FLUSH PRIVILEGES;

Con l'accesso pronto, il primo artefatto che risolve il problema dei "numeri grezzi" è una query che traduce i codici di stato. Vale per entrambi: in Metabase diventa una "Domanda SQL", in Grafana un pannello a tabella o a barre.

-- Ticket aperti per stato, con i codici tradotti.
-- In GLPI, glpi_tickets.status va da 1 a 6.
SELECT
  CASE status
    WHEN 1 THEN 'Nuovo'
    WHEN 2 THEN 'In corso (assegnato)'
    WHEN 3 THEN 'In corso (pianificato)'
    WHEN 4 THEN 'In attesa'
    WHEN 5 THEN 'Risolto'
    WHEN 6 THEN 'Chiuso'
  END AS stato,
  COUNT(*) AS totale
FROM glpi_tickets
WHERE is_deleted = 0          -- ignora il cestino (cancellazione logica)
  AND status IN (1, 2, 3, 4)  -- solo quelli ancora aperti
GROUP BY status
ORDER BY status;

In Metabase c'è una scorciatoia: invece del CASE, puoi mappare i valori della colonna direttamente nelle impostazioni del campo (1 in "Nuovo", 2 in "In corso" e così via), e l'etichetta compare automaticamente in ogni grafico. È un guadagno di produttività che Grafana non ha - lì il CASE è obbligatorio.

Grafana: la dashboard come codice

Il vantaggio di Grafana per chi gestisce molti ambienti non è a schermo, è su disco: sorgente dati e pannelli sono file versionabili. Provisioniamo la stessa dashboard su più clienti a partire da uno YAML e un JSON in Git, senza cliccare nulla.

# /etc/grafana/provisioning/datasources/glpi.yaml
# Sorgente dati versionabile: lo stesso file provisiona N ambienti.
apiVersion: 1
datasources:
  - name: GLPI-MariaDB
    type: mysql
    access: proxy
    url: mariadb.interno:3306
    database: glpi
    user: bi_ro
    jsonData:
      maxOpenConns: 5             # limita le connessioni: non soffocare GLPI
      timezone: America/Sao_Paulo
    secureJsonData:
      password: ${GLPI_BI_PASSWORD}

L'altro elemento distintivo è il tempo. Grafana capisce le serie temporali in modo nativo: con le macro $__timeFilter e $__timeGroup, il selettore di periodo e l'auto-refresh in alto passano a controllare la query, e una variabile di template diventa un filtro di entità dinamico.

-- Pannello di serie temporale: le macro collegano il time picker in alto.
SELECT
  $__timeGroup(date, '1d') AS time,    -- raggruppa per giorno
  COUNT(*)                 AS aperti
FROM glpi_tickets
WHERE is_deleted = 0
  AND entities_id IN (${entita})        -- variabile di template (filtro per cliente)
  AND $__timeFilter(date)               -- rispetta l'intervallo scelto a schermo
GROUP BY 1
ORDER BY 1;

-- Query che alimenta la variabile di template "entita":
SELECT name AS __text, id AS __value
FROM glpi_entities
ORDER BY completename;

Il trade-off che emerge in gestione operativa

Nella gestione operativa di parchi GLPI per i clienti, la decisione è raramente tecnica - riguarda chi guarderà la dashboard. L'errore più comune che correggiamo è sempre lo stesso: qualcuno sceglie Grafana perché "è più potente", costruisce un pannello operativo impeccabile e, tre mesi dopo, il direttore chiede un report mensile dei ticket per categoria con esportazione per il cliente. In Grafana è penoso: è stato fatto per metriche in tempo reale, non per far navigare ed esportare tabelle a un gestore. Allora entra Metabase, e l'ambiente diventa due BI da mantenere.

Un dettaglio che solo l'operatività rivela è la segregazione per cliente. In una società di consulenza che serve vari clienti sullo stesso GLPI (o su GLPI distinti), devi garantire che la dashboard del cliente A non mostri mai un ticket del cliente B. In Metabase, il vero row-level security - il sandboxing per utente - è una funzione a pagamento; nella versione gratuita, la via d'uscita è creare una domanda per cliente con l'entities_id fisso nel WHERE, il che moltiplica la manutenzione. In Grafana lo risolviamo con una variabile di template legata alle entità, ma il controllo di chi vede cosa resta nelle tue mani. Non esiste una scorciatoia gratuita per l'isolamento multi-cliente - decidiamo caso per caso, e nel dubbio separiamo per istanza, non per query.

Verdetto per scenario

Scegli Metabase quando il pubblico è il management, il cliente o l'analista senza SQL. La curva è bassa, il report esce navigabile ed esportabile, e la mappatura visuale degli stati risolve i "numeri grezzi" senza scrivere un CASE. È lo strumento migliore per portare il dato del service desk a chi non apre un terminale.

Scegli Grafana quando la dashboard è operativa e in tempo reale - coda per gruppo, SLA a rischio, ticket all'ora - per il team tecnico o il NOC. Il time picker, l'auto-refresh, gli avvisi multicanale e il provisioning come codice sono vantaggi reali che Metabase non copre bene.

Usa entrambi quando lo stesso GLPI serve pubblici diversi: Grafana sul muro dell'operatività, Metabase in mano al management e al cliente. È comune e funziona, ma metti in conto il costo di mantenere due BI - non prendere quella strada "per sicurezza".

Costo ed effort

La licenza non è l'asse della decisione: entrambi hanno un'edizione open source gratuita che basta per le dashboard di GLPI, e i piani a pagamento (Metabase Pro/Enterprise, Grafana Enterprise) entrano in gioco solo su scenari di scala o governance. Il costo reale è quello della modellazione. La parte pesante non è installare - è conoscere lo schema di GLPI: mappare stati e priorità, ricordarsi di is_deleted, risolvere l'albero delle entità e non sovraccaricare la produzione. Come intervallo onesto: una manciata di pannelli operativi in Grafana si monta in un pomeriggio; un insieme di report gestionali ben modellati in Metabase, con filtri per cliente e stati tradotti, richiede di solito da due a quattro giorni di lavoro prima di essere affidabile. Per capire quali metriche mettere su ogni dashboard, vedi la nostra guida ai KPI di Service Desk in GLPI.

In NexTool implementiamo Metabase e Grafana sul GLPI dei clienti su entrambi i fronti - report gestionale e dashboard operativa - sempre con un utente in sola lettura e senza far cadere la produzione. Se vuoi le dashboard giuste per il pubblico giusto, senza restare ostaggio di un BI che non si adatta, la nostra consulenza progetta quello strato di indicatori dall'inizio alla fine.

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