NetXMS Support Forum

More experienced people might correct me, but as long as I remember, reading status of link duplex was pretty non-standard thing that differed accross device make and models. For your specific devices you can create SNMP DCIs. If you need to check across peer devices, it's possible in nxsl as interface class has peerInterface attribute.

Hi,

I would expect that these devices support SNMP. If this is so, you need to enable snmp on the device and run configuration poll in NetXMS to check if SNMP capablitiy is detected (it's visible on node's Overview page). When this is done, you can use MIB explorer to walk available OIDs and add data collection items.

The other possible approach is to use ssh - in node properties you can specify ssh password or key. Or, if you have many devices, credentials can be specified in Configuration -> Network credentials - these will be auto-probed. If ssh credentials are ok, on configuration poll SSH capability should become "YES".

And, finally, if your device runs under linux, you can try generic NetXMS agents - but this depends on platform/cpu and not necessarily would work

nxshell is integration tool, that allows python code to interact with netxms server. For Windows GUI client you need to install this: https://netxms.com/download/releases/4.5/netxms-client-4.5.6-x64.exe

Current Windows WEB UI installer includes web api as well. It can be reached at http://127.0.0.1:4788/api/
War file itself is located in C:\NetXMS-WebUI\jetty-base\webapps\api.war

Yes, debug log on level 6 would be beneficial. Couple of options
 - use some netxms agent in proxy mode and take the log of it
- use some test installation of netxms server that has just a couple of SNMP nodes (it's also worth to unmanage the node that represents server itself to minimize logged stuff)

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.