OpenTelemetry in
Use collectors, SDKs and existing exporters to normalise telemetry before it reaches the platform
Observability across the operating estate
Every layer
One data platform
Collect with OpenTelemetry, investigate with PromQL, LogQL and TraceQL, and retain large telemetry volumes efficiently on a ClickHouse® database backend. Start with one part of the stack without creating another isolated monitoring system
operating.estate8 SOLUTION PATHS
OBSERVABILITY PLATFORMPulsusDBOpenTelemetry · open query APIs
PromQLLogQLTraceQLClickHouse® database
Choose the layer you operate
Purpose-built paths
One platform underneath
Each solution starts from its own telemetry sources and operational questions. Every path converges on the same stateless PulsusDB tier, signal-aware data models and ClickHouse database execution layer
01
InfrastructureClouds and clusters
CLUSTER TO CONTAINER
Kubernetes monitoring
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
Cluster metricsContainer logsApplication traces
Explore Kubernetes → ACCOUNT TO SERVICEAWS monitoring
Route service metrics, logs and traces through an OpenTelemetry pipeline, preserve account and region context, and query the result on a ClickHouse® database backend
Service metricsCloud logsDistributed traces
Explore AWS → SUBSCRIPTION TO WORKLOADAzure monitoring
Send platform and application telemetry through OpenTelemetry, retain Azure resource context, and use the query languages your operators already know on a ClickHouse® database backend
Platform metricsActivity logsApplication traces
Explore Azure → PROJECT TO SERVICEGCP monitoring
Collect Google Cloud platform and workload telemetry through OpenTelemetry, preserve project and region identity, and query large histories efficiently on a ClickHouse® database backend
Cloud metricsPlatform logsApplication traces
Explore GCP → 02
WorkloadsServices and dependencies
CLIENT TO QUERY
Database monitoring
Bring database metrics, server logs and client spans into the same observability platform. Investigate saturation, errors and slow operations without giving up PromQL, LogQL or TraceQL
Engine metricsQuery logsClient spans
Explore Databases → EDGE TO SERVICENetwork monitoring
Normalise network metrics and flow logs through your collection pipeline, then query them beside application and infrastructure telemetry on a ClickHouse® database backend
Interface metricsFlow logsCloud network logs
Explore Network → REQUEST TO RUNTIMEApplication monitoring
Send application metrics, logs, traces and profiles over OpenTelemetry. Keep instrumentation portable and let PulsusDB expose the query languages already used by your dashboards and engineers
RED metricsApplication logsDistributed traces
Explore Applications → MODEL TO INFRASTRUCTUREAI and LLM monitoring
Store OpenTelemetry spans, metrics and logs from model calls and agent workflows beside the services, databases and infrastructure they depend on. Query the result on a ClickHouse® database backend
Model call tracesToken metricsAgent logs
Explore AI and LLM → The common foundation
Different telemetry
Consistent architecture
PulsusDB is the translation and API tier between open observability clients and the database. It remains stateless while the ClickHouse database owns durable storage and distributed execution
Signal-aware schemas
Store each signal according to its query shape instead of forcing every event into one generic table
Familiar queries
Compile PromQL, LogQL and TraceQL into work the database can execute close to the data
ClickHouse database
Use columnar scans, compression, rollups, object storage tiering, replication and horizontal scale
OPEN SOURCE · AGPLV3Start with one layer
Start with one layer
Keep one observability platform
Run PulsusDB beside the ClickHouse database deployment you control and connect the tools your team already uses