Nodes stats returns -1 cpu percent on my desktop

[nik9000]

Elasticsearch version (bin/elasticsearch --version): master

Plugins installed: none

JVM version (java -version):

=======================================
Elasticsearch Build Hamster says Hello!
  Gradle Version        : 7.0
  OS Info               : Linux 5.11.15-arch1-2 (amd64)
  JDK Version           : 15 (AdoptOpenJDK)
  JAVA_HOME             : /usr/lib/jvm/java-15-adoptopenjdk
  Random Testing Seed   : AF807D8F67D509D1
  In FIPS 140 mode      : false
=======================================

OS version (uname -a if on a Unix-like system):

Linux beast 5.11.15-arch1-2 #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +0000 x86_64 GNU/Linux

Description of the problem including expected versus actual behavior:
GET /_nodes/stats and GET /_cat/nodes returns -1 for my cpu load percent. It looks like OperatingSystemMXBean.getSystemCpuLoad is returning -1 for me. Its documented as doing that if the load isn't available.

Steps to reproduce:

1. Get my desktop
2. ./gradlew -p docs check -Dtests.method='*cat*'
3. That fails to match the pattern, getting a -1 on load.
4. You could also ./gradlew run and GET /_nodes/stats. That dumps:

        "cpu" : {
          "percent" : -1,
          "load_average" : {
            "1m" : 0.44,
            "5m" : 0.37,
            "15m" : 0.43
          }
        },

It looks like this is super rare on developer machines because we don't expect -1 in the tests. Do we to modify the tests? Do we want to figure out why the jvm can't get my load percentage?

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[jakelandis]

Related : #42725 (and a lot of other related issues)

[elasticmachine]

Pinging @elastic/es-core-features (Team:Core/Features)

[nik9000]

@DaveCTurner and I looked at this and couldn't figure out why my machine doesn't like this. I straced my jvm and it read the /proc/stats just fine. My /proc/stats looks pretty similar to his, so we're not sure what is up.

[jbaiera]

Given the previous problems with receiving -1 on stats calls, we agreed that snapping this value to 0 and logging a warning like we do in #42725 is likely the best approach. A deeper dive into why this might be returned would be great for historical purposes.

[nik9000]

It looks like this is closed by #42725.

[nik9000]

For what it's worth I haven't seen this in a while. But it might have had to do with my linux version at the time. Now I'm:

Linux porco 5.16.14-arch1-1 #1 SMP PREEMPT Fri, 11 Mar 2022 17:40:36 +0000 x86_64 GNU/Linux

and don't see any problems.