Capture and distinguish value in trigger

[markfree]

I have a template to capture SNMP traps from a server.
It has two items receiving all messages correctly:
For "server is Down" messages

snmptrap["\.1729\.104\.0\.4"]

For "server is UP" messages

snmptrap["\.1729\.104\.0\.3"]

The trap server receives this kind of message (UP or DOWN):

SNMPv2-SMI::enterprises.1729.100.1.10.12.0 type=4 value=STRING: "service:server is DOWN"

**The "service" name changes**

I can capture the service name using this macro function:

{{ITEM.VALUE}.iregsub("\"(.*):server is DOWN\"",\1)}

So, I thought of creating a trigger like this:

Problem:

find(/System SnmpV2/snmptrap["\.1729\.104\.0\.4"],#1,"regexp","\"{{ITEM.VALUE}.iregsub("\"(.*):serv er is DOWN\"",\1)}:server is DOWN\"")=1

Recovery:

find(/System SnmpV2/snmptrap["\.1729\.104\.0\.3"],#1,"regexp","\""{{ITEM.VALUE}.iregsub("\"(.*):ser ver is UP\"",\1)}":server is UP\"")=1

But Zabbix states that the expression is invalid

Cannot update trigger
Invalid parameter "/1/expression": incorrect expression starting from "find(/System SnmpV2/snmptrap["\.1729\.104\.0\.4"],#1,"regexp",""{{ITEM.VALUE}.iregsub(""(.*):serv er is DOWN"",\1)}:server is DOWN"")=1".

Any idea how to capture and distinguish the service name in the trigger expression?

[markfree]

I've changed some things.

Considering the SNMP trap value:

SNMPv2-SMI::enterprises.1729.100.1.10.12.0 type=4 value=STRING: "service:server is DOWN"

The template trigger expressions are:

Event name: Service is down - {{ITEM.VALUE}.iregsub("value=STRING: "(.*):server is DOWN"",\1)}
Problem: find(/System SnmpV2/snmptrap["\.1729\.104\.0\.4"],#1,"regexp",":server is DOWN"")=1
Recovery: find(/System SnmpV2/snmptrap["\.1729\.104\.0\.3"],#1,"regexp",":server is UP"")=1

I've added a tag in the trigger witch resolves to the service name.

Name: Service
Value: {{ITEM.VALUE}.iregsub("value=STRING: "(.*):server is DOWN"",\1)}

The trigger is now considering the "tag for matching" OK event.

PROBLEM event generation mode: Multiple
OK event closes: All problems if tag values match
Tag for matching: Service

Now, whenever a Down trap is received, the event is fired and I can see the alarm with the correct service name and Service tag value.


Still, when an UP trap is received for the same service, the event is not resolved.

What could be the issue?

[markosa]

Perhaps it's because of using "#1" in find, I think it means "use most recent value" which is for ....0.4 as DOWN and ...0.3 as UP, same time. I've strugled with same issue, even when not using "#1" in find but instead using time value(1 or 2s), it's quite random when you get ack for trigger and when you won't.

[cyber]

Now, whenever a Down trap is received, the event is fired and I can see the alarm with the correct service name and Service tag value.


Still, when an UP trap is received for the same service, the event is not resolved.

What could be the issue?

You are using 2 items here... item1 (/System SnmpV2/snmptrap["\.1729\.104\.0\.4") for generating a problem and item2 (/System SnmpV2/snmptrap["\.1729\.104\.0\.3") as additional condition, that has to be true, when trigger expression has turned false... Do you see your issue? Your initial item1 based expression is not turning False ever.... you only get those similar "server is DOWN" values there... look into item history. Your recovery expression will not even be considered...

Expression

Logical expression used to define the conditions of a problem. A problem is created after all the conditions included in the expression are met, i.e. the expression evaluates to TRUE. The problem will be resolved as soon as the expression evaluates to FALSE, unless additional recovery conditions are specified in Recovery expression.

Recovery expression

Logical expression (optional) defining additional conditions that have to be met before the problem is resolved, after the original problem expression has already been evaluated as FALSE. Recovery expression is useful for trigger hysteresis. It is not possible to resolve a problem by recovery expression alone if the problem expression is still TRUE. This field is only available if 'Recovery expression' is selected for OK event generation.

[markfree]

Oh, I see what you mean.
I guess that the "after the original problem expression has already been evaluated as FALSE" condition is the limiting factor in my scenario.

Fortunately, the monitored system has another similar trap for the same behavior. So, I had to change the item logic to make it work.

Thank you.