New Intel PowerStat input plugin

[MaciejMis]

Required for all PRs:

• Signed CCLA.
• Associated README.md updated.
• Has appropriate unit tests.

CCLA completed and signed by Intel Corporation.

Feature Request

We have created a Telegraf PowerStat input plugin which enables monitoring of platform metrics (power, TDP) and per-CPU metrics like temperature, power and utilization.

Intel PowerStat plugin supports Intel based platforms and assumes presence of Linux based OS.

Proposal:

The plugin we have created is able to provide following metrics:

Platform metrics:

• thermal_design_power (Maximum Thermal Design Power (TDP) available for processor package [Watts])
• current_power_consumption (Current power consumption of processor package [Watts])
• current_dram_power_consumption (Current power consumption of processor package DRAM subsystem [Watts])

Per-CPU metrics:

• cpu_frequency (Current operational frequency of CPU Core [MHz])
• cpu_temperature (Current temperature of CPU Core [Celsius degrees])
• cpu_busy_cycles (CPU Core Busy cycles as a ratio of Cycles spent in C0 state residency to all cycles executed by CPU Core [%])
• cpu_c6_state_residency (Percentage of time that CPU Core spent in C6 Core residency state [%])
• cpu_c1_state_residency (Percentage of time that CPU Core spent in C1 Core residency state [%])
• cpu_busy_frequency (CPU Core Busy Frequency measured as frequency adjusted to CPU Core busy cycles [MHz])

Use case:

Key source of platform telemetry is power domain that is beneficial for MANO/Monitoring&Analytics systems to take preventive/corrective actions based on platform busyness, CPU temperature, actual CPU utilization and power statistics.
Main use cases are power saving and workload migration.

Closes: #8485

[srebhan]

Hey @MaciejMis, cool stuff. I've some comment nevertheless...

1. I think the metric output format is costly on the query side. If you e.g. want the "cpu_frequency" you need to constrain the field value if "name" to "cpu_frequency". That means you need to touch all rows of the DB. Making it a field i.e. field: "cpu_frequency_mhz"=value would be much more efficient.
2. The whole "services" thing feels like a standalone golang package. Can maybe Intel host that as a package (just the "services", "data", "mocks" thing) as a golang package that we can use here? I'm asking because that's a lot of code not solely bound with telegraf (e.g. someone could use it in a different golang project)...
3. The skipfirst feels strange. While I couldn't come up with an ad-hoc replacement it feels like circumventing an Init() case...

[p-zak]

Hey @MaciejMis, cool stuff. I've some comment nevertheless...

1. I think the metric output format is costly on the query side. If you e.g. want the "cpu_frequency" you need to constrain the field value if "name" to "cpu_frequency". That means you need to touch all rows of the DB. Making it a field i.e. field: "cpu_frequency_mhz"=value would be much more efficient.
2. The whole "services" thing feels like a standalone golang package. Can maybe Intel host that as a package (just the "services", "data", "mocks" thing) as a golang package that we can use here? I'm asking because that's a lot of code not solely bound with telegraf (e.g. someone could use it in a different golang project)...
3. The skipfirst feels strange. While I couldn't come up with an ad-hoc replacement it feels like circumventing an Init() case...

1. Good point!
2. Hosting "services" thing somewhere else is not an option right now. There are just helper functions extracted from main file to read and calculate values and crafted to be used by this plugin.
3. skipfirst is just to omit few metrics which are calculated deltas. In first iteration they doesn't make any sense (need at least two iterations of Gather to calculate something).

[srebhan]

Nice code, but I have the feeling it has too many indirections. Please see my comments.

[srebhan]

LGTM. I really enjoy reading the code!

One thing worth mentioning is the atomic organization of the metrics. There are multiple metrics emitted with the same name but different fields. One could argue to collect those fields before emitting, but on the other hand the current structure keeps the code clean.