Interrupts+spurious

[richardelling]

Adds an optional spurious_interrupts measurement for tracking spurious interrupts.

Also, removes metrics for phantom CPUs: those who may be reported in the /proc/softirqs, but might not actually exist and only include zeroes. See also #5451

Required for all PRs:

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

[danielnelson]

This looks nice but we need to stick to the previous format style to match https://raw.githubusercontent.com/influxdata/telegraf/master/plugins/inputs/EXAMPLE_README.md

[richardelling]

will do, though I will assert your standard is ugly and takes up too much screen space :-)

[danielnelson]

Let's just enable this by default, and rely on the metric filtering for those who don't want spurious counts per IRQ.

[richardelling]

ok

[danielnelson]

The previous defer method is actually preferred, since it will be less likely to be broken in future code updates.

[richardelling]

The problem with the previous method is that the static code checkers complain about the f.close() return code being ignored, which it is. Two choices:

1. add proper func for defer f.Close() to explicitly ignore the return value
2. add comment for static checkers to ignore the ignored return value error

I'm fine either way. Do you have a preference?

[danielnelson]

I'm not our goal to keep static code checkers quiet, outside of the ones required by the integration tests (go vet in particular). So I'd rather just leave it as before, I don't find assigning to _ to be helpful in explaining the code.

[richardelling]

I think I'll prefer to f.Close() in the loop. If defer is in a loop, we trigger possible leak detection because the defer's closure is the function, not the loop. In this particular location inside Gather, we loop twice, not a real problem. In parseInterrupts we open one file per irq, this can easily grow into the hundreds of open file descriptors, so it is better to close in the loop.

[danielnelson]

Good point, this is possibly an indication that we should extract a function.

[richardelling]

yeah, I'm not particularly happy with the overall design, lemme try a more detailed refactor, including some improved testing

[srebhan]

@richardelling any update on this? The code looks quite nice already and it would be a pitty if it bit-rots like this.

[srebhan]

@richardelling do you see a chance to work on this PR?

[srebhan]

Anyone interested in taking over this PR?

[richardelling]

@srebhan thanks for the ping, I'll not have time until next month at the earliest. I

[srebhan]

@richardelling thank you for letting me know. Please drop me a note once you get to it (or decide to drop this PR). :-)

[richardelling]

@srebhan closing this in favor of a newer PR #9496