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 "por quê". Metabase e Grafana leem o mesmo banco MariaDB do GLPI e transformam esse histórico em painel - só que resolvem problemas diferentes, e escolher errado custa retrabalho.

O que muda ao ligar um BI no GLPI

Antes de comparar as duas ferramentas, é preciso entender que o banco do GLPI não foi desenhado para BI. Três detalhes definem a maior parte do trabalho de qualquer dashboard, seja no Metabase ou no Grafana:

• Status, prioridade e 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 disso sozinha - se você não traduzir os códigos, o gestor vê "status 2" no gráfico.
• Nada é apagado de verdade. O GLPI usa exclusão lógica: is_deleted = 1 marca o registro como "na lixeira". Esquecer o filtro is_deleted = 0 infla todas as contagens.
• É multi-entidade. A coluna entities_id segrega os dados por cliente ou área. Um painel que o cliente vai ver precisa filtrar a subárvore de entidades certa - e isso não sai de graça no SQL puro.

Some a isso um quarto ponto, puramente operacional: apontar o BI direto no banco de produção, em horário comercial, com consultas que varrem a glpi_tickets inteira junto de glpi_logs, é o caminho mais rápido para deixar o próprio GLPI lento. Voltamos a isso adiante.

Comparativo direto

Como conectar sem derrubar o GLPI

Independentemente da ferramenta, a conexão é a mesma: um usuário de banco só-leitura, idealmente apontando para uma réplica ou uma cópia restaurada de madrugada, nunca para o master de produção com permissão de escrita.

-- Usuario so-leitura para o BI (rode 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 '${SENHA_FORTE}';
GRANT SELECT ON glpi.* TO 'bi_ro'@'10.0.0.%';
FLUSH PRIVILEGES;

Com o acesso pronto, o primeiro artefato que resolve o problema dos "números crus" é uma consulta que traduz os códigos de status. Vale para os dois: no Metabase ela vira uma "Pergunta SQL", no Grafana um painel de tabela ou barra.

-- Chamados abertos por status, 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 atendimento (atribuido)'
    WHEN 3 THEN 'Em atendimento (planejado)'
    WHEN 4 THEN 'Pendente'
    WHEN 5 THEN 'Solucionado'
    WHEN 6 THEN 'Fechado'
  END AS situacao,
  COUNT(*) AS total
FROM glpi_tickets
WHERE is_deleted = 0          -- ignora a lixeira (exclusao 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 direto nas configurações do campo (de 1 para "Novo", 2 para "Em atendimento" e assim por diante), e o rótulo passa a aparecer em qualquer gráfico automaticamente. É um ganho de produtividade que o Grafana não tem - lá o CASE é obrigatório.

Grafana: dashboard como código

A vantagem do Grafana para quem opera muitos ambientes não aparece na tela, e sim no disco: fonte de dados e painéis são arquivos versionáveis. Provisionamos o mesmo dashboard em vários clientes a partir de um YAML e um JSON no Git, sem clicar em nada.

# /etc/grafana/provisioning/datasources/glpi.yaml
# Fonte de dados versionavel: o mesmo arquivo provisiona 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 conexoes: nao sufoque o GLPI
      timezone: America/Sao_Paulo
    secureJsonData:
      password: ${GLPI_BI_PASSWORD}

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

-- Painel de serie temporal: as macros ligam o seletor de periodo 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 na tela
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 trade-off que aparece na sustentação

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

Um detalhe que só aparece na operação é a segregação por cliente. Numa consultoria que atende vários clientes no mesmo GLPI (ou em GLPIs distintos), você precisa garantir que o painel do cliente A jamais mostre chamado do cliente B. No Metabase, o row-level security de verdade - o sandboxing por usuário - é recurso pago; 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 amarrada às entidades, mas o controle de quem vê o quê continua na sua mão. Não existe atalho grátis para isolamento multi-cliente - decidimos caso a caso, e na dúvida a gente separa por instância, não por consulta.

Veredito por cenário

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

Escolha Grafana quando o painel é operacional e ao vivo - fila por grupo, SLA em risco, chamados por hora - para o time técnico ou o NOC. O time picker, o auto-refresh, os alertas multi-canal e o provisionamento como código são vantagens reais que o Metabase não cobre bem.

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

Custo e esforço

Licença não é o eixo da decisão: os dois têm versão open source gratuita que dá conta de dashboards 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 de modelagem. A parte pesada não é instalar - é conhecer o schema do GLPI: mapear status e prioridades, lembrar do is_deleted, resolver a árvore de entidades e não onerar a produção. Como faixa honesta: um punhado de painéis operacionais no Grafana sobe numa tarde; um conjunto de relatórios gerenciais bem modelados no Metabase, com filtros por cliente e status traduzidos, costuma consumir de dois a quatro dias de trabalho até ficar confiável. Para saber quais métricas colocar em cada painel, vale o nosso guia de KPIs para Service Desk no GLPI.

Na NexTool implantamos Metabase e Grafana sobre o GLPI de clientes nas duas frentes - relatório gerencial e painel operacional - sempre com usuário só-leitura e sem derrubar a produção. Se você quer os dashboards certos para o público certo, sem virar refém de um BI que não serve, nossa consultoria desenha essa camada de indicadores de ponta a ponta.

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