NexTool Solutions

O Grafana só entrega valor quando os painéis respondem a perguntas de quem opera e de quem decide. Na sustentação de GLPI e infraestrutura que fazemos para clientes B2B, ele é a camada de visualização que colocamos ao lado do service desk: lê métricas de SLA e chamados direto do banco do GLPI, cruza com séries de disponibilidade vindas do Zabbix ou Prometheus e apresenta tudo em uma tela que o NOC e a liderança conseguem interpretar sem exportar planilha.

Como posicionamos o Grafana ao lado do GLPI

A arquitetura que usamos é deliberadamente enxuta: um contêiner Grafana no mesmo host que já roda o GLPI, atrás do mesmo reverse proxy com TLS, consumindo três fontes de dados distintas. A primeira é o próprio MariaDB/MySQL do GLPI, em usuário somente-leitura, para indicadores de service desk (chamados abertos, SLA estourado, tempo médio de atendimento). A segunda é o Zabbix ou Prometheus, para disponibilidade e capacidade de infraestrutura. A terceira, quando o cliente tem o plugin NexTool, são as métricas de sincronização e integração que o ecossistema expõe.

O erro comum que vemos em quem monta isso sozinho é apontar o Grafana para o usuário administrativo do GLPI. Nunca fazemos isso. Um painel só precisa ler, e um datasource comprometido não pode virar porta de escrita no banco de produção. Criamos um usuário dedicado com SELECT restrito às tabelas de interesse, e o Grafana nunca recebe mais permissão do que precisa para desenhar um gráfico.

Artefato: usuário read-only e datasource

Este é o par que provisionamos em toda implantação. Primeiro o usuário de leitura no banco do GLPI, com privilégio mínimo:

-- usuario somente-leitura para o Grafana ler o GLPI
CREATE USER 'grafana_ro'@'%' IDENTIFIED BY '${SENHA_FORTE}';
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: o painel so desenha, nunca escreve

E o provisionamento do datasource via arquivo, para que o painel suba versionado junto com o contêiner e não dependa de clique manual na interface:

# /etc/grafana/provisioning/datasources/glpi.yaml
apiVersion: 1
datasources:
  - name: GLPI (read-only)
    type: mysql
    access: proxy
    url: glpidb:3306
    database: glpi
    user: grafana_ro
    secureJsonData:
      password: ${SENHA_FORTE}   # injetada por variavel de ambiente
    jsonData:
      maxOpenConns: 5            # nao sufoca o banco de producao
      timeInterval: "1m"

Consulta real: SLA estourado por categoria

Um painel executivo que sempre entregamos é o de chamados com SLA de resolução vencido, agrupado por categoria. É a leitura que a liderança abre na segunda-feira. A query roda direto sobre o GLPI, respeitando o formato de série temporal que o Grafana espera:

SELECT
  c.completename                             AS categoria,
  COUNT(*)                                   AS chamados_estourados
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.status NOT IN (5, 6)                 -- exclui resolvido e fechado
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()             -- prazo de resolucao ja venceu
  AND t.is_deleted = 0
GROUP BY c.completename
ORDER BY chamados_estourados DESC;

Detalhe que só quem opera GLPI sabe: os status 5 e 6 são resolvido e fechado no schema padrão, e is_deleted = 0 é obrigatório porque o GLPI faz exclusão lógica - ignorar essa coluna infla o número com chamados que já estão na lixeira. Na sustentação, já vimos painel de terceiro reportar o dobro de SLA estourado só por esquecer o is_deleted. É o tipo de bug que mina a confiança da gestão no dashboard inteiro.

Dashboard por audiência: o que separamos

Não misturamos NOC e diretoria na mesma tela. A operação precisa de granularidade para agir agora; a gestão precisa de tendência para decidir. A separação que padronizamos:

Alertas: onde disparar sem duplicar

A regra que aplicamos é simples e evita o pior problema de observabilidade: o mesmo evento alertando por dois caminhos. Disponibilidade e capacidade de infraestrutura alertam na fonte (Zabbix ou Prometheus), que já tem o histórico e o contexto do host. O Grafana alerta apenas sobre indicadores de negócio que só existem no cruzamento das fontes - por exemplo, SLA de um contrato específico prestes a estourar. Cada painel que entregamos carrega, na descrição, a definição da métrica e a ação esperada quando houver desvio. Painel sem essa documentação vira enfeite, e enfeite ninguém olha.

Outro ponto de sustentação: limitamos maxOpenConns no datasource justamente porque um dashboard executivo com refresh agressivo e várias queries pesadas pode abrir conexões demais e competir com o GLPI de produção. Já corrigimos lentidão de chamado que a equipe atribuía ao GLPI e era, na verdade, um Grafana mal configurado sugando o pool de conexões do banco.

Quando o cliente usa o plugin NexTool, ainda expomos no mesmo dashboard as métricas de sincronização dos módulos - status de integração, filas de webhook e saúde dos jobs - de modo que operação de service desk e saúde do ecossistema ficam na mesma leitura, sem trocar de ferramenta.

Se a sua operação de GLPI ainda depende de exportar planilha para saber como está o SLA, a NexTool implanta e sustenta essa camada de observabilidade ao lado do seu service desk, com os painéis já integrados ao GLPI e à infraestrutura. Fale com a gente sobre sustentação de GLPI com observabilidade integrada.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.