NetXMS Support Forum

Got it. 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.

Могли быть недавние изменения в работе с прокси

что дальше в этих строчках в логе, "synchronized" или "not synchronized", каких строчек больше?

насколько большая система, покажите вывод sh st в debug console

сколько нод с агентами, работают ли они напрямую или через прокси, есть ли такое что на зонах указано больше одного прокси?

включен ли cache mode на агентах?

I don't see anything wrong in the configuration (the only thing to check if RAIDCONTROLLER_LSA_CRITICAL had "write to log" checkbox).

You can try right-clicking on the template and performing "Force deployment of agent policies".

Next step is to check that policy file is really present on this machine - they should be in C:\Windows\System32\ config\systemprofile\AppData\Local\nxagentd\logparser_ap (that's home folder of System user).

And next is to enable debug in agent config:
DebugTags = logwatch.*:7
agent log should have detailed information about logparser operations

Hi,

That message is expected if the Oxidized module itself is not loaded — it's logged at startup once the server has scanned all loaded modules and found none providing a device backup interface.

The thing to check: adding the OXIDIZED settings section to netxmsd.conf only provides configuration values — it does not load the module. You also need to add the module to the load list:

Module = oxidized

So a complete config looks like this:

Module = oxidized

*OXIDIZED
BaseURL = https://oxidized.example.com
Login = user
Password = secret
DefaultModel = ios

Once the module is actually loaded, you should instead see:

[backup] Network device backup interface is provided by module OXIDIZED

If you've already got Module = oxidized in place and still see "not available", look at the lines just above it in the server log — the module reports the specific reason there, e.g.:

- Oxidized integration module initialization failed (cannot parse module configuration)
- Oxidized integration module initialization failed (invalid base URL) — the BaseURL must start with http:// or https://.

Starting the server with -D5 and checking the backup/oxidized debug-tag output will show exactly where it stops. Note that the Oxidized server being temporarily unreachable does not cause this message — that only produces a warning ("Oxidized server is not reachable, will retry on demand"), and the interface still initializes.

One more thing to confirm: the Oxidized integration was introduced in NetXMS 6.1.0, so make sure you're running 6.1.0 or later — on earlier versions the module doesn't exist.

Best regards,
Tatjana

XML parser error is not really an error - this happens in some places, e.g. if configuration of a notification channel is empty (or contains only comments).

/var/lib/netxms/netxms.cmib is more interesting. Is your server running under root user or some other user? Does this file change it's modification time when you compile MIBs from the GUI? You can just move this file to some other folder and then check if it's recreated by mib compilation.

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?

NX-2437 only adds option to change MAC address for interfaces that were created manually, so guess this won't work in your case.

Дополнение от 9.6.26
Рестарт netxms-server привел к тому же процессу - "*D* [dc.agent.cache     ] Node::syncDataCollectionWithAgent: node" по куче нодов по логам и пока не стартанувший полностью сервер

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.

Hi, thank you for your answer - sorry i was on holidays.

Now i tested it again:

406 is creating a warning - this is working
251 should trigger a Critical warning - i have triggers for: 251 without level, 251 with Level 1 and 2 and 3

But nothing with 251 is working. 406 is triggering fine everytime.