Thanks for the hint. It seems that’s the culprit. Not sure why going to v2.0 became an issue all of a sudden, but I am considering to disable SNMP discovery on the ESXi hosts to fix it. Maybe there are two other better solutions:
1 - Create a rule to disable checks like: hr_cpu, hr_fs, hr_mem, if64 for SNMP (this one I know where it is);
2 - Better yet, how to create a rule that will disable the conflicting ones: esx_vsphere_hostsystem_cpu_usage, esx_vsphere_hostsystem_mem_usage, esx_vsphere_counters_uptime, esx_vsphere_counters_if?
I can only say the same as @r.sander - SNMP on ESX hosts makes no sense.
The information from the vCenter or the direct API access are way better and more comprehensive.
We have some legacy ones, but the majority is v6.7+. We have SNMP enabled on the hosts. For some monitoring/tools and apps in place, so it would be a try and error type of situation, to find out if disabling would “break” something somewhere. Right now, I am good…
Here is what I managed to do so far, to understand the issue and find ways around it:
1 - Disable the SNMP agent for the host, then re-inventory it - OK;
2 - Disable the SNMP check using a rule = Disabled or enabled sections (SNMP): Setup | Agents | SNMP rules | Disabled or enabled sections (SNMP) - OK;
3 - Disable the Check_MK check using a rule = Disabled checks | Setup | Services | Service discovery rules | Disabled checks - OK;
All the above did the trick, it seems. Option #2 and #3 seem the fastest to resolve my issue.
The good thing is, right now, the conflicts are gone! I appreciate the help and feedback! It pointed me into the right direction.
Extra info, for option #1, to mass disable the SNMP, I edited my hosts.mk file, containing all the hosts and did a findNReplace ‘snmp_ds’: ‘snmp-v2’, ‘snmp’: ‘snmp’, with ‘snmp_ds’: ‘no-snmp’, to all my hosts. Re-inventory and reloaded.
Why do you disable SNMP on all hosts? This was only a thing for the ESX hosts.
It is also not the recommended way to mass edit the configuration of hosts.
Better is to use the search function inside the host configuration and search for hosts with SNMP enabled and some other markers then mass edit these found hosts.
I hear you. I also prefer to use the WATO way, but I noticed that, at times (for whatever reason), when I mass edit similar servers which contain different settings (let’s say options enabled/disabled, different home sites or parents, etc), the end result is not what I expect. It is not something I do often. Like I said before, this was triggered by the upgrade. If the problem was there, it was dormant.
Regards,
you need to set “use new service description” for the MSSQL check in the global settings of checkmk.
Take a look at this Werk, I assume that that will fix your problem :
But that is not related to the problem of the thread you hijacked
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.