process monitoring for automation helpers, is done with the following regex:
~(.*cmk-automation-helper.*|gunicorn:.*automation-helper)
which creates a capturing match group which you can see in the match_groups parameter ~/var/check_mk/autochecks/<hostname>.mk file, in 2.4:
hostname_2_4.mk: {'check_plugin_name': 'ps', 'item': 'svamon automation helpers', 'parameters': {'process': '~(.*cmk-automation-helper.*|gunicorn:.*automation-helper)', 'match_groups': ('gunicorn: worker [automation-helper',), 'user': 'svamon', 'cgroup': (None, False), 'cpu_rescale_max': True}, 'service_labels': {}},
this capture group is part of the service, and if the capture group doesn’t match, it doesn’t matter if the actual match group would match, you have to do a “remove all and find new” (fka tabula rasa)
hostname_2_5.mk: {'check_plugin_name': 'ps', 'item': 'svamon automation helpers', 'parameters': {'process': '~(.*cmk-automation-helper.*|gunicorn:.*automation-helper)', 'match_groups': ('cmk-automation-helper[worker]',), 'user': 'svamon', 'cgroup': (None, False), 'cpu_rescale_max': True}, 'service_labels': {}},
I’m wondering if anyone is aware of a good reason for this capture group in general and specifically for the checkmk defined self-monitoring of checkmk + checkmk helper processes.
We’ve done similar monitoring for systemd which changes its path from /usr/lib/ to /lib/ or vice-versa and we just configured the regex to use a non-capturing group "(?:/usr)?/lib/systemd/systemd.*"
Does anyone see any reason why this couldn’t be done with the officially shipped process discovery rules?