~/LINUXexpert$
Articles

Announcing Cairn OBS: Kubernetes-Native Log Aggregation, AGPLv3, No Feature Gate

A log line is a message left behind by a process that isn’t around anymore. Something writes it at 3 a.m. under conditions nobody is watching, and walks away. Its entire job is to still make sense hours or weeks later to an engineer who wasn’t there.

That is, almost exactly, what a cairn is: a stack of stones left on a trail so that whoever comes after — a stranger, years later, in bad weather — can look at it and know someone was here, and this is the way through.

That’s the name. The project is Cairn OBS, and its public site went live today.

Disclosure: Cairn OBS is a LINUXexpert.org project. I’m the one building it. Treat this post as an announcement from the author, not a review.

What it is

Cairn OBS is a Kubernetes-native log aggregation and observability platform. Six things, in one system:

  • One query language over two engines. Pipe syntax for the common case, raw SQL as the escape hatch. Both compile to the same execution plan across ClickHouse and Tantivy, so there’s no performance tax for picking one style over the other. service=api status>=500 | stats count by host | sort -count and message:"connection refused" are not two different code paths — the compiler routes each clause to whichever backend actually answers it.
  • Dashboards. Multi-panel, built from saved queries, backed by the same engine as the search bar rather than a parallel path that drifts.
  • Alerting. Threshold and absence conditions on an interval, delivered to Slack, PagerDuty, or a generic webhook — with delivery attempts logged rather than fired and forgotten.
  • A cross-platform agent. One statically linked Rust binary against musl. journald or plain files on Linux, Event Log and ETW on Windows. No glibc runtime dependency, one file per host.
  • Multi-tenant RBAC. Per-tenant ClickHouse pools and Tantivy indexes, isolated at the connection layer rather than by row filter — including against the raw-SQL escape hatch. OIDC and SAML SSO, append-only hash-chained audit log.
  • AI-assisted queries. Plain-English question to structured query, inline fix suggestions, autocomplete. Self-hosted via Ollama by default. No cloud dependency required.

None of that is held back for a paid tier, because there isn’t one.

How it’s put together

Agents never write storage directly. Every record crosses a Kafka-API transport, which keeps storage credentials off the edge entirely and lets ClickHouse and Tantivy fail independently of one another:

agent → ingest → Redpanda → { ClickHouse-writer, Tantivy-indexer } → api → web

The dependency list is deliberately boring. Rust and musl for the agent. Go for ingest and API. Redpanda for transport. ClickHouse as the columnar store, partitioned by day. Tantivy embedded as the full-text index, so there’s no second search service to operate. SvelteKit on the front end, static-buildable, no server runtime in production. A kubebuilder-based Operator with one CRD and a Helm chart for fleets — and docker compose up for a homelab or a small team, with the same Tenant custom resource driving provisioning either way. Growing past one node shouldn’t mean a rewrite.

Every one of those was picked for being proven rather than novel. Infrastructure software people have to trust at 3 a.m. is the wrong place to be adventurous about dependencies.

The architecture page walks the pipeline properly; the stack page has the component-by-component rationale.

Why it exists

Most log tooling still runs on paradigms built for a world that no longer exists: a single machine writing to a local flat file, or an enterprise platform architected around one on-prem datacenter with a fixed number of boxes you could point at. Those tools didn’t fail. They did exactly what they were built for. Everything around them changed.

Workloads are containers that live for minutes. Infrastructure spans multiple clouds plus whatever’s still on-prem — frequently inside the same org, occasionally inside the same afternoon’s incident. Failure modes are distributed by default, not “the one box that’s down.” And the old tools got bent, extended, and duct-taped to cover ground they were never designed for, because ripping out load-bearing logging infrastructure is precisely the project nobody gets budget to do properly.

The mismatch shows up in four specific places:

  1. Per-GB ingest pricing punishes the verbose logging an incident actually needs. Teams quietly log less than they should, and find out during the postmortem.
  2. “Which cloud, which datacenter” is an afterthought instead of a first-class dimension of every query.
  3. Free-text search and structured querying get sold as two products instead of one language over both.
  4. Alerting and AI assistance arrive bolted on as a separate, often unauditable paid layer rather than living inside the query path itself.

Cairn OBS starts from the present rather than retrofitting the past. Cloud and on-prem are equally first-class inputs from day one — not a legacy on-prem product with a cloud bolt-on, and not a cloud product treating on-prem as an unsupported edge case. AI assistance runs through the same compiled query path every hand-written query already uses, so you can read what it produced and audit what it ran.

And the whole thing ships AGPLv3 — including multi-tenant RBAC and SSO, the two features open-core vendors almost universally hold hostage. Self-host it, fork it, run it as a service. The terms are identical for everyone, including me. The network-use clause is deliberate, not an oversight: modify it and offer it over a network, and your users get your source too. That’s the same protection that keeps this project from being taken closed downstream by anyone, myself included. The license page states it in full.

The code you can read is the code that runs. During an incident, that should be the baseline expectation, not a differentiator.

Why now

Three things converged in the last eighteen months.

The cost conversation stopped being an engineering complaint and became a budget line. Elastic’s 2026 observability research, conducted by Dimensional Research across more than 500 IT decision-makers, found that unexpected costs and overages are effectively universal — 97% of organizations reported cost surprises, and a majority of decision-makers now field explicit pressure from leadership to justify observability spend. Gartner figures put roughly a third of enterprise clients above $1M annually, with a small band above $10M. More than half of that spend lands on logs specifically, which are also the noisiest and most redundant signal in the stack. Dynatrace’s State of Log Management 2026 reports that close to 80% of teams are already filtering, archiving, or offloading logs to control the bill — deliberately reducing visibility into the exact data they’ll need next time. Industry survey work puts 96% of teams taking active cost-reduction steps, with 42% simply switching observability off in less-critical environments. That is not an optimization trend. That’s a pricing model actively degrading the practice it’s supposed to support.

The instrumentation layer settled. OpenTelemetry graduated from the CNCF in May 2026, announced at the Observability Summit in Minneapolis, putting it in the same maturity tier as Kubernetes and Prometheus, with over 12,000 contributors from more than 2,800 companies and the second-highest project velocity in the entire CNCF ecosystem. Practically, that turns proprietary agent lock-in from an architectural fact of life into a procurement problem you can actually name in a meeting. When the collection layer is standardized and portable, the backend becomes a swappable, comparable component — and a new backend no longer has to win an instrumentation war before it can win an evaluation.

The licensing ground shifted, twice. The last few years took the industry through HashiCorp’s BUSL relicensing, Elastic’s SSPL detour and eventual return to AGPLv3, Redis’s SSPL/RSALv2 move and subsequent AGPLv3 reversal, and Splunk landing inside Cisco. Operators learned an expensive lesson: the license on the thing you built your incident response around is not a settled question, and a rug-pull lands on you, not on the vendor. Post-Elastic and post-Redis, AGPLv3 with no commercial carve-out reads very differently than it did in 2021. It’s no longer an ideological flourish. It’s a procurement answer.

Add AI workloads on top — where token-level attribution and agent traces break the assumption that telemetry volume scales linearly with traffic — and per-GB billing goes from painful to structurally broken.

That’s the window. A backend that’s cheap per GB, honest about its license, and doesn’t care whether the signal came from a container in us-east-1 or an IBM i box in a warehouse.

Where the project actually stands

Early. The site is live, the architecture is settled, and the demo page has screenshots from a working prototype — but a public demo instance is not up yet, and I’m not going to pretend otherwise. IBM i (iSeries) support and cloud-native collectors for AWS, Azure, and GCP are on the roadmap, not in the binary.

What’s on the site today is the design, the reasoning, and the license commitment, published before the release rather than after — so that anyone who wants to argue with the architecture can do it while arguing still changes something.

Start at cairnobs.org. The about page covers the name and the case against retrofitting decades-old logging paradigms onto a multi-cloud present; the features page covers what’s built.

If you operate logging infrastructure at scale and something on those pages looks wrong to you, I want to hear it now.