[prometheus-users] Re: Ensuring Persistent Labels in Ingested Metrics

2025-03-11 Thread mohan garden
Please ignore my previous email. I am repeating previous message again as i missed out setting under modified configuration b): Thank you for the response Brian, with both config a and config b, i was unable to see the source label. suggested config a) metric_relabel_configs: - source_l

[prometheus-users] Re: Ensuring Persistent Labels in Ingested Metrics

2025-03-11 Thread mohan garden
Thank you for the response Brian, with both config a and config b, i was unable to see the source label. suggested config a) metric_relabel_configs: - source_labels: [ source, __address__ ] regex: ";(.*)(:.*)?" target_label: source replacement: '${1}' output: *query: cus

[prometheus-users] Re: Ensuring Persistent Labels in Ingested Metrics

2025-03-11 Thread 'Brian Candler' via Prometheus Users
It's better to avoid honor_labels unless you really need it. It allows the exporter to do bad things like overriding the "job" and "instance" labels. Better to use metric_relabel_configs to relabel, at which point you have the combined set of labels from service discovery and the scrape. A missi

[prometheus-users] Re: Ensuring Persistent Labels in Ingested Metrics

2025-03-11 Thread mohan garden
here's some additional context - the following metrics are exported by the node exporter via text file: custom_metrics_from_server{ source="server1.example.com",status="run" } 3213 custom_metrics_from_server{ source="server1.example.com",status="pend" } 3215 hence they have source= label, wh