|
Similar issue: ZBX-11844
|
|
ZBX-9933 asks to deal with associated triggers, and ZBX-10684 did some related documentation changes
|
|
Closely following this issue. This is something other monitoring products have addressed. It's an even nosier issue in environments with significant Windows footprints where the SNMP OID's for Network Adapters are very sensitive to change.
|
|
I have exacly the same problem as described in ZBX-4475.
There is many situations when item is not discovered any more and should have disabled trigger at LLD or eventual for specific trigger context.
|
|
Following this issue as it would be helpful to have an option to disable (item/trigger) prototypes, when the 'Keep lost resource period' kicks in.
Please provide us with the option to choose this on a case by case basis (in the discovery).
|
|
Two more use cases.
Dynamic infrastructures pollute the Zabbix queue
I monitor Kubernetes with Zabbix. It's a highly dynamic infrastructure, items and hosts come and go to match the application's workload.
I prefer not to remove immediately the results of a LLD that aren't discovered anymore, just in case I need their history to investigate an incident.
But then I end up with hundred of items in the queue for nodes or pods that were replaced, and I can't differentiate them from real Zabbix issues (overloaded proxy, misconfigured items etc.)
Dynamic infrastructures can produce invalid data
I connect to the IP of certain discovered pods to get further metrics from the application. I then aggregate the metrics of the group into a calculated item.
When a pod of application A gets deleted and its IP is reallocated to a new pod of application B that happens to answer to the same queries, Zabbix feeds metrics of B into the old items of A, even though the LLD marks them as lost resources. Of course, my aggregate gets plain wrong.
In that case I have no other choice than to remove lost resources immediately and forgo their history.
Conclusion
To monitor dynamic infrastructures, Zabbix needs to support pausing collection of items/hosts when they are not discovered anymore.
|
|
@Thomas very good conclusion.
Thanks
|
|
Extension proposal:
If LLD preprocessing uses "discards unchanged with hearthbeat", specifying this by "number of fails" will be unpredictable.
I propose extending this "after how many failed discoveries items should stop working" setting so it supports both "#7" and "5d" formats, just like min(), avg(), max(), etc.
I leave it to developers if setting it to "5d" will x) disable collection exactly after 5 days, or y) disable collection on next LLD run after 5 days run out.
|
|
This functionality is coming in 7.0, now under development. Thanks for all your comments.
|
|
FR looks good, but I can't understand 1.c.i.1. "the flag must be set to 1 (see 1.a)".
First I realize "the flag" is the flag from 1.a not this "Disable lost entities after period" setting.
Maybe change 1.c.i. to "When LLD rule is executed and entities (items, triggers, hosts) are not discovered for more than this period" and change 1.c.i.1. to "the flag (see 1.a) must be set to 1 and the entity disabled?
|
|
Will search be able to find items/triggers in this new "disabled by LLD" state? Will it find them exclusively, or only mixed together with "regular disableds"?
Will search be able to find entities in new "not discovered, but still collecting" state (related to ZBXNEXT-8508 )?
|
|
user185953,
That will be new internal flag. If entity is disabled by LLD rule, this flag will be set to 1.
|
|
user185953, thank you for the suggestion. The current task does not include implementing the ability to filter entities by "disabled by LLD" status, but it will be considered for potential implementation in the nearest future.
|
|
Available in versions:
|
|
Updated documentation:
|
|
Updated API documentation:
|
Generated at Mon Jun 09 07:33:02 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.
image-2024-03-04-09-52-46-613.png
✅ FR_ Disable entities marked for deletion by LLD v2.1.pdf
Team B