NetXMS Support Forum

Guess the answer depends on if you want to create a DCI (as you mentioned a transform script) that collects these top 5/top 10 at regular intervals or if you just want a script/tool you can execute at any given time to provide you with the data.

Not sure about the prior, but for the latter you have a couple of options.

• Summary Table
• Scripts

If you just want a top 5 of a DCI value, a summary table should do it.
It won't exactly be a top 5, as it will list all systems that match, but you can simply sort the result and look at the top 5 rows. That's the easy solution. Doesn't work for your "between 9pm and 11pm" though.

The more complex solution would be to write a script that goes through all relevant nodes and queries the DCI values (possibly by going via template, as per your previous post https://www.netxms.org/forum/general-support/adding-together-oids-from-many-different-nodes-within-a-tempate/). The per-system results (and system names) are placed in an array (would be easier if you could have arrays with strings as keys, but I believe it's only non-negative integers). You can sort the array as you add items or fill the array first followed by you implementing your favourite sorting algorithm (there may be a built-in way to sort an array, but I couldn't see one on https://wiki.netxms.org/wiki/NXSL_Function_Reference). Finally you only return the top 5 results.
Why go through that hassle when you can use a Summary Table? Because a small adjustment will allow you to get your 9pm-11pm solution, which I assume means "average value between any given time". You'd have to adjust the script to use the GetAvgDCIValue function instead of GetDCIValue and pass it the start and end time in UNIX Epoch format. If you call this script via an Object tool, you could have the Console pop up with window to ask you for the start/end time instead of you having to modify the script each time.

Sorry, no actual script from me for that one...

Your server is probably configured to be case sensitive in regards to usernames (that's the default).
The LDAP username is all uppercase, while you're logging in with the name in all lowercase.
So either use the all caps name to log in, or set the "CaseInsensitiveLoginNames" server configuration option to "1" and restart your NetXMS server service.

Always worked for me, but I am having the same issue since today: "Your session timed out while posting. Please go back and try again."
Only logging in via Login page works.

If I understand you correctly, you want a total figure of a specific DCI that exists on all nodes which are assigned to a template.

You could create a dummy node, assign it to the same template and create a separate Script DCI on it, similar to this:

templates = GetNodeTemplates($node);
total=0;
foreach(t : templates) {
if ( t->name == "<NAMEOFYOURTEMPLATE>" ) {
children = GetObjectChildren(t);
foreach(c : children) {
dciValue = GetDCIValue(c,FindDCIByName(c,"<YOUROID>"));
if ( dciValue != null ) total+=dciValue;
}
}
}
return total;


Quite possible that this can be simplified.
I just tested that against a PostgreSQL Template we have, to add up the size of some databases with the same name. I used FindDCIByDescription for this purpose, but the effect will be the same.
Example output (with some additional println to show the individual database sizes to confirm this works):
Database Size: 17988120
Database Size: 1099291160
Database Size: 20306456
Database Size: 49494552
Database Size: 19675672
Database Size: 30808600
Database Size: 16579096


*** FINISHED ***

Result: Total: 1254143656

You can then add this particular script DCI to your Dashboard.

As the template is using instance discovery (https://www.netxms.org/documentation/adminguide/data-collection.html?highlight=instance%20discovery#instance), your data collection configuration will show:
- The {instance} DCI.
- Any DCIs created by instance discovery based on that {instance} DCI.
Last values will not show the {instance} one.

To filter out volumes you don't want to see, you will want to look at adding an instance discovery filter in the template.
Some examples around filtering file system monitoring can be found at https://www.netxms.org/forum/configuration/dci-filter-script-how-to-ignore-some-filesytems/

To add the node name in the email, you'll want to use the %n macro (name of event source object), as per https://www.netxms.org/documentation/adminguide/event-processing.html#macros-for-event-processing

If you want full configuration management, Unimus is probably the way to go with NetXMS.

If you're just after config backups and diffs (not really management, as you're not pushing anything back), you can probably use tftp servers and git.
For example, we've configured our Ciscos to write a config backup to a tftp server on any config save. That server runs git for versioning.
For our Brocade switches, we use the configuration change traps to trigger a config backup via SNMP Write to the same tftp server. Same git.
I'm sure similar things can be done for other vendors.

It really depends on what you're after I guess.

If I'd hazard a guess:
Reason #1: Is the one you gave. If you google network monitoring software, NetXMS pops up once in one of the top ten hits, inside an article. With like two paragraphs. It's simply not visible enough.
Reason #2: Templates. There aren't a lot of them publicly available. If you have a reasonably sized network, you have a lot of template building to do. That costs time and may also require additional learning. I certainly learned SNMP and SNMP Traps in more depth as a result of this. Not everyone has the time to do so. Not everyone has the support of the employer for that either. Which brings us to
Reason #3: Learning curve/time investment vs. "just buy something". The way I see it, when you buy something like PRTG you basically pay for the work they put into the templates. You install it, let it scan your network and you have pretty graphs and things out of the box and you can move on with life. Until maybe you notice something's missing or eventually the cost of ownership creeps up too much and you start looking around again. But you already spent so much money on the product.... (with NetXMS that'd be the other way around... you already spent so much time on making the solution work "just right" for yourself, you probably feel emotionally attached).

Question 1:
- Do not enable Windows' own SNMP Trap service. That service is designed to allow Windows itself to capture other device traps, but you want the NetXMS Agent service to capture those.
- You do not need to configure SNMP Traps (inside the SNMP service), unless you want your Windows 10 Pro PC to send its own Traps somewhere. In short: You do not need this to collect traps from network devices.

Question 2:
- Move the Windows 10 Pro PC into the SITE1 Zone (right-click on node, Change Zone)
- Right-click the zone, select properties, select Communications, select the Windows 10 Pro PC as default proxy
- Add the SNMP devices manually and ensure they are in the SITE1 Zone. (Alternatively: configure Active Discovery for the Zone and wait for devices to be discovered. However, for now it is probably easiest to just add the handful of devices manually),
- If you are looking to poll SNMP data (e.g. bandwidth/cpu/memory usage, etc.) on the printers/switches/router now, you should be ready to go.

Notes:
If you are looking at collecting SNMP Traps (which is something very different to polling SNMP data - Traps are packets sent from the device in question when a certain event is triggered, these are NOT used for Data Collection Items), you need to also configure each of these devices so send SNMP Traps to your Windows 10 Pro PC (might as well configure Syslog while you're at it) and add "EnableSNMPTrapProxy=yes" to your proxy agent configuration on Windows 10 Pro PC.
Your proxy agent does not require any additional configuration to act as Syslog Proxy.

The dashboard is built left to right, top to bottom. The order is important here, as it leads to the following column assignment in your setup:
First row: 2, 2, 1, 1, 3 (one too many as it builds left to right and 1/1 fits next to 1/1 still)
Second row: 2, 2, empty(!), 3

You want to move the second 1/1 item below the 3/2 one, which should give you what you're looking for:
First row: 2, 2, 1, 3
Second row: 2, 2, 1, 3

I built a quick test dashboard which shows the layout and values.

This means that you have a DCI that uses instance discovery (with {instance} in it).
Multiple DCIs will be generated based on a list you configured to be used by that instance discovery DCI (see the Instance Discovery section of the DCI). Those generated DCIs will no longer have {instance} in it. That variable will have been replaced by an entry from the provided list.

Those generated DCIs can be overwritten at any moment because:
- the contents of your list might change (leading to a new DCI being generated or an old one wiped)
- the instance discovery DCI itself might be changed, e.g. you might change the name, transform scripts, thresholds, etc.. These changes will be pushed down to the generated DCIs, too.

You generally do not want to actually edit such a generated DCI.
If you want to make a change, you want to make it on the primary instance discovery one (i.e. the one with the {instance})

How long does it take your script to run?
More than the 5 second timeout?
Have you restarted the agent and did you run a Configuration Poll after adding the External Parameter?

I believe you need to separate the parameters with a ",", i.e. EMC_Getbalance(--ip=10.12.60.42,--port=80).
Not sure how exactly your tool works, but if it always expects --ip= and --port, you could probably add that to your ExternalParameter and only pass the actual IP and port number, e.g. ExternalParameterShellExec=EMC_Getbalance(*):C:\NetXMS\scripts\EMCCommunication.exe --ip=$1 --port=$2.

There's a feature request for this one: https://track.radensolutions.com/issue/NX-1557
For your other feature requests, I suggest creating an account on the page above and registering them there, too.

You can have two ServerConnection parameters (these need to be on separate lines in your configuration), but they will not act as failover. They will both be live.
I am not sure how the server will handle two connections from the same agent.

Using Agent Tunnels, you can have all the NetXMS Agents talk directly to the server via tunnel - they agents themselves no longer need to be polled via a proxy.
However, you will still need to use one of the agents as proxy for any SNMP devices you wish to monitor in that remote network.