SUBSCRIPTION TO WORKLOAD

Azure observability
With OpenTelemetry

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

See the query paths Plan the ingest path

azure.observabilityOTEL IN · OPEN QUERIES OUT

AZURE ENVIRONMENT OTel CollectorAzure Monitor exportActivity 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

01Platform metrics02Activity logs03Application traces04Resource logs

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 / SUBSCRIPTIONS

See resource health across subscriptions

Preserve subscription, resource group, region and service identity as queryable resource attributes

02 / CHANGE CONTEXT

Put activity logs beside runtime symptoms

Search deployment and control-plane events alongside the metrics and traces emitted by the affected application

03 / DATA CONTROL

Keep the observability data plane in your architecture

Run stateless PulsusDB processes in front of the ClickHouse database topology and storage policy you choose

Service-specific collection

How Azure telemetry
Reaches PulsusDB

Use Azure Monitor and Diagnostic Settings to select platform telemetry, Event Hubs to move activity and resource logs, and OpenTelemetry instrumentation for application traces. A collector or gateway converts those feeds into OTLP before PulsusDB ingestion

01 / METRICSAzure Monitor metrics

AZURE MONITOR → OTEL COLLECTOR → OTLP

Collect selected resource metrics and retain subscription, resource group, region and resource identity

02 / LOGSDiagnostic Settings and Event Hubs

AZURE SERVICE → EVENT HUB → OTLP

Stream Activity Logs, diagnostic logs and flow logs to a collector or gateway that emits OTLP logs

03 / TRACESOpenTelemetry SDKs and auto-instrumentation

WORKLOAD → OTEL COLLECTOR → OTLP

Instrument applications on AKS, App Service, Functions and virtual machines with portable OpenTelemetry libraries

TELEMETRY BY SERVICE

Know what to collect
And where it comes from

Virtual Machines

Host metrics, event logs, application logs and traces

COLLECT WITHOpenTelemetry Collector and Azure Monitor

AKS

Cluster metrics, container logs, events and application traces

COLLECT WITHCollector DaemonSet and gateway

App Service

Request metrics, application logs and traces

COLLECT WITHDiagnostic Settings and OpenTelemetry SDKs

Azure Functions

Executions, failures, duration, logs and traces

COLLECT WITHAzure Monitor and OpenTelemetry instrumentation

Azure SQL

Performance metrics, audit logs and client spans

COLLECT WITHDiagnostic Settings and application tracing

API Management and Application Gateway

Requests, status codes, latency and access logs

COLLECT WITHAzure Monitor and Event Hubs

NSG and Front Door

Flow logs, WAF events and edge access logs

COLLECT WITHDiagnostic Settings routed through Event Hubs

Activity and Storage logs

Subscription changes, data access and service events

COLLECT WITHActivity Log and resource Diagnostic Settings

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 / REQUEST FAILURES

sum by (cloud_region, service_name) (
  rate(http_server_request_duration_seconds_count{http_response_status_code=~"5.."}[5m])
)

Aggregate application failures by service and Azure region

LogQL02 / ACTIVITY LOGS

{cloud_provider="azure",
 azure_resource_group="payments"}
|= "Failed"

Narrow activity and resource logs by cloud identity before evaluating the pipeline

TraceQL03 / REGIONAL LATENCY

{ resource.cloud.provider = "azure"
  && resource.cloud.region = "uksouth"
  && duration > 1s }

Search slow traces in a region without introducing a proprietary trace language

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

Azure observabilityWith OpenTelemetry

Keep the operational questionClose to the data