Fix CPU gauge to just use normalized CPU percentages

[fearful-symmetry]

What does this PR do?

This alters the CPU Usage Gauge to just use normalized values for visualizations, and removes the painless script, which was (incorrectly) dividing the normalized value by the CPU count.

I'd actually like some feedback on this, since I can't figure out why the visualization hasn't always been like this. We've been doing some math cleverness to take the "regular" CPU value and divide it by the CPU count, when this is basically what the norm.cpu values do to begin with. I've tested this change and it works fine, but I'm a tad paranoid and I wonder if there's a reason why we haven't been doing this before.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.

How to test this PR locally

Pull down, build. Find the CPU Usage gauge In the System Integration Host Details dashboard. Make sure the gauge is populated and the value is correct.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2021-08-10T16:51:16.142+0000

• Duration: 14 min 30 sec

• Commit: 2626767

Test stats 🧪

Test	Results
Failed	0
Passed	266
Skipped	0
Total	266

Trends 🧪

[mtojek]

I think this is more like a "bugfix" than "enhancement".

[exekias]

I'd actually like some feedback on this, since I can't figure out why the visualization hasn't always been like this. We've been doing some math cleverness to take the "regular" CPU value and divide it by the CPU count, when this is basically what the norm.cpu values do to begin with. I've tested this change and it works fine, but I'm a tad paranoid and I wonder if there's a reason why we haven't been doing this before.

@jsoriano do you happen to remember this? I don't 🤔 , I guess this is because normalized values were added after the initial dashboards were created

[exekias]

Change LGTM, besides comment on change type in the changelog

[andrewkroh]

I guess this is because normalized values were added after the initial dashboards were created

Or maybe that normalized_percentages are disabled by default. But here we have control of the cpu.metrics setting.

[fearful-symmetry]

Or maybe that normalized_percentages are disabled by default. But here we have control of the cpu.metrics setting.

So, @andrewkroh , everything is enabled by default save for ticks, which makes it even weirder.

I guess this is because normalized values were added after the initial dashboards were created
Honestly, that's my best guess.

[andrewkroh]

everything is enabled by default save for ticks

I think the docs are wrong then. They say:

The default value is cpu.metrics: [percentages].

[fearful-symmetry]

The default value is cpu.metrics: [percentages].

@andrewkroh where are you seeing that? I'm grepping through the repo and can't find it.

[andrewkroh]

That's from the Metricbeat docs for cpu.metrics. https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-metricset-system-cpu.html#_configuration_4

[jsoriano]

I guess this is because normalized values were added after the initial dashboards were created

Or maybe that normalized_percentages are disabled by default. But here we have control of the cpu.metrics setting.

Yes, I think the reason is this one, that normalized values are (or were) disabled by default.

[fearful-symmetry]

Yah, key word being were here. We might want to look into just refreshing most of the system dashboards. A lot of this stuff looks really old.