Need Help - NetXMS 6.1.3 Alarm Notification Setup

[justrest]

Thank you so much for taking the time to reply to my post and offer your help!

I’m trying to set up reliable alarm and recovery notifications for my monitoring setup, and I was hoping you could advise me on the best way to achieve this using **native EPP rule configurations** in NetXMS 6.1.3, without needing to write custom NXSL scripts.

The core functionality I need is:
1.  **Alarm deduplication**: Only send one notification for the same issue within a 2-hour window, to avoid spamming
2.  **Proper alarm-recovery pairing**: Ensure recovery notifications are only sent for issues that actually triggered an alarm earlier
3.  **Targeted device filtering**: Only send notifications for devices I’ve marked as "focused" (not all devices in the system)

I did try writing my own NXSL scripts to implement this, but I got stuck on one critical part: I couldn’t figure out how to design a **universal key value that works across all types of events and alarms** (similar to what I’ve seen others refer to as an "alarm key") to properly link alarm events with their corresponding recovery events. Without this, I can’t reliably ensure that a recovery notification is only sent if an alarm notification was actually sent for that specific issue first.

I’ve looked through the EPP rule settings but I’m not sure how to combine these three requirements correctly using the built-in options. Could you walk me through how to configure the EPP rules to achieve this, or point me to the relevant documentation sections?

Thanks again for your time and generosity.

[Filipp Sudanov]

Can you give some examples of the issues for which you want to send notifications? How it can be determined that it's the same issue?

[justrest]

@filipp-sudanov said in Need Help - NetXMS 6.1.3 Alarm Notification Setup:

Can you give some examples of the issues for which you want to send notifications? How it can be determined that it's the same issue?

Thanks for your reply!

For nodes with frequent online/offline status or fluctuating PING latency around the threshold caused by line issues, do not send repeated alarms temporarily as the admin has been informed. Send recovery alerts only after the initial alarm is issued, and keep alerting for other new fault types on the same node.

[Filipp Sudanov]

For 2-hour window for a server action in an EPP rule set the following:

• Snooze time: 7200
• Snooze/blocking timer key: NODE_DOWN_%i

What this does - on the first time when action is executed is starts a timer with given key, on next executions it will run the action only if such timer is not running.

You can watch these timers in Configuration->Scheduled tasks if you enable "Show system tasks" there.

Is the problem is node-wide, e.g. node down you can use timer key with just %i macro - this will expand into node's id. If problem is related to a DCI use a %i_%<dciId> macro combination - this will be both node ID and DCI ID to ensure uniqueness of the timer key.

[justrest]

Thanks a lot for your help. I'll give it a try.