OpenObserve in production: best practices

1. Going to production #

From a single node to a cluster.

Which mode to choose? #

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.yaml

2. 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.

Documentation #

• OpenObserve documentation
• Architecture
• Editions and download
• GitHub repository