Remove most of the PMDANOTREADY/READY PDU logic from PMDA MMV.
This isn't worth the trouble is causes (just log warnings, AFAICT).
In our experience with a production MMV-alike PMDA, if configuration
changes for one monitored application, you cannot simply not return
a value for other monitored applications, which is how the current
implementation effectively behaves at the moment. When metrics are
monitored by pmie feeding events into some frameworks (like Nagios),
if no data is available this is a major problem (people get notified
and/or woken at 2am, etc).
This change does keep the NOTREADY/READY logic for the Store PDU,
however, so there remains a mechanism to "cleanly" force a MMV name
refresh (with no log warnings being generated).
Some whitespace cleanup in here too, and no longer initialise some
globals that didn't need it.
Remove most of the PMDANOTREADY/READY PDU logic from PMDA MMV.
This isn't worth the trouble is causes (just log warnings, AFAICT).
In our experience with a production MMV-alike PMDA, if configuration
changes for one monitored application, you cannot simply not return
a value for other monitored applications, which is how the current
implementation effectively behaves at the moment. When metrics are
monitored by pmie feeding events into some frameworks (like Nagios),
if no data is available this is a major problem (people get notified
and/or woken at 2am, etc).
This change does keep the NOTREADY/READY logic for the Store PDU,
however, so there remains a mechanism to "cleanly" force a MMV name
refresh (with no log warnings being generated).
Some whitespace cleanup in here too, and no longer initialise some
globals that didn't need it.