OpenObserve

Last reviewed Aug 26, 2026 · 870 words

OpenObserve replaces 4 containers with 1. The usual self-hosted observability stack is Grafana for dashboards, Prometheus for metrics, Loki for logs and Tempo for traces, each with its own config dialect and storage quirks. OpenObserve is a single binary that ingests all three signal types, stores them as compressed Parquet on local disk or S3, and serves its own dashboards and alerting on port 5080. The catalogue's 1 GB minimum is honest for a homelab, which is less than Loki plus Prometheus plus Grafana together, and the storage claim is the reason to try it.

One binary, one port, five minutes

services:
  openobserve:
    image: public.ecr.aws/zinclabs/openobserve:latest
    ports:
      - "5080:5080"
    environment:
      - [email protected]
      - ZO_ROOT_USER_PASSWORD=change-this-before-first-start
      - ZO_DATA_DIR=/data
    volumes:
      - ./oo-data:/data
    restart: unless-stopped

The root user is created from those two variables on first start and cannot be changed by editing them later, so set the password before the first docker compose up. Everything lives under ZO_DATA_DIR: the Parquet files, the metadata store and the dashboard definitions, which makes backup a directory copy. The same binary runs on bare metal without Docker if you prefer; download, set the same variables, run it.

Getting data in: bring your own shipper

OpenObserve does not ship a general-purpose host agent, and that is fine, because the ingestion side speaks the protocols the good shippers already talk. It accepts OpenTelemetry (OTLP over gRPC and HTTP) for logs, metrics and traces; an Elasticsearch-compatible bulk endpoint, so Fluent Bit, Filebeat and Vector configs written for Elastic work with a URL change; Prometheus remote write; and syslog. A single-line JSON endpoint per stream is the simplest possible integration:

curl -u [email protected]:change-this-before-first-start \
  -X POST https://logs.example.com/api/default/homelab/_json \
  -d '[{"host":"nas","level":"warn","msg":"disk 87% full"}]'

For containers, Vector with the docker_logs source and the Elasticsearch sink pointed at OpenObserve is the least-config route I have found. Streams are created on first write, fields are inferred, and there is no index template to design, which is the schema-less advantage over Elastic that the project leans on.

The storage claim is mostly true, with one asterisk

The project's headline is that it needs a small fraction of the disk Elasticsearch uses for the same logs. Columnar Parquet plus compression makes that believable and my own homelab experience agrees: the same container logs that filled a Loki volume take a noticeably smaller slice of the same disk. The asterisk is that Loki is also cheap on disk, and the real comparison for most self-hosters is OpenObserve versus the Grafana stack, where the win is operational simplicity more than gigabytes. Against Elasticsearch, which is the comparison the project makes and the one the Datadog alternatives page frames for people leaving hosted tools, the saving is large and the RAM saving is larger.

Query performance on cold data is where columnar storage costs you: searching 30 days for a single request ID means scanning Parquet, and it is slower than a hot Loki label lookup. For a homelab that is seconds, not minutes.

Where Grafana still belongs

OpenObserve's built-in dashboards are good enough that many people never open Grafana again, and the alerting covers threshold and absence rules with the usual webhook, Slack and email destinations. If you already have a wall of Grafana dashboards, there is an OpenObserve data-source plugin for Grafana, so the migration path is to swap the backend and keep the panels. What you do not get is Grafana's plugin ecosystem, its unified alerting across a dozen data sources, or its polish on visualisation types. SigNoz is the other unified option and is closer to Grafana's feel; OpenObserve is the lighter one.

The AGPL question, answered plainly

OpenObserve is AGPL-3.0 with a commercial enterprise edition holding some features (single sign-on, some role-based access and scaling features at last check). For a homelab, an internal team tool or a company using it for its own monitoring, the AGPL changes nothing. It matters only if you embed it in a product you offer to others over a network. The catalogue's "less mature ecosystem" con is the real cost: fewer integrations, fewer tutorials, and a project young enough (first released 2023) that breaking changes between versions still happen. Pin the image tag and read release notes before upgrading.

What I'd do

For a new homelab or a small team that has not yet built the Grafana stack, run OpenObserve as the single compose above, ship container logs with Vector over the Elasticsearch-compatible endpoint, send host metrics via Prometheus remote write from whatever exporter you already have, and put the data directory in your nightly backup. Give it 2 GB rather than the 1 GB minimum so queries over a month of data stay quick. If you already run Grafana, Loki and Prometheus happily, do not migrate; the monitoring category is full of people who did and gained little. The win is for those starting from zero.