Cuando un servicio empieza a fallar, normalmente las señales están dispersas: métricas en Prometheus, logs en otro backend, traces en una tercera herramienta y alertas sin contexto. El OpenObserve intenta unificar ese trabajo en una plataforma open source para logs, métricas, traces, RUM, dashboards, alertas e incidentes. Escrito en Rust, consulta logs y traces con SQL, métricas con SQL o PromQL y utiliza Parquet con almacenamiento orientado a objetos para reducir el coste de retención.
Resumen en vídeo: la demostración oficial de dos minutos muestra la instalación y los primeros pasos de OpenObserve. URL: OpenObserve 2-Minute Demo: Quick Install and Setup.
Qué es OpenObserve
OpenObserve, también llamado O2, es una plataforma de observabilidad unificada. La idea no es reemplazar todos los agentes que recopilan telemetría, sino ofrecer un destino y una interfaz comunes para las señales: logs, métricas y trazas distribuidas. La plataforma también incluye cuadros de mando, alertas, pipelines de ingestión, gestión de incidentes, monitorización de usuario real (RUM) y recursos de observabilidad para aplicaciones de IA.
El proyecto es open source bajo AGPL-3.0. También hay una edición Enterprise y el servicio OpenObserve Cloud. Esto importa en la elección: la edición OSS es útil para quienes quieren control de la infraestructura y de la residencia de los datos; las funciones corporativas específicas, como SSO, RBAC granular, búsqueda federada y gestión de carga, pertenecen a la oferta Enterprise.
Por qué unificar logs, métricas y traces
Las tres señales responden a preguntas diferentes:
- Métricas muestran tendencia y estado agregado: uso de CPU, tasa de errores, latencia y volumen de peticiones.
- 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 y 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.
Cómo la arquitectura reduce el número de piezas
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.
Características principales
| Á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. |
Instalación rápida en Docker para laboratorio
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:latestAbre 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.
Del laboratorio a producción
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, cuadros de mando y 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 y 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.
Cuándo tiene sentido — y cuándo no
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.
Un vídeo más: comparación con 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.
Fuentes oficiales y próximos pasos
- Repositório OpenObserve no GitHub
- Documentación 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.