Loki vs Elasticsearch: como escolher seu backend de logs

Escolher o backend de logs certo define quanto sua equipe gasta por mês. Também determina quanto tempo leva para achar um erro em produção e quanto trabalho operacional sobra no fim do mês. Nesse cenário, duas ferramentas dominam a conversa: Grafana Loki e Elasticsearch.

Elasticsearch nasceu como motor de busca distribuído e virou o padrão de facto do stack ELK. Ele indexa cada linha de log como um documento JSON pesquisável. A Grafana Labs, por outro lado, desenhou o Loki com uma premissa oposta. A ferramenta indexa apenas labels, comprime o restante e armazena tudo em object storage barato.

Por isso, a decisão Loki vs Elasticsearch raramente é sobre qual é melhor de forma absoluta. Neste guia, vamos comparar as duas ferramentas em arquitetura, linguagens de consulta, custo, casos de uso e critérios objetivos de decisão dentro dos pilares da observabilidade.

O que é Grafana Loki?

Loki é um sistema de agregação de logs open-source criado pela Grafana Labs em 2018. A inspiração veio do modelo de indexação do Prometheus, que indexa apenas metadados.

Em vez de indexar o conteúdo completo de cada linha, o Loki indexa somente labels. Pares chave-valor como app=nginx ou env=prod formam o índice. O corpo dos logs é comprimido em chunks e guardado em object storage como S3, GCS ou Azure Blob.

Dessa forma, Loki reduz drasticamente o custo de armazenamento e o esforço operacional. Como resultado, ele se tornou o backend padrão em stacks LGTM (Loki, Grafana, Tempo, Mimir) e em ambientes cloud-native, sobretudo em monitoramento de Kubernetes, onde os labels já existem nativamente nos pods.

O ecossistema inclui agentes de coleta como Promtail e Grafana Alloy, integração nativa com Grafana para visualização e alertas via Alertmanager. Vale destacar que a filosofia de “indexar o mínimo possível” tem um preço. Consultas do tipo “procurar uma string única em bilhões de linhas” ficam lentas, já que o Loki varre os chunks em vez de consultar um índice invertido. Para quem quer aprofundar, a documentação oficial do projeto detalha a arquitetura interna.

O que é Elasticsearch?

Elasticsearch é um motor de busca distribuído open-source lançado em 2010 pela Elastic NV, construído sobre Apache Lucene. Diferente do Loki, ele indexa o conteúdo completo de cada documento usando um índice invertido. Com isso, cada palavra fica pesquisável em milissegundos.

Em um pipeline típico de logs, o Elasticsearch opera junto com Logstash ou Beats para ingestão e Kibana para visualização. Esse conjunto forma o stack ELK. Por outro lado, sua aplicação vai muito além de logs: SIEM, busca em catálogos de e-commerce, analytics de dados e motores de recomendação rodam sobre a mesma engine.

O ponto forte do Elasticsearch é a flexibilidade de consulta. Com Query DSL e KQL, equipes executam agregações complexas, busca full-text, fuzzy matching e análises estatísticas sobre gigabytes de logs. Para um texto mais aprofundado sobre a ferramenta, veja o artigo dedicado no blog da OpServices ou o material de referência oficial.

Entretanto, essa capacidade tem custo. Manter um cluster Elasticsearch saudável exige tunning de JVM, shards, replicas, hot/warm/cold tiers e mais hardware. Isso pesa no TCO quando o volume de logs cresce.

Diferenças arquiteturais: indexação, armazenamento e escalabilidade

A diferença mais importante está na forma como cada ferramenta organiza os dados no disco. Loki trata logs como streams identificados por labels e comprime o resto. Elasticsearch trata logs como documentos ricos e indexa tudo.

Na prática, isso muda o perfil de recursos. Loki consegue armazenar o mesmo volume consumindo até 10 vezes menos espaço do que Elasticsearch, porque só o metadata vai para o índice. Além disso, o uso de object storage corta custo por GB em cerca de uma ordem de grandeza se comparado ao disco local SSD exigido pelos shards.

Contudo, Loki tem um calcanhar de Aquiles: alta cardinalidade. Se você adicionar um label como user_id ou trace_id, o número de streams explode e a performance degrada severamente. Elasticsearch, em contrapartida, lida bem com cardinalidade alta porque indexa tudo de qualquer jeito.

Para a coleta, ambos se integram bem a ferramentas padrão. Loki usa Promtail, Grafana Alloy, Fluent Bit ou agentes OpenTelemetry. Elasticsearch usa Filebeat, Logstash e aceita coleta via protocolo Syslog. A tabela a seguir resume os trade-offs arquiteturais principais.

 
A escalabilidade horizontal também difere. Loki escala separadamente ingester, querier e distributor em microsserviços. Elasticsearch escala shards em múltiplos nodes, o que tende a ser mais complexo de orquestrar em picos de volume.

Linguagens de consulta: LogQL vs Query DSL

A linguagem de consulta é o ponto onde engenheiros sentem diariamente a diferença entre as duas ferramentas. Loki usa LogQL — sintaxe inspirada no PromQL e orientada a labels. Elasticsearch oferece Query DSL em JSON e KQL como camadas de consulta.

LogQL é enxuta e parecida com a sintaxe que times de SRE já conhecem do Prometheus. Uma consulta típica filtra por labels e aplica um predicado de texto, conforme o exemplo abaixo.

# Erros do servico api em producao, ultimos 5 minutos
{app="api", env="prod"} |= "error"
  | json
  | status_code >= 500

 
Do mesmo modo, Query DSL permite filtros muito mais expressivos, incluindo agregações estatísticas, full-text com stemming e queries geoespaciais. A consulta equivalente em JSON fica assim.

{
  "query": {
    "bool": {
      "filter": [
        { "term": { "app.keyword": "api" } },
        { "term": { "env.keyword": "prod" } },
        { "range": { "status_code": { "gte": 500 } } }
      ]
    }
  }
}

 
Na prática, LogQL vence em consultas “quero ver todos os logs deste serviço nos últimos 15 minutos”. Query DSL vence em consultas “quero contar erros agrupados por endpoint e por versão com filtros complexos”.

Como resultado, o skillset da equipe pesa na decisão. Times acostumados com PromQL aprendem LogQL em dias. Times vindos de Splunk ou do ELK tradicional tendem a preferir a flexibilidade de Query DSL.

Comparativo de custo e recursos computacionais

Custo é onde a decisão geralmente se resolve em empresas com alto volume de logs. Loki tipicamente consome 5 a 10 vezes menos recursos computacionais do que Elasticsearch para o mesmo throughput de ingestão. Os dados vêm de benchmarks públicos de equipes como Arquivei e relatos da própria Grafana Labs.

Para ilustrar, um cluster Elasticsearch que ingere 500 GB/dia precisa de dezenas de nodes com SSD rápido, memória abundante para JVM heap e shards bem dimensionados. Loki, por outro lado, pode rodar o mesmo volume com poucos ingesters e S3 como storage. Dessa forma, o TCO mensal cai de forma significativa.

Entretanto, custo não se limita a infra. Operar Elasticsearch exige conhecimento profundo de JVM tuning, gestão de shards e políticas ILM. Loki tem menos botões para girar, mas exige disciplina no design de labels.

Em suma, quem tem ELK rodando bem raramente ganha muito migrando. Contudo, quem está começando do zero em ambiente cloud-native economiza bastante escolhendo Loki.

Casos de uso ideais de cada ferramenta

Apesar das diferenças, cada ferramenta brilha em cenários específicos. Loki se encaixa melhor quando o volume é alto, os logs são gerados por contêineres com labels ricos e o time já usa Grafana como painel central. Elasticsearch se encaixa melhor quando a análise precisa ser profunda, com agregações, busca full-text e cruzamento de campos.

 
Para quem está montando a stack do zero dentro de uma seleção moderna de ferramentas, o ponto de partida natural é Loki. A adoção de Elasticsearch costuma vir de requisitos específicos de busca ou compliance.

Ecossistema e integrações: onde cada ferramenta se encaixa

O ecossistema ao redor de cada backend pesa tanto quanto o core na decisão final. Loki nasceu dentro do guarda-chuva LGTM da Grafana Labs. Ele conversa nativamente com Prometheus para métricas, Tempo para traces e Mimir para séries temporais em escala. Já o Elasticsearch fica no centro do stack ELK, orquestrando-se com Logstash para pipeline de ingestão e Kibana para dashboards e exploração.

Grafana, vale notar, funciona como camada unificadora. Ela conecta Loki, Elasticsearch, Prometheus, Jaeger e dezenas de outras fontes em uma única experiência de navegação. Por isso, muitas equipes usam Grafana como frontend mesmo em stacks ELK, acessando Elasticsearch via data source nativo.

Ainda assim, Kibana continua imbatível para agregações complexas, detecção de anomalias e análises de segurança. Em suma, escolher Loki raramente descarta o Elasticsearch de vez — e vice-versa. O ecossistema moderno permite combinar as ferramentas conforme o tipo de análise que cada time precisa entregar.

Matriz de decisão: como escolher entre Loki e Elasticsearch

Ao invés de decidir pelo nome da moda, pese cinco critérios objetivos antes de fechar a arquitetura da sua stack de logs.

Em primeiro lugar, quantifique o volume diário em GB. Se passa de 200 GB/dia e o orçamento aperta, Loki costuma vencer. Em segundo lugar, identifique o tipo predominante de consulta.

Depois disso, avalie o skillset do time. Engenheiros com PromQL na memória dominam LogQL rapidamente. Times com background Splunk ou ELK pedem Query DSL. Por fim, considere compliance. Logs com retenção longa exigida pela LGPD ou por setor regulado podem pesar o custo do Elasticsearch. Nesse cenário, a storage em camadas do Loki fica mais atrativa.

Abordagem híbrida: quando usar os dois juntos

Nada impede rodar Loki e Elasticsearch em paralelo, e essa combinação é mais comum do que parece. Em arquiteturas maduras, Loki absorve o volume principal de logs de infraestrutura. Elasticsearch recebe apenas o subset crítico: logs de segurança, auditoria e payloads com necessidade de busca full-text.

O OpenTelemetry facilita essa divisão ao funcionar como camada de instrumentação única. Com instrumentação OpenTelemetry no ponto de coleta, um pipeline de processadores exporta a telemetria seletivamente para Loki ou Elasticsearch. A especificação oficial de logs do OpenTelemetry detalha os padrões de exportação.

Dessa forma, a decisão não é “um ou outro”, mas “qual backend recebe o quê”. Ingerir todos os logs no Elasticsearch fica caro. Uma alternativa é enviar só o que precisa de busca rica para lá e o resto para Loki. Essa divisão equilibra orçamento e capacidade analítica.

Conclusão

Escolher entre Loki e Elasticsearch raramente é uma decisão técnica pura. É um balanço entre custo de infraestrutura, tipo de consulta, skillset da equipe e stack já existente. Loki se destaca pelo baixo custo e excelente integração com Grafana e Kubernetes. Elasticsearch continua imbatível em busca full-text, agregações e casos SIEM.

Na prática, a maioria das empresas brasileiras se beneficia começando com Loki para logs de infraestrutura. Se necessário, adiciona-se Elasticsearch apenas onde a análise profunda justifica o custo. Avaliar volume, padrão de consulta e retenção exigida define qual caminho faz sentido. Revisar essa escolha a cada 12 a 18 meses evita manter arquiteturas que não escalam com o negócio.

Se você precisa de ajuda para desenhar sua arquitetura de logs sem desperdiçar orçamento, nossos especialistas em serviços de observabilidade podem apoiar sua equipe. Fale com um consultor e receba uma análise da sua stack atual.