Add label to mysqld-exporter to show the mysql instance

[ehsan karimi]

I install the mysqld-exporter on Kubernetes and when I scrape it with Prometheus, the instance label will show the pod IP of the mysqld-exporter instance and when we saw the MySqlIsDown alert, I don't know what MySQL instance is for it. I wanna add a label to the exposed metrics to show the host of MySQL.

[Matthias Rampke]

This is not supported in the exporter and we have no plans to add it. Most exporters use a different approach, which we recommend for exporters in general.

Deploy the expory as a sidecar alongside the MySQL instance. In Kubernetes, this means an additional container in the MySQL pod. This solves your problem by making each MySQL+exporter pod its own scrape target with its own instance label.

For most exporters, the way to think about them is not as a separate service that somehow interacts with what it is translating for (in this case, MySQL). Rather see the exporter as an out-of-process plugin, paired 1:1 with each MySQL process. For the purposes of monitoring, they are one unit, and when looking at metrics and alerts you don't need to worry whether a piece of software supports Prometheus natively or through an exporter.

I hope this helps!

Matthias

On Mon, Jan 17, 2022, 13:01 ehsan karimi <karimie...@gmail.com> wrote:

I install the mysqld-exporter on Kubernetes and when I scrape it with Prometheus, the instance label will show the pod IP of the mysqld-exporter instance and when we saw the MySqlIsDown alert, I don't know what MySQL instance is for it. I wanna add a label to the exposed metrics to show the host of MySQL.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/0a4a1c76-3436-4e92-be4d-e90e0e6cc069n%40googlegroups.com.

[Matt Palmer]

https://prometheus.io/docs/instrumenting/writing_exporters/#target-labels-not-static-scraped-labels
describes why this is a bad idea. Use server-side relabelling to give your
metrics meaningful metadata, if you need it.

- Matt

[Ben Kochie]

And to add to this, for the case of managed MySQL where the sidecar is not possible, we can add multi-target exporter support.

https://prometheus.io/docs/guides/multi-target-exporter/

There's a partial implementation of this in a PR on the exporter, but the author has not responded to feedback requests.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMV%3D_gbi7mV2UWL-n8aFAUWZY%3DVC2c3hPo8%3DfUKp7ZkefNwb2w%40mail.gmail.com.

[ehsan karimi]

I see. I did it with relabeling. But this option can be in the exporter because sometimes we have no access to the MySQL's host or some another reasons. The multi-target idea can be done as well. I have 3 mariadb nodes and I forced to run one exporter per mariadb instance and I have 3 exporter instances on production that is too resource consuming.

[Ben Kochie]

The exporter consumes almost no resources. It should not be resource impacting.

Just run the exporter 1:1 with your nodes, this is the correct design, It means you are communicating over localhost with the mariadb process, which allows you to improve security by restricting the exporter user to localhost only.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/74b3b95c-b37f-4356-9900-4b92413fc4ffn%40googlegroups.com.