NexTool Solutions

La visibilidad no consiste en tener más informes - consiste en ver el estado de la cola mientras todavía puedes actuar. GLPI ya guarda todo lo que necesitas; el problema es que el dato está disperso y el panel nativo solo muestra el pasado. Esta guía muestra dónde vive la visibilidad real en GLPI, qué consultas de diagnóstico ejecutamos al asumir el soporte de un entorno, cómo anticipar el incumplimiento de un SLA antes de que ocurra y cómo convertir todo eso en una alerta automática.

La visibilidad que GLPI ya te da - y dónde se detiene

GLPI trae paneles (dashboards) en la Central y una búsqueda con filtros potente. Para el día a día, eso resuelve mucho: recuentos por estado, por técnico, por categoría. El límite aparece en tres puntos:

• Es bajo demanda, no proactivo. El panel solo se actualiza cuando alguien abre la pantalla. Nadie recibe aviso cuando se forma un cuello de botella - tienes que ir a mirar.
• Cuenta lo que tu perfil puede ver. El número del panel depende de la entidad y del perfil de quien inicia sesión. El coordinador de una entidad y el admin global ven totales distintos de la misma cola.
• Muestra el agregado, no el ticket olvidado. "42 tickets abiertos" no te dice cuál lleva 20 días parado.

La visibilidad de verdad empieza cuando dejas de mirar el total y empiezas a mirar la forma de la cola y lo que está a punto de salir mal.

Paso 1: hacia dónde se acumula el backlog

Antes de cualquier dashboard bonito, la primera radiografía es la distribución del backlog por grupo y estado. Todo vive en glpi_tickets; la asignación a grupo, en glpi_groups_tickets (tipo 2 = asignado). Los estados que importan: 1 Nuevo, 2/3 En curso, 4 Pendiente, 5 Resuelto, 6 Cerrado.

-- Backlog abierto por grupo asignado (type 2 = asignado)
SELECT
  g.completename                    AS grupo,
  COUNT(*)                          AS abiertos,
  SUM(t.status = 1)                 AS nuevos_sin_triar,
  SUM(t.status = 4)                 AS pendientes
FROM glpi_tickets t
JOIN glpi_groups_tickets gt
     ON gt.tickets_id = t.id AND gt.type = 2
JOIN glpi_groups g ON g.id = gt.groups_id
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
GROUP BY g.id
ORDER BY abiertos DESC;

En segundos ves qué grupo está sobrecargado y cuánto del backlog son tickets nuevos que nadie ha triado - el número que el panel nativo esconde tras el total.

Paso 2: el SLA que va a incumplirse antes de incumplirse

Aquí está la diferencia entre una operación que reacciona y una que anticipa. Cuando un SLA coincide con el ticket, GLPI graba el plazo en columnas propias de glpi_tickets: time_to_resolve (plazo de resolución) y time_to_own (plazo de asignación). Eso es un reloj - puedes mirar lo que vence en las próximas horas, no solo lo que ya venció:

-- Tickets abiertos con SLA de resolución venciendo en las próximas 4h
SELECT
  t.id,
  t.name,
  t.time_to_resolve,
  TIMESTAMPDIFF(MINUTE, NOW(), t.time_to_resolve) AS minutos_restantes
FROM glpi_tickets t
WHERE t.status NOT IN (4, 5, 6)        -- excluye Pendiente, Resuelto, Cerrado
  AND t.is_deleted = 0
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve > NOW()
  AND t.time_to_resolve <= NOW() + INTERVAL 4 HOUR
ORDER BY t.time_to_resolve ASC;

La trampa de campo está en ese IS NOT NULL. La columna time_to_resolve solo se rellena cuando una regla de SLA coincidió con el ticket al crearlo. Un ticket que no coincidió con ninguna regla se queda con el plazo NULL - y desaparece silenciosamente del panel de riesgo. Es decir: los tickets sin SLA, justo los que nadie está midiendo, son invisibles para cualquier alerta basada en plazo. Al asumir un entorno, el primer recuento que ejecutamos es cuántos abiertos tienen time_to_resolve IS NULL. Ya hemos visto a un cliente con el 60% del backlog sin ningún SLA asociado: el panel decía "todo en plazo" porque la mitad de la cola simplemente no tenía plazo.

Paso 3: el responsable que no existe

Otro punto ciego clásico: ticket asignado solo a un grupo, sin técnico nombrado. En pantalla parece asignado; en la práctica, nadie se siente el responsable. Esos tickets desaparecen de los paneles personales ("mis tickets") y envejecen invisibles. La asignación a persona vive en glpi_tickets_users con type = 2:

-- Abiertos asignados a grupo pero SIN técnico responsable nombrado
SELECT COUNT(*) AS sin_responsable
FROM glpi_tickets t
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
  AND NOT EXISTS (
    SELECT 1 FROM glpi_tickets_users tu
    WHERE tu.tickets_id = t.id AND tu.type = 2
  );

Las capas de visibilidad: qué usar para qué

No existe una herramienta única. Cada capa resuelve un problema y tiene un límite. Así decidimos dónde colocar cada indicador:

Paso 4: convertir el diagnóstico en alerta automática

Ejecutar la consulta a mano no escala y, peor, depende de que alguien se acuerde de mirar. Dos formas de cerrar ese bucle en GLPI:

1. Nativo, sin infraestructura extra: guarda la búsqueda de "SLA por vencer" o "pendientes desde hace más de 7 días" y crea una alerta de búsqueda guardada. El cron de GLPI ejecuta la búsqueda periódicamente y dispara un correo cuando el recuento cruza el umbral que definas.
2. Fuera de GLPI, para panel de pared e histórico: programa la consulta de diagnóstico en el cron del sistema, leyendo la credencial de un fichero .cnf (chmod 600) para no dejar nunca la contraseña en la línea de comandos.

# /etc/cron.d/glpi-visibilidad  ->  cada hora laboral, como www-data
# Lista tickets con SLA por vencer en las próximas 4h para la cola de guardia
0 8-18 * * 1-5 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/sla-por-vencer.sql \
  > /var/log/glpi-kpi/sla-riesgo-$(date +\%Y-\%m-\%d-\%H).csv 2>&1

Antes de programar, asegúrate de que el propio cron de GLPI está funcionando en modo externo (el cron del sistema llamando a front/cron.php) - si no, los plazos de SLA y las alertas nativas ni siquiera se recalculan, y estarías leyendo un reloj parado.

El punto de inflexión, desde la práctica del soporte

Cuando asumimos el GLPI de un cliente, la primera radiografía nunca es el dashboard nativo - es el recuento de tickets asignados solo a un grupo (sin responsable) y de tickets con time_to_resolve nulo. En un caso, el 40% del backlog estaba "asignado" a un grupo de ocho personas y nadie se sentía responsable; ninguno de esos tickets aparecía en un panel personal y el más antiguo tenía 90 días. La corrección no fue un dashboard nuevo - fue una regla de negocio que forzaba un técnico nombrado en la asignación, más una alerta de SLA a 4 horas de vencer. La visibilidad no vino de comprar una herramienta; vino de mirar los campos correctos.

Errores de campo habituales

• Confiar en el total del panel: agrega y esconde el ticket parado; mira la distribución por grupo y por antigüedad.
• Creer que todo ticket tiene SLA: time_to_resolve NULL = fuera de cualquier alerta de plazo. Cuenta primero los que no tienen SLA.
• Tratar "asignado a grupo" como "tiene responsable": sin un registro en glpi_tickets_users con type = 2, nadie es responsable.
• Comparar entidades por el mismo número: el panel nativo ya filtra por perfil y entidad; el total cambia según quién esté conectado.
• Olvidar is_deleted = 0: la papelera de GLPI no sale de la tabla y contamina cualquier recuento.
• Medir con el cron parado: sin el cron externo funcionando, el SLA y las alertas nativas no se actualizan.

Siguiente paso

Empieza por los tres recuentos de esta guía (sin responsable, sin SLA, SLA por vencer), sube esos cortes a un dashboard en Metabase o Grafana y conecta tus KPIs de Service Desk a alertas. Así la cola deja de ser un número a fin de mes y pasa a ser una señal que se dispara mientras todavía hay tiempo de actuar.

En NexTool, esta radiografía de visibilidad es el primer entregable cuando asumimos el soporte de un GLPI: mapeamos los puntos ciegos, conectamos las alertas y entregamos el panel. Si quieres ese seguimiento en tu entorno, conoce nuestro servicio de soporte y mantenimiento.

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