Grafana vs Kibana: o critério que decide a camada de visualização da sua stack
Autor: Pedro Tebaldi PM do KeepGreenA pergunta chega quase sempre pelo lado errado. O time abre uma planilha de recursos, marca o que cada ferramenta tem, soma as colunas e descobre que o placar deu empate. Não deu. Ou seja, as duas nasceram para resolver problemas diferentes e continuam melhores em coisas diferentes.
O que decide não é a lista de recursos. É de onde vem o seu dado hoje. Depois disso, quem escreve as consultas e quantos painéis a operação sustenta durante um incidente às três da manhã.
Este artigo compara as duas pela camada de visualização, que é onde a escolha realmente acontece. A decisão vizinha, sobre onde o log fica armazenado e indexado, está em qual backend guarda os seus logs. Dessa forma, as duas juntas fecham o desenho da stack.
De onde vem o seu dado: a pergunta que decide antes de qualquer comparação
Se todo o seu dado já vive no Elasticsearch, o Kibana entrega valor no primeiro dia sem nenhuma configuração de fonte.
No entanto, o dado costuma se espalhar entre Prometheus, CloudWatch, um PostgreSQL de negócio e um coletor OpenTelemetry. Nesses casos o Kibana não alcança a maior parte dele.
Essa é a assimetria estrutural entre as duas. O Kibana é a interface nativa de um motor específico; o Grafana é uma camada agnóstica que se conecta ao que existir. Portanto, a pergunta não é qual ferramenta é melhor, é quantas origens de dado a sua operação precisa correlacionar no mesmo painel.
O número ajuda a calibrar. Segundo um levantamento com 1.255 respostas publicado pela Grafana Labs, uma organização usa em média oito tecnologias de observabilidade, contra nove no ano anterior.
Consolidar caiu de moda como promessa, mas continua sendo o que reduz o tempo de diagnóstico.
Vale um alerta de leitura: a pesquisa é da própria Grafana Labs, parte interessada nesta comparação. A metodologia está declarada, o que a torna citável, mas o número não é levantamento neutro de mercado.
Grafana e Kibana lado a lado
Em resumo, a tabela abaixo traz as diferenças que mudam a decisão. Ela ignora de propósito estrelas de repositório e contagem de contribuidores, métricas que medem popularidade, não adequação ao seu ambiente.
| Dimensão | Grafana | Kibana |
|---|---|---|
| Origem | Fork do Kibana em 2014, voltado a séries temporais | Nasceu em 2013 como interface do Elasticsearch |
| Fontes de dados | 189 plugins de fonte no catálogo oficial | Só o Elastic Stack |
| Linguagem de consulta | PromQL, LogQL, SQL (uma por fonte) |
KQL, Lucene, ES|QL, Query DSL |
| Busca full-text livre | Depende da fonte; fraca fora do Elastic e do Loki | É a função central do produto |
| Alerta unificado | Regra única sobre qualquer fonte conectada | Nativo, porém restrito ao dado indexado |
| Exploração ad hoc | Explore, orientado a consulta escrita | Discover e Lens, sem escrever consulta |
| Detecção de anomalia e SIEM | Depende de integração externa | Módulos nativos no Elastic Stack |
| Licença do núcleo | AGPLv3 |
AGPL, ELv2 ou SSPL |
O catálogo de fontes é o número que mais separa as duas na prática. A Grafana Labs mantém hoje 189 plugins de fonte de dados no catálogo oficial de plugins, dentro de um total de 356 extensões. Por outro lado, o Kibana lê um motor só, por desenho.
Onde o Kibana é imbatível
O Kibana é a interface de exploração do Elastic Stack. Ele consulta índices do Elasticsearch como motor de busca e armazenamento, monta visualizações e sustenta os módulos de segurança e de aprendizado de máquina.
Fora do Elastic ele não opera. Por outro lado, dentro dele nenhuma outra interface chega perto na exploração de texto.
Vale destacar o Discover, o exemplo mais concreto. O analista digita um trecho de mensagem de erro e filtra por campo com dois cliques. Em seguida, navega por milhões de documentos sem escrever uma linha de consulta. Assim, em investigação de incidente a diferença aparece em minutos economizados por ocorrência.
Além disso, o caso de segurança pesa. Suponha que o mesmo índice alimente a operação de correlação de eventos em SOC, a detecção de anomalia e a trilha de auditoria. Nesse cenário, sair do Kibana significa reimplementar o que já vem pronto. Trocar a interface custa mais do que rende.
Somado a isso, entra a modelagem de dado orientada a documento. Log com estrutura irregular, campo que aparece em metade dos eventos, agregação por termo de alta cardinalidade: o Elasticsearch foi construído para isso. Consequentemente, o Kibana expõe essa capacidade sem intermediário nenhum.
Ebook: Como sobreviver à fatura cloud?
Nosso framework, Observability Maturity Index, mede a maturidade das operações em nuvem das empresas. Você encontrará: os quatro perfis de empresas, as métricas que você deveria estar medindo, um checklist de avaliação e um plano de ação para 90 dias.
Só o e-mail. Sem spam, e seus dados protegidos pela LGPD.
Onde o Grafana é imbatível
O Grafana resolve o problema oposto: correlacionar dado que mora em lugares diferentes. Ele conecta Prometheus, Loki, Elasticsearch, CloudWatch, bancos SQL e coletores OpenTelemetry no mesmo painel.
Inclusive, sustenta uma camada de alerta única por cima de todas essas fontes. Por isso ele domina ambientes distribuídos, onde nenhuma fonte isolada conta a história inteira.
A vantagem operacional aparece no incidente. Em vez de abrir três abas e cruzar horários na mão, o time olha um eixo de tempo só. Ali estão a métrica de saturação, o log da janela e o trace da requisição lenta. Consequentemente, o diagnóstico deixa de ser tentativa e erro.
Na operação do Instituto Butantan, o SESuite acumulava lentidão de 3 a 5 minutos por operação. A resposta padrão era reiniciar o serviço ou aumentar hardware. Montamos observabilidade da aplicação com stack aberta: consumo por processo, captura da query exata no SQL Server, logs no Loki e traces com OpenTelemetry.
Como resultado, a causa apareceu: query lenta somada a consumo de memória do Java. O ajuste saiu no banco e na aplicação, sem hardware novo, com os painéis operados pela equipe interna.
Por fim, o relato está no case de observabilidade do Instituto Butantan. No OpCast #06, Claudia Anania, CIO do instituto, conta como a TI sustentou a produção de vacinas.
O que mudou desde que o Grafana era só métrica
Vale registrar uma virada recente: o Grafana deixou de ser apenas painel de métrica. Com o Loki, ele consulta log com LogQL; com o Tempo, lê trace distribuído. Portanto, a premissa antiga de que o Grafana não serve para log envelheceu.
Essa expansão muda o cálculo de quem já usa o Elastic só por causa dos logs. Quem está montando o primeiro ambiente encontra a arquitetura de coleta, fonte e painel detalhada em como a ferramenta funciona por dentro. Em síntese, o ponto de partida quase nunca é o painel: é decidir quem entrega o dado.
O painel que sobrevive à primeira semana
Ferramenta escolhida não resolve painel mal desenhado. Por exemplo, um dashboard com 40 gráficos ninguém lê durante um incidente; um com três gráficos genéricos ninguém abre no dia seguinte. O critério é sempre o mesmo: cada painel responde a uma pergunta que alguém faz de verdade.
No OpCast #05, Miguel Moraes mostra como sai um painel de Grafana do rascunho ao uso. Ele aponta ainda onde a inteligência artificial ajuda no design e onde ela atrapalha.
Linguagem de consulta: o custo escondido da escolha
Aqui está a conta que quase nenhum comparativo faz. A ferramenta você instala em uma tarde; a linguagem de consulta o time carrega por anos.
O Kibana concentra a curva em um lugar só. Assim, quem aprende KQL e Query DSL resolve busca, agregação e visualização dentro do mesmo modelo mental. O ES|QL, mais recente, aproxima ainda mais a consulta do formato tabular que o analista já conhece.
Em contrapartida, o Grafana distribui a curva. Cada fonte traz a própria linguagem: PromQL para métrica, LogQL para log, SQL para banco relacional. A flexibilidade cobra em treinamento. O efeito prático é conhecido: dois ou três especialistas escrevem as consultas complexas e o resto do time consome painel pronto.
Portanto, avalie o time real, não o time ideal. Se a operação tem plantão em N1 que precisa investigar sozinho, a exploração sem consulta do Kibana tem valor difícil de substituir. Se a investigação sempre sobe para N2, a curva do PromQL deixa de ser obstáculo.
Licença, custo e a conta de operar dois painéis
Boa parte do que circula sobre licenciamento está desatualizada. Em agosto de 2024, porém, a Elastic voltou a oferecer AGPL para Elasticsearch e Kibana.
As opções ELv2 e SSPL seguem disponíveis, conforme o anúncio oficial da empresa. Do mesmo modo, o núcleo do Grafana já roda sob AGPLv3. Em suma, o argumento de “um é aberto, o outro não” deixou de separar as duas.
O custo real está em outro lugar. Nas duas plataformas, a fatura sobe com volume ingerido, retenção e número de séries distintas, não com o preço de lista da interface.
Inclusive, quem já viu a conta crescer sem explicação costuma encontrar a resposta na cardinalidade de métricas, que multiplica séries a cada rótulo novo.
Existe ainda o custo que não aparece em contrato: manter dois painéis. São dois onboardings, duas linguagens, duas listas de alerta e, ao mesmo tempo, dois lugares para procurar durante um incidente. Esse custo é aceitável quando cada ferramenta cobre um domínio distinto. Vira desperdício quando as duas mostram o mesmo dado.
O cenário híbrido: Grafana lendo Elasticsearch
Na prática, boa parte das equipes não escolhe uma das duas. Elas mantêm o Elasticsearch como repositório e apontam o Grafana para ele como fonte de dados.
Ao mesmo tempo, reservam o Kibana para o que só ele faz bem. Essa é, sobretudo, a montagem mais comum em ambiente que já tinha ELK antes de adotar Prometheus.
O ganho é direto. Em seguida, o painel de operação mostra log do Elastic ao lado de métrica do Prometheus, com uma regra de alerta só. A coleta com Prometheus continua onde está, sem ninguém migrar índice.
A perda também é concreta, embora quase ninguém escreva sobre ela. Pelo Grafana você não tem Discover, não tem Lens, não tem os módulos de aprendizado de máquina do Elastic nem os alertas nativos da plataforma. O que sobra é consulta estruturada sobre o índice, ótima para painel e pobre para caça livre.
A regra que funciona é simples: Grafana como painel único da operação, Kibana como bancada de investigação e de segurança. Ou seja, um cobre o dia a dia e o outro cobre o mergulho profundo. Quando essa divisão não se sustenta, provavelmente uma das duas ferramentas está sobrando.
Seus KPIs de TI e negócio visíveis para quem precisa tomar decisão.
Construímos painéis interativos que conectam métricas operacionais a indicadores de negócio em tempo real, com atualização automática.
Qual escolher a partir da stack que você já tem
Se todo o dado relevante está no Elasticsearch e a investigação de texto é rotina, fique no Kibana. Trocar a interface custaria a exploração livre e os módulos de segurança, sem devolver nada equivalente.
Por outro lado, se a operação já roda Prometheus, nuvem e aplicação instrumentada, o Grafana é a escolha. Isto é, só ele coloca essas origens no mesmo eixo de tempo.
Começando do zero, a decisão vira uma pergunta sobre o produto: operação de infraestrutura e aplicação pede Grafana com Prometheus e Loki; produto de busca, análise de texto ou segurança pede Elastic com Kibana. E quando as duas frentes existem, a montagem híbrida da seção anterior costuma sair mais barata que padronizar à força.
Antes de decidir, meça o que você tem: quantas fontes precisam conviver no mesmo painel, quem escreve as consultas e qual o volume mensal ingerido. Em última análise, sem esses três números qualquer comparativo vira preferência pessoal.
Vale o mesmo cuidado ao desenhar o que cada painel responde, tema do nosso serviço de projeto de painéis e gestão à vista.
Se a sua stack já cresceu além do que um time consegue acompanhar, fale com um especialista da OpServices. A gente mapeia as fontes, mostra onde a correlação está quebrada e desenha a camada de visualização que a sua operação sustenta.
Perguntas Frequentes
O Grafana é um fork do Kibana?
O Kibana é open source?
AGPL para Elasticsearch e Kibana, ao lado das opções ELv2 e SSPL que já existiam. Nenhuma licença anterior foi removida, então quem já usava sob ELv2 ou SSPL não precisou mudar nada. O argumento de que o Kibana não é software livre, ainda comum em comparativos publicados antes dessa data, está desatualizado.O Kibana lê alguma fonte de dados além do Elasticsearch?
