Quando um serviço começa a falhar, normalmente os sinais estão espalhados: métricas no Prometheus, logs em outro backend, traces em uma terceira ferramenta e alertas sem contexto. O OpenObserve tenta reunir esse trabalho numa plataforma open source para logs, métricas, traces, RUM, dashboards, alertas e incidentes. Escrito em Rust, ele consulta logs e traces com SQL, métricas com SQL ou PromQL e usa Parquet com armazenamento orientado a objetos para reduzir o custo de retenção.
Resumo em vídeo: a demonstração oficial de dois minutos mostra a instalação e os primeiros passos do OpenObserve. URL: OpenObserve 2-Minute Demo: Quick Install and Setup.
O que é o OpenObserve
OpenObserve, também chamado de O2, é uma plataforma de observabilidade unificada. A ideia não é substituir todo agente que coleta telemetria, mas oferecer um destino e uma interface comuns para os sinais: logs, métricas e traces distribuídos. A plataforma também inclui dashboards, alertas, pipelines de ingestão, gerenciamento de incidentes, monitoramento de usuário real (RUM) e recursos de observabilidade para aplicações de IA.
O projeto é open source sob AGPL-3.0. Há também uma edição Enterprise e o serviço OpenObserve Cloud. Isso importa na escolha: a edição OSS é útil para quem quer controle da infraestrutura e da residência dos dados; recursos corporativos específicos, como SSO, RBAC granular, busca federada e gestão de carga, pertencem à oferta Enterprise.
Por que reunir logs, métricas e traces
Os três sinais respondem perguntas diferentes:
- Métricas mostram tendência e estado agregado: uso de CPU, taxa de erros, latência e volume de requisições.
- Logs preservam o evento e o contexto: mensagens da aplicação, erros, campos estruturados e auditoria.
- Traces acompanham uma requisição através de serviços, filas e bancos, tornando visível onde o tempo foi gasto.
O valor de uma plataforma unificada aparece na investigação. Um pico de erros no gráfico pode levar aos traces daquele serviço e, deles, aos logs do mesmo período. Isso não elimina a necessidade de instrumentar bem a aplicação nem corrige cardinalidade excessiva; apenas reduz as trocas de contexto entre ferramentas.
Se você já acompanha máquinas Linux, comece pelo nosso guia de Prometheus e Node Exporter. O OpenObserve pode complementar esse fluxo ao centralizar outros sinais, mas não há motivo para migrar às pressas uma stack estável apenas porque uma plataforma reúne mais funções.
Como a arquitetura reduz o número de peças
No modo de nó único, o OpenObserve usa SQLite para metadados e pode gravar localmente ou em armazenamento de objetos. É o caminho para laboratório, desenvolvimento e cargas que não exigem alta disponibilidade. A documentação também prevê nó único com S3, GCS, MinIO ou Azure Blob: continua simples de operar, mas os arquivos Parquet ficam em armazenamento mais durável.
Em alta disponibilidade, a topologia muda: o projeto separa os papéis de Router, Ingester, Compactor, Querier e Scheduler. Kubernetes orquestra os nós; PostgreSQL guarda metadados; NATS coordena o cluster; e o armazenamento de objetos mantém os arquivos Parquet. Isso escala melhor, mas não é “um binário sem operação”: é uma arquitetura de produção que precisa de capacidade, backups, atualização planejada, rede e observabilidade do próprio backend.
Parquet é um formato colunar adequado a consultas analíticas. Somado ao uso de armazenamento de objetos, ele é a base da alegação do projeto de até 140× menos custo de armazenamento em comparação com Elasticsearch. Trate esse número como uma referência do fornecedor, não como garantia: volume, retenção, compressão, padrões de consulta, índice e custo do seu bucket determinam a conta real.
Recursos principais
| Área | O que o OpenObserve oferece | Ponto de atenção |
|---|---|---|
| Logs | Busca textual, filtros, SQL e construção visual de consultas. | Defina schema, retenção e campos úteis antes de enviar tudo indiscriminadamente. |
| Métricas | Consulta por SQL ou PromQL, gráficos e alertas. | Compatibilidade de consulta não substitui revisão das regras existentes. |
| Traces | Exploração de traces OpenTelemetry, waterfall, flame graph e service graph. | O resultado depende de propagação correta do contexto entre serviços. |
| Dashboards e alertas | Painéis, variáveis, visualizações, alertas e incidentes. | Alertas devem ter dono, severidade, rota e procedimento de resposta. |
| Pipelines | Transformações de ingestão, normalização e conversão de logs em métricas. | Teste transformações em amostra; um parser errado pode destruir contexto. |
| RUM e IA | Core Web Vitals, erros, replay de sessão e sinais para aplicações GenAI/LLM. | RUM e dados de IA exigem atenção redobrada a PII, consentimento e retenção. |
Instalação rápida em Docker para laboratório
O procedimento abaixo usa a imagem OSS indicada pelo repositório do projeto. Ele é para teste local ou uma prova de conceito; não exponha a porta 5080 diretamente na internet e não use uma senha de exemplo em servidor acessível.
mkdir -p ~/openobserve/data
cd ~/openobserve
export ZO_ROOT_USER_EMAIL="admin@example.com"
export ZO_ROOT_USER_PASSWORD="$(openssl rand -base64 32)"
printf '%s\n' "$ZO_ROOT_USER_PASSWORD" > senha-inicial.txt
chmod 600 senha-inicial.txt
docker run -d \
--name openobserve \
--restart unless-stopped \
-v "$PWD/data:/data" \
-p 127.0.0.1:5080:5080 \
-e ZO_DATA_DIR="/data" \
-e ZO_ROOT_USER_EMAIL \
-e ZO_ROOT_USER_PASSWORD \
public.ecr.aws/zinclabs/openobserve:latestAbra http://127.0.0.1:5080 no próprio host ou faça um túnel SSH. Para uma equipe, publique a interface atrás de um proxy reverso com TLS e autenticação apropriada. Em produção, prefira uma tag de imagem testada em vez de latest e acompanhe a página de releases.
O usuário raiz é definido na primeira inicialização. Guarde a credencial fora do histórico do shell e de arquivos compartilhados, por exemplo em um gerenciador de segredos. Antes de apagar o teste, pare o container e remova o diretório de dados conscientemente: é ali que a telemetria local foi persistida.
Do laboratório à produção
Uma instalação de produção começa por decisões de dados, não pelo comando de Docker:
- Escolha a retenção por tipo de sinal. Logs de debug e replay de sessão não precisam ter a mesma janela que métricas de capacidade.
- Planeje o armazenamento. Para durabilidade e escala, use um bucket compatível com o desenho recomendado pelo projeto; para HA, armazenamento local não é suportado.
- Use OpenTelemetry quando possível. Padronizar instrumentação e contexto reduz dependência de agentes específicos.
- Separe organizações, streams e credenciais. Não misture produção, homologação e dados sensíveis sem uma política clara.
- Trate acesso como parte da arquitetura. A comparação oficial informa que a OSS não fornece RBAC granular; valide os requisitos de SSO, auditoria e permissões antes de abrir a plataforma para vários times.
- Teste restauração. Backup não testado é apenas uma esperança. Verifique dados, metadados e as configurações necessárias para recuperar o ambiente.
O guia oficial deixa claro que o modo HA requer Kubernetes, PostgreSQL, NATS e armazenamento de objetos. Se a equipe não tem maturidade para operar esses componentes, a edição Cloud ou um nó único bem delimitado pode ser uma decisão mais segura que uma implantação HA subdimensionada.
Consultas, dashboards e alertas
Logs e traces podem ser explorados com SQL; métricas podem usar SQL ou PromQL. A vantagem prática é preservar linguagens que muitos times já conhecem em vez de obrigar uma DSL proprietária. Ainda assim, migração de dashboards e alertas exige revisão: nomes de métricas, labels, janelas temporais, agregações e semântica de funções precisam ser validados contra o resultado anterior.
Comece por um painel pequeno e acionável: disponibilidade, taxa de erro, latência de percentis e sinais de saturação. Para cada alerta, documente qual dashboard abrir, quais campos filtrar, quem atende e qual ação pode ser tomada. Alertar sobre tudo é o caminho mais curto para ignorar alertas.
Vídeo oficial: este tutorial do canal OpenObserve percorre a criação de dashboards. URL: Building Dashboards with OpenObserve: A Comprehensive Tutorial.
Open source, Enterprise e Cloud
A edição OSS é AGPL-3.0 e gratuita, com logs, métricas, traces, RUM, dashboards e alertas. Segundo a tabela oficial de downloads, ela tem suporte básico a usuários, mas sem RBAC granular: os usuários têm acesso completo. A edição Enterprise acrescenta, entre outros itens, SSO, papéis personalizados, grupos, auditoria, busca federada, controle de workload e recursos avançados de pipeline e segurança.
No momento da consulta, a página comercial informa que a edição Enterprise self-hosted é gratuita até 50 GB/dia de ingestão; acima disso e para suporte contratado, é necessário contato comercial. Para o OpenObserve Cloud, a página mostra cobrança por GB ingerido e consultado, além de retenção padrão. Preços, limites e recursos comerciais mudam: confirme a página de preços e a comparação OSS versus Enterprise antes de fechar orçamento.
Quando faz sentido — e quando não
OpenObserve é uma boa opção para quem quer consolidar telemetria em torno de OpenTelemetry, SQL, PromQL e armazenamento de objetos; para times que já pagam caro por retenção de logs; ou para quem prefere operar uma plataforma integrada em vez de conectar várias peças.
Ele talvez não seja a escolha certa se a equipe só precisa de métricas de poucos hosts, se já existe uma plataforma com SLOs e integrações maduras que atende bem, ou se não há capacidade para operar dados, backup e upgrades. “Um binário” simplifica o primeiro teste; não elimina responsabilidade operacional, governança de acesso nem custo de armazenamento.
Mais um vídeo: comparação com Splunk
Para uma visão de posicionamento do produto, este vídeo de WPoets TV traz uma conversa com a OpenObserve sobre comparação com Splunk. É uma fonte complementar, não substitui teste de carga e cálculo de custo no seu ambiente.
Fontes oficiais e próximos passos
- Repositório OpenObserve no GitHub
- Documentação oficial
- Recursos da plataforma
- Arquitetura e modos de implantação
- Quickstart: Cloud e self-hosted
- Blog do OpenObserve
- Preços e downloads
O melhor próximo passo é pequeno: rode o laboratório, envie uma fonte de logs e uma métrica que você já conhece, crie um único alerta e calcule ingestão e retenção reais. Só então decida se vale ampliar a plataforma.