prometheus / prometheus/node_exporter
Expose the CPU EPP similarl to governor
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 13.8k
- Forks
- 2.7k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 8
Description
It would be useful if node_exporter could expose the current CPU Energy Performance Preference (EPP), similar to node_cpu_scaling_governor.
In practical terms, the governor defines the general CPU frequency/performance scaling policy, while EPP is a finer hint to the CPU about how strongly it should prefer performance versus energy efficiency within that policy. For example, with the powersave governor active, EPP can still range from performance to balance_performance, balance_power, or power, which can noticeably change responsiveness and power consumption.
Linux already exposes this per CPU through:
/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_available_preferences
Something like this would make EPP changes easy to monitor historically:
node_cpu_energy_performance_preference{cpu="0",preference="balance_power"} 1
node_cpu_energy_performance_preference{cpu="0",preference="performance"} 0
Since governor state is already exposed this way, EPP seems like a natural addition to the cpufreq collector.
Thank you. :)
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 in the cpufreq collector alongside the existing node_cpu_scaling_governor metric, then inspect the per-CPU sysfs paths for energy_performance_preference and energy_performance_available_preferences. The work is done when the collector exposes the current EPP preference per CPU with the requested preference labels and handles the available values consistently with governor metrics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, linux
- Domain
- observability, operating-systems
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100