Observability
Metropolis is now part of the standard Caproni rig
The GitLab Metrics Operator ships in Caproni, so service teams can test their monitoring manifests locally against a real GitLab. Production adoption is staged in the Metropolis Adoption epic.
Get distributed tracing on Runway
From scaffold to spans in Google Cloud Trace with LabKit v2, Fairway, and Runway — the effort is deploying.
Get structured logging on Runway
From scaffold to queryable logs in Grafana — JSON on stderr is the whole contract, and the scaffold already honours it.
Get Prometheus metrics on Runway
Expose metrics with LabKit v2, declare the port in Fairway, flip one deploy-time switch — then query Mimir in Grafana.
Ship service metrics with Metropolis
Declare your SLIs once in a GitLabServiceMetrics resource, review the generated rules and dashboards in CI, and ship them with your chart.
Check pod health: restarts and probes
Count pod restarts, read probe failures, and hit your liveness and readiness endpoints for a Runway service. What exists per cell.
Operate
Running a modular feature in production: what is deployed, pod health, rolling and rolling back, safe rollout, configuration, and knowing which cell is affected. Built for the middle of an incident.
Know which cell is affected
Get SLO alerts for your Runway service, split them by region and cluster, and understand how a cell identifies itself in alerts today.
The Observability Story
Instrument once with LabKit, collected by Runway with zero configuration, rendered on consistent dashboards — and, next, dashboards defined in the service repo and picked up automatically on deploy.
Co-located Grafana dashboards
Dashboards are part of the service: jsonnet in the service repo, compiled in CI, shipped in the Helm chart, and discovered by whatever Grafana lives in the cell.
Metropolis: Monitoring as Part of the Service
SLIs, alerts, and dashboards declared as resources in the service repo, shipped with the chart, and compiled in-cluster by the GitLab Metrics Operator.