-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
feat(inputs.linux_cpu): Add CPUFreq input plugin for Linux (v3) #8988
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤝 ✅ CLA has been signed. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, check few minor comments.
It would be great to see a few unit tests for this plugin.
@zak-pawel Thanks for the comments. I have tried to address them. Do you have any advice regarding the following question:
I might be interested in tracking other CPU-related metrics exposed by Linux but that are not part of the CPUFreq subsystem (like |
Hard to say... What metrics can be gathered from |
@zak-pawel Perhaps to give a more concrete example of my question: Linux also exposes information about the idle states via |
@zak-pawel Is there still anything I can do from my side? |
I don't think so :) Just waiting for some comments from @reimda / @ssoroka about |
Hi Fabian, thanks for picking up #4215. It makes sense to me for this plugin to include things like /sys/devices/system/cpu/cpuX/cpuidle that are outside of the cpufreq linux subsystem. In that case I agree a more general name would be useful to quickly communicate to the user what the plugin does. Would the name linux_cpu be more appropriate? There's already a linux_sysctl_fs plugin that matches this naming scheme. cpu_linux is another option. It has the advantage of showing up next to the cpu plugin in sorted list, so it might be more visible. I think I prefer linux_cpu. Both these options position this plugin as the place for linux specific metrics. That leaves the cpu plugin as the place for cross platform metrics (through gopsutil). It would be great to have only one cpu plugin but I don't think it's practical to expect gopsutil to provide the metrics this plugin does. If this is going to be the place for all linux cpu metrics, I would expect the field names to match linux terms. For example, scaling_cur_freq instead of current_khz. |
@reimda I agree with your points. My plan is to rename the plugin to |
@zak-pawel I have re-requested your review. Although not all possible metrics are included yet, I want to get your opinion on the current design. I have two questions in particular:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I think that plugin should fail (during
Init()
) when there are no metrics to gather at all. For other cases, it would be good to gather what is possible. - I think that these two flags (which should be converted to array of strings in config ;)) will control the metrics that are being collected by the plugin just fine. But I would fail as soon as possible if both of them are not enabled (== no metrics to gather).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still without unit tests :(
Thanks @zak-pawel for the review. I have been a bit busy these weeks with other things. Given that I don't have a lot of experience with Go, I am still researching what's the best way to test the plugin. I am probably going to approach it the same way as the |
@fabianishere Do you have a chance to continue working on this? Or else we'll see if someone else wants to take it over. |
I was planning on finishing this at the start of next year. Currently rather busy with wrapping up some other things. |
📦 Looks like new artifacts were built from this PR. Expand this list to get them here ! 🐯Artifact URLs |
When run as unprivileged user, this would have no permissions to read /sys/devices/system/cpu/cpuXX/cpufreq/cpuinfo_cur_freq on fresh kernels , but because file exists, it will keep trying to read and pollute logs. |
@antst Good catch! I’ll probably go with just trying to open the file. |
@zak-pawel I think this is ready for another review since you last looked at it? Is that true? |
I would love to see few unit tests :) |
@zak-pawel Sorry for the delay, I was quite busy with some other work last months. I have rebased the changes onto the master branch and added a few unit tests. Let me know if you want me to cover any additional cases. |
This change adds to Telegraf an input plugin that tracks the per-CPU metrics exposed by the Linux kernel. Currently, the plugin only supports a few properties exposed by the CPUFreq subsystem as well as by thermal_throttle.
Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.tar.gz, and windows_amd64.zip. 📦 Click here to get additional PR build artifactsArtifact URLs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job! Thank you so much for keeping this pull request alive, I think it looks great.
@zak-pawel is out, but it looks like all the comments have been resolved. If there are any other changes I think we should handle them in a separate PR, merging.
This pull request adds an input plugin for monitoring Linux' CPUFreq subsystem. This pull request builds upon the work #4215 and #8342, but given that they haven't seen any activity in a while, I would like to complete the integration of this plugin into the Telegraf repository.
Currently, the plugin only exposes
cpufreq/scaling_cur_freq
,cpufreq/scaling_min_freq
,cpufreq/scaling_cur_freq
andthermal_throttle/core_throttle_count
. If desirable, we could also add other fields exposed by the CPUFreq subsystem.Question to the maintainers: the
thermal_throttle/core_throttle_count
field is a bit out of place in this plugin, since it is not part of the CPUFreq subsystem in Linux. We could limit this plugin to only expose properties from the CPUFreq subsystem and have a separate plugin forthermal_throttle
or we could emit all properties that Linux exposes per CPU (and rename the plugin tocpulinux
for instance)?I have optimized the implementation to reduce the number of syscalls per gather cycle. However, a limitation of this implementation is that it does not support hotplugging CPUs, though I don't expect this to affect many people.
Required for all PRs:
Resolves #2601
Resolves #4256