NexTool Solutions

GLPI guarda todo el histórico del service desk, pero los informes nativos se detienen justo donde la gestión empieza a preguntar "por qué". Metabase y Grafana leen la misma base de datos MariaDB de GLPI y convierten ese histórico en dashboards - pero resuelven problemas distintos, y elegir mal cuesta retrabajo.

Qué cambia al conectar un BI a GLPI

Antes de comparar las dos herramientas, hay que entender que la base de datos de GLPI no fue diseñada para BI. Tres detalles definen la mayor parte del trabajo de cualquier dashboard, sea en Metabase o en Grafana:

• El estado, la prioridad y la urgencia son números, no texto. En glpi_tickets, la columna status va de 1 (Nuevo) a 6 (Cerrado). Ninguna herramienta lo sabe por sí sola - si no traduces los códigos, el gestor ve "status 2" en el gráfico.
• Nada se borra de verdad. GLPI usa borrado lógico: is_deleted = 1 marca el registro como "en la papelera". Olvidar el filtro is_deleted = 0 infla todos los recuentos.
• Es multientidad. La columna entities_id segrega los datos por cliente o área. Un dashboard que el cliente va a ver debe filtrar el subárbol de entidades correcto - y eso no sale gratis en SQL puro.

Añade un cuarto punto, puramente operativo: apuntar el BI directo a la base de datos de producción, en horario laboral, con consultas que recorren toda la glpi_tickets junto con glpi_logs, es la forma más rápida de ralentizar el propio GLPI. Volvemos a ello más abajo.

Comparativa directa

Cómo conectar sin tumbar GLPI

Independientemente de la herramienta, la conexión es la misma: un usuario de base de datos de solo lectura, idealmente apuntando a una réplica o a una copia restaurada de madrugada, nunca al maestro de producción con permiso de escritura.

-- Usuario de solo lectura para el BI (ejecuta en el MariaDB/MySQL de GLPI).
-- Apunta, preferiblemente, a una replica o a una copia restaurada,
-- nunca al maestro de produccion con permiso de escritura.
CREATE USER 'bi_ro'@'10.0.0.%' IDENTIFIED BY '${CLAVE_FUERTE}';
GRANT SELECT ON glpi.* TO 'bi_ro'@'10.0.0.%';
FLUSH PRIVILEGES;

Con el acceso listo, el primer artefacto que resuelve el problema de los "números crudos" es una consulta que traduce los códigos de estado. Sirve para ambos: en Metabase se convierte en una "Pregunta SQL", en Grafana en un panel de tabla o de barras.

-- Tickets abiertos por estado, con los codigos traducidos.
-- En GLPI, glpi_tickets.status va de 1 a 6.
SELECT
  CASE status
    WHEN 1 THEN 'Nuevo'
    WHEN 2 THEN 'En curso (asignado)'
    WHEN 3 THEN 'En curso (planificado)'
    WHEN 4 THEN 'Pendiente'
    WHEN 5 THEN 'Resuelto'
    WHEN 6 THEN 'Cerrado'
  END AS estado,
  COUNT(*) AS total
FROM glpi_tickets
WHERE is_deleted = 0          -- ignora la papelera (borrado logico)
  AND status IN (1, 2, 3, 4)  -- solo los que siguen abiertos
GROUP BY status
ORDER BY status;

En Metabase hay un atajo: en lugar del CASE, puedes mapear los valores de la columna directamente en la configuración del campo (1 a "Nuevo", 2 a "En curso" y así), y la etiqueta aparece automáticamente en cualquier gráfico. Es una ganancia de productividad que Grafana no tiene - allí el CASE es obligatorio.

Grafana: dashboard como código

La ventaja de Grafana para quien opera muchos entornos no está en la pantalla, sino en el disco: la fuente de datos y los paneles son archivos versionables. Provisionamos el mismo dashboard en varios clientes a partir de un YAML y un JSON en Git, sin hacer clic en nada.

# /etc/grafana/provisioning/datasources/glpi.yaml
# Fuente de datos versionable: el mismo archivo provisiona N entornos.
apiVersion: 1
datasources:
  - name: GLPI-MariaDB
    type: mysql
    access: proxy
    url: mariadb.interno:3306
    database: glpi
    user: bi_ro
    jsonData:
      maxOpenConns: 5             # limita las conexiones: no ahogues GLPI
      timezone: America/Sao_Paulo
    secureJsonData:
      password: ${GLPI_BI_PASSWORD}

El otro diferencial es el tiempo. Grafana entiende las series temporales de forma nativa: con las macros $__timeFilter y $__timeGroup, el selector de período y el auto-refresh de la parte superior pasan a controlar la consulta, y una variable de plantilla se convierte en un filtro de entidad dinámico.

-- Panel de serie temporal: las macros conectan el time picker de arriba.
SELECT
  $__timeGroup(date, '1d') AS time,    -- agrupa por dia
  COUNT(*)                 AS abiertos
FROM glpi_tickets
WHERE is_deleted = 0
  AND entities_id IN (${entidad})       -- variable de plantilla (filtro por cliente)
  AND $__timeFilter(date)               -- respeta el intervalo elegido en pantalla
GROUP BY 1
ORDER BY 1;

-- Consulta que alimenta la variable de plantilla "entidad":
SELECT name AS __text, id AS __value
FROM glpi_entities
ORDER BY completename;

El trade-off que aparece en la operación

En la sustentación de parques GLPI para clientes, la decisión rara vez es técnica - es sobre quién va a mirar el dashboard. El error más común que corregimos es siempre el mismo: alguien elige Grafana porque "es más potente", monta un panel operativo impecable y, tres meses después, el director pide un informe mensual de tickets por categoría con exportación para el cliente. En Grafana eso es penoso: se hizo para métricas en vivo, no para que el gestor navegue y exporte tablas. Ahí entra Metabase, y el entorno se convierte en dos BIs que mantener.

Un detalle que solo aparece en la operación es la segregación por cliente. En una consultora que atiende a varios clientes en el mismo GLPI (o en GLPIs distintos), hay que garantizar que el dashboard del cliente A nunca muestre tickets del cliente B. En Metabase, el row-level security real - el sandboxing por usuario - es una función de pago; en la versión gratuita, la salida es crear una pregunta por cliente con el entities_id fijo en el WHERE, lo que multiplica el mantenimiento. En Grafana lo resolvemos con una variable de plantilla ligada a las entidades, pero el control de quién ve qué sigue en tus manos. No existe un atajo gratuito para el aislamiento multicliente - lo decidimos caso por caso, y en la duda separamos por instancia, no por consulta.

Veredicto por escenario

Elige Metabase cuando el público es gestión, cliente o analista sin SQL. La curva es baja, el informe sale navegable y exportable, y el mapeo visual de estados resuelve los "números crudos" sin escribir CASE. Es la mejor herramienta para llevar el dato del service desk a quien no abre una terminal.

Elige Grafana cuando el panel es operativo y en vivo - cola por grupo, SLA en riesgo, tickets por hora - para el equipo técnico o el NOC. El time picker, el auto-refresh, las alertas multicanal y el provisioning como código son ventajas reales que Metabase no cubre bien.

Usa ambos cuando el mismo GLPI atiende a públicos diferentes: Grafana en la pared de operaciones, Metabase en manos de la gestión y del cliente. Es común y funciona, pero asume el coste de mantener dos BIs - no tomes esa ruta "por si acaso".

Coste y esfuerzo

La licencia no es el eje de la decisión: ambos tienen una edición open source gratuita que basta para dashboards de GLPI, y los planes de pago (Metabase Pro/Enterprise, Grafana Enterprise) solo entran en escenarios de escala o gobernanza. El coste real es el del modelado. La parte pesada no es instalar - es conocer el esquema de GLPI: mapear estados y prioridades, acordarse del is_deleted, resolver el árbol de entidades y no sobrecargar la producción. Como rango honesto: un puñado de paneles operativos en Grafana se levanta en una tarde; un conjunto de informes de gestión bien modelados en Metabase, con filtros por cliente y estados traducidos, suele consumir de dos a cuatro días de trabajo hasta ser fiable. Para saber qué métricas poner en cada panel, revisa nuestra guía de KPIs para Service Desk en GLPI.

En NexTool implantamos Metabase y Grafana sobre el GLPI de clientes en ambos frentes - informe de gestión y panel operativo - siempre con usuario de solo lectura y sin tumbar la producción. Si quieres los dashboards correctos para el público correcto, sin quedar preso de un BI que no encaja, nuestra consultoría diseña esa capa de indicadores de principio a fin.

Este contenido se produjo con ayuda de inteligencia artificial y fue revisado por el equipo de Nextool Solutions.