I guess my main concern is that if the consumer is periodically calling Oshi, and the system is in such a bad state, the log will contain many duplicated entries like that. Maybe this means that Oshi would benefit from having some logic to log such things only once, or expose some health information so that consumers can check and call things that are in a bad state ony once.

All of the above log messages originate in a path that will only execute once per counter.

Here's the wrapper method inside which all 3 log warnings above are generated:

Note that we check whether the query has failed before, before attempting any more PDH Counter retrievals for that counter.

That is a static variable, so that set will remain until the entire JVM is restarted. queryInstancesAndValuesFromPDH() takes us eventually here:

And the first error is generated on the PDH failure call.

I believe logging a warning on an unexpected system error is appropriate. I recognize there is duplication in the first and second log messages, but they only happen once per counter name per JVM instance, and the second message explains the meaning of the first and provides detailed information (corrupt performance counters) for which there is ample information available how to resolve.

The last message is, perhaps, informational and could be reduced from a warning to INFO or even DEBUG, but the three messages together do somewhat tell a story. OSHI is saying "your registry is corrupt, and I'm handling it with a backup".

Now in theory you might say "hey if one set of counters is corrupt then all of them are" and that is probalby the most common scneario. We could certainly add some logic (or a configuration vairable) to say "log at most N PDH failures".

As the above reply is a bit wordy, I'll tack on the TLDR:

• Currently there are 3 WARN log messages for each counter
• I still think we need at least 1 WARN log message and would favor the second one (describing corrupt counters). As the first one is easily disabled with logging filters, I'm not overly eager to disable it; however given that it almost always results in the second message I could be convinced to lower it to debug.
• I'm ok with lowering the third message to INFO.

I'm also ok with adding a configuration setting to assume if any counter hits these issues, all should be disabled. The net effect would be a single log message similar to the 2nd ("... corrupt ....") but without naming the specific counter. That combined with the previous suggestions would reduce the 12 messages above to one single WARN message, if appropriately configured.

I'm fine with your last message. We hit the "if one set of counters is corrupt then all of them are" and saw multiple messages with slightly different counter names.
Thanks for the detailed answer.

Great. I'll try to get something together by this weekend and cut a release as there's another pending logging change.

6.6.4 release cut, see #2725