The three signals
Observability exposes three kinds of telemetry, each answering a different
question. You read all three through the same workspace-scoped API, with an
engine that selects the provider and an open query language per signal.
Logs, metrics, and traces
Section titled “Logs, metrics, and traces”- Logs answer “what happened, in words”. A log line is a timestamped message with a set of labels. You query them with LogQL over a bounded time window and get back one page of lines, or you tail a stream to watch new lines arrive. Listing the log streams shows which label dimensions exist to query against.
- Metrics answer “how much, over time”. A metric is a named numeric series carrying labels and samples. You query them with PromQL either at a single instant or as a range with a step, and you discover what is queryable through the metric descriptors (the metric names) and their labels.
- Traces answer “where did this request go”. A trace is a tree of spans, each span naming a service, an operation, a start time, and a duration. You search traces with TraceQL, fetch one trace in full by its id, or read the service graph, which rolls the spans up into call counts and error counts on the edges between services.
The three are complementary: a metric tells you an error rate rose, the logs tell
you what the errors said, and a trace tells you which hop caused them. Because the
query languages are the open standards you already use (LogQL, PromQL, and
TraceQL), moving a dashboard or an alert onto qibdo does not mean rewriting
your queries.
Reads, not writes
Section titled “Reads, not writes”The three signals are query-only. Your workloads emit telemetry through the ingestion path; the read API never creates or edits a log, metric, or trace. That is why logs, metrics, and traces have no delete or update calls, only queries. The resources you do manage, alert rules, silences, retention policies, log sinks, and ingestion configs, shape how that telemetry is stored, routed, and acted on.
Engines and providers
Section titled “Engines and providers”Every query takes an engine path segment naming the provider that holds the
telemetry. qibdo is the engine available today; aws, gcp, and azure are
planned behind the same calls. An unknown engine is rejected, and a known engine
with no adapter yet returns an unimplemented error rather than silently falling
back, so a query always runs against the provider you named or fails loudly.
Workspace scope and organisation-wide queries
Section titled “Workspace scope and organisation-wide queries”Every query is scoped to a workspace, and a workspace’s telemetry is isolated from every other workspace’s: you only ever read your own. You name the workspace on the path; the platform authorizes you against it and applies the tenant scoping server-side, so naming another workspace without permission fails rather than leaking its telemetry.
To look across a whole organisation, pass - as the workspace. This runs a
read-only query over every workspace under the organisation that you are allowed
to read, and it requires an organisation-scoped permission. Two limits keep it
safe: an organisation must be supplied for the wildcard to resolve, and a live
tail cannot use it, since tailing is always scoped to a single workspace.