bigip_exporter
bigip_exporter copied to clipboard
ExpressenAB
Add bigip_host label
I'm using the exporter in a cluster with multiple bigip instances (I also have multiple exporter instances as well). It will be very helpful if the exporter will add a label with the bigip host it is collecting data from.
Hi, Yes, that should not be a big issue to fix. In the meantime perhaps you can solve it with relabeling in prometheus?
yeah I guess thats possible, but having it "out of the box" will be much more simple and readable.
Yes, I agree. It was just a suggestion if you wanted a temporary fix. I've created the branch feature/host-label which fixes this. I will create a release when I have the time but I've tested it and it seems to work fine. If you would like to use it now it's just to build it yourself.
Thanks for the quick fix! I'll wait for the release.
BTW, another possible enhancement I had in mind is to have the exporter work with a list of bigip hosts instead of just one. This way my deployment won't need to have multiple instances of the exporter. But I assume this one is more complicated to implement...
@cgunning do you by any chance have an example of a grafana dashboard that relies on the bigip exporter?
Hi. Regarding having several targets, this goes against the Prometheus guidelines so I would advise you to simply run one instance of the exporter per bigip-host.
Regarding the grafana dashboard, I only have one that is heavily dependent on our setup but the main parts of that dashboard are to show graphs over incoming and outgoing traffic for the virtual servers as well as some other things as traffic to nodes, irule failures and such. I'll see if I have the time to create a generic example dashboard.
On the multiple targets it does not actually go against the guidelines. The statement "Each exporter should monitor exactly one instance application, preferably sitting right beside it on the same machine." Is talking about cases where you can run this side by side. Like the node exporter which runs on the host your scraping. Ideally the instrumentation would actually be in the code you are trying to monitor, like kubernetes or the prometheus server itself responding to scrapes.
For cases like this where we can't update the code itself and it's not even feasible to run it on the host we're monitoring this behavior is perfectly reasonable. In fact they have several exporters that do just that.
The doc you reference goes on to delve into that in more detail just two paragraphs from the above quote.
There are two exceptions:
The first is where running beside the application your monitoring is completely nonsensical. The SNMP, blackbox and IPMI exporters are the main examples of this. The IPMI and SNMP exporters as the devices are often black boxes that it’s impossible to run code on (though if you could run a node exporter on them instead that’d be better), and the blackbox exporter where you’re monitoring something like a DNS name, where there’s also nothing to run on. In this case, Prometheus should still do service discovery, and pass on the target to be scraped. See the blackbox and SNMP exporters for examples.
However it does mean that the exporter should not have the hosts it will poll configured. The configuration should include the credentials to use (so that those aren't being passed on the wire) and BIG-IP specific settings like probably the partitions to poll, settings like BasicAuth and the namespace. Then when scraping it we pass a 'module' and a 'target' and it uses the settings specified by that module to scrape the target you've just passed.
We are actually working on a PR for this right now. It should come through in the next couple of days.
