# Observability Stack

> zop.dev deploys its 5-component observability backend on Azure (Loki, Cortex, Mimir, Tempo, and OpenObserve) as 5 Helm releases writing to 5 Azure Storage blob containers in the storage account created during cluster provisioning. Blob capacity bills continuously; retention and ingestion limits set the slope.

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

---

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

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