Query accounts and regions as one estate
Keep cloud account, region, availability zone and service attributes attached to every signal instead of navigating separate monitoring stores
ACCOUNT TO SERVICE
AWS observability
Without another silo
Route service metrics, logs and traces through an OpenTelemetry pipeline, preserve account and region context, and query the result on a ClickHouse® database backend
aws.observabilityOTEL IN · OPEN QUERIES OUT
AWS ENVIRONMENT ADOT CollectorCloudWatch telemetryVPC Flow LogsOTel SDKs
STATELESS PULSUSDB
Ingest APIsnormalise · batch · route
Query compilersPromQL · LogQL · TraceQL
STATEFUL DATABASE ClickHouse® database signal-aware schemas
rollups · tiering · scale
rollups · tiering · scale
Complex work is pushed down to the dataReduced results return
01Service metrics02Cloud logs03Distributed traces04Flow 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
Move from an error rate to the request and log line
Use familiar signal-specific languages while shared OpenTelemetry attributes preserve the service context between them
Keep high-volume cloud telemetry economical
Use ClickHouse database compression, materialised metric rollups and object storage tiering for longer operational history
Service-specific collection
How AWS telemetry
Reaches PulsusDB
AWS services expose telemetry through CloudWatch, service log destinations and OpenTelemetry instrumentation. Route those sources through an ADOT or OpenTelemetry collector, or a gateway that converts cloud-native delivery into OTLP, then send the normalised signals to PulsusDB
01 / METRICSAmazon CloudWatch metrics
CLOUDWATCH → OTEL COLLECTOR → OTLP Select namespaces, accounts and regions in the collector, then preserve service dimensions as resource attributes
02 / LOGSCloudWatch Logs, S3 and Kinesis delivery
AWS EXPORT → OTEL GATEWAY → OTLP Route service logs through a processor or collector gateway that emits structured OTLP log records
03 / TRACESADOT Collector and OpenTelemetry SDKs
WORKLOAD → ADOT OR OTEL → OTLP Instrument applications and serverless functions, then export spans with AWS account, region and service context
TELEMETRY BY SERVICE Know what to collect
Know what to collect
And where it comes from
EC2
Host and application metrics, system logs and traces
COLLECT WITHADOT or OpenTelemetry Collector on the instance
ECS and EKS
Container metrics, workload logs and distributed traces
COLLECT WITHCollector sidecar, DaemonSet or gateway
Lambda
Invocations, errors, duration, function logs and traces
COLLECT WITHCloudWatch plus ADOT Lambda instrumentation
RDS
CPU, connections, storage, engine logs and client spans
COLLECT WITHCloudWatch metrics, log export and application tracing
DynamoDB
Consumed capacity, throttles, errors and latency
COLLECT WITHCloudWatch metrics and instrumented client spans
API Gateway and ALB
Request counts, status codes, latency and access logs
COLLECT WITHCloudWatch metrics and access-log delivery
VPC
Accepted and rejected network flows
COLLECT WITHVPC Flow Logs through CloudWatch or S3 delivery
CloudTrail and WAF
Account activity, API usage and security events
COLLECT WITHCloudWatch Logs, S3 or Kinesis delivery
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 / LAMBDA ERRORS
sum by (cloud_region, faas_name) (
rate(faas_invocations_total{status="error"}[5m])
)Group serverless failures by region and function using standard PromQL
LogQL02 / VPC REJECTS
{cloud_provider="aws",
cloud_region="eu-west-2"}
|= "REJECT"Search rejected flows after label selection has bounded the account and region scope
TraceQL03 / SLOW SERVICES
{ resource.cloud.provider = "aws"
&& resource.cloud.region = "eu-west-2"
&& duration > 2s }Find slow requests across instrumented AWS workloads using cloud resource attributes
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 · AGPLV3Bring the telemetry
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