Un inventario responde "qué tengo". Una CMDB responde "qué se cae junto cuando esto falle". El puente entre ambos en GLPI no es la pestaña Conexiones, como muchos suponen - es el análisis de impacto, y ahí es exactamente donde se atasca la mayoría de los proyectos de CMDB. Esta guía muestra los cuatro mecanismos de relación que ofrece GLPI, cuál usar en cada caso y las consultas que ejecutamos en soporte para encontrar la CMDB ciega.
Inventario vs CMDB: la diferencia que cambia la respuesta a incidentes
El inventario es un registro: marca, modelo, número de serie, garantía, responsable. Es control patrimonial y es donde todos empiezan - con el inventario automático de GLPI Agent pueblas cientos de activos en días. La CMDB es lo que viene después: la capa de relación que responde la pregunta que importa en medio de un incidente - si este switch se cae, ¿qué servidores, servicios y usuarios se detienen con él?
| Aspecto | Inventario | CMDB |
|---|---|---|
| Pregunta que responde | ¿Qué tengo? | ¿Qué depende de qué? |
| Unidad | Activo (ítem) | Relación entre CIs |
| Cómo se puebla | Automático (GLPI Agent) | Manual, una decisión de modelado |
| Valor durante un incidente | Encontrar el equipo | Prever el radio de impacto |
El error estratégico común es tratar la CMDB como "inventario más detallado" e intentar rellenar una relación para todo. No escala y nadie lo mantiene. Una buena CMDB es escueta: solo los CIs críticos y las dependencias que realmente usarías en un análisis de impacto.
Los cuatro mecanismos de relación en GLPI
GLPI no tiene un único "campo de relación" - tiene cuatro mecanismos distintos, cada uno en su tabla, y elegir el equivocado es la raíz de la mayoría de las CMDB que no funcionan. En soporte, el error número 1 es montarlo todo en la pestaña Conexiones creyendo que eso es la CMDB, y luego descubrir que el análisis de impacto está vacío.
| Mecanismo | Tabla | Modela | ¿Dirigido? | Poblado por |
|---|---|---|---|---|
| Conexiones directas | glpi_computers_items | Periférico conectado a un ordenador (monitor, impresora, teléfono) | No | Inventario o manual |
| Puertos de red | glpi_networkports_networkports | Cableado entre dos puertos (switch ↔ host) | No | SNMP/LLDP o manual |
| Aplicaciones (Appliances) | glpi_appliances_items | Un servicio/aplicación como CI + la infraestructura que lo sostiene | No (agrupación) | Manual |
| Análisis de impacto | glpi_impactrelations | Grafo de dependencia para calcular el radio de impacto | Sí (origen → impactado) | Manual (pestaña Impacto) |
Conexiones y puertos de red modelan el enlace físico. Aplicaciones agrupa la infraestructura de un servicio. Y el análisis de impacto - el único dirigido - es el grafo de dependencia que de verdad responde "qué se cae junto". Los cuatro conviven; la confusión viene de esperar que uno haga el trabajo del otro.
Modela el servicio como un CI: Aplicaciones (Appliances)
El paso que falta en la mayoría de los inventarios es darle existencia propia al servicio. "Correo", "ERP", "Portal del cliente" no son hardware - son servicios que corren sobre hardware. En GLPI el objeto correcto para esto es la Aplicación (Appliances, menú Activos), disponible desde GLPI 9.5. Una Aplicación es un CI lógico al que vinculas los ítems que lo sostienen:
- Crea la Aplicación (p. ej. "Servicio de Correo").
- En la pestaña de ítems asociados, vincula los CIs de soporte: el servidor, el switch core, el almacenamiento, el enlace de internet. Esto se graba en glpi_appliances_items.
- Registra el responsable técnico, el contrato de soporte y el proveedor en la propia Aplicación.
A partir de ahí el servicio existe como entidad consultable: abres "Servicio de Correo" y ves la lista de infraestructura que lo sostiene, sin depender de la memoria de nadie.
La CMDB de verdad: el análisis de impacto
Agrupar infraestructura en una Aplicación dice quién sostiene qué, pero no calcula el radio de impacto de un fallo. Ese es el trabajo de la pestaña Análisis de impacto (presente desde GLPI 9.4), que dibuja un grafo dirigido de dependencias guardado en glpi_impactrelations. Cada arista tiene origen y destino: itemtype_source, items_id_source impacta a itemtype_impacted, items_id_impacted.
La dirección es el detalle que separa a quien entiende de quien solo arrastró cajitas. Una arista del switch al servidor significa "el switch impacta al servidor". Cuando el switch se cae, sigues las flechas hacia delante y ves todo lo que se detiene con él. El error común es dibujar la flecha invertida - poner el servidor impactando al switch - y entonces el análisis de impacto del switch caído sale vacío, justo cuando más lo necesitas. Modela siempre en el sentido del flujo de dependencia: de la infraestructura base hacia el servicio en la cima.
Un aviso de campo: el grafo se renderiza en el navegador y se vuelve lento con cientos de nodos. No intentes dibujar todo el parque. Usa la criticidad de negocio (el desplegable Criticidad, en Configurar > Desplegables) para marcar los CIs críticos y pon solo esos en el grafo. Una CMDB densa es una CMDB abandonada.
SQL de diagnóstico: encontrar la CMDB ciega
Al iniciar un contrato de soporte, antes de discutir procesos, ejecutamos una auditoría de cobertura: qué CIs críticos están en el inventario pero fuera de cualquier relación de impacto. Son los puntos donde el análisis de impacto mentirá, diciendo "nada se ve afectado" cuando en realidad nadie lo modeló. La consulta lista los ordenadores sin ninguna arista - ni como origen ni como destino:
-- Ordenadores SIN ninguna relacion de impacto:
-- existen en el inventario, pero son invisibles para el analisis de impacto.
SELECT c.id, c.name
FROM glpi_computers c
LEFT JOIN glpi_impactrelations r
ON (r.itemtype_source = 'Computer' AND r.items_id_source = c.id)
OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id)
WHERE c.is_deleted = 0
AND r.id IS NULL
ORDER BY c.name;Y el otro lado: dado un servicio modelado como Aplicación, qué CIs agrupa. Útil para comprobar si "Servicio de Correo" apunta de verdad al servidor y al switch correctos antes de confiar en él en una madrugada de incidente:
-- Items que sostienen una Aplicacion (servicio) especifica:
SELECT ai.itemtype, ai.items_id
FROM glpi_appliances_items ai
INNER JOIN glpi_appliances a ON a.id = ai.appliances_id
WHERE a.name = 'Servicio de Correo';Ejecutamos estas dos consultas directamente contra la base de datos (con un cliente SQL de solo lectura), nunca mediante un LIKE en la interfaz, porque queremos el número exacto de huérfanos para dimensionar el esfuerzo de modelado.
El autodescubrimiento no monta la CMDB por ti
Conviene deshacer una expectativa que aparece en todo proyecto: el inventario de red por SNMP descubre las conexiones físicas - si GLPI Agent escanea los switches por SNMP y LLDP/CDP está activo, los puertos de red entre switch y host se pueblan solos en glpi_networkports_networkports. Eso es excelente y no debes hacerlo a mano. Pero la dependencia lógica de servicio - "el correo depende de este servidor" - ningún protocolo la descubre. El agente no sabe que cierto proceso Exchange es tu servicio de correo crítico. Esa capa es siempre una decisión humana, y es justamente la que convierte el inventario en CMDB.
Mantén el grafo vivo o mentirá
Una CMDB desactualizada es peor que no tener CMDB: da falsa confianza. Cambias un switch, olvidas actualizar la relación y, en el siguiente fallo, el análisis de impacto apunta a un equipo que ya no existe. Ata el mantenimiento del grafo al proceso de gestión de cambios - todo cambio en un CI crítico debe revisar sus relaciones de impacto antes de cerrarse. Sin esa disciplina, el grafo envejece en semanas. Es el mismo principio de la base de conocimiento: una relación que nadie mantiene se vuelve ruido.
¿Necesitas una CMDB en GLPI que sostenga un análisis de impacto real, con el grafo modelado en los CIs correctos y mantenido junto a los cambios? Conoce el servicio de soporte y mantenimiento de GLPI de NexTool.
Revisado por el equipo de NexTool Solutions.
