need pcp2zabbix with PMNS_CHANGED / optional-metric tolerance

[fche]

need pcp2zabbix with PMNS_CHANGED / optional-metric tolerance

[goodwinos]

There was some discussion a while back with Marko (pmrep author) and other PCP developers around this proposal and the consensus is that it would be too difficult/intrusive to retrofit this feature into pmrep (which is the back-end for pcp2zabbix). pmrep was never designed to re-parse it's metric arguments and config after starting. The work-around is to restart pcp2zabbix, at which time pmrep will re-evaluate the PMNS. The Zabbix receiver would need to tolerate reconnection of the datasource - not sure if that is already the case, but likely.

[fche]

The need continues to exist. At the very least pmrep could be configurable so that it can exit when it receives a PMCD_NAMES_CHANGE. That would give the caller an opportunity to restart it.

[fche]

If the above were combined with tolerance by pmrep to unresolvable metric names (so it doesn't quit, just ignores them), we can have what we need without major pmrep surgery.

[goodwinos]

Thanks to Nathan and Marko, pmrep and all pmrep/pmconfig based pcp2xxx tools in upstream pcp-4.3.0 (including pcp2zabbix) now have support for (a) --ignore-unknown to tolerate unresolved metric names and (b) --names-change where supported options are 'ignore' (default), or 'abort'.

See upstream commits : 2aa0081f24cf1db0172a 86e6b73f5aca768a 71d684326aeb22b43 7673438cd7cd8e c1caf330fbd86236 04fd0569bea5c6dc22b and related QA.

These commits should be sufficient for this issue so pcp2zabbix can abort on PMCD_NAMES_CHANGE (and be restarted e.g. by pmmgr), and tolerate unresolvable metric names on startup instead of exiting.

[goodwinos]

As per the above, this feature is now in upstream master and will release with pcp-4.3.0 (December 21).