• Status: proposed
• Date: 2026-11-04
• Issue: #15

Context

SLOs need metric history. The cluster is destroyed after each session, so anything stored inside the cluster is lost with it. The README lists Azure Monitor, Prometheus, Grafana and OpenTelemetry, and the roles of each are not defined yet.

Decision

• Metrics: Prometheus format. Send them to an Azure Monitor workspace using Azure Monitor managed service for Prometheus. The workspace is in the persistent layer, so metric history survives cluster teardown.
• Logs: Log Analytics workspace, also in the persistent layer.
• Traces: OpenTelemetry instrumentation in the sample service, sent through an OpenTelemetry Collector in the cluster. The traces go to Application Insights (ADR 0019).
• Dashboards: saved queries on the workspaces, stored as code in monitoring/. There is no Grafana (ADR 0019).
• Alerts: Azure Monitor alert rules that notify an action group, with email as the first target. This is an assumption.

Consequences

• Metric history outlives each cluster, which SLO reporting needs.
• Ingestion and retention costs apply to the workspaces. Amounts are not estimated here.
• An SLO window is only meaningful while the service is running. Because the cluster is down between sessions, SLOs are measured over session time, with generated traffic. The architecture document says this.

Alternatives considered

• Self-hosted Prometheus in the cluster. No Azure ingestion cost, but history is lost on teardown unless it is written to persistent storage or remote storage.
• Azure Monitor only, without Prometheus. Less portable, and does not match the planned tool list.