Uploaded image for project: 'ZABBIX FEATURE REQUESTS'
  1. ZABBIX FEATURE REQUESTS
  2. ZBXNEXT-4271

Delay escalator by a huge escalations table with Recovery operations

XMLWordPrintable

    • Team A
    • Sprint 42, Sprint 43, Sprint 44
    • 1

      from ZBX-13137

      There are cases in which you store them in the escalations table without the OK event.

      Examples:

      zabbix=> select count(*) from escalations where status=2;
        count  
      ---------
       1180124
      

      The real problem is the "escalator busy 100%" in this situation.
      Escalator's busy rate has increased and It's hard to notice the problem until the problem occurs.

      Solution 1 (no need for development)
      Delete a "recovery operation" actions or "all event manual close" can solves this problem. (escalation table datas is also deleted.)

      And I also thought it's better to remove it from the escalations if really don't need to deal with "RECOVERY" by trigger settings. Problem of "escalator busy" is need improvement. Therefore, the additional improvements that require development are below.

      Solution 2
      With "OK event generation : None" and "Don't allow manual close" datas -> to be removed

      Solution 3
      With "OK event generation : None" and "Allow manual close" datas -> If possible, We need a solution that doesn't increase the escalator busy rate. (The best solution is not to store data in escalations.)

      Solution 4 (New Features)
      An additional feature that allows to automatically close (remove the old escalation data)

            vso Vladislavs Sokurenko
            JKKim Kim Jongkwon
            Team A
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: