Relabeling Question

[Murali Krishna Kanagala]

Hello everyone,

We are moving from wmi_exporter to windows_exporter and trying to do it in a smooth manner.

Our Alerts and Graphs are heavily dependent on WMI metrics and moving to Windows exporter may cause some issues because of a different metric prefix (wmi to windows).

We are looking for a temporary solution where we can keep both wmi and windows exporter metrics. This can be done by running both exporters on the server and by adding that to scrape config but I am looking for an option if I can use the relabel features to create a new metric with wmi_ prefix for every windows_ prefix metric.

For ex. If i scrape windows_cpu_seconds_total, i want to keep that metric and also create a new one like wmi_cpu_seconds_total.

Is there a way in metric relabeling to keep both old and relabeled metrics?

Thanks,

Murali Kanagala

[Brian Brazil]

This isn't possible. Relabelling can rename, but it cannot create or duplicate.

 

--

Brian Brazil

www.robustperception.io

[Alexander Golikov]

Hello, dears.
This is possible. You could create new timeseries from existing by new rule record.
I had the same problem with missing timeseries in RHEL6 OS and created it by conditional rule.
See my solution here:
https://stackoverflow.com/questions/59309508/conditional-rules-for-synthetic-series-in-prometheus/59317986#59317986

[Brian Candler]

You could scrape twice and relabel one of them - but then you'd be better off just scraping the old and new exporters once each.

I think is is probably the best option anyway.  Unless you are 100% sure that every wmi_xxx metric has exactly the same semantics and labels as the corresponding windows_xxx metrics, you could cause yourself accidental pain.

Do you mind if I ask, why did you decide to move from wmi_exporter to windows_exporter?  I rarely have to deal with Windows machines, but when I do, I'd like to know what influences the choice of exporter.  The fact you're considering relabelling suggests that the metrics they produce are very similar.

[Ben Kochie]

The wmi_exporter was renamed to windows_exporter when we moved it to the Prometheus Community org. It originally started out as only handling WMI. But the functionality was expanded to use windows-native system calls to replace a number of WMI calls for performance and reliability. (WMI is slow and unreliable)

IMO, relabeling, or duplicating data, is not the correct way to handle a transition like this. This can be solved in PromQL in Grafana or alerting rules.

A simple "or" operator can pick the correct metric.

windows_FOO or wmi_FOO

--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/be6e41c6-c853-454c-ac85-c0d31f2ab2a4o%40googlegroups.com.

[Murali Krishna Kanagala]

Thanks for the replies guys! We have chosen to switch to windows exporter in one shot and adjust grafana queries and alerts accordingly. 

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CABbyFmo2E7tsz0i8pgBLAmz7yxE39Fo5Zp4sa03qKCKgkdEQaA%40mail.gmail.com.