Skip to content
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

Replace --collectors.enabled with per-collector flags #640

Merged
merged 14 commits into from
Sep 28, 2017

Conversation

carlpett
Copy link
Member

@SuperQ mentioned that after the switch to kingpin, now would be a good time to also replace --collectors.enabled with individual flags for each collector, since there is a breaking change anyway.

This PR does that. The flags are now --collector.<name>.enabled (or --no-collector.<name>.enabled to disable a default collector), but if there are shorter alternatives that might be good to consider.

This PR also moves the NodeExporter type into the collector package, as suggested by @SuperQ to follow mysqld_exporter #209.

It is possible to remove a few more exported symbols from the collector package, but I'd like some opinions on if that would be positive or not. Making Factories internal seems like a reasonable thing, for instance, but then we'd need to make --collectors.print call into some new function.

@carlpett
Copy link
Member Author

Working on the bash-fu to fix the e2e test script...

@carlpett carlpett force-pushed the collector-flags branch 2 times, most recently from 5c18ebc to 061842c Compare August 13, 2017 12:10
@@ -76,7 +83,8 @@ fi
./node_exporter \
--collector.procfs="collector/fixtures/proc" \
--collector.sysfs="collector/fixtures/sys" \
--collectors.enabled="$(echo ${collectors} | tr ' ' ',')" \
$(for c in $enabled_collectors; do echo --collector.$c.enabled ; done) \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor bash style thing here, for consistency I prefer to use ${var_name}.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, fixed!

@SuperQ
Copy link
Member

SuperQ commented Aug 13, 2017

This is great, thanks for taking care of this.

@discordianfish
Copy link
Member

Overall looking good, thanks!
One concern though: If a user wants a specific set of collectors enable, they would need to keep track of the currently enabled defaults and disabled the ones they don't need selectively, right?
I think we should have a way to only explicitly enable a list of collectors and I don't think this is possible with this right now. Maybe we could have a flag to disable the defaults? E.g --no-collector.defaults.enabled would disable all default-enabled collectors so you can specify explicitly which ones you want to use.

@SuperQ
Copy link
Member

SuperQ commented Aug 14, 2017

@discordianfish Either way, the user has to track collectors between releases. I'd rather keep this simple if possible.

I suggest we file an issue for "disable everything flag" and see if anyone really needs it.

@grobie
Copy link
Member

grobie commented Aug 14, 2017

I have similar concerns to @discordianfish and I'm not sure the current change is a clear win in usability. Given PromCon and related preparations, I won't have time to research for ideas in similar setups and comment before next week.

@SuperQ
Copy link
Member

SuperQ commented Aug 14, 2017

For what it's worth, this is the same style as we use on the mysqld_exporter, and I don't recall any requests for "disable everything by default".

To, me, there are some clear usability wins. The reasoning is detailed in #216.

@discordianfish
Copy link
Member

@SuperQ But as right now, without this PR you can explicitly set the collectors you want to use. With this change this isn't possible anymore which is why I believe we need to change this before merging this PR. Otherwise I would agree that such improvements could be made later.

The mysql-exporter is IMO a different story where the need to explicitly enable a specific set of option isn't as important.

@carlpett
Copy link
Member Author

One concern though: If a user wants a specific set of collectors enable, they would need to keep track of the currently enabled defaults and disabled the ones they don't need selectively, right?

@discordianfish Yes, pretty much. Which is the inverse of the current issue - if I just want to run with the defaults and add a few more, I will have to pull out the defaults, add the optional ones I need, and then keep that list up to date as I update the exporter.

Empirically, this need is more common requirement (the defaults are fairly uncontroversial, but I want to add one or two of the non-defaults), but maybe the groups I've worked with are outliers in this?

Anyway, I don't think it is unreasonable to have a "disable all" flag which then lets the user enable the specific ones with --collector.<name>.enabled for those cases where someone needs to be very precise about what collectors are enabled (although if one of the default collectors are troublesome in some cases, should it really be default?).

@grobie
Copy link
Member

grobie commented Aug 15, 2017

although if one of the default collectors are troublesome in some cases, should it really be default?

They shouldn't if they really cause trouble. The most common use case to disable default collectors is to reduce the amount of metrics produced in space limited setups.

@matthiasr
Copy link
Contributor

matthiasr commented Aug 15, 2017 via email

@discordianfish
Copy link
Member

Yes, also thinking about limit-number-of-metrics usecase. So we agree about a flag like --no-collector.defaults.enabled? Or other preferences?

@SuperQ
Copy link
Member

SuperQ commented Aug 15, 2017

How about --disable-collector-defaults, with the default of false.

@matthiasr
Copy link
Contributor

matthiasr commented Aug 15, 2017 via email

@discordianfish
Copy link
Member

I liked the consistency but sure that name work

@SuperQ
Copy link
Member

SuperQ commented Aug 20, 2017

@carlpett Would you add a flag --disable-collector-defaults to this PR that sets all collectors to false unless explicitly enabled?

@carlpett
Copy link
Member Author

carlpett commented Aug 20, 2017 via email

@SuperQ
Copy link
Member

SuperQ commented Aug 21, 2017

No worries, I was just wanting to ping. 😃

@carlpett
Copy link
Member Author

Hm, so actually this isn't as easy as I would have first thought. Currently the "enabledness" of collectors is tracked in a map[string]*bool, pointed to by the flag, and the default state is set while setting up the flag. This means that changing the default state via a flag is hard - the setting of default state is done before parsing flags.
One potential solution would be to add another map for default state and then copy that over to the enabled-map if the defaults are not disabled. Any better suggestions?

@discordianfish
Copy link
Member

I realized that too when looking at this. Don't really have a better answer. Maybe we should check out how others are doing this.

@carlpett
Copy link
Member Author

Finally got my laptop back... I split the bool into two, so it is possible to track if the user has chosen to enable it and the default state separately.
I named the flag --collectors.disable-defaults to keep it more in line with the general namespacing. What do you think? If you prefer --disable-collector-defaults I'll change it to that.

@carlpett
Copy link
Member Author

carlpett commented Aug 31, 2017

Huh, and apparently I broke some of the previous functionality when implementing it. Whoops. I even added tests, but forgot this case.
Fixing it.
EDIT: ... but apparently not tonight. I'll look at it again tomorrow.

@carlpett
Copy link
Member Author

Rebased now.
As an aside, I cannot run the end-to-end tests locally since my company-issued laptop is a Windows machine, which does not allow :s in file names (created in the sysfs fixtures). Are those paths crucial to the tests, or could they be dropped?

@SuperQ
Copy link
Member

SuperQ commented Sep 27, 2017

We should have fixed the windows filename issues with the ttar tool.

Copy link
Member

@SuperQ SuperQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@SuperQ
Copy link
Member

SuperQ commented Sep 27, 2017

Oh, sorry, I was confused. We fixed the code so you can check it out, but tests will still not run on windows because it needs to unpack the ttar fixtures which contain windows-incompatible file names. There is currently no way around this.

@discordianfish
Copy link
Member

I also note that there are --collector.procfs and --collector.sysfs that are a bit confusing now

Agreed, we should find a better name for these. I'd say either --collector.global.procfs or --global.procfs or something?

Beside that, LGTM!

@carlpett
Copy link
Member Author

That naming seems fine to me!
@SuperQ @grobie Any feedback on the procfs/sysfs naming from @discordianfish?

@SuperQ
Copy link
Member

SuperQ commented Sep 27, 2017

No objection to the naming.

@grobie
Copy link
Member

grobie commented Sep 27, 2017

What about just --procfs and --sysfs? Global is pretty generic, what does that namespace give us in the end?

@SuperQ
Copy link
Member

SuperQ commented Sep 28, 2017

@grobie Good idea, I like that one best.

@carlpett
Copy link
Member Author

If we still want some namespace, how about path? So --path.procfs for example.
Or we could do without

@discordianfish
Copy link
Member

@carlpett I like that, let's go with --path..

@discordianfish
Copy link
Member

@SuperQ Guess you're fine with that too? IMO better than no namespace. We might have more path options in the future so IMO this makes sense.

@grobie
Copy link
Member

grobie commented Sep 28, 2017 via email

@SuperQ
Copy link
Member

SuperQ commented Sep 28, 2017

Yes, --path. is approved.

Copy link
Member

@grobie grobie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I'd drop the print command, but looks great otherwise!

README.md Outdated
@@ -16,7 +16,8 @@ The [WMI exporter](https://github.com/martinlindhe/wmi_exporter) is recommended
There is varying support for collectors on each operating system. The tables
below list all existing collectors and the supported systems.

Which collectors are used is controlled by the `--collectors.enabled` flag.
Collectors are enabled by providing a `--collector.<name>` flag.
Collectors that are enabled by default can be disabled by providing a `--no-collector.name` flag.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency, this should be <name>

type NodeCollector struct {
Collectors map[string]Collector
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NewNodeCollector should have a docstring as it's exported.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, perhaps it shouldn't be exported? Not much point to it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh, I meant that the NodeCollector struct possibly shouldn't be exported. I'll add a doc string to NewNodeCollector.

node_exporter.go Outdated
printCollectors = kingpin.Flag("collectors.print", "If true, print available collectors and exit.").Bool()
listenAddress = kingpin.Flag("web.listen-address", "Address on which to expose metrics and web interface.").Default(":9100").String()
metricsPath = kingpin.Flag("web.telemetry-path", "Path under which to expose metrics.").Default("/metrics").String()
printCollectors = kingpin.Flag("collectors.print", "If true, print available collectors and exit.").Bool()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need this? All available collectors are already visible when showing --help.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, that should be dropped.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I thought we had talked about dropping this previously.

@discordianfish
Copy link
Member

LGTM beside @grobie's comments.

@discordianfish discordianfish merged commit 859a825 into prometheus:master Sep 28, 2017
@discordianfish
Copy link
Member

Awesome, thanks @carlpett for the contribution!

oblitorum pushed a commit to shatteredsilicon/node_exporter that referenced this pull request Apr 9, 2024
* Move NodeCollector into package collector

* Refactor collector enabling

* Update README with new collector enabled flags

* Fix out-of-date inline flag reference syntax

* Use new flags in end-to-end tests

* Add flag to disable all default collectors

* Track if a flag has been set explicitly

* Add --collectors.disable-defaults to README

* Revert disable-defaults flag

* Shorten flags

* Fixup timex collector registration

* Fix end-to-end tests

* Change procfs and sysfs path flags

* Fix review comments
tamcore pushed a commit to gitgrave/node_exporter that referenced this pull request Oct 22, 2024
Deprecate TCP APIs in favor of `github.com/mdlayher/netlink`.

Refer:
prometheus/procfs#622 (review).

Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants