[ZBXNEXT-2844] Multiple Escalator Processes Created: 2015 Jun 11  Updated: 2017 May 31  Resolved: 2015 Dec 13

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Server (S)
Affects Version/s: 2.4.5
Fix Version/s: 3.0.0alpha3

Type: Change Request Priority: Minor
Reporter: Mathew Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: escalator, patch
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File multiescalator-busy-escalator-processes.png     PNG File multiescalator-busy-escalator.png     PNG File multiescalator-mysql-queries-per-second.png     Text File zabbix-escalator.patch    
Issue Links:
Duplicate

 Description   

Zabbix currently only allows a single Escalator. This provides a bottleneck for large installations relying on the Escalator to perform actions.

The attached patch implements multiple processes through a shared workload. Worload is distributed based on the modulus of the escalation ID. The MOD function has been chosen to preserve functionality with MySQL, SQLITE & Oracle.

This has been tested in production now for a few days with great results.

This patch is released in its entirety into public domain.

This is free and unencumbered software released into the public domain. Do with it what you will.

Specification: https://zabbix.org/wiki/Docs/specs/ZBXNEXT-2844

 Comments   
Comment by Oleksii Zagorskyi [ 2015 Jun 11 ]

Just a note - multiple alerters requested in ZBXNEXT-2442

Comment by Mathew [ 2015 Jul 16 ]

Any comment on the patch?

We did some feature testing with features we dont use relating to actions, almost everything worked with this patch. We tested dependencies, order of execution, different conditions, etc.

From this some considerations that might be worth consideration for a V2 patch:
a) MOD() could be performed on the eventid & r_eventid to stricly enforce order within escalation steps (i.e no possible BC breaks). Currently within the same escalation step it is possible for the order to be inconsistent.
b) We dont use recovery, and I am unsure if our action built to test it was correct but there may be an issue there. I was unable to find the cause however.

Happy to contribute in any way possible.

Comment by Alexei Vladishev [ 2015 Oct 12 ]

Specification proposal is available at https://zabbix.org/wiki/Docs/specs/ZBXNEXT-2844.

Comment by Andris Zeila [ 2015 Oct 14 ]

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-2844

Comment by dimir [ 2015 Oct 14 ]

Thank you for the patch, splitice! The approach we used is actually the same you offered. In addition we separated the escalations in 3 groups, based on the source of escalation. For details please see the specification and the dev branch.

Comment by Andris Zeila [ 2015 Oct 15 ]

Released in:

  • pre-3.0.0alpha3 r56197
Comment by dimir [ 2015 Oct 15 ]

The attached screenshots show improvement on using 10 escalators. With server restart number of escalators is changed to 1.

Each escalator is fetching the job executing SQL select so with every new escalator process SQL queries are added. But the last screenshot the difference is not significant.

Comment by Andris Zeila [ 2015 Dec 07 ]

Documentation:

sasha Thanks! CLOSED

Comment by Mathew [ 2016 Jan 16 ]

See bug ZBX-10237

Generated at Thu Apr 25 16:56:38 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.