Solutions for the environments you operate

Clouds to applications
One observability data layer

Begin with Kubernetes, a cloud provider or an application workload. Each path collects through OpenTelemetry, preserves the resource context operators need and exposes PromQL, LogQL and TraceQL over the same ClickHouse® database backend

operating.estate8 SOLUTION PATHS
INFRASTRUCTUREKubernetesAWSAzureGCP
OBSERVABILITY PLATFORMPulsusDBOpenTelemetry · open query APIs
PromQLLogQLTraceQLClickHouse® database
Explore by operating layer

What each solution collects and how engineers query it

Every path maps its environment into OpenTelemetry resource identity, retains the signals in query-optimised models and presents the query languages already used for investigation

InfrastructureCLUSTER 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 tracesKubernetes events
OPERATIONAL QUESTIONS
01Move from cluster pressure to the workload causing it
02Search the logs around every failed rollout
03Keep infrastructure and application context aligned
Explore Kubernetes →
COLLECT FROM
OTel Collectorkube-state-metricsContainer logsApplication SDKs
PromQLCPU 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

QUERY LANGUAGESPromQLLogQLTraceQL
All solution guides

Collection sources, query examples and operating context for every layer

Open a detailed guide for the services, collectors and signal-specific queries used in each environment. Every solution converges on the same stateless PulsusDB tier and stateful ClickHouse database layer

The common foundation

The same ingestion, query and storage architecture supports every solution

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

01 / COLLECT

OpenTelemetry in

Use collectors, SDKs and existing exporters to normalise telemetry before it reaches the platform

02 / MODEL

Signal-aware schemas

Store each signal according to its query shape instead of forcing every event into one generic table

03 / COMPILE

Familiar queries

Compile PromQL, LogQL and TraceQL into work the database can execute close to the data

04 / SCALE

ClickHouse database

Use columnar scans, compression, rollups, object storage tiering, replication and horizontal scale

OPEN SOURCE · AGPLV3

Deploy the platform once and add telemetry sources as your scope grows

Run stateless PulsusDB processes beside the ClickHouse database deployment you control, then connect each environment through OpenTelemetry

Read the documentation ↗View on GitHub