NexTool Solutions

Grafana solo aporta valor cuando los paneles responden a las preguntas de quien opera y de quien decide. En el soporte de GLPI e infraestructura que ofrecemos a clientes B2B, es la capa de visualización que colocamos junto al service desk: lee métricas de SLA y tickets directamente de la base de datos de GLPI, las cruza con series de disponibilidad que llegan de Zabbix o Prometheus y lo muestra todo en una pantalla que el NOC y la dirección pueden interpretar sin exportar una hoja de cálculo.

Cómo posicionamos Grafana junto a GLPI

La arquitectura que usamos es deliberadamente ligera: un contenedor Grafana en el mismo host que ya ejecuta GLPI, detrás del mismo proxy inverso con TLS, consumiendo tres fuentes de datos distintas. La primera es el propio MariaDB/MySQL de GLPI, mediante un usuario de solo lectura, para indicadores de service desk (tickets abiertos, SLA incumplido, tiempo medio de respuesta). La segunda es Zabbix o Prometheus, para disponibilidad y capacidad de infraestructura. La tercera, cuando el cliente tiene el plugin NexTool, son las métricas de sincronización e integración que expone el ecosistema.

El error común que vemos en quien lo monta por su cuenta es apuntar Grafana al usuario administrativo de GLPI. Nunca lo hacemos. Un panel solo necesita leer, y una fuente de datos comprometida no puede convertirse en una puerta de escritura a la base de producción. Creamos un usuario dedicado con SELECT restringido a las tablas de interés, y Grafana nunca recibe más permiso del que necesita para dibujar un gráfico.

Artefacto: usuario de solo lectura y fuente de datos

Este es el par que aprovisionamos en cada implantación. Primero el usuario de lectura en la base de GLPI, con privilegio mínimo:

-- usuario de solo lectura para que Grafana lea GLPI
CREATE USER 'grafana_ro'@'%' IDENTIFIED BY '${CONTRASENA_FUERTE}';
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;
-- nada de GRANT ALL: el panel solo dibuja, nunca escribe

Y el aprovisionamiento de la fuente de datos por archivo, para que el panel arranque versionado junto al contenedor y no dependa de un clic manual en la interfaz:

# /etc/grafana/provisioning/datasources/glpi.yaml
apiVersion: 1
datasources:
  - name: GLPI (solo lectura)
    type: mysql
    access: proxy
    url: glpidb:3306
    database: glpi
    user: grafana_ro
    secureJsonData:
      password: ${CONTRASENA_FUERTE}   # inyectada por variable de entorno
    jsonData:
      maxOpenConns: 5                  # no ahoga la base de produccion
      timeInterval: "1m"

Consulta real: SLA incumplido por categoría

Un panel ejecutivo que siempre entregamos es el de tickets con SLA de resolución vencido, agrupados por categoría. Es la vista que la dirección abre el lunes por la mañana. La consulta se ejecuta directamente sobre GLPI, respetando el formato de serie temporal que Grafana espera:

SELECT
  c.completename                             AS categoria,
  COUNT(*)                                   AS tickets_incumplidos
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.status NOT IN (5, 6)                 -- excluye resuelto y cerrado
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()             -- el plazo de resolucion ya vencio
  AND t.is_deleted = 0
GROUP BY c.completename
ORDER BY tickets_incumplidos DESC;

Un detalle que solo sabe quien opera GLPI: los estados 5 y 6 son resuelto y cerrado en el esquema por defecto, y is_deleted = 0 es obligatorio porque GLPI hace borrado lógico - ignorar esa columna infla el número con tickets que ya están en la papelera. En soporte ya hemos visto un panel de terceros reportar el doble de SLA incumplido solo por olvidar el is_deleted. Es el tipo de fallo que socava la confianza de la dirección en todo el dashboard.

Dashboard por audiencia: lo que separamos

No mezclamos NOC y dirección en la misma pantalla. La operación necesita granularidad para actuar ahora; la dirección necesita tendencia para decidir. La separación que estandarizamos:

Alertas: dónde disparar sin duplicar

La regla que aplicamos es simple y evita el peor problema de observabilidad: el mismo evento alertando por dos caminos. La disponibilidad y la capacidad de infraestructura alertan en la fuente (Zabbix o Prometheus), que ya tiene el histórico y el contexto del host. Grafana alerta solo sobre indicadores de negocio que únicamente existen en el cruce de fuentes - por ejemplo, el SLA de un contrato concreto a punto de incumplirse. Cada panel que entregamos lleva, en su descripción, la definición de la métrica y la acción esperada cuando hay una desviación. Un panel sin esa documentación se convierte en adorno, y nadie mira un adorno.

Otro punto de soporte: limitamos maxOpenConns en la fuente de datos precisamente porque un dashboard ejecutivo con refresco agresivo y varias consultas pesadas puede abrir demasiadas conexiones y competir con el GLPI de producción. Ya hemos corregido lentitud de tickets que el equipo atribuía a GLPI y era, en realidad, un Grafana mal configurado agotando el pool de conexiones de la base.

Cuando el cliente usa el plugin NexTool, además mostramos en el mismo dashboard las métricas de sincronización de los módulos - estado de integración, colas de webhook y salud de los jobs - de modo que la operación de service desk y la salud del ecosistema quedan en la misma lectura, sin cambiar de herramienta.

Si tu operación de GLPI todavía depende de exportar una hoja de cálculo para saber cómo va el SLA, NexTool implanta y da soporte a esta capa de observabilidad junto a tu service desk, con los paneles ya integrados con GLPI y tu infraestructura. Habla con nosotros sobre soporte de GLPI con observabilidad integrada.

Este contenido se ha producido con ayuda de inteligencia artificial y ha sido revisado por el equipo de Nextool Solutions.