OpenObserve

Logs, metrics and traces from one connection — SQL log search with a live tail, PromQL metrics, and trace waterfalls.

OpenObserve in Kubo
The logs section: a SQL or full-text filter, chosen columns, and results paged by infinite scroll.

OpenObserve is the first connection in Kubo that carries all three signals at once — logs, metrics and traces — because that is how it is deployed. One instance, one organization, the whole telemetry of a system.

The organization rides on the connection

Every OpenObserve path is org-scoped (/api/{org}/…), so the organization is part of the connection rather than something you pick per request. The add form’s Test button doubles as org discovery: it lists the organizations your credentials can see and offers them as chips to choose from.

Authentication is HTTP Basic (a login email and password, or an API key) or a bearer token, with the usual optional CA.

Everything is a stream of records

A log line, a metric sample and a span are the same kind of row in OpenObserve, which shapes the module: Logs and Traces are SQL searches over a stream, while Metrics is PromQL against the Prometheus-compatible endpoints — the same surface a Grafana Prometheus datasource pointed at OpenObserve would use.

Everything is time-bounded

Every request must carry an explicit microsecond window (start_time / end_time) — a missing range is rejected outright, there is no “all time”. So one time-range picker is shared by all three sections, and it is always visible: you are never looking at results without knowing what window produced them.

An OpenObserve error body (a SQL parse error, say) surfaces the server’s own message rather than a bare status code.

In detail