# Preserve a Prometheus discovery label before filtering metrics with it

> Keep the discovery and post-scrape relabeling stages in the correct order.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-141-preserve-a-prometheus-discovery-label-before-filtering-metrics-with-it/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:32:39+00:00
- Modified: 2026-09-17T16:42:36+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 1 minutes

## What you need to know

Keep the discovery and post-scrape relabeling stages in the correct order.

## Potentially affected

Use this review for an Azure Managed Prometheus PodMonitor or ServiceMonitor filter that depends on target-discovery metadata. Identify the original meta-label, the ordinary label chosen to preserve its value and the intended included targets. Keep this question separate from API migration or alert-rule deployment.

## DSE recommendation

DSE recommends reviewing the two transformation stages together before changing collection.

## Article

## Source facts

Microsoft states that discovered targets carry monitor-specific meta-labels and that labels beginning with double underscores are dropped after discovery. To filter metrics using that information, its guide first preserves the value with relabelings, then filters with metricRelabelings. The latter stage runs after scraping and before ingestion. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-metrics-scrape-crd).

## Applicability

Use this review for an Azure Managed Prometheus PodMonitor or ServiceMonitor filter that depends on target-discovery metadata. Identify the original meta-label, the ordinary label chosen to preserve its value and the intended included targets. Keep this question separate from API migration or alert-rule deployment.

## DSE recommendation

DSE recommends reviewing the two transformation stages together before changing collection. Write a small expected-result table containing an included target and an excluded target. Check that the preservation rule produces the exact label read by the later filter. Have the application owner confirm the excluded metrics are intentional before applying the change.

## Verification

In a controlled target set, inspect discovery results and the resulting ingested labels. Confirm the preserved value exists where the metric filter expects it, then compare included and excluded series with the table. Investigate a missing target separately from a filtered metric. Retain sanitized label examples and the deployed monitor configuration with the outcome.

## Official references

[Microsoft Learn: Create custom Prometheus scrape job from your Kubernetes cluster using CRDs](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-metrics-scrape-crd).

## Primary reference

- Name: Create custom Prometheus scrape job from your Kubernetes cluster using CRDs - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-metrics-scrape-crd
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Preserve a Prometheus discovery label before filtering metrics with it,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-141-preserve-a-prometheus-discovery-label-before-filtering-metrics-with-it/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.