Check_MK Discover always warning on failed check_mk@ services despite rule

[chriswilkes33 (chris wilkes)]

On any system we have the agent running, latest v2.0, the Check_MK Discovery always finds unmonitored service check_mk@XXXXX

I dont care that it crashes, I just want check_mk to ignore it. I tried adding an exception in a systemd services summary rule excluding the pattern check_mk@* and check_mk@\d+ and it continues to report. I also tried excluding the same patterns in the systemd single services rules.

There are a hodgepodge of posts here that make it seem like it is either a bug that returns from time to time or something I should easily be able to exclude with a rule.

[chriswilkes33 (chris wilkes)]

for the record, I also tried the ridiclous regex check_mk@\d+-\d+.\d+.\d+.\d+:\d+-\d+.\d+.\d+.\d+:\d+

same, just keeps finding the next failed one up

[chriswilkes33 (chris wilkes)]

Any help here from the community?

[chriswilkes33 (chris wilkes)]

Hi, still struggling with this and it makes check mk pretty much unusable for us, any tips would really be helpful, I have tried a bunch of different excludes and I just don’t get it.

[lkoenig (Lorenz Koenig)]

Hello @chriswilkes33,

i think you are describing two different things.
There is the service “Systemd Service Summary” which is a summary of all systemd services, but is only discovered once.
From what i see in the screenshots the problem you are facing is that checkmk is discovering new systemd services with the check “systemd_units_services” and the server wants to create new services for every single systemd unit.
Do you have a rule for “Systemd single services discovery” that discovers every single systemd unit on your servers?
By default (at least in my sites) there is no rule for that, so there should only be the “Systemd Service Summary” and the server should not discover any single systemd services.
Could you check if there are any rules in “Setup → Services → Service Discovery Rules → Systemd Single Service Discovery”?

Cheers,
Lorenz

[chriswilkes33 (chris wilkes)]

Thank you for answering. I do have two rules there also, in attempts to also exclude these, perhaps they are not needed?

If Im understanding correctly

, If I remove these it shouldnt find this new failed one unless we do a full scan on the host again?

[lkoenig (Lorenz Koenig)]

These rules only apply if the services have already been discovered.
Could you check in "Setup → Services → Service Discovery Rules → Systemd Single Service Discovery” if there are any rules there?
The screenshots from the rules you posted are from “Setup → Services → Service Monitoring Rules → Systemd Single Services”
For what you are trying to achieve i don’t think you need those.

[chriswilkes33 (chris wilkes)]

Ahh, ok.

I do have a rule in that spot as well, with no exceptions, it looks like this:

I do want it to discover services, just not the ones called check_mkXXXXXXX or check-mk-agentXXXXXX, isnt this rule the one that does that?

[chriswilkes33 (chris wilkes)]

I removed the summary rules and the nasty looking single services rules from the earlier posts but still see this check_mk@ thing as a crit after rescanning hosts.

I did find this rule so I guess I can just change the severity of the unmonitored service but if someone stood up a new service on one of my systems it would be cool to be warned about it

[chriswilkes33 (chris wilkes)]

I think I found it…The rule is called disabled services and it is found at Setup > Services > Service Discovery Rules > Disabled Services

I made my rule look like this and those check_mk service now immediately show as disabled and dont report:

Thank you so much for the push in the right direction. This has been bugging me for a while.

[lkoenig (Lorenz Koenig)]

Ah yes, that’s exaclty what i would have suggested in the next step!
Unfortunately it looks like in the service discovery rule you’re not able to “filter out” services by name.
So disabling the ones you don’t want to see is the easiest way to achieve what you’re looking for.
Glad to hear you got it solved!