# 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.

Source: https://zop.dev/integrations/provision/gcp/observability-stack
Updated: 2026-08-19

---

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

```text
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.