PROJECT TO SERVICE

GCP observability
Across every project

Collect Google Cloud platform and workload telemetry through OpenTelemetry, preserve project and region identity, and query large histories efficiently on a ClickHouse® database backend

See the query paths Plan the ingest path

gcp.observabilityOTEL IN · OPEN QUERIES OUT

GOOGLE CLOUD ESTATE OTel CollectorCloud Monitoring exportCloud Logging exportApplication 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

01Cloud metrics02Platform logs03Application traces04Audit events

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

Query project boundaries without creating data silos

Retain project, zone, region and service metadata on ingestion, then use it consistently across each query surface

02 / SERVERLESS

Investigate Cloud Run and function latency

Follow service metrics into slow traces and the corresponding structured application logs

03 / SCALE

Keep cloud telemetry fast as volume grows

ClickHouse database columnar execution, pruning and distributed queries keep analytical work close to the stored data

Service-specific collection

How GCP telemetry
Reaches PulsusDB

Export logs with Cloud Logging sinks and Pub/Sub, collect service metrics through a Google Cloud or OpenTelemetry receiver, and instrument workloads with OpenTelemetry SDKs. A collector or gateway normalises each feed to OTLP before it reaches PulsusDB

01 / LOGSCloud Logging sinks and Pub/Sub

LOG ROUTER → PUB/SUB → OTLP

Select projects and resource types in a sink, then have a subscriber or collector gateway emit structured OTLP logs

02 / METRICSCloud Monitoring metrics

CLOUD MONITORING → OTEL COLLECTOR → OTLP

Collect platform measurements for selected services and preserve project, zone, region and resource labels

03 / TRACESOpenTelemetry SDKs and collectors

WORKLOAD → OTEL COLLECTOR → OTLP

Export application traces from GKE, Cloud Run, Cloud Functions and Compute Engine using open instrumentation

TELEMETRY BY SERVICE

Know what to collect
And where it comes from

Compute Engine

VM metrics, system logs, application logs and traces

COLLECT WITHOpenTelemetry Collector and cloud metric receiver

GKE

Cluster metrics, container logs, events and workload traces

COLLECT WITHCollector DaemonSet and gateway

Cloud Run

Requests, container metrics, revision logs and traces

COLLECT WITHCloud Logging, Cloud Monitoring and OTel SDKs

Cloud Functions

Invocations, failures, duration, execution logs and traces

COLLECT WITHCloud Logging, Cloud Monitoring and OTel SDKs

Cloud SQL

Instance metrics, database logs and client spans

COLLECT WITHCloud Monitoring, log export and application tracing

Cloud Load Balancing

Request volume, response codes, latency and access logs

COLLECT WITHCloud Monitoring and Cloud Logging

VPC Flow Logs

Network flows with project and resource context

COLLECT WITHCloud Logging sink through Pub/Sub

Cloud Audit Logs

Administrative activity, policy and data-access events

COLLECT WITHCloud Logging sink through Pub/Sub

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 / CLOUD RUN LATENCY

histogram_quantile(0.99,
  sum by (le, service_name) (
    rate(http_server_request_duration_seconds_bucket[5m])
  )
)

Calculate tail latency for instrumented services with standard PromQL

LogQL02 / AUDIT FAILURES

{cloud_provider="gcp",
 cloud_account_id="production"}
|= "PERMISSION_DENIED"

Search audit and platform logs inside a selected project scope

TraceQL03 / SLOW PROJECT

{ resource.cloud.provider = "gcp"
  && resource.cloud.account.id = "production"
  && duration > 1500ms }

Find slow requests by project identity using TraceQL

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

GCP observabilityAcross every project

Keep the operational questionClose to the data