NexTool Solutions

Visibilidade não é ter mais relatório - é enxergar o estado da fila enquanto ainda dá para agir. O GLPI já guarda tudo que você precisa; o problema é que o dado está espalhado e o painel nativo só mostra o passado. Este guia mostra onde a visibilidade real vive no GLPI, quais consultas de diagnóstico rodamos ao assumir a sustentação de um ambiente, como antecipar o estouro de SLA antes de ele acontecer e como transformar tudo isso em alerta automático.

A visibilidade que o GLPI já te dá - e onde ela para

O GLPI vem com painéis (dashboards) na Central e uma busca com filtros poderosa. Para o dia a dia, isso resolve muita coisa: contagem por status, por técnico, por categoria. O limite aparece em três pontos:

• É sob demanda, não proativo. O painel só atualiza quando alguém abre a tela. Ninguém é avisado quando um gargalo se forma - você precisa ir olhar.
• Conta o que o seu perfil enxerga. O número no painel depende da entidade e do perfil de quem está logado. O coordenador de uma entidade e o admin global veem totais diferentes da mesma fila.
• Mostra o agregado, não o chamado esquecido. "42 chamados abertos" não diz qual está parado há 20 dias.

Visibilidade de verdade começa quando você para de olhar o total e começa a olhar a forma da fila e o que está prestes a dar errado.

Passo 1: para onde o backlog está indo

Antes de qualquer dashboard bonito, o primeiro raio-x é a distribuição do backlog por grupo e status. Tudo vive em glpi_tickets; a atribuição a grupo, em glpi_groups_tickets (tipo 2 = atribuído). Os status que importam: 1 Novo, 2/3 Em atendimento, 4 Pendente, 5 Solucionado, 6 Fechado.

-- Backlog aberto por grupo atribuído (type 2 = atribuído)
SELECT
  g.completename                    AS grupo,
  COUNT(*)                          AS abertos,
  SUM(t.status = 1)                 AS novos_sem_triagem,
  SUM(t.status = 4)                 AS pendentes
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 abertos DESC;

Em segundos você vê qual grupo está sobrecarregado e quanto do backlog é chamado novo que ninguém triou - o número que o painel nativo esconde atrás do total.

Passo 2: SLA que vai estourar antes de estourar

Aqui mora a diferença entre operação que reage e operação que antecipa. Quando um SLA casa com o chamado, o GLPI grava o prazo em colunas próprias de glpi_tickets: time_to_resolve (prazo de resolução) e time_to_own (prazo de atribuição). Isso é um relógio - dá para olhar o que vence nas próximas horas, não só o que já venceu:

-- Chamados abertos com SLA de resolução vencendo nas 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)        -- fora Pendente, Solucionado, Fechado
  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;

A armadilha de campo está no IS NOT NULL. A coluna time_to_resolve só é preenchida quando uma regra de SLA casou com o chamado na abertura. Chamado que não bateu com nenhuma regra fica com o prazo NULL - e some silenciosamente do painel de risco. Ou seja: os chamados sem SLA, justamente os que ninguém está medindo, são invisíveis para qualquer alerta baseado em prazo. Ao assumir um ambiente, a primeira contagem que rodamos é quantos abertos estão com time_to_resolve IS NULL. Já vimos cliente com 60% do backlog sem nenhum SLA associado: o painel dizia "tudo dentro do prazo" porque metade da fila simplesmente não tinha prazo.

Passo 3: o dono que não existe

Outro ponto cego clássico: chamado atribuído só a um grupo, sem técnico nomeado. Na tela ele parece atribuído; na prática, ninguém se sente dono. Esses chamados somem dos painéis pessoais ("meus chamados") e envelhecem invisíveis. A atribuição a pessoa vive em glpi_tickets_users com type = 2:

-- Abertos atribuídos a grupo mas SEM técnico responsável nomeado
SELECT COUNT(*) AS sem_dono
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
  );

As camadas de visibilidade: o que usar para quê

Não existe uma ferramenta única. Cada camada resolve um problema e tem um limite. É assim que decidimos onde colocar cada indicador:

Passo 4: transformar diagnóstico em alerta automático

Rodar consulta na mão não escala e, pior, depende de alguém lembrar de olhar. Duas formas de fechar esse laço no GLPI:

1. Nativo, sem infra extra: salve a busca de "SLA vencendo" ou "pendentes há mais de 7 dias" e crie um alerta de pesquisa salva. O cron do GLPI roda a busca periodicamente e dispara e-mail quando a contagem cruza o limite que você definir.
2. Fora do GLPI, para painel de parede e histórico: agende a consulta de diagnóstico no cron do sistema, lendo a credencial de um arquivo .cnf (chmod 600) para nunca deixar senha na linha de comando.

# /etc/cron.d/glpi-visibilidade  ->  toda hora útil, como www-data
# Lista chamados com SLA a estourar nas próximas 4h para a fila de plantão
0 8-18 * * 1-5 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/sla-a-estourar.sql \
  > /var/log/glpi-kpi/sla-risco-$(date +\%Y-\%m-\%d-\%H).csv 2>&1

Antes de agendar, garanta que o cron do próprio GLPI está de fato rodando em modo externo (o cron do sistema chamando front/cron.php) - senão os prazos de SLA e os alertas nativos nem são recalculados, e você mede um relógio parado.

A virada, na prática da sustentação

Quando assumimos um GLPI de cliente, o primeiro raio-x nunca é o dashboard nativo - é a contagem de chamados atribuídos só a grupo (sem dono) e de chamados com time_to_resolve nulo. Num caso, 40% do backlog estava "atribuído" a um grupo de oito pessoas e ninguém se sentia responsável; nenhum desses chamados aparecia em painel pessoal e o mais antigo tinha 90 dias. A correção não foi um dashboard novo - foi uma regra de negócio forçando técnico nomeado na atribuição, mais um alerta de SLA a 4 horas de estourar. Visibilidade não veio de comprar ferramenta; veio de olhar os campos certos.

Erros comuns de campo

• Confiar no total do painel: ele agrega e esconde o chamado parado; olhe a distribuição por grupo e por idade.
• Achar que todo chamado tem SLA: time_to_resolve NULL = fora de qualquer alerta de prazo. Conte os sem SLA primeiro.
• Tratar "atribuído a grupo" como "tem dono": sem um registro em glpi_tickets_users com type = 2, ninguém é responsável.
• Comparar entidades pelo mesmo número: o painel nativo já filtra por perfil e entidade; o total muda conforme quem está logado.
• Esquecer is_deleted = 0: a lixeira do GLPI não some da tabela e contamina qualquer contagem.
• Medir com o cron parado: sem o cron externo rodando, SLA e alertas nativos não atualizam.

Próximo passo

Comece pelas três contagens deste guia (sem dono, sem SLA, SLA a vencer), suba os recortes para um painel no Metabase ou Grafana e ligue os KPIs de Service Desk a alertas. Assim a fila deixa de ser um número no fim do mês e vira um sinal que dispara enquanto ainda dá para agir.

Na NexTool, esse raio-x de visibilidade é o primeiro entregável quando assumimos a sustentação de um GLPI: mapeamos os pontos cegos, ligamos os alertas e entregamos o painel. Se quiser esse acompanhamento no seu ambiente, conheça nosso serviço de suporte e sustentação.

Revisado pela equipe NexTool Solutions.