Duplicate service description (auto check) after v2.0.0p1 Upgrade

Hi,

Started getting duplicate alerts after going from v1.6.0p22 to v2.0.0p1. Haven’t been able to figure out where the problem lies:

OMD[SITE1]:~$ cmk -O
Generating configuration for core (type nagios)...
WARNING: ERROR: Duplicate service description (auto check) 'CPU utilization' for host 'SERVER01'!
 - 1st occurrence: check plugin / item: esx_vsphere_hostsystem_cpu_usage / None
 - 2nd occurrence: check plugin / item: hr_cpu / None

WARNING: ERROR: Duplicate service description (auto check) 'Memory used' for host 'SERVER01'!
 - 1st occurrence: check plugin / item: esx_vsphere_hostsystem_mem_usage / None
 - 2nd occurrence: check plugin / item: mem_used / None

WARNING: ERROR: Duplicate service description (auto check) 'Uptime' for host 'SERVER01'!
 - 1st occurrence: check plugin / item: esx_vsphere_counters_uptime / None
 - 2nd occurrence: check plugin / item: uptime / None

Anyone, any clues?

Warnings:
check_mk: ERROR: Duplicate service description (auto check) 'CPU utilization' for host 'SERVER01'! - 1st occurrence: check plugin / item: esx_vsphere_hostsystem_cpu_usage / None - 2nd occurrence: check plugin / item: hr_cpu / None
check_mk: ERROR: Duplicate service description (auto check) 'Memory used' for host 'SERVER01'! - 1st occurrence: check plugin / item: esx_vsphere_hostsystem_mem_usage / None - 2nd occurrence: check plugin / item: mem_used / None
check_mk: ERROR: Duplicate service description (auto check) 'Uptime' for host 'SERVER01'! - 1st occurrence: check plugin / item: esx_vsphere_counters_uptime / None - 2nd occurrence: check plugin / item: uptime / None
check_mk: ERROR: Duplicate service description (auto check) 'CPU utilization' for host 'SERVER02'! - 1st occurrence: check plugin / item: esx_vsphere_hostsystem_cpu_usage / None - 2nd occurrence: check plugin / item: hr_cpu / None
check_mk: ERROR: Duplicate service description (auto check) 'Memory used' for host 'SERVER02'! - 1st occurrence: check plugin / item: esx_vsphere_hostsystem_mem_usage / None - 2nd occurrence: check plugin / item: mem_used / None
check_mk: ERROR: Duplicate service description (auto check) 'Uptime' for host 'SERVER02'! - 1st occurrence: check plugin / item: esx_vsphere_counters_uptime / None - 2nd occurrence: check plugin / item: uptime / None

Is this an ESX host where you also query the SNMP agent?

Disable SNMP on these hosts.

1 Like

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?

Regards,

What version of ESX are you running?

Current ESX hosts do not have an SNMP agent running, just disable querying it.

1 Like

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… :slight_smile:

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. :+1:

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.

Sorry, I meant disabled SNMP on all ESXi 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. :blush:
Regards,

Hello,

I have the same message, but for SQL-Server. CheckMK 2.0.0p7.

WARNING: ERROR: Duplicate service description (auto check) ‘MSSQL Blocked Sessions’ for host ‘’!

  • 1st occurrence: check plugin / item: mssql_blocked_sessions / ‘CONTROLLING’
  • 2nd occurrence: check plugin / item: mssql_blocked_sessions / ‘PERSONAL’

But I only see this check once in the services. There are two instances on this SQL-server.

With kind regards

Hi,

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 :slight_smile:

1 Like

Thank you very much, that was the solution. :wink:

1 Like

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.