Observability Stack
What does zop.dev create for Observability Stack?
zop.dev deploys 5 Helm releases (Loki, Cortex, Mimir, Tempo, and OpenObserve) with 5 GCS buckets and 5 dedicated service accounts with keys, one per component. Storage access uses per-component service-account keys rather than one shared identity, and the buckets bill continuously as telemetry accumulates.
| Field | Value |
|---|---|
| Cloud | gcp |
Every zop.dev GKE cluster can ship logs, metrics, and traces to a self-hosted, GCS-backed backend. The stack mirrors the AWS design with Google-native storage and identity.
Buckets, service accounts, and five Helm releases
Five GCS buckets, five dedicated service accounts with keys, and five Helm releases (loki, cortex, mimir, tempo, openobserve).
The per-component observability_config shape
Same per-component observability_config shape as AWS: replicas, autoscaling, persistence, resource limits, remote_write, ingestion limits.GCS replaces S3 and keys replace roles
Storage is GCS instead of S3; access uses per-component service-account keys.
Per-component identities, per-component keys
Each backend gets its own service account, and each account an exported key. The isolation is genuine: Loki’s credential reaches Loki’s bucket and nothing else, so one compromised component does not expose the whole telemetry estate. The cost of that isolation is 5 static keys in circulation, none of which expire on their own. On a platform that uses Workload Identity for application workloads, these are among the few exported keys around, and they belong on whatever rotation schedule the platform’s other standing credentials follow.
Buckets that only ever grow
Telemetry is the purest append workload: logs, metrics, and traces arrive every second the
cluster runs, and the 5 GCS buckets accumulate them at standard storage rates. The
per-component retention and ingestion limits in observability_config are the brakes. Set
deliberately, they cap the curve; left at defaults, the buckets grow linearly until the GCS
line item asks why. The other half of the cost is invisible: the Helm releases run on the
cluster’s own nodes, so ingesters and stores surface as GKE compute, not as a monitoring
bill.
The same stack on every cloud
The configuration shape (replicas, autoscaling, persistence, resource limits, remote_write, ingestion limits) matches the AWS and Azure variants exactly; only the storage substrate and identity mechanics are Google-flavored. For multi-cloud teams that symmetry is the operative feature: one set of runbooks, one alerting vocabulary, one mental model of Loki and Mimir behaviour, portable across providers. The GCP-specific knowledge reduces to two facts: telemetry lives in GCS, and access rides per-component service-account keys.