-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
illumos/solaris CPU usage is reported in ticks, not seconds #1837
Labels
Comments
davepacheco
changed the title
illumos+solaris CPU usage is reported in ticks, not seconds
illumos/solaris CPU usage is reported in ticks, not seconds
Sep 5, 2020
rexagod
added a commit
to rexagod/node_exporter
that referenced
this issue
Mar 19, 2024
Replace all cpu_ticks_* with cpu_nsec_*, since the former was off my a magnitude of 10e6, and showed incorrect values for node_cpu_seconds_total. Fixes: prometheus#1837 Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
I've opened up a PR purely based on David's research above (and a bit of mine), which should address this bug. |
rexagod
added a commit
to rexagod/node_exporter
that referenced
this issue
May 12, 2024
Replace all cpu_ticks_* with cpu_nsec_*, since the former was off my a magnitude of 10e6, and showed incorrect values for node_cpu_seconds_total. Fixes: prometheus#1837 Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
SuperQ
pushed a commit
that referenced
this issue
May 15, 2024
Replace all cpu_ticks_* with cpu_nsec_*, since the former was off my a magnitude of 10e6, and showed incorrect values for node_cpu_seconds_total. Fixes: #1837 Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
SuperQ
pushed a commit
that referenced
this issue
May 21, 2024
Replace all cpu_ticks_* with cpu_nsec_*, since the former was off my a magnitude of 10e6, and showed incorrect values for node_cpu_seconds_total. Fixes: #1837 Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
SuperQ
pushed a commit
that referenced
this issue
May 21, 2024
Replace all cpu_ticks_* with cpu_nsec_*, since the former was off my a magnitude of 10e6, and showed incorrect values for node_cpu_seconds_total. Fixes: #1837 Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
SuperQ
pushed a commit
that referenced
this issue
May 21, 2024
Replace all cpu_ticks_* with cpu_nsec_*, since the former was off my a magnitude of 10e6, and showed incorrect values for node_cpu_seconds_total. Fixes: #1837 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
Host operating system: output of
uname -a
node_exporter version: output of
node_exporter --version
node_exporter command line flags
No command-line flags passed (
node_exporter
)Are you running node_exporter in Docker?
No.
What did you do that produced an error?
Viewed stat
node_cpu_seconds_total
.What did you expect to see?
I expected to see the total number of seconds of idle time for this CPU since boot.
What did you see instead?
I saw the total number of idle ticks for this CPU since boot.
It's easier to look at all the data in one place:
What we see in this snippet is that:
Looking at the source, it's pretty clear why:
node_exporter/collector/cpu_solaris.go
Lines 63 to 66 in d8a1585
It's pulling the "cpu_ticks_idle" kstat, which is measured in ticks. That's related to seconds by "nsec_per_tick". The above output shows that nsec_per_tick is 1,000,000 on this system, which explains why our output is off by a factor of 1,000,000.
As far as I can tell, this has always been wrong in this way. My guess is that users don't see this if they're always graphing a ratio of the CPU time metrics (e.g., idle / sum_of_all_of_them). You see this if you're trying to calculate idle percent as
100 * node_cpu_seconds_total{mode="idle"}
, which should work.The straightforward solution would be to use the
cpu_nsec_{idle,kernel,user,wait}
kstats instead of thecpu_ticks_{idle,kernel,user,wait}
kstats. I don't know if we'd be worried about this being a breaking change.CC @dsnt02518 (because you seem to be doing related work in #1803), @jpds (maybe I've misunderstood something here?)
The text was updated successfully, but these errors were encountered: