-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adding a possibility to enable collectors additional to standard #216
Comments
Current behaviour is unusual but could be easily handled with any deployment system, for example |
This, though, would require that you manually add each new exporter to that role, so if you miss a changelog (or build from git-HEAD, which is quite common from what I experience), you have no idea that you might have disabled an exporter you want to have. |
True, but you'll still have to add rules or graphs for new metrics, otherwise they are useless. |
There are a couple ways this could be done. IMO the ideal way would be to drop the comma separate list approach and go with a map[string]bool approach for collectors, with flags to enable or disable each - with default collectors initialized as true before application of the flags. I'd also combine it with a 'enableDefault' flag, defaulting to true. That way if someone wants to only have a few specific ones they can use -enableDefault=false (or whatever it wound up being called) combined with eg. -enable-NAME=true for the ones they wanted. I acknowledge this would be much easier to implement with the cli package but should be doable with the flag package as well. |
I see how it's convinient, but I like the explicitness of the current approach. In general I assume we will have more collectors that are enabled by default and less that are disabled, give that we want to limit the node-exporter to system metrics for which it's usually cheap to have the enabled but not expose anything. @SuperQ Thoughts? |
I personally prefer the individual flags for each collector, the way we do it in the mysqld_exporter. No need for a global default flag, each collector can just keep their defaults. |
@SuperQ The question (as I understand it) is about enabling additional collectors without having to specific all collectors as you do now. |
Yes, individual collector flags allow for exactly that. Either take the default on a collector-by-collector basis, or override them. |
Ah, got it. What about we keep the comma-separated enabled flag and use that as default for per collector flags like |
What I'm thinking is this:
We can remove support for |
Just to be clear: |
Yes, that's what I was thinking |
see #390. |
Since #390 isn't exactly what we want, I created https://github.com/prometheus/node_exporter/compare/master...discordianfish:rework-flags?expand=1 In it's current form, the defaults are as before. You can enable or disable collectors explicitly. This is the desired functionality, correct? What's not working yet is enabling/disabling the collectors via the old flag and this is a bit tricky, since we need to first parse the collectors.enabled flag, then set up a bunch of flags. Hope that's even possible with stdlib flag. Pointers welcome but otherwise I'll dig deeper tomorrow. |
FYI: This work is now being done in #640 |
With #640 closed, it appears this can be closed as well. Feel free to re-open if I made a mistake. |
Hi,
over in IRC there was a discussion if it would make sense to include a commandline-flag of some sort to be able to enable collectors additional to the standard.
This would have several benefits:
-collectors.textfile.directory
) that can get fairly long.Therefore I'm proposing adding some possibility to just specify the additional collectors.
We talked about some ideas in IRC how this could be implemented, which I will just recall here:
-collectors.enabled.additional
-collectors.enabled
not just to take a list of collectors, but check if the first character is a+
. If that's the case, append to the list of default collectors.+
or-
to disable default collectors as well.These, are ideas emerging from the first discussion and do of course not have to be the final user interface.
Any opinions on the idea in general? Finding a good user interface would be the second step if the general idea is found to be worth investigating.
@juliusv @brian-brazil @grobie @fabxc
If I have forgotten to highlight someone, feel free to do it. ;)
The text was updated successfully, but these errors were encountered: