user@host1:~ $ ansible all -b -m shell -a "/lib/check_mk_agent/plugins/mk_apt"
host2 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host4 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host3 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host1 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
user@host1:~ $
I’m not seeing a new Service appear in the list of Services for any of the 4 hosts though, not even as Pending.
While reading thru other threads of similar mk_apt plug-in issues, I get the impression that a Service Discovery rule for APT Updates may not be required. Unfortunately, enabling/disabling the APT Updates Service Monitoring rule does not seem to make any difference.
what does running check_mk_agent| grep -A1 '...apt' result in? Is the line <<<apt:sep(0)>>> shown?
Another suggestion, not exactly related to your problem: Put the mk_apt plugin into a subfolder with the amount of seconds that you want a cache to be valid. For example, I put mine into a subfolder “43200” in order to have 12h cache for this check. Then, also take a look inside the plugin itself. If left on default, this plugin will perform an update by itself, which
a) could take longer and results in a slow execution / long wait time of your agent
b) might be something you do not want
It seems the expected result is generated when executing the Agent as well:
user@host1:~ $ ansible all -b -m shell -a "check_mk_agent| grep -A1 '^<<<apt:sep(0)>>>'"
host2 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host4 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host3 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host1 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
user@host1:~ $
Thank you for the scheduling suggestion! Once I can achieve a working state, I’ll definitely move forward with that.
Thanks again @simon-mueller for the suggestions. I agree, scheduling the APT plug-in avoids excessive execution and unpredictable changes that the apt upgrade may otherwise introduce.
While sub-dirs easily allow the scheduling of the APT plug-in’s execution, unfortunately though my CheckMK Raw Server apparently still does not see or process this part of the CheckMK Linux Agents:
<<<apt:sep(0):cached(1712513174,3600)>>>
All packages are up to date.
Recently, I came across a blog article which contains some detail on how I might further troubleshoot the problem by evaluating the output from the APT check’s execution on the CheckMK server. Perhaps the output will reveal more clues when Updates exist for installation:
OMD[mysite]:~$ cmk -nv --checks=apt host2
WARNING: '--checks' is deprecated in favour of option 'detect-plugins'
+ FETCHING DATA
[TCPFetcher] Execute data source
[agent] Success, execution time 1.5 sec | execution_time=1.510 user_time=0.170 system_time=0.020 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=1.320
OMD[mysite]:~$
What do you see, when you run cmk -d host2? It will give you the raw agent output, as the Checkmk server sees it. If the apt sections are not in there, it is an agent side problem.
If the data is there, you maybe just forgot to add the service in the service configuration (aka. service discovery), or you have a “Disabled Services” or “Disabled Checks” rule?
The output of cmk -d host2 does include the section for apt:
<<<apt:sep(0):cached(1716663496,3600)>>>
5 packages can be upgraded. Run 'apt list --upgradable' to see them.
I’m not sure of what files would show the appropriate service configuration for the mk_apt plug-in to work, hopefully these screenshots are sufficient:
Okay, the section is in the output, which means the agent is working just fine.
The automatic service with automatic removal of services is generally dangerous, but is probably not the issue here. Do you have any “Disabled services” rules, which might disable the APT services, or “Disabled checks” rules, which disable entire plugins?
Those were the rulesets I was referring to. But as they are empty, they have no effect.
I am running out of ideas right now. It might be some change in $OMD_ROOT/local/ or something entirely different. From the distance it is hard to tell.
I’ve recently had success by adding an Enforced Services rule for APT Updates, where the Checktype is apt - APT: Normal and Security Updates. Whether this is required alongside the Service Monitoring rule for APT Updates, I’m not certain. The Service check now works as expected though. Thanks again @simon-mueller@robin.gierse !
It is not required, and I would consider it a workaround, but as long as it fixes your issue, that is great. The root cause will be somewhere else though.
Also, make sure to read up on Enforced Services, what they are and how/when to use them in general.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
:
