[ZBX-15942] Caveat with value throttling: queue statistics show real update time, not poll time Created: 2019 Apr 04  Updated: 2024 Apr 10  Resolved: 2019 Oct 29

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P), Server (S)
Affects Version/s: 4.2.0
Fix Version/s: 4.2.4rc1, 4.4.0alpha1, 4.4 (plan)

Type: Problem report Priority: Minor
Reporter: Alexey Asemov Assignee: Zabbix Development Team
Resolution: Fixed Votes: 3
Labels: preprocessing, queue
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File custom_autoincrement_step.diff    
Issue Links:
Duplicate
is duplicated by ZBXNEXT-5262 Option to exclude from Queue the item... Closed
Sub-task
depends on ZBX-16835 Caveat with value throttling (LLD) Closed
Team: Team A
Sprint: Sprint 51 (Apr 2019), Sprint 52 (May 2019)
Story Points: 1

 Description   

There is a caveat with preprocessing of change throttling (update when changed / update when changed with heartbeat).

We've started using that for multiple items, with 'heartbeat' interval of hours up to entire day.

Queue display started showing all such items in above 10 minutes. While it's correct because item was not actually updated for long (no changes), it is totally misleading, because item was actually polled, and looks like there is some polling problem (indistinguishable from polling issues).

The solution to distinguish between throttling and polling issue on queue view can be recording actual poll time for the item instead of the update time, and using this poll time for queue view display.

 Comments   
Comment by Elina Kuzyutkina (Inactive) [ 2019 Apr 05 ]

 
Hello Alexey,
I can't confirm the situation. During the day, did not repeat for any item with the preprocessing throttling step. Added for all discrete values (~ 10) with different heartbeat parameter and without heartbeat.
And this is the way it should be. The queue displays items that are waiting for a refresh. Those that zabbix server expected but didn't receive. (about saving in the database, we are not talking.) With throttling enabled zabbix receives values (but don't put them in DB if they are same as previous). There must be other reasons why you see a growing queue. Are there in the queue only these items? What type of check are items from the queue? Are they monitored via server \ proxy? Сheck the settings of the items themselves, the state of the server (all server performance graphs from Zabbix server templates), connectivity to proxy \ agents, etc.
If you are sure that throttling is the reason, then please attach screenshots of the queue + queue with the type Details, screenshots of the items settings, screenshots of all performance graphs from Zabbix server templates 1day period, zabbix server log file
Regards, Elina
 

Comment by Glebs Ivanovskis [ 2019 Apr 05 ]

Maybe this only affects items monitored by proxy?

Comment by Alexey Asemov [ 2019 Apr 05 ]

Hello,

Indeed, I confirm this happens only on items that are monitored by proxy. Can't repeat on 'local' items either.

Comment by Alexey Asemov [ 2019 Apr 05 ]

I also confirm it's certainly not a polling issue per se, throttling heartbeat works nicely.

Comment by Andris Zeila [ 2019 May 29 ]

Released ZBX-15942 in:

  • pre-4.2.3rc1 61aab3a703
  • pre-4.4.0alpha1 3362e79f87
Comment by Alexey Asemov [ 2019 Jun 27 ]

I confirm it works fine.

Thanks a lot for fixing this, it was really a big deal in my case 

Comment by Yanda Andrey [ 2019 Oct 29 ]

Hello,

This release broke zabbix proxy in some environments. For example, proxy cannot send more than 10 records per connection if auto_increment_increment > 1.

Comment by Yanda Andrey [ 2020 Mar 23 ]

I tried to fix this issue for me and I can share my tries. This workaround can be not optimal but I hope it could help someone.

custom_autoincrement_step.diff

Generated at Wed Apr 24 21:17:36 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.