Ad Widget

Collapse

Trigger and Recovery Expression Help

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • NightEdition
    Junior Member
    • Mar 2024
    • 19

    #1

    Trigger and Recovery Expression Help

    I have one generic item which captures all Critical, Error and Warning events from a Windows Event Log (i.e. DFS Replication).
    and another item that captures specific Information events that are to be used for recovery expressions.

    Template: DFS Replication Events Template:

    Item Name 1: DFS Replication: Critical Error and Warning Events
    Key: eventlog[DFSReplication,,(Critical|Error|Warning),,,,skip]

    Item Name 2: DFS Replication: Replication Resumed
    Key: eventlog[DFSReplication,,"Information",,^5004$,,skip]
    I then have separate triggers for each event ID that I wish to generate problems for.
    An example for the trigger for event ID 5014 (replication stopped) with severity of Warning, and associated recovery event ID of 5004 (replication resumed) is shown below:

    Trigger Name: DFS Replication Event 5014: Replication Stopped
    Severity: Warning

    Trigger Expression:
    {DFS Replication Events Template:eventlog[DFS Replication,,(Critical|Error|Warning),,,,skip].logseverity()}=2
    and
    {DFS Replication Events Template:eventlog[DFS Replication,,(Critical|Error|Warning),,,,skip].logeventid(^5014$)}=1

    OK Event Generation: Recovery Expression

    Recovery Expression:
    {DFS Replication Events Template:eventlog[DFS Replication,,"Information",,^5004$,,skip].logeventid(^5004$)}=1

    Problem Event Generation Mode: Single

    Despite event 5014 and subsequent 5004 occurring, the problem is never resolved.
    I understand this is because the trigger expression remains TRUE, hence recovery expression does nothing.

    Is there a way to use the nodata function (or any other function) with my existing Trigger Expression, to allow the recovery expression to take effect?

    Please help advise of best solution for this issue.

    Thanks.​
  • cyber
    Senior Member
    Zabbix Certified SpecialistZabbix Certified Professional
    • Dec 2006
    • 4807

    #2
    Your understanding is correct. If main expression is still true, recovery is not looked at..

    If you add "... and nodata(/host/item,X)=0" to your main expression, it will stay open for that time X in case no new data has come for the item... X cannot be shorter than 30s. Its internal thing.... all nodata triggers are recalculated each 30s...

    If you really-really want original to be closed only, if specific other event is found by other item, then you most probably ened to turn to event correlation. Extracting some data from both events, setting tags and values and doing correlation based on that...

    Comment

    • NightEdition
      Junior Member
      • Mar 2024
      • 19

      #3
      Thanks for the reply. I'm currently on v4, I understand nodata is supported, however I don't believe the specific "nodata(/host/item,X)=0" is supported.
      Is there an alternative?

      Comment

      • ISiroshtan
        Senior Member
        • Nov 2019
        • 324

        #4
        The nodata should be supported, but v. 4 Had different syntax. It was smithing like:
        {DFS Replication Events Template:eventlog[DFS Replication,,(Critical|Error|Warning),,,,skip].nodata(X)}=0

        Tho I think it would be more complicated then just nodata. Your recovery expression item value will be always matchimng the expression condition, as last value is always recovery message, so it will essentially always resolve when nodata() timer ends.

        I would advise to remake item to collect both firing and resolving events from log. Then you can skip nodata part and point both trigger and recovery expressions to same item and it should work.

        Comment

        • NightEdition
          Junior Member
          • Mar 2024
          • 19

          #5
          I think that's a disadvantage to the generic item configuration I have.
          If I understand correctly. .... Multiple event IDs are being captured by the item, therefore I don't have a means to use nodata with a specific eventID in expressions, is this correct?

          Re-configuring my configuration to have multiple items and triggers per event ID would be required if I wanted to effectively use the nodata function?

          Am I understanding this correctly?

          Comment

          • ISiroshtan
            Senior Member
            • Nov 2019
            • 324

            #6
            Multiple event IDs are being captured by the item, therefore I don't have a means to use nodata with a specific eventID in expressions, is this correct?
            Based on your original post, you seem to catch 3 different levels of messages (warn, err, crit) into single item #1. If you use no data in such case, they will extend each other. So if you had a warning message - alert fired - before nodata() timer went out an error message was captured - now nodata() timer will be counted from this latest error message, not from original warning message

            But what I try to draw your attention to: you also have #2 item which catches only recovery messages and you try to make a recovery expression of it. The expression logeventid() checks if last value item has matches specific eventid. But that item will ALWAYS match, because it captures ONLY recovery events. Even if fresh event happened 5 seconds ago, the last value in item #2 is event 5004 from hours/days/weeks ago, which matches recovery criteria..

            Optimally you would want to have item that capture events of start of problem and end of problem. If last log sent by agent is a problem event log - alert remains fired(or getting opened). If last log sent by agent is recovery event - problem closes. This way you don't need nodata() function at all.

            More complicated scenario is if you want a separate alert fire in Zabbix for each warn/err/crit log entry, but I would not go there just yet and first figure out basic operation of trigger how you want it.

            Comment

            Working...