[ZBX-9100] LLD - Cannot create item: item with the same key "wmi.get["root\cimv2","SELECT StartMode (...) already exists. Created: 2014 Dec 02 Updated: 2017 May 30 Resolved: 2014 Dec 02 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Incident report | Priority: | Major |
| Reporter: | Stefan Bauer | Assignee: | Unassigned |
| Resolution: | Won't fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
We're using service discovery on Windows 2008 machines. That works but error messages are showing up for the discovery rule. The discovery mechanism is not updating the items frequently so we see a relation to the reported problem: This is the complete error message: Cannot create item: item with the same key "wmi.get["root\cimv2","SELECT StartMode FROM Win32_Service WHERE Name like '{#INESSERVICENAME}'"]" already exists
These are the config snippets: UserParameter=service.discovery,powershell -File "C:\Program Files\zabbix\service_discovery.ps1" Please find attached the powershell script as well as an example script output. |
| Comments |
| Comment by Aleksandrs Saveljevs [ 2014 Dec 02 ] |
|
In "example_output.txt", there is no {#INESSERVICENAME} macro. For this reason, this macro is not expanded. |
| Comment by Aleksandrs Saveljevs [ 2014 Dec 02 ] |
|
Please refer to https://www.zabbix.org/wiki/Getting_help for ways to get community support. |
| Comment by Stefan Bauer [ 2014 Dec 02 ] |
|
Hi Aleksandrs, We have two items defined for discovery: wmi.get["root\cimv2","SELECT StartMode FROM Win32_Service WHERE Name like '{#INESSERVICENAME}'"]
wmi.get["root\cimv2","SELECT StartMode FROM Win32_Service WHERE Name like '{#SERVICENAME}'"]
so the latter should be used for the above example. Is this problem related to the fact that even though services on clients have been removed, they are still listed - no rediscovery is "cleaning up" old entries? KR Stefan |
| Comment by Aleksandrs Saveljevs [ 2014 Dec 02 ] |
|
Stefan, could you please post the screenshot of your discovery rule with the error message and item prototype configuration, so that we are on the same page? |
| Comment by Stefan Bauer [ 2014 Dec 02 ] |
|
Alex, i just noticed that the error is not related to the discovery / delete of services. According to screen3 - auto discovery will remove the service in 2 weeks. |
| Comment by Aleksandrs Saveljevs [ 2014 Dec 02 ] |
|
Regarding your last comment, in order to remove discovered entities faster, adjust "Keep lost resources period (in days)" field in discovery rule configuration. Regarding the original case, the problem is indeed in your configuration. Discovery rule has two prototypes for wmi.get[]: one with {#INESSERVICENAME} and another one with {#SERVICENAME}. However, "services.discovery" outputs only one of them for each service. Thus, for JSON rows, which include {#INESSERVICENAME}, {#SERVICENAME} will not be expanded, and vice versa. So the error is expected and it works as designed. In order to correct the configuration, if you need to distinguish between "ines" services and regular services, the discovery rule should probably be split in two: one for each type of service. If you do not need the distinction, you might wish to use {#SERVICENAME} for both. |