PATTERN Cited by 1 source

Parallel-scraper observability migration¶

Problem¶

Replacing the metrics backend for a production fleet risks losing diagnosis capability precisely while engineers need to compare the old and new query paths. A big-bang Prometheus replacement also couples collection, storage, dashboards, alerts, and retention changes into one operational event.

Pattern¶

Keep the legacy metrics stack in service while a second, managed scraper collects a scoped metric tier and forwards it to the target backend. Move the metrics whose scale or query cost most needs the new system first. The transition is incremental: legacy workflows remain available while the target backend proves its query and operational properties on production telemetry.

instrumented targets
  ├── legacy scraper -> legacy Prometheus workflow
  └── managed scraper -> managed metrics workspace -> target dashboards

When it helps¶

High-cardinality metrics have exceeded the practical query envelope of the self-managed backend.
Existing dashboards and operational workflows cannot be interrupted.
Collection can be scoped by metric tier, namespace, job family, or another durable boundary.
The target backend has a compatible query/data model but must be validated under real production load.

Trade-offs¶

Reduced migration blast radius: the legacy path remains available while the new path is adopted.
Lower initial operational burden: a managed scraper and backend can remove self-hosted collection and HA work for the selected tier.
Temporary duplicate complexity: engineers must reason about two collection paths and avoid ambiguous dashboard or alert ownership.
No automatic correctness proof: parallel collection does not establish equivalence of scrape coverage, labels, query results, retention, or alerts; teams need explicit comparison and cutover criteria.

Adobe Firefly instance¶

Adobe Firefly retained self-managed Prometheus while AMP managed scrapers collected critical EKS GPU-training metrics for AMP. The initial tier contained 2 million time series. Reported query improvements then justified extending the managed system to remaining metric tiers. (Source: sources/2026-08-13-aws-adobe-firefly-simplified-observability-with-amazon-managed-prometheus)

patterns/dual-write-migration — related technique when applications write the same logical data to two stores; this pattern specifically duplicates scraping/collection during an observability transition.
patterns/phased-migration-with-soak-times — a fleet/cohort rollout discipline that can govern expansion of the managed metric tier.
systems/amazon-managed-prometheus-collector
concepts/metric-cardinality