prometheus / prometheus/node_exporter
Distinguish between enabling collectors additively vs. by enumeration
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 13.8k
- Forks
- 2.7k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 8
Description
The discussion in #735 made it clear that on one hand the dev team is concerned about surprising users upgrading to a new version, and on the other hand a subset of users (myself included) desires the pre-0.15 behaviour of exactly enumerating which collectors should be enabled.
It seems like both sides could be addressed by having --enable.{collector} act additively, and using a different option to define the exact collector set. (E.g., --collectors X,Y,Z.) Arguably, users opting for the latter option are experienced enough where they understand they have to read the upgrade notes for any collector name changes.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading discussion #735 and tracing the current handling of --enable.{collector}. Clarify the proposed --collectors X,Y,Z behavior and how it should coexist with additive enabling, including upgrade compatibility. Done means the two selection modes have an agreed, testable specification and implementation path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100