Ad Widget

Collapse

Two OK messages, no problem. Issue with the trigger

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Valinor
    Junior Member
    • Sep 2020
    • 20

    #1

    Two OK messages, no problem. Issue with the trigger


    Hello,
    I have an issue with some trigger.
    It is based on two dependent items which basically are numbers get from the base item in JSON.
    The idea of it to compare these two numbers and fire an alert if they are not the same.
    {Template App Zabbix Server:first_one.last()}<>{Template App Zabbix Server:second_one.last()} here is how I made the trigger expression and it seem to work fine if there are any problems.
    But, once in a while(not every time the item renewed, but quite often) I get a message with two OK events of the same trigger with the opt data with the correct data: like 96742, 96742
    When I open the "problem" in Zabbix I can see that it was triggered and resolved with the same timestamp like: 2022-02-02 20:04:06

    Can someone tell what is wrong with it? Or give me direction to look further.
    Thanks!
  • cyber
    Senior Member
    Zabbix Certified SpecialistZabbix Certified Professional
    • Dec 2006
    • 4807

    #2
    Trigger is recalculated each time, when any of items used gets a new value. There is a slight difference in those two item value arrivals (nanoseconds). And then 0 length events happen.. I have seen this, but I don't have good cure for it...

    Comment

    • ISiroshtan
      Senior Member
      • Nov 2019
      • 324

      #3
      First thought in my head - calculated item. Setup calculated item that will do Item#1 minus item#2. The trigger - last value of calculated item <> 0.

      Unless I'm mistaken, calculated item updates on set intervals not on sub-item updates. So I believe it should work.

      Comment

      • splitek
        Senior Member
        • Dec 2018
        • 101

        #4
        Other way, if data is from one master item, is to add third dependent item that has a preprocessing that works like your trigger rule. This is the only way if you must trigger something as fast as possible (right after data arrival). If the delay between the data arriving and the recalculation of the calculated item doesn't bother you then calculated item is easiest way.

        I was in such situation (trigger action as fast as possible no delay allowed). Data what send by zabbix sender as a csv file, content like:1,2,3,4. This content was split by "," into dependent items (to build graphs for them). And the trigger had a rule like: "trigger action when (item_A>intem_B) or (item_C>item_D). So I added fifth item with javascript preprocessing. Simple JS script that split data into separate values, and compare them like trigger rule. If rule is meet script returns 1, if not 0. So I have fifth dependent item that is calculated with no delay, and now only need simple trigger to check for 1 or 0.

        But from where is the problem? Like cyber said, trigger is recalculated each time, when any of items used gets a new value.
        As an example how it works:

        We have a rule: "if A <> B run trigger". Data flow is:
        time(hh:mm), value A, value B
        01:00, 1, 1
        01:01, 0, 0
        In both minutes A=B (no trigger run). But let's do it step by step like Zabbix:
        In 01:00 time we have on stack A = 1, B = 1
        In 01:01 time new data come and we read value A first, because it is first in our "file". So we have on stack:
        A = 0, B = 1
        Now trigger check is run, because value A just changed. 0<>1 meet our trigger rule, so new event is generated!!!
        In just a processor tick, second value is read and put on stack, so we have:
        A = 0, B = 0
        Now trigger check is run, because value B just changed. Result of 0 <> 0 does not meet our trigger rule, so close the event !!!

        I think if a trigger is built on many dependent items which come from one and the same master item then this procedure should work differently:
        Don't run a trigger check every time a value changes, but wait until all the dependent values are "pushed onto the stack" and then run the trigger check. Run it once to save resources and not generate useless events.

        Comment

        Working...