opinions needed: extending an official prometheus client library to receive arguments

71 views
Skip to first unread message

vi...@tlmt.ch

unread,
Sep 6, 2018, 9:23:19 AM9/6/18
to Prometheus Users
TL;DR;

I implemented a feature into the official prometheus-net client library and would love to hear some opinions about whether this is a good idea or not.




In depth explanation

I'm developing a custom prometheus exporter that works just like the infamous blackbox exporter but will be able to collect more customisable metrics (with validating responses of endpoints and lots of funny stuff). This would be particularly helpful to perform "whitebox monitoring" for systems that do not offer a metrics endpoint them self. I guess we could even call it "whitebox exporter". I'm developing that thing in dotnet core and therefore I'm using the official prometheus-net library. Currently the library does a lot, but it's not possible to send arguments to the exporter, which then can be interpreted. Currently I have to configure the finally scraped endpoints directly inside my custom exporter but I would like to configure this inside prometheus and use relabelling to send the scrapping endpoint to my exporter as an HTTP Argument (like it's done with the blackbox exporter). A call to this exporter would then look like this: `https://my-exporter/metrics?target=https://google.com`. This is literally how it's done with the blackbox exporter.

As it stands I implemented the feature to receive the needed arguments and handle them inside the mentioned library. I created a pull request but the maintainer is not sure whether this is a good idea or not. 
We would love to hear some opinions of experienced prometheus users and developers.

Even more details can be found on the pull request: https://github.com/prometheus-net/prometheus-net/pull/94

Feel free to comment here or on the pull request on Github.

Thanks in advance !







Brian Brazil

unread,
Sep 6, 2018, 9:38:10 AM9/6/18
to vi...@tlmt.ch, Prometheus Users
Existing client libraries have specifically avoided adding such features, as passing arbitrary blobs of data from whatever is requesting the data is a layering violation and could make it quite a bit harder to operate the system. For example what if two collectors have different interpretations of a given URL parameter?

The way this is handled for the blackbox exporter and similar exporters is via a custom registry that is created just for the request, with a collector created also with the parameters for that request - https://github.com/prometheus/snmp_exporter/blob/master/main.go#L89 for example.

--
Reply all
Reply to author
Forward
0 new messages