CLUSTER TO CONTAINER

Kubernetes observability
On a ClickHouse® database

Bring cluster metrics, container logs and application traces together through OpenTelemetry. Keep Kubernetes telemetry queryable with PromQL, LogQL and TraceQL as clusters and retention grow

See the query paths Plan the ingest path

kubernetes.observabilityOTEL IN · OPEN QUERIES OUT

KUBERNETES ESTATE OTel Collectorkube-state-metricsContainer logsApplication SDKs

STATELESS PULSUSDB

Ingest APIsnormalise · batch · route

Query compilersPromQL · LogQL · TraceQL

STATEFUL DATABASE ClickHouse® database signal-aware schemas
rollups · tiering · scale

Complex work is pushed down to the dataReduced results return

01Cluster metrics02Container logs03Application traces04Kubernetes events

What this lets you investigate

Keep the operational question
Close to the data

PulsusDB keeps the collection and query surfaces open. The ClickHouse database handles high-volume storage and analytical execution while the signal-specific query language preserves the workflow your team already knows

01 / WORKLOAD HEALTH

Move from cluster pressure to the workload causing it

Filter by cluster, namespace, workload, pod and container using the resource identity already carried by OpenTelemetry

02 / DEPLOYMENT FAILURES

Search the logs around every failed rollout

Use indexed words and LogQL pipelines to narrow large container log volumes before inspecting the lines that matter

03 / SERVICE LATENCY

Keep infrastructure and application context aligned

Use shared Kubernetes resource attributes across metrics, logs and traces to follow a slow request back to its namespace and pod

Service-specific collection

How Kubernetes telemetry
Reaches PulsusDB

Deploy an OpenTelemetry Collector as a DaemonSet and gateway, or use your existing collector topology. Kubernetes receivers and processors attach cluster, namespace, workload, pod, container and node identity before every signal is sent to PulsusDB over OTLP

01 / METRICSPrometheus and Kubernetes receivers

SCRAPE → OTEL COLLECTOR → OTLP

Scrape kube-state-metrics, kubelet stats, node exporters, the API server and application metric endpoints

02 / LOGS + EVENTSFilelog and Kubernetes event receivers

NODE + API → OTEL COLLECTOR → OTLP

Tail container output from each node and convert Kubernetes events into structured OTLP log records

03 / TRACESOpenTelemetry Operator and SDKs

POD → OTEL GATEWAY → OTLP

Auto-instrument or manually instrument applications, then route traces through a cluster gateway

TELEMETRY BY SERVICE

Know what to collect
And where it comes from

Nodes

CPU, memory, disk, filesystem and network metrics

COLLECT WITHKubelet stats and host metrics receivers

Control plane

API server, scheduler and controller-manager metrics

COLLECT WITHPrometheus receiver scrape targets

Workloads

Deployment, StatefulSet, DaemonSet, Job and pod state

COLLECT WITHkube-state-metrics

Containers

Stdout, stderr, restarts, resource use and limits

COLLECT WITHFilelog and kubelet stats receivers

Kubernetes events

Scheduling, eviction, image and readiness events

COLLECT WITHKubernetes objects or event receiver

Applications

Request metrics, structured logs and distributed traces

COLLECT WITHOpenTelemetry SDKs and auto-instrumentation

Ingress and gateways

Request rates, status codes, latency and access logs

COLLECT WITHPrometheus scrape, filelog and OTLP

Persistent storage

Volume capacity, latency, errors and mount events

COLLECT WITHKubelet and CSI metric endpoints

PulsusDB receives standard OTLP. Cloud-native export, subscription and receiver configuration lives in the collection tier, so it remains replaceable and vendor-neutral

Three signals Three query languages

Ask the question
In its native language

PulsusDB compiles familiar observability queries into efficient database work, pushes filters and aggregation toward the ClickHouse database tier and returns only the result needed by the client

PromQL01 / CPU BY NAMESPACE

sum by (cluster, namespace) (
  rate(container_cpu_usage_seconds_total{container!=""}[5m])
)

Compare namespace pressure across clusters without changing the metric query language your dashboards use

LogQL02 / FAILED PODS

{k8s_cluster_name="prod-eu",
 k8s_namespace_name="payments"}
|= "CrashLoopBackOff"

Resolve the stream labels first, then use the word index to prune container log data

TraceQL03 / SLOW REQUESTS

{ resource.k8s.cluster.name = "prod-eu"
  && resource.k8s.namespace.name = "payments"
  && duration > 1s }

Search spans using the same cluster and namespace identity carried by the workload

One architecture underneath

Optimised for the signal
Unified at the platform

Metrics, logs, traces and profiles do not have the same read path. PulsusDB gives each one a purpose-built physical model, then exposes a consistent OpenTelemetry ingest layer and familiar query APIs above it

Explore the architecture →

Signal-specific models

Ordering keys, indexes, codecs and projections follow the dominant query shape for each signal

Stateless application tier

Scale ingest and query processes independently while durable state remains in the database tier

Efficient long retention

Compression, materialised rollups and object storage tiering reduce the cost of detailed operational history

Open client workflows

Use OpenTelemetry for ingest and PromQL, LogQL or TraceQL for investigation

OPEN SOURCE · AGPLV3

Bring the telemetry
Keep the query language

Start with the workload in front of you, then add the rest of the estate without adding another observability backend

View on GitHub ↗Read the documentation

Kubernetes observabilityOn a ClickHouse® database

Keep the operational questionClose to the data