NetXMS Forum

Hello,

On yesterday Q&A Webex session i've got a great idea on how to solve a challenge that i have for years - have generic EPP & Email notification actions, while selecting email recipients based on user's email addresses and group membership.

Apparently this can be implemented elegantly using the new feature Responsible Users.

Users and group objects can be set as Responsible Users on nodes and containers.
Then NXSL have the necessary functionality to write a script that finds the responsible users for a given node and return a list of their email addresses.
Then this script can be run through a macro in email notification action recipient address field - hopefully with a $node parameter. So that this script always returns the full list of email recepients for this particular node.

All above combined together will deliver exactly what i need - if i understand it correctly.

I spent few hours trying to develop such a NXSL script, but failed miserably. Can someone help with some hints? I am sure this will be beneficial for the community, not just me.

Thanks!

Hi,
Thanks guys, i confirm that it was using Java 8 and that was the problem. After installing OpenJDK11 it worked.

Hello,
we recently upgraded to v3.7, but noticed very wierd and unfortunately very destructive behavior.

The nodes keep changing their primary hostname without human intervention. The new address is some of the addresses of the nodes, but that completely breaks our monitoring.

Is that expected behaviour and how can we disable it? It is completely ruining our monitoring and other support processes.

Obviously we have set "Prevent automatic SNMP configuration changes", but that does not help.

I just increased debuglevel to 6 and i have lots and lots of these:

2021.03.02 13:03:50.815 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.43): failed
2021.03.02 13:03:50.930 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.93): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:50.930 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.90): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:50.941 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.86): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:50.999 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.95): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.016 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.124): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.080 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.126): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.106 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.137): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.110 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.142): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.110 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.141): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.142 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.148): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.229 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.5.142): trying version 0 community 'public'
2021.03.02 13:03:51.307 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.151.100): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.366 *D* [snmp.discovery    ] SnmpCheckV3CommSettings(10.8.17.113): failed
2021.03.02 13:03:51.366 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.8.17.113): trying version 1 community 'public'
2021.03.02 13:03:51.406 *D* [snmp.discovery    ] SnmpCheckV3CommSettings(10.8.24.102): failed
2021.03.02 13:03:51.406 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.8.24.102): trying version 1 community 'public'
2021.03.02 13:03:51.406 *D* [snmp.discovery    ] SnmpCheckV3CommSettings(10.8.49.107): failed
2021.03.02 13:03:51.406 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.8.49.107): trying version 1 community 'public'
2021.03.02 13:03:51.505 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.43.113.249): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.613 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.42.19.197): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.666 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.40.173.2): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.691 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.14): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.700 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.11): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.702 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.14): trying version 0 community 'public'
2021.03.02 13:03:51.710 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.11): trying version 0 community 'public'
2021.03.02 13:03:51.735 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.10): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.737 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.28): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.763 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.31): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.768 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.51): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.773 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.31): trying version 0 community 'public'
2021.03.02 13:03:51.779 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.27): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.779 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.37): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.803 *D* [snmp.discovery    ] SnmpCheckV3CommSettings(10.8.168.14): failed
2021.03.02 13:03:51.803 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.8.168.14): trying version 1 community 'public'
2021.03.02 13:03:51.815 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.32): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.835 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.40): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.838 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.36): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.844 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.40): trying version 0 community 'public'
2021.03.02 13:03:51.849 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.36): trying version 0 community 'public'
2021.03.02 13:03:51.975 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.88): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.983 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.102): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:51.990 *D* [snmp.discovery    ] SnmpCheckCommSettings(192.168.1.88): trying version 0 community 'public'
2021.03.02 13:03:52.229 *D* [snmp.discovery    ] SnmpCheckCommSettings(78.90.9.1): trying version 1 community 'CyIraBpNx3JjBqUDExzM'
2021.03.02 13:03:52.247 *D* [snmp.discovery    ] SnmpCheckCommSettings(10.43.114.250): trying version 1 community 'CyIraBpNx3

Does this confirm that network discovery is actually runing despite it is disabled in the configuration?
what can i do to stop it?

Hello,
shortly after upgrade to 3.7 we have decided to give it a try of the network discovery.
Initially it worked seemingly well, but we decided to not use it for multiple reasons.
However it seems to me that it never stops, regardless of disabling it from configuration->network discover-> general settings: Disabled
Even after netxmsd restart devices keep appearing in the Zones' subnets.

Also there is a significant increase in load of netxms server and agent proxies that i believe is caused by the continous network discovery.

is there a way i can actually check if discovery is acutally happening and a way to forcefully disable it?

Hi,
i have tried many different versions of java and NXMC but no button or menu option for debug console has appeared?
can someone with server 3.7 confirm if he has the console availalbe?

Hi,
I just noticed that i am missing the server debug console from NXMC (both windows app and web) after the upgrade to 3.7.

• is that expected?
• what are the alternatives?

Hello,
i have always wondered what is the deal behind the duplicate actions in the console tools->info->.. menu.

I can understand that some actions can be executed using Agent or SNMP, but there are few that say exactly the same thing but are duplicate.

Is there any actual function or is it just a bug?

Thanks!

I just faced the same issue to my suprise.

Server version 3.2
agent version 3.2

What is the recommended way to renew those certificates?

What i did (linux agent) is to delete the expired certificate from /var/lib/netxms/certificates; restart nxagent; it appeared as new unbound tunnel on the server and bound it again on the correct node.

Although it worked, it seems a bit "rough" to say the least.. is that the recommended way to go?

Thanks!

Hello,
For certain cases it would be very useful it we could specify as a DCI parameter source IP address for the Service Monitoring connections ServiceCheck.*

Our use case is we are monitoring 2 different paths to the same destination, where you select the path based on the source IP you are using to connect.

thanks in advance!

Hello,
We are running version 3.1-300

We are heavily using instance discovery and the performance tab for network devices. It works very very well and way it is developped gives us the flexibility we need to cover wide variety of scenarios.

Often we are using the grouping function which is also really nice, but i am wondering if there is a way to use automatic color selectionl, so that automatically created and grouped DCIs by instance discovery end up with distinct colors in the same graph?

+1 Vote for global server setting

Hello,
recently we noticed this occuring more and more. Without any human intervention some nodes change their SNMP version from v2c to v1.
Unfortunately that breaks most of the data collection, since i suppose some of the OIDs, or maybe 64-bit counters, are not supported over v1.

My question is - are there any normal circumstances where this change is expected to occur or that sounds like a bug?

I've seen some devices that it is easy to reproduce - every configuration poll changes v2c to v1, even though polling over v2c works fine.

For others the issue is not reproducible, but anyways we find them at some point changed to v1.

Thanks in advance!
Regards,

BTW is there a way to set interface propagate as fixed value in script? I saw few others asked the same thing in the years before with no answer.
My idea is to set it in Hook:CreateInterface if there is no other way to change the behavior globally.

Hello,
we are monitoring hundreds of network devices with many interfaces each.
Interface expected state is a neat and useful feature, but the default behavior of propagate as "Critical" does not fit our use case.

When a device is completely unreachable - that is critical for me, whereas when an interface that is expected to be UP goes DOWN, that is probably WARNING or MINOR.
and that covers 100% of our nodes and use cases.
So my question is - what would be the most simple and elegant way to globally change the behavior?
I know how to change it on a per-port basis - properties on port; set propagate as->fixed value->warning
I suppose i can make a script that regularly iterates all interfaces on all nodes to set that, probably also a script on a Hook (more optimal), but i was wondering if there is just a simple global way to configure it?

Hello,

in the recently passed few weeks we noticed brand new issue:
one or few of the agent tunnels appear as unbound without anyone changing anything. Ofcourse data collection stops at that time until you manually bind the tunnel again to the appropriate node.

We use the agents as proxies, so lots of nodes are affected on each occurence.

Any ideas are welcome on how to approach the troubleshooting of this issue!

Thanks!

Does that mean that even if in theory i write to code to translate to human readable text in instance discovery filter i will not be able to pass it back to the DCI parameter because the SNMP agent will not poll it if it is in text, and 255 characters are not enough to pass it as SNMP OID?

I think i can write the code to translate to readable text in the instance discovery filtering script, but i found that some instances are just too long even for the DCI parameter. What is the maximimum length of {instance} and the DCI parameter?

Hello,
i am trying to setup a nice template for monitoring F5 load balancers and their services with instance discovery.
I stumbled upon the way they are encode their object names in SNMP OIDs. I would like to use the decoded human readable string in NetXMS DCI instead of the long encoded code. Here is an example:

root@nxagent:~/.snmp/mibs# snmpwalk -v2c -c XXXXX 192.168.120.YYY iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500
iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500 = Gauge32: 10

root@nxagent:~/.snmp/mibs# snmpwalk -m F5-BIGIP-LOCAL-MIB -v2c -c XXXX 192.168.120.YYY iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500
F5-BIGIP-LOCAL-MIB::ltmPoolMemberStatServerCurConns."/Common/bok_finbridge_prod_pool"."/Common/bok_prod_10.102.149.41_finbridge".35500 = Gauge32: 10

root@nxagent:~/.snmp/mibs# snmptranslate -m F5-BIGIP-LOCAL-MIB iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500
F5-BIGIP-LOCAL-MIB::ltmPoolMemberStatServerCurConns."/Common/bok_finbridge_prod_pool"."/Common/bok_prod_10.102.149.41_finbridge".35500

As seen above when i load the MIBs in the standard linux net-snmp tools it does it automatically, but i couldnt find a way to implement it in NetXMS DCI/Instance discovery, apart from writing the code for translation myself in the instance discovery filtering script.

Any ideas?

Yes, that is it.
Is it by design?
I think it has been working for a while.