Observability Stack

zop.dev’s Azure clusters ship logs, metrics, and traces to a Blob-storage-backed observability backend, matching the AWS and GCP stacks with Azure-native storage.

Helm releases writing to Azure blob containers

Five Azure Storage blob containers and five Helm releases (loki, cortex, mimir, tempo, openobserve).

The shared observability_config shape

Same per-component observability_config shape as the other providers.

The storage account comes from cluster provisioning

Backed by an Azure storage account created during remote-state / cluster provisioning.

One storage account, five containers

Azure’s variant leans on a storage account that already exists, created during remote-state and cluster provisioning, and adds 5 blob containers to it, one per component. That concentration is convenient and worth noticing: the telemetry history of the cluster lives in a single storage account, so its access keys, firewall rules, and lifecycle policies govern all of it at once. Anyone auditing who can read logs is really auditing that one account.

Capacity bills by the hour, grows by the day

Blob storage charges for what is stored, continuously, and telemetry is append-mostly. Logs, metrics, and traces arrive as long as the cluster breathes. Retention settings and the per-component ingestion limits in observability_config are the only brakes; with defaults left alone, the containers grow linearly and the storage line follows. The stack’s Helm releases also run on the cluster’s own nodes, so their replicas, persistence, and resource limits surface as AKS node capacity rather than as a monitoring product’s invoice. That is cheaper, but easier to misattribute.

Parity is the feature

The stack is configured through the same observability_config shape as the AWS and GCP variants, with storage swapped to Azure blobs. That shape covers replicas, autoscaling, persistence, resource limits, remote_write, and ingestion limits. For a team running clusters on more than one cloud, that symmetry is the practical value: dashboards, alert rules, and operational habits transfer between clouds without translation, and a runbook written against Loki or Mimir on one provider reads the same on this one. The cloud-specific part is deliberately confined to where the bytes land.