NetXMS Support Forum

Hi,

I have a few Performance Counter DCIs, which will only collect data when a process is running.
When the process doesn't run, NetXMS will generate a collection error.
So far, so expected.

In this particular case, I'd like to be able to transform a data collection error into a value, i.e. 0. Main reason for this are graphs - the errors mean NetXMS will try to connect the dots between whenever instances when the process was running, which looks rather confusing and 0 is in fact accurate in this case. If a process is not running at all, then it is not utilising any CPU (or disk/memory).

But it looks as if a collection error means the transformation script is not even called (I added some trace commands, but nothing was ever logged)?
Not sure if it would be possible to allow sending such an error condition through to a transformation script to handle (without breaking the current process, i.e. if a transformation script doesn't handle this particular condition, it should still return the usual data collection error).

Cheers

Hi,

I believe reducing the AlarmHistoryRetentionTime from the default of 180 days, followed by running the housekeeper process (which usually runs once a night, but can be triggered by opening the NetXMS Server Console and running "hkrun") should clean that up somewhat. The housekeeper may run for a very long time though.
Same with DCI data, you can set a DefaultDCIRetentionTime (or per DCI) as well as EventLog, AuditLog, Syslog and SNMPTrapRetentionTime.

Not sure what database you are running. If it's Postgres, make sure your autovacuums are running properly, especially on the raw_dci_values table.

Cheers

Hi,

Just as a follow up in case anyone else runs into this:
It is an issue with WatchGuard firewalls from firmware 12.0.1 onwards and due to a change by WatchGuard.
The ifIndex OID no longer returns a matching value, which leads to NetXMS' confusion.
A ticket has been opened with WatchGuard.

Cheers

I generally keep debug to level 1 (or off) unless something is wrong, as I otherwise end up with several gigabytes of logs in a matter of minutes.
Is there a way to set debug level to 5 for this particular area only?

Hi,

Looks like this was fixed in 2.2.2, as per https://www.netxms.org/forum/general/dci-initital-type-conversion-before-translation-rule-works-different-since-2-2-1/.

Cheers

Hi,

There have been some changes around data types recently and it appears that the data type in a DCI is now both, the expected data type for in- and output.
For some transformation scripts that may not be desirable though. For example data might come in as a string, but the transformation script returns an integer. This integer will now be treated as a string and thus line graphs don't work (just showing "0").

Not sure if it would be possible to allow users to optionally have different in- and output data types?

Cheers

Hi,

Just found one and attached a screenshot, which basically shows that nothing happened while updating instances.
Yet, the "Hyper-V" ones had a number of Disabled instances.
For all I can tell Instance Discovery ran at some point while the relevant service on the server wasn't up, so it couldn't generate the instance list at the time. This resulted in some garbage instances (I need to add better error handling to the external list command). Either way, those garbage instances were properly disabled once the service was back up. However, the correct instances were not re-enabled. The moment I manually switched them to "Active", they just started working without any further changes necessary.

Cheers

Hi,

We have run into an odd issue after installing firmware upgrades on a number of virtual firewalls.
The old firmware would happily show all relevant interfaces, while the new firmware results in a lot of nonsense (and breaks our instance discovery).

Initially I was going to consider this a bug in the firmware and report it to the vendor, however, upon going through an actual SNMP walk on two devices (one with, one without the upgrade), both return sensible data. So now it seems like NetXMS is having an issue of some sort.
I can confirm that the firmware does lead to changes in the interface tables, namely the interfaces suddenly start at 65536, instead of 1.
For all I recall OIDs fields are allowed to be up to 2^32-1, so this shouldn't be an issue?

See attached screenshots of a device with the old and a device with new firmware.

Thanks

Hi,

Of course since I posted I have not run into this again.
The only ones that are currently staying disabled are indeed due to OID changes or similar events which trigger new instances.
I'll let you know if/when I encounter this again.

Cheers

Hi,

I stumbled over some syslog entries in our system which were being generated just before midnight on 31.12.2017 and ended up with a timestamp of 31.12.2018 in the NetXMS database. Screenshot below. The timestamp on the left is the NetXMS database one. The one on the right is part of the syslog message generated by the device.

The entries appear to all be in the one minute before midnight, so possibly a bug?

Cheers

Hi,

I noticed that the new feature of a grace period for DCIs sets instances to disabled when they are no longer found.
However, it does not appear to re-activate them when they re-appear, which means unless one manually goes through the nodes to locate such DCIs to re-activate them, they will simply be deleted after the grace period.

Not sure if that is the intended behaviour?

Cheers

Hi,

Same issue here.
We don't use a lot of Ping checks and the few we have are non-critical, but they do show the same problem as yours.

Cheers

Hi,

Our server is on the public internet. Of course there is a firewall in front of it (i.e. it is in a DMZ), but the port to allow agent tunnels in is open.
If you know the IPs that tunnels come from, you can obviously lock that down on the firewall.
Similar to other monitoring or RMM solutions that use agents, e.g. PRTG, Solarwinds, Kaseya, Labtech, N-Able, ...

Other options I can think of:
If you want to ensure there are no ports open to the internet, you may be able to use a VPN from the NetXMS Server to each site or, if all you care about are events, a separate NetXMS Server at each site for that particular network, forwarding events to the main server (you'd still need to allow for that communication though) which will handle alerting.
Assuming that your sites don't all have unique requirements, you'd also need to keep the config between servers in sync, probably via some scripting.

Not sure what others are doing, there may be other options.

Cheers

Hi,

Without providing a full guide (the Admin Guide, Wiki and Forum should be able to help with the details), you could use a PowerShell script to generate an ExternalList. Something like this:
$wmiServiceNames = (Get-WmiObject Win32_Service -Filter "StartMode='Auto'").Name
foreach ($wmiServiceName in $wmiServiceNames) {
    $serviceDisplayName = (Get-Service $wmiServiceName).DisplayName
    $wmiServiceName + "," + $serviceDisplayName
}
Note, the above will provide a list of Service Names and Service Display Names, separated by commas.
That way you can use instance discovery to split the two, then use DCI the parameter
System.ServiceState{instance}
while being able to use the more readable {instance-name} for the DCI description.

Going a step further, you can create an event, action and event processing rule to automatically attempt to restart a service should it not be running.

Cheers

Hi,

You can create an ExternalParameter (or ExternalParametersProvider) which can run a handful of commands or call a PowerShell script, which returns the data you are after. If you are after one very specific Scheduled Task, that may be enough. You can also implement an ExternalList, which can call PowerShell to generate a list of Scheduled Tasks you are interested in and which exist on that node, then use this with Instance Discovery to create DCIs for you (using the agent parameter created via ExternalParameter or ExternalParametersProvider).

For semi-native PowerShell, you can create an ExternalParameter that simply calls powershell -c "$1" (you can tweak that with -noninteractive, -noprofile, etc.), with $1 being the parameter passed from the DCI. We're using the above not as an ExternalParameter, but an Action, so we can run a single, arbitrary PowerShell command on Windows nodes at any time via NetXMS (and lock this object tool down to the users that we trust with that access).
This method is not suitable for running multi-line commands or scripts of course.

Cheers