A simpler self-hosted OpenObserve alternative

OpenObserve and Central Logging pitch the same first sentence: a self-hosted single binary, no cluster, no JVM.

Then they diverge, and the honest summary is short. OpenObserve does more, and it is free. If you have read this far expecting a page explaining why a $187 product beats an AGPL-licensed one on features, it does not.

What follows is the case for the smaller tool, which is a real case but a narrow one.

Start with what OpenObserve has

It is free and open source, under AGPL-3.0, with a commercial enterprise edition alongside.

It is an observability platform, not a log server. Logs, metrics, traces, real user monitoring, and AI/LLM observability — one product, one binary.

It queries with SQL and PromQL. SQL for logs and traces, PromQL for metrics, no proprietary query language to learn.

It stores in Parquet and is designed around object storage. Single-node mode defaults to local disk (ZO_LOCAL_MODE_STORAGE=disk), and you can point it at S3 without changing anything else. Its own documentation describes a largest production deployment ingesting over 2 PB a day.

It scales past one node. Turn ZO_LOCAL_MODE off and it becomes a cluster with separate roles.

It alerts, scheduled and real-time, with anomaly detection and several notification channels.

That is a genuinely impressive amount of software to get for nothing, and for a team that wants traces alongside logs there is no argument to make here. Install OpenObserve.

The case for less

Three reasons people pick the smaller thing, and only the third is about features.

One: the storage is a SQLite file. Central Logging writes one SQLite database per log source, WAL mode, on the local disk. You back it up by copying a file. You query it with sqlite3 when the web UI is not what you want. There is no WAL directory, stream directory, Parquet compaction or object-store lifecycle to understand, because there is nothing that needs them at this size.

That is a real limit, not a boast. It is sized for teams under roughly 10 GB a day. Above that, the design stops being an advantage and starts being the problem.

Two: ops monitoring is in the box. Not a log query dressed up as monitoring — separate features:

• Cron job monitoring that learns each job’s schedule from the last hundred check-ins and tells you when one is late. Nothing to declare. See cron monitoring.
• Website uptime checks with keyword and TLS-expiry conditions.
• Host check-ins and inventory — which servers are reporting, what is installed, what is running.
• Prometheus scraping and charts, without running Prometheus and Grafana.

For a small team, those four are usually three more self-hosted services avoided. That is the thing being bought.

Three: the licence. AGPL-3.0 is fine for most people and a hard no for some — typically anyone embedding a log viewer in something they ship, or working somewhere with a policy about network-copyleft. Central Logging’s licence is a one-time purchase with no source obligations. If AGPL is not a problem for you, ignore this paragraph; it is the least interesting difference on the page.

Side by side

The bottom four rows are the whole pitch, and the rows above them are the whole counter-argument.

Be honest about the auth row

Central Logging has one admin login. No SSO, no SAML, no OIDC, no LDAP, no roles, no second user account. The licence is verified offline against a compiled-in key, so there is no call-home, but there is also nobody to give read-only access to.

OpenObserve’s open-source edition has basic auth and its enterprise edition adds OIDC, OAuth, SAML 2.0 and LDAP. If more than one person needs to log in with their own credentials, that decides it, and no other row matters.

What the query experience is actually like

Both use SQL over logs, and the difference is what the SQL runs against.

OpenObserve parses structured fields at ingest and queries columns.

Central Logging keeps the raw line in a msg column and gives you SQLite’s JSON functions on top:

SELECT datetime("timestamp", 'unixepoch') AS at,
       json_extract(msg, '$.MESSAGE') AS message
FROM logs
WHERE json_valid(msg)
  AND CAST(json_extract(msg, '$.PRIORITY') AS INTEGER) <= 3
ORDER BY "timestamp" DESC
LIMIT 50;

Two details in there are load-bearing, and they are the kind of thing worth knowing before you choose. json_valid(msg) belongs in the WHERE clause — without it, one plain-text line among the JSON makes json_extract raise an error partway through, after rows have already been returned. And the CAST is not decoration: SQLite compares TEXT above every integer, so an uncast <= 3 matches nothing at all, silently.

That is the trade. Less schema, more SQL. Querying logs with SQL covers it properly.

Things OpenObserve does that this does not

• Cost nothing.
• Traces and real user monitoring. Central Logging has neither.
• Store in object storage, with Parquet columnar files.
• Run as a cluster, past what one machine can hold.
• PromQL over metrics.
• SSO — OIDC, SAML, LDAP — in the enterprise edition.
• Anomaly detection on alerts.

Things Central Logging does that OpenObserve does not

• Monitor cron jobs, learning each job’s schedule rather than asking you to declare it.
• Check website uptime, with keyword and TLS-expiry alerting.
• Track host check-ins and inventory.
• Store logs in a file you can copy, read with sqlite3, and back up with cp.
• Ship without a copyleft licence, if that matters where you work.

Who should choose which

Use OpenObserve if you want observability — traces and metrics beside your logs — or if you expect to outgrow one machine, or if free is the requirement. It is the more capable product and it is not close.

Use Central Logging if logs are the whole job, the volume is modest, and you would rather the same binary also watched your cron jobs, your sites and your servers so you have fewer things to run.

Weighing the heavier stacks instead? The ELK stack and Grafana Loki comparisons cover those. For live Docker log viewing specifically, Dozzle is free and better at it than either.

Try it

The free download is the complete product, not a trial. Ship one server’s journal at it and see whether the smaller tool is enough.

14-day refund if you buy and it does not fit.