1. Going to production #
From a single node to a cluster.
Which mode to choose? #
| Situation | Mode |
|---|---|
| Trial, small team, losing a few minutes is acceptable | Single node on disk |
| Single node, data to protect | Single node with object storage |
| Availability required, heavy load | High availability on Kubernetes |
High availability is deployed with the official Helm chart, which requires object storage and PostgreSQL:
helm repo add openobserve https://charts.openobserve.ai
helm repo update
helm install o2 openobserve/openobserve -n openobserve --create-namespace -f values.yaml2. Best practices #
What avoids bad surprises.
Data #
- One stream per log family: the schema of a too heterogeneous stream grows fast, and
ZO_COLS_PER_RECORD_LIMIT(1000 fields) rejects events beyond that. - Per-stream retention: keep audit long, debug logs briefly.
- Few partitions, on few values: level or environment, never an identifier.
- Time-bounded queries: this is the first performance lever.
Security #
- Change the root password, and do not use it for collection.
- Put OpenObserve behind a TLS proxy.
- Keep SSRF protection on, allowing only necessary targets.
- Mask sensitive data in a real-time pipeline.
Operations #
- Back up: with local disk, the whole data folder; in HA, object storage and PostgreSQL.
- Pin an image version rather than
latest, and read the release notes. - Monitor OpenObserve: it exposes its metrics on
/metrics. - Disable telemetry if your policy requires it:
ZO_TELEMETRY=false.
3. Official sources #
To go further.
