NexTool Solutions

O GLPI guarda todo o histórico do service desk, mas os relatórios nativos param onde a gestão começa a perguntar "porquê". O Metabase e o Grafana lêem a mesma base de dados MariaDB do GLPI e transformam esse histórico em painéis - só que resolvem problemas diferentes, e escolher mal custa retrabalho.

O que muda ao ligar um BI ao GLPI

Antes de comparar as duas ferramentas, é preciso perceber que a base de dados do GLPI não foi desenhada para BI. Três detalhes definem a maior parte do trabalho de qualquer painel, seja no Metabase ou no Grafana:

• O estado, a prioridade e a urgência são números, não texto. Em glpi_tickets, a coluna status vai de 1 (Novo) a 6 (Fechado). Nenhuma ferramenta sabe isto sozinha - se não traduzir os códigos, o gestor vê "status 2" no gráfico.
• Nada é apagado de verdade. O GLPI usa eliminação lógica: is_deleted = 1 marca o registo como "na reciclagem". Esquecer o filtro is_deleted = 0 inflaciona todas as contagens.
• É multi-entidade. A coluna entities_id segrega os dados por cliente ou área. Um painel que o cliente vai ver tem de filtrar a subárvore de entidades certa - e isso não sai de graça em SQL puro.

Junte a isto um quarto ponto, puramente operacional: apontar o BI diretamente à base de dados de produção, em horário de expediente, com consultas que percorrem toda a glpi_tickets em junção com glpi_logs, é a forma mais rápida de tornar o próprio GLPI lento. Voltamos a isto mais à frente.

Comparativo direto

Como ligar sem derrubar o GLPI

Independentemente da ferramenta, a ligação é a mesma: um utilizador de base de dados só de leitura, idealmente a apontar para uma réplica ou uma cópia restaurada de madrugada, nunca para o master de produção com permissão de escrita.

-- Utilizador so de leitura para o BI (execute no MariaDB/MySQL do GLPI).
-- Aponte, de preferencia, para uma replica ou copia restaurada,
-- nunca para o master de producao com permissao de escrita.
CREATE USER 'bi_ro'@'10.0.0.%' IDENTIFIED BY '${PALAVRA_PASSE_FORTE}';
GRANT SELECT ON glpi.* TO 'bi_ro'@'10.0.0.%';
FLUSH PRIVILEGES;

Com o acesso pronto, o primeiro artefacto que resolve o problema dos "números crus" é uma consulta que traduz os códigos de estado. Serve para os dois: no Metabase torna-se uma "Pergunta SQL", no Grafana um painel de tabela ou de barras.

-- Tickets abertos por estado, com os codigos traduzidos.
-- No GLPI, glpi_tickets.status vai de 1 a 6.
SELECT
  CASE status
    WHEN 1 THEN 'Novo'
    WHEN 2 THEN 'Em curso (atribuido)'
    WHEN 3 THEN 'Em curso (planeado)'
    WHEN 4 THEN 'Pendente'
    WHEN 5 THEN 'Resolvido'
    WHEN 6 THEN 'Fechado'
  END AS estado,
  COUNT(*) AS total
FROM glpi_tickets
WHERE is_deleted = 0          -- ignora a reciclagem (eliminacao logica)
  AND status IN (1, 2, 3, 4)  -- so os que ainda estao abertos
GROUP BY status
ORDER BY status;

No Metabase há um atalho: em vez do CASE, dá para mapear os valores da coluna diretamente nas definições do campo (1 para "Novo", 2 para "Em curso" e assim por diante), e o rótulo passa a aparecer automaticamente em qualquer gráfico. É um ganho de produtividade que o Grafana não tem - aí o CASE é obrigatório.

Grafana: o painel como código

A vantagem do Grafana para quem opera muitos ambientes não está no ecrã, está no disco: a fonte de dados e os painéis são ficheiros versionáveis. Aprovisionamos o mesmo painel em vários clientes a partir de um YAML e de um JSON no Git, sem clicar em nada.

# /etc/grafana/provisioning/datasources/glpi.yaml
# Fonte de dados versionavel: o mesmo ficheiro aprovisiona N ambientes.
apiVersion: 1
datasources:
  - name: GLPI-MariaDB
    type: mysql
    access: proxy
    url: mariadb.interno:3306
    database: glpi
    user: bi_ro
    jsonData:
      maxOpenConns: 5             # limite as ligacoes: nao sufoque o GLPI
      timezone: Europe/Lisbon
    secureJsonData:
      password: ${GLPI_BI_PASSWORD}

O outro diferenciador é o tempo. O Grafana percebe séries temporais nativamente: com as macros $__timeFilter e $__timeGroup, o seletor de período e o auto-refresh do topo do ecrã passam a controlar a consulta, e uma variável de template torna-se um filtro de entidade dinâmico.

-- Painel de serie temporal: as macros ligam o time picker do topo.
SELECT
  $__timeGroup(date, '1d') AS time,    -- agrupa por dia
  COUNT(*)                 AS abertos
FROM glpi_tickets
WHERE is_deleted = 0
  AND entities_id IN (${entidade})      -- variavel de template (filtro por cliente)
  AND $__timeFilter(date)               -- respeita o intervalo escolhido no ecra
GROUP BY 1
ORDER BY 1;

-- Consulta que alimenta a variavel de template "entidade":
SELECT name AS __text, id AS __value
FROM glpi_entities
ORDER BY completename;

O compromisso que aparece na sustentação

Na sustentação de parques GLPI para clientes, a decisão raramente é técnica - é sobre quem vai olhar para o painel. O erro mais comum que corrigimos é sempre o mesmo: alguém escolhe o Grafana porque "é mais poderoso", monta um painel operacional impecável e, três meses depois, o diretor pede um relatório mensal de tickets por categoria com exportação para o cliente. No Grafana isso é penoso: foi feito para métricas em direto, não para o gestor navegar e exportar tabelas. Aí entra o Metabase, e o ambiente passa a ter dois BIs para manter.

Um detalhe que só aparece na operação é a segregação por cliente. Numa consultora que atende vários clientes no mesmo GLPI (ou em GLPIs distintos), é preciso garantir que o painel do cliente A nunca mostra um ticket do cliente B. No Metabase, o row-level security a sério - o sandboxing por utilizador - é uma funcionalidade paga; na versão gratuita, a saída é criar uma pergunta por cliente com o entities_id fixo no WHERE, o que multiplica a manutenção. No Grafana resolvemos com uma variável de template ligada às entidades, mas o controlo de quem vê o quê continua nas suas mãos. Não existe atalho gratuito para o isolamento multi-cliente - decidimos caso a caso, e na dúvida separamos por instância, não por consulta.

Veredicto por cenário

Escolha o Metabase quando o público é a gestão, o cliente ou o analista sem SQL. A curva é baixa, o relatório sai navegável e exportável, e o mapeamento visual de estados resolve os "números crus" sem escrever CASE. É a melhor ferramenta para levar o dado do service desk a quem não abre um terminal.

Escolha o Grafana quando o painel é operacional e em direto - fila por grupo, SLA em risco, tickets por hora - para a equipa técnica ou o NOC. O time picker, o auto-refresh, os alertas multicanal e o provisioning como código são vantagens reais que o Metabase não cobre bem.

Use os dois quando o mesmo GLPI serve públicos diferentes: Grafana na parede da operação, Metabase na mão da gestão e do cliente. É comum e funciona, mas assuma o custo de manter dois BIs - não escolha esse caminho "por garantia".

Custo e esforço

A licença não é o eixo da decisão: ambos têm uma edição open source gratuita que chega para painéis do GLPI, e os planos pagos (Metabase Pro/Enterprise, Grafana Enterprise) só entram em cenários de escala ou governança. O custo real é o da modelação. A parte pesada não é instalar - é conhecer o esquema do GLPI: mapear estados e prioridades, lembrar do is_deleted, resolver a árvore de entidades e não sobrecarregar a produção. Como intervalo honesto: um punhado de painéis operacionais no Grafana sobe numa tarde; um conjunto de relatórios de gestão bem modelados no Metabase, com filtros por cliente e estados traduzidos, costuma consumir de dois a quatro dias de trabalho até ficar fiável. Para saber que métricas colocar em cada painel, veja o nosso guia de KPIs para Service Desk no GLPI.

Na NexTool implementamos Metabase e Grafana sobre o GLPI de clientes nas duas frentes - relatório de gestão e painel operacional - sempre com utilizador só de leitura e sem derrubar a produção. Se quer os painéis certos para o público certo, sem ficar refém de um BI que não serve, a nossa consultoria desenha essa camada de indicadores de ponta a ponta.

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