[privateip]

Summary

Three metric collectors set labels that the collection pipeline owns, so their values collided with the pipeline's own values. This renames the provider, namespace and node labels on the Edge, fabric routing and traffic policy metrics, and keeps every value. Alerts, their tests, the scrape config and the operator docs use the new names. A new unit test fails the build if any collector sets a reserved label.

Compatibility

Queries, dashboards and alerts on the old names stop matching. The downstream copy of these alerts and the traffic policy dashboard need the same rename, merged together with this PR, because staging tracks main. The release notes should list the renames, which are in the first comment.

Rolling back restores the old names.

Test plan

• The new test fails on main, naming exactly the three collectors, and passes here.
• The alert rule tests pass. The new tests fail against main's rules for all 13 affected alerts, so each alert still fires after the rename.
• Lint, build and unit tests pass. The branch merges in test: Exempt the MASQUE grant authority from the scrape test #1192, which fixes a unit test that fails on main, so either PR can merge first.
• End-to-end tests run in CI only. The local kernel lacks a module they need.

Fixes #1150

🤖 Generated with Claude Code

[privateip]

Renamed labels, for the release notes. Every value is unchanged.

Metrics	Old label	New label
galactic_edge_foundation_{attachments,routes,services}	provider	edge_provider
galactic_fabric_routing_*, except collect_success	namespace	resource_namespace
galactic_fabric_routing_deployment_*, galactic_fabric_routing_router_accepted	node	target_node
galactic_cni_traffic_policy_{rule,fallback}_*	namespace	resource_namespace

target_node is the node a deployment or router targets. The fabric routing series now also carry the pipeline's own node, namespace and pod for the controller pod, so:

• The fabric-router-controller PodMonitor drops honorLabels: true, which only kept the object's namespace from being scraped as exported_namespace.
• The fabric routing alerts also aggregate node away when they merge the two controller replicas. Without that, a leader change splits the merge. Each replica in the rule tests has its own node.

Checks I ran:

• TestCustomCollectorLabels type-checks the module and resolves the label names of every prometheus.NewDesc. It fails on a reserved name, or on a name it can't resolve, including a variable later written through an element, pointer or copy.
• promtool check rules and promtool test rules pass, which are the task test:alerts steps.
• task lint, task build and task test:unit pass, except TestEveryBinaryHasScrapeTest. That test already fails on main for cmd/masque-authority, and test: Exempt the MASQUE grant authority from the scrape test #1192 fixes it. With test: Exempt the MASQUE grant authority from the scrape test #1192 applied, internal/instrumentation passes under -race.
• task test:e2e stops locally at modprobe vrf.

[polylane]

Warning

Polylane could not verify the production impact of this pull request.

I checked the live production cluster infrastructure-control-plane-prod and its rule, scrape and dashboard inventory. Only one galactic workload runs there, galactic-controller-fabric (1/1 ready, --role=fabric), which registers none of the three renamed collectors, and no production rule or dashboard consumes the renamed metric families.

View the full analysis →

Also considered · 4 refuted

• Refuted · Renamed labels leave the production fabric-routing and edge alerts matching nothing · The 13 alerts this pull request rewrites exist in the repository bundle and in the downstream staging copy, but production's live galactic-bgp VMRule has no fabric-routing group at all, and the three edge alerts sit in groups production does not carry.
• Refuted · Dropping honorLabels re-keys fleet series on the production fabric-router-controller scrape · The scrape config this line edits is not applied in production: the production cluster carries no galactic scrape resource, and the fabric-router-controller binary does not run there.
• Refuted · Old collectors and new rules overlap during the rollout window · The mixed-version break needs a resource that both emits the old labels and is evaluated by a rule.
• Refuted · Production dashboards lose their traffic policy and edge series after the rename · The dashboards shipped by this workspace do not query the renamed families, so no production dashboard goes blank.

Analysed against 1 cloud account and 1 repository

• Cloud account: datum-cloud-prod
• Repository: datum-cloud/galactic

Polylane could not find the cloud resources this repository manages, so this review looked at the entire cloud account. Connect this repository to its resources and the next review will focus on exactly what this code deploys to.

_{Polylane analysed 4520959 for production impact. You can ask follow-ups by mentioning @polylane in a comment.}

Rate this review: 👍 helpful · 👎 not helpful · 😕 confusing

Previous verdicts (1)

Head	Verdict	Analysis
8a2a4ff	Production impact not verified	analysis

[ecv]

Approve.

The renames are complete and consistent in the collectors, in-repo rules, rule tests and PodMonitor, and a new test guards against reserved labels. The one real risk sits in infra: its staging copy of these rules still uses the old labels, so it must be re-copied in the same bundle bump.

The red Unit Tests is not this PR: TestEveryBinaryHasScrapeTest fails on cmd/masque-authority, which main has carried without a scrape test since #1176, and main's CI fails the same way.

• infra infrastructure/monitoring/galactic/staging/galactic-bgp-alerts.yaml is a copy of this file and is not touched here. Once staging picks up this bundle, its fabric-routing group (all 13 alerts) still aggregates without (pod, instance, ...), so the controller pod's new node label differs per replica: each alert doubles and a leader change splits the series and restarts for. Its annotations also render the controller's node and an empty $labels.namespace.
• The same copy's galactic-edge alerts use max by (provider, reason): provider is now empty, so providers merge into one alert per reason and the summary text loses the provider name.
• Production is not affected: infra's production overlay removes both groups and the production edge pins v0.8.0. The staging copy needs the identical rename and node aggregation, merged with the first staging bundle that carries this change.
• Every rule whose expression changes in this PR (all 13 fabric-routing and both edge alerts that group on provider) resets alert state in whatever evaluator loads it. This is staging-only today.
• The PodMonitor edit removes only honorLabels: true and its comment. It removed no relabelings, so job, pod, instance and node still come from the pipeline, and target_node keeps the old per-deployment node value for joins with kube-state-metrics (label_replace to node, or on (target_node) against a renamed side).

Follow-ups:

• infra dashboard galactic-traffic-policy (.jsonnet/galactic-traffic-policy/config.jsonnet) groups on exported_namespace for galactic_cni_traffic_policy_rule_* and fallback_*. It becomes empty once resource_namespace replaces it; the dashboard needs resource_namespace.
• Rename map for release notes: galactic_edge_foundation_{attachments,routes,services} provider to edge_provider; galactic_fabric_routing_* (except collect_success) namespace to resource_namespace; galactic_fabric_routing_deployment_* and router_accepted node to target_node; galactic_cni_traffic_policy_{rule,fallback}_* namespace to resource_namespace.

[ecv]

Approve.

The only change since 8a2a4ff adds masque-authority to noMetricsEndpoint, which fixes the TestEveryBinaryHasScrapeTest failure main has carried since #1176. The exemption is accurate: cmd/masque-authority serves only the grant API over TLS and registers no /metrics handler. My earlier findings on infra's staging alert copy and the galactic-traffic-policy dashboard stand.

Follow-ups:

• The grant authority exports no metrics, so issue, deny and authentication-failure rates are invisible. When it gets a metrics endpoint, drop it from the exemption list and add a scrape test.