NetXMS Support Forum

The only situation when this might be happening - if during configuration poll device did not answer to a packet with currently stored community string. In this case server thinks that community string might have changed and starts trying all available ones. You can do tcpdump from your server filtering by device IP and SNMP port, then we will have some more information. The command is
tcpdump -s 0 -w traffic.pcap host = IP_ADDRESS

Or you can just set checkbox "Prevent automatic SNMP configuration changes" in node properties, it should prevent trying community strings.

Alarm filter allows to filter by multiple conditions - if you press space bar in filter field, drop down with possible keywords will open.

Source: - is node name, however wildcards are not supported. But you can make a separate container for your servers - nodes can be present in multiple containers simultaneously. And containers can have auto-bind scripts to add nodes automatically.

Event: - is event name, list of possible options will be shown. It is convenient to configure events with different names for different occasions in addition to SYS_THRESHOLD_REACHED. This way it's easier to dealt with them in EPP rules or search alarms, so your update DCI is a good candidate to have separate event for it.

That's approximately it. In addition you can check DCI summary table functionality - this allows to display table with DCI data accross multiple nodes.
And, also, you can use a container and it's auto-bind script to add only nodes that have some threshold triggered. This way you'll always have a list of nodes that require attention at hand.

Hi,

how it is with dimensions of these vertical PDUs - are they all same length or there are different ones? Are they typically installed on say left side, or may be on both sides? Are these happen to be with SNMP, or just passive (in that case that could fit as some overall rack decoration image).

Its actually available, but not yet documented. In proxy agent config you need to enable

EnableTCPProxy=yes



URL and local command object tools have "Setup TCP tunnel to remote port" - set a checkbox there. When running such object tool, client will open a local port and establish tunnel via the server and the proxy. Your node should be in a zone and the proxy should be specified as zone proxy in proxy's properties.
Then there's a couple of macros that you can use in URL or local command:
${local-address}:${local-port}

More details can be found in recent webinar: https://www.youtube.com/watch?v=M4EgwnzGXVE

In new management client it's in "Configuration", "Import configuration" / "Export configuration"

For servers - you'd need to install netxms agent and set
MasterServers = IP-address-of-your-netxms-server

in nxagentd.conf

After adding a node in netxms, it should detect that agent is present on that system, then you can add DCIs (data collection items) for the metrics that you need.

Also, check the docs, there's some info there:
https://www.netxms.org/documentation/adminguide/concepts.html

https://www.netxms.org/documentation/adminguide/quickstart.html

Какая именно версия NetXMS? Возможно в каком-то из последних релизов была проблема с тем, что радиус построения карты по умолчанию был неправильный, можно поставить его вручуную в значение 5.

Еще проверить закладку Interfaces на двух девайсах, соединенных вместе - видна ли связь с обоих сторон в колонке Peer node.

The are not instantly deleted and can be still viewed in Alarm Log. Deletion will happen by housekeeper after 180 days (can be configured in Configuration -> Server Configuration, parameter name "Alarm.HistoryRetentionTime")

The password should normally work unencrypted. The only exception is when the password itself is base-64 encoded and has specific length (44 or 88 characters) - in this case NetXMS will think that it's something encripted by nxencpasswd - in this case the workaround is to actually encrypt it with nxencpasswd.
Also, double-check the "Login" field.

You can select many alarms at once and select "Terminate" from right-click menu. And disabling event processing policy rules that you don't need would prevent these alarms from happening in the future.

Try issuing
debug nc 8
debug ncd.* 8
in Tools->Server Debug Console. Then try to send another email and show what you have in your server log (/var/log/netxmsd on Linux)

Check configuration -> Event processing policy. 

The way NetXMS is built is that when something happenins (interface went down, threshold reached, etc...) it creates events (log of these can be seen in Event Log). Reaction to events is defined in Event processing policy (make sure you click "save" button when working with it).

This page: https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview says that "OSPF SNMP monitoring" is N/A, so looks that this is not yet implemented in Mikrotik.
I've seen mentions that OSPF can be monitored using Miktorik API - I've never tried that, but it should be possible to take some client for that and use it via NetXMS agent external metrics.
Or, if this information can be collected via ssh - collecting metrics via ssh is out-of-the-box in NetXMS

Maps were reworked in 5.0, but there are still some things to finalize before it's released. Release should happen within coming month.

Hi,

Out of curiosity, what are the reasons to build from source, as there are packages for Debian. But, chances are that it will also crash if installed from packages.

Can you please run it under gdb:
gdb --args netxmsd -D 6

then enter run
when it crashes, enter bt and show us the output