NexTool Solutions

O Grafana só entrega valor quando os painéis respondem às perguntas de quem opera e de quem decide. Na sustentação de GLPI e infraestrutura que fazemos para clientes B2B, é a camada de visualização que colocamos ao lado do service desk: lê métricas de SLA e chamados diretamente da base de dados do GLPI, cruza-as com séries de disponibilidade vindas do Zabbix ou Prometheus e apresenta tudo num ecrã que o NOC e a liderança conseguem interpretar sem exportar uma folha de cálculo.

Como posicionamos o Grafana ao lado do GLPI

A arquitetura que utilizamos é deliberadamente leve: um contentor Grafana no mesmo anfitrião que já executa o GLPI, atrás do mesmo reverse proxy com TLS, a consumir três origens de dados distintas. A primeira é o próprio MariaDB/MySQL do GLPI, através de um utilizador só de leitura, para indicadores de service desk (chamados abertos, SLA ultrapassado, tempo médio de resposta). A segunda é o Zabbix ou o 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 isto sozinho é apontar o Grafana ao utilizador administrativo do GLPI. Nunca o fazemos. Um painel só precisa de ler, e uma origem de dados comprometida não pode tornar-se uma porta de escrita na base de produção. Criamos um utilizador dedicado com SELECT restrito às tabelas de interesse, e o Grafana nunca recebe mais permissões do que precisa para desenhar um gráfico.

Artefacto: utilizador só de leitura e origem de dados

Este é o par que aprovisionamos em cada implementação. Primeiro o utilizador de leitura na base do GLPI, com privilégio mínimo:

-- utilizador so de leitura para o Grafana ler o GLPI
CREATE USER 'grafana_ro'@'%' IDENTIFIED BY '${PALAVRA_PASSE_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 aprovisionamento da origem de dados por ficheiro, para que o painel arranque versionado junto com o contentor e não dependa de um clique manual na interface:

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

Consulta real: SLA ultrapassado por categoria

Um painel executivo que entregamos sempre é o de chamados com SLA de resolução vencido, agrupados por categoria. É a vista que a liderança abre na segunda de manhã. A consulta corre diretamente sobre o GLPI, respeitando o formato de série temporal que o Grafana espera:

SELECT
  c.completename                             AS categoria,
  COUNT(*)                                   AS chamados_ultrapassados
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()             -- o prazo de resolucao ja venceu
  AND t.is_deleted = 0
GROUP BY c.completename
ORDER BY chamados_ultrapassados DESC;

Um detalhe que só quem opera GLPI conhece: os estados 5 e 6 são resolvido e fechado no esquema por omissão, e is_deleted = 0 é obrigatório porque o GLPI faz eliminação lógica - ignorar essa coluna infla o número com chamados que já estão no lixo. Na sustentação, já vimos um painel de terceiros reportar o dobro de SLA ultrapassado só por esquecer o is_deleted. É o tipo de erro que mina a confiança da gestão em todo o painel.

Painel por público: o que separamos

Não misturamos NOC e direção no mesmo ecrã. 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 a alertar por dois caminhos. A disponibilidade e a capacidade de infraestrutura alertam na origem (Zabbix ou Prometheus), que já tem o histórico e o contexto do anfitrião. O Grafana alerta apenas sobre indicadores de negócio que só existem no cruzamento das origens - por exemplo, o SLA de um contrato específico prestes a ser ultrapassado. Cada painel que entregamos leva, na sua descrição, a definição da métrica e a ação esperada quando há um desvio. Um painel sem essa documentação torna-se um enfeite, e ninguém olha para um enfeite.

Outro ponto de sustentação: limitamos o maxOpenConns na origem de dados precisamente porque um painel executivo com atualização agressiva e várias consultas pesadas pode abrir demasiadas ligações e competir com o GLPI de produção. Já corrigimos lentidão de chamados que a equipa atribuía ao GLPI e era, na realidade, um Grafana mal configurado a esgotar o pool de ligações da base.

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

Se a sua operação de GLPI ainda depende de exportar uma folha de cálculo para saber como está o SLA, a NexTool implementa e mantém esta camada de observabilidade ao lado do seu service desk, com os painéis já integrados com o GLPI e a sua infraestrutura. Fale connosco sobre sustentação de GLPI com observabilidade integrada.

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