Metropolis is now part of the standard Caproni rig

Caproni !94 merged today, and the standard rig now runs Metropolis, the GitLab Metrics Operator. The operator, its CRDs, grafana-operator, and real GitLabServiceMetrics for gitaly, redis, sidekiq and webservice ship as an opt-in fragment. Those four SLI sets are ported from the runbooks metrics catalog, with every metric name, label and threshold checked against the rig’s own Prometheus. Thanks to Andrew Newdigate, Brittany Wilkerson and Kev Kloss for landing it.

What this means

Until now, Metropolis could only be exercised against the synthetic samples in its own repository. Now a service team can:

• Develop monitoring against a real GitLab. Write your GitLabServiceMetrics and GitLabGrafanaDashboard resources and see the rules and dashboards the operator generates before anything reaches a shared environment.
• Opt in with two fragments. Enable o11y-metrics and metropolis in caproni.local.yaml, then caproni up. Metropolis deploys on its own but does nothing useful without o11y-metrics, which owns the Prometheus and Grafana it targets. Both charts live in private registries, so two helm registry login calls come first.
• Try your own resource. Apply it to the gitlab namespace with caproni kubectl apply, confirm it reports Ready with caproni kubectl -n gitlab get gsm, and open the gitlab folder in Grafana at grafana.caproni.test.

The Metropolis fragment doc in the Caproni repo carries the full setup, the checks, and one tear-down caveat: the CRDs are cluster-scoped, and deleting them deletes every Metropolis resource in the cluster.

The path forward

The rig is the development half. The production half is the Metropolis Adoption epic, opened on 7 October and owned by the Observability group. Its goal is to make the operator the source of truth for GitLab monitoring across GitLab.com, Dedicated and Cells, and Self-Managed, with service-owned declarations replacing centrally compiled rules. The work is staged:

1. Deploy to Dedicated and Cells: install order, least-privilege RBAC, signed and digest-pinned images, and a canary tenant before the fleet.
2. Runway GKE integration: how generated PrometheusRule objects reach Mimir and dashboards reach GitLab.com Grafana, proven with one rule and one dashboard from a Runway service.
3. Orbit and Artifact Registry: the first service-owned monitoring on the operator.
4. Dedicated legacy monitoring migration, Self-Managed support in CNG and the Helm charts, and customer adoption enablement.
5. GitLab.com migration and Runbooks retirement, with cross-cutting controls and PREP tracking running alongside rather than gating early adoption.

Where it stands today: the foundational deploys to Dedicated and Cells ( instrumentor!8723) and to Runway ( runbooks!11748, argocd apps!3958) are in flight in parallel. They land the operator, not the rules; rule migration follows. PREP runs as an evidence and gap-tracking exercise, and each target platform decides which findings block its own rollout stage.

Start here

• Ship service metrics with Metropolis: declare, inspect, ship, and see it locally in the rig.
• Metropolis: monitoring as part of the service: why declarations replace compiled dashboards.