Um inventário responde "o que eu tenho". Um CMDB responde "o que cai junto quando isto falhar". A ponte entre os dois no GLPI não é a aba Conexões, como muita gente assume - é a análise de impacto, e é exatamente aí que a maioria dos projetos de CMDB trava. Este guia mostra os quatro mecanismos de relação que o GLPI oferece, qual usar para cada caso, e as queries que rodamos na sustentação para achar o CMDB cego.
Inventário vs CMDB: a diferença que muda a resposta a incidente
Inventário é cadastro: marca, modelo, número de série, garantia, responsável. É controle patrimonial e é onde todo mundo começa - com o inventário automático do GLPI Agent você popula centenas de ativos em dias. CMDB é o que vem depois: a camada de relacionamento que responde à pergunta que importa no meio de um incidente - se este switch cair, quais servidores, serviços e usuários param junto?
| Aspecto | Inventário | CMDB |
|---|---|---|
| Pergunta que responde | O que eu tenho? | O que depende do quê? |
| Unidade | Ativo (item) | Relação entre CIs |
| Como se popula | Automático (GLPI Agent) | Manual, por decisão de modelagem |
| Valor no incidente | Achar o equipamento | Prever o raio de impacto |
O erro estratégico comum é tratar o CMDB como "inventário mais detalhado" e tentar preencher relação para tudo. Não escala e ninguém mantém. CMDB bom é enxuto: só os CIs críticos e as dependências que você de fato usaria numa análise de impacto.
Os quatro mecanismos de relação no GLPI
O GLPI não tem um único "campo de relacionamento" - tem quatro mecanismos distintos, cada um em sua tabela, e escolher o errado é a raiz da maioria dos CMDBs que não funcionam. Na sustentação, o engano número 1 é montar tudo na aba Conexões achando que aquilo é o CMDB, e depois descobrir que a análise de impacto está vazia.
| Mecanismo | Tabela | Modela | Direcionado? | Populado por |
|---|---|---|---|---|
| Conexões diretas | glpi_computers_items | Periférico ligado a um computador (monitor, impressora, telefone) | Não | Inventário ou manual |
| Portas de rede | glpi_networkports_networkports | Cabeamento entre duas portas (switch ↔ host) | Não | SNMP/LLDP ou manual |
| Aplicativos (Appliances) | glpi_appliances_items | Um serviço/aplicação como CI + a infra que o sustenta | Não (agrupamento) | Manual |
| Análise de impacto | glpi_impactrelations | Grafo de dependência para calcular raio de impacto | Sim (origem → impactado) | Manual (aba Impacto) |
Conexões e portas de rede modelam ligação física. Aplicativos agrupa a infra de um serviço. E a análise de impacto - a única direcionada - é o grafo de dependência que realmente responde "o que cai junto". As quatro convivem; a confusão vem de esperar que uma faça o trabalho da outra.
Modele o serviço como um CI: Aplicativos (Appliances)
O passo que falta na maioria dos inventários é dar existência ao serviço. "E-mail", "ERP", "Portal do cliente" não são hardware - são serviços que rodam sobre hardware. No GLPI, o objeto certo para isso é o Aplicativo (Appliances, menu Ativos), disponível desde o GLPI 9.5. Um Aplicativo é um CI lógico ao qual você vincula os itens que o sustentam:
- Crie o Aplicativo (ex.: "Serviço de E-mail").
- Na aba de itens associados, vincule os CIs de suporte: o servidor, o switch core, o storage, o link de internet. Isso grava em glpi_appliances_items.
- Registre o responsável técnico, o contrato de suporte e o fornecedor no próprio Aplicativo.
A partir daí o serviço existe como entidade consultável: você abre "Serviço de E-mail" e vê a lista da infra que o sustenta, sem depender da memória de ninguém.
O CMDB de verdade: a análise de impacto
Agrupar infra num Aplicativo diz quem sustenta o quê, mas não calcula o raio de impacto de uma falha. Isso é trabalho da aba Análise de impacto (presente desde o GLPI 9.4), que desenha um grafo direcionado de dependências e é gravado em glpi_impactrelations. Cada aresta tem origem e destino: itemtype_source, items_id_source impacta itemtype_impacted, items_id_impacted.
A direção é o detalhe que separa quem entende de quem só arrastou caixinha. Uma aresta do switch para o servidor significa "o switch impacta o servidor". Quando o switch cai, você segue as setas para a frente e vê tudo que para junto. O erro comum é desenhar a seta invertida - ligar o servidor impactando o switch - e aí a análise de impacto do switch caído sai vazia, justamente quando você mais precisa dela. Modele sempre no sentido do fluxo de dependência: da infra de base para o serviço no topo.
Um cuidado de campo: o grafo é renderizado no navegador e fica lento com centenas de nós. Não tente desenhar o parque inteiro. Use a criticidade de negócio (dropdown Criticidade, em Configurar > Listas) para marcar os CIs críticos e coloque só esses no grafo. CMDB denso é CMDB abandonado.
SQL de diagnóstico: achando o CMDB cego
Na entrada de um contrato de sustentação, antes de discutir processo, rodamos uma auditoria de cobertura: quais CIs críticos estão no inventário mas fora de qualquer relação de impacto. São os pontos onde a análise de impacto vai mentir, dizendo "nada é afetado" quando na verdade ninguém modelou. A query lista os computadores sem nenhuma aresta - nem como origem, nem como destino:
-- Computadores sem NENHUMA relacao de impacto:
-- existem no inventario, mas sao invisiveis para a analise 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;E o outro lado: dado um serviço modelado como Aplicativo, quais CIs ele agrupa. Útil para conferir se o "Serviço de E-mail" realmente aponta para o servidor e o switch certos antes de confiar nele numa madrugada de incidente:
-- Itens que sustentam um Aplicativo (servico) especifico:
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 = 'Servico de E-mail';Rodamos essas duas queries direto no banco (via cliente SQL somente-leitura), nunca por LIKE na interface, porque queremos o número exato de órfãos para dimensionar o esforço de modelagem.
Descoberta automática não monta o CMDB por você
Vale desfazer uma expectativa que aparece em todo projeto: o inventário de rede via SNMP descobre as conexões físicas - se o GLPI Agent varre os switches com SNMP e o LLDP/CDP está ativo, as portas de rede entre switch e host são populadas sozinhas em glpi_networkports_networkports. Isso é ótimo e você não deve fazer à mão. Mas a dependência lógica de serviço - "o e-mail depende deste servidor" - nenhum protocolo descobre. O agente não sabe que aquele processo Exchange é o seu serviço de e-mail crítico. Essa camada é sempre decisão humana, e é justamente ela que transforma inventário em CMDB.
Mantenha o grafo vivo ou ele mente
CMDB desatualizado é pior que CMDB inexistente: dá falsa confiança. Você troca um switch, esquece de atualizar a relação, e na próxima falha a análise de impacto aponta para um equipamento que nem existe mais. Amarre a manutenção do grafo ao processo de gestão de mudanças - toda mudança em um CI crítico deve revisar suas relações de impacto antes de fechar. Sem essa disciplina, o grafo envelhece em semanas. É o mesmo princípio da base de conhecimento: relacionamento que ninguém mantém vira ruído.
Precisa de um CMDB no GLPI que sustente análise de impacto de verdade, com o grafo modelado nos CIs certos e mantido junto às mudanças? Conheça a sustentação de GLPI da NexTool.
Revisado pela equipe NexTool Solutions.
