Understand who is talking to what
Keep source, destination, protocol, port and cloud resource identity available for bounded LogQL searches
EDGE TO SERVICE
Network telemetry
Beside every workload
Normalise network metrics and flow logs through your collection pipeline, then query them beside application and infrastructure telemetry on a ClickHouse® database backend
network.observabilityOTEL IN · OPEN QUERIES OUT
NETWORK ESTATE Flow collectorsSNMP exportersCloud flow logsOTel gateways
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
01Interface metrics02Flow logs03Cloud network logs04Gateway traces
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
Track interface and gateway pressure over time
Use PromQL for rates, saturation and error ratios while materialised rollups reduce long-range scan volume
Put network symptoms beside service latency
Preserve shared resource and service attributes so operators can compare network changes with application traces
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 / INTERFACE ERRORS
sum by (device, interface) (
rate(network_interface_errors_total[5m])
)Rank error rates across network devices and interfaces with PromQL
LogQL02 / DENIED FLOWS
{network_transport="tcp",
cloud_region="eu-west-2"}
|= "DENY"Bound a flow-log search by protocol and region before matching the action
TraceQL03 / GATEWAY LATENCY
{ span.http.route = "/checkout"
&& resource.service.name = "api-gateway"
&& duration > 1s }Inspect slow gateway requests alongside the network telemetry for the same window
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