[ZBX-20175] Zabbix still uses value cache for trigger calculation when not keeping history data Created: 2021 Nov 04  Updated: 2024 Apr 10  Resolved: 2022 Jan 25

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 6.0.0alpha5
Fix Version/s: 6.0.0beta3, 6.0 (plan)

Type: Problem report Priority: Major
Reporter: Kaspars Mednis Assignee: Andris Zeila
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File history.diff    
Team: Team A
Sprint: Sprint 82 (Nov 2021), Sprint 83 (Dec 2021), Sprint 84 (Jan 2022)
Story Points: 0.5

 Description   

Steps to reproduce:

  1. Create some item and trigger
  2. Send some data to item and detect problem
  3. Change item to do not keep history
  4. Send some data to item and detect problem again

Zabbix still uses value cache to calculate trigger, and it seems the value will stay there until Zabbix server restart.
Even when sending any value which must not create a problem, it is ignored, value is colected from value cache and problem is detected

If the calue cache is empty, it will try to read the value from database, where it still may exist

This behavior is very confusing, it may detect problems using wrong values ,and additionaly these problems will never close.

Expected:

If item is not storing history, history syncer will not try to calculate triggers for this item using value cache

 Comments   
Comment by Vladislavs Sokurenko [ 2021 Nov 08 ]

Thank you for your report, is there a reason why trigger for historical value exists if history is disabled for that item ?
Also tried restarting Zabbix server and it works the same as without restart, so it simply caches last value from database if it is requested.
Could you please elaborate more about expected behavior, should trigger become unknown ?
Could it be frontend issue that it should warn that trigger still exists for historical value ?

Comment by Kaspars Mednis [ 2021 Nov 10 ]

I think if the trigger will become unknown and will be not calculated, this will solve most of the problems.

Any open problem caused by such trigger also should be closed or removed, otherwise this may leave some problems in open state forever.

It would be nice, if frontend would give a warning like this - You are disabling history for the item, but there are some triggers using this item which will no longer work.

This may rise another issue with setting the triggers to UNKNOWN status - we are supporting several trend based trigger functions (trendavg, trendcount, trendmax, trendmin, trendsum), they do not rely on history but completely on trends (as far as i know), there should be different behavior for such functions if history is disabled but trends are still colected.

Comment by Kaspars Mednis [ 2021 Dec 08 ]

Yes, i think this approach will solve the problems

As i can see from the patch, it will handle history and trends functions differently, which is perfect.

wiper: With exception of nodata() function, which I will add.

Comment by Andris Zeila [ 2022 Jan 17 ]

Released ZBX-20175 in:

  • pre-6.0.0beta3 d34ce9424c
Generated at Fri Jul 04 07:24:09 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.