[ZBX-6315] LLD triggers are deleted immediately if not discovered anymore Created: 2013 Feb 25  Updated: 2017 May 30  Resolved: 2014 Jan 31

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 2.0.5
Fix Version/s: 2.0.11rc1, 2.2.2rc1, 2.3.0

Type: Incident report Priority: Major
Reporter: Marc Assignee: Unassigned
Resolution: Fixed Votes: 19
Labels: delete, lld, trigger
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, CentOS-6.3, PostgreSQL 9.1.8, Apache HTTPD-2.2.15, PHP-5.3.3


Issue Links:
Duplicate
duplicates ZBX-7109 Very slow processing of low-level dis... Closed
is duplicated by ZBXNEXT-1974 LLD Graph/Trigger prototypes saving Closed
is duplicated by ZBXNEXT-1635 LLD triggers are deleted immediately ... Closed
is duplicated by ZBXNEXT-1683 Trigger and Trigger-Status will be re... Closed

 Description   

We use LLD to dynamically discover ActiveMQ queues. After restarting the application these queues may not exist until they are used the first time. New queues may appear at any time as well as queues may disappear for ever.

This works quite well for items because they still get their values even if they are no longer discovered and if a queue is no longer available for a reasonable time it gets finally removed from Zabbix.
In this use case SLA calculation gets broken if it depends on triggers which are based on LLD prototypes.

Not sure if it's a bug or the documentation doesn't point it out clearly:
"Items (similarly, triggers and graphs) created by a low-level discovery rule [...] will be deleted automatically if a discovered entity [...] stops being discovered [...] they will be deleted after the days defined in the Keep lost resources period field pass."

That's exactly how it works for items but not for triggers.
Triggers based on LLD prototypes are deleted immediately if not discovered anymore. Normally that wouldn't have a big impact because they get created again as soon as they will re-discovered. But this behavior is really counterproductive if one got hundreds of LLD-Triggers that are used for SLA calculations in IT-Services.



 Comments   
Comment by Oleksii Zagorskyi [ 2013 Feb 26 ]

Interesting, need to check.

This works quite well for items because they still get their values even if they are no longer discovered ...

ZBX-4475 - related to the quote

Comment by Mark Strey [ 2013 Mar 27 ]

are there any Plans to fix this in 2.0.6? It´s critical for our Environment where nearly everything will be discovered dynamically...

Comment by Riaan Olivier [ 2013 Apr 10 ]

Can we please have an update on this task. Would love this to be fixed in the next version. Agree with mark Strey above, we also setup almost all our our monitoring as automated discoveries and would like this fixed. We are missing services thats down because the auto discovery removes the triggers.

Comment by richlv [ 2013 Apr 11 ]

this is not on the roadmap currently

Comment by Marc [ 2013 Apr 23 ]

In this case the documentation should be corrected

Comment by adient [ 2013 May 16 ]

Any update on getting this on the roadmap? Completely breaks monitoring we've designed to use the low-level discovery feature.

Comment by Volker Fröhlich [ 2013 May 17 ]

I tripped over that as well! Please update the documentation!

Comment by Raymond Kuiper [ 2013 May 24 ]

I've run into issues here as well. Some types of item/trigger combinations need to stay active for a while, even if LLD has not discovered them on the last run.
Would be nice to state a grace period in the discovery in addition to the cleanup period ("Keep lost resources period (in days)").

Comment by Andrey Semyonov [ 2013 Aug 21 ]

As of ZBX-6914 I could provide some scenarios either: dynamic SNMP tables monitored with LLD, for example OSPF-MIB::ospfNbrTable.

As for suggestions: trigger prototypes and triggers based on them could be flagged as "keep within related items' keep in history interval", so at least configuration manager (or zbx-admin) makes his own decision on whether he needs trigger persistence or better not.

Comment by Andrey Semyonov [ 2013 Aug 21 ]

Furthermore, some related bugs refer to ZBXNEXT-1575 as for trigger states upon item's availability states. If so, then this might be a blocker bug for 2.2

Comment by Andrey Semyonov [ 2013 Sep 04 ]

I've proposed a very rough patch here: https://support.zabbix.com/secure/attachment/23912/lld-c.patch

If anyone could review the patch and could also make appropriate changes to frontend that'd be a great start to fix this issue.

Comment by richlv [ 2013 Oct 22 ]

(1) when this is fixed, it should be checked that graphs are kept for that period, too

<richlv> graphs are ZBX-5789 , CLOSED

Comment by zhangjialiang [ 2013 Nov 26 ]

Any update about this issue? We can not try zabbix 2.2.0, the bug will make our lld-related check useless.

Comment by Marc [ 2013 Nov 29 ]

Just become aware about an actually obvious fact of loosing related events as well

Comment by Alexander Vladishev [ 2014 Jan 02 ]

It will be fixed with ZBX-7109. LLD trigger-related code will completely rewritten.

Please wait a little.

Comment by richlv [ 2014 Jan 07 ]

closing as a dupe of ZBX-7109 where this was fixed

Comment by richlv [ 2014 Jan 11 ]

...actually, not fixed yet, reopening

Comment by yuusou [ 2014 Jan 17 ]

This is still happening with 2.2.1. Also, deleting the host and re-adding it by hand doesn't re-create the triggers nor graphs. I have identical hardware and software (bar IPs and hostnames) with completely different number of triggers and graphs between them. I use solely SNMP.

Comment by Alexander Vladishev [ 2014 Jan 27 ]

Fixed in pre-2.0.11 r41917, pre-2.2.2 r41993 and pre-2.3.0 r42023.

Generated at Fri Mar 29 07:39:57 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.