NetXMS Support Forum

Hi Victor,

If I use FindInterfaceByName, I would have to loop through all interfaces on the node for each individual interface I want to instance (as per your code). If I have a switch stack of 96 ports or more, that would cost some resources every time an instance discovery is running. I was hoping that if I can use FindObject instead and provide the $node as per documentation, i.e. FindObject($1,$node), that should not be a global search and avoid the loops?
Guess I'll wait for 2.0.5 and see if I can get it to work with that. Otherwise I'll be looping.

Cheers

Sorry, but that does not work for me either.
If I use Net.InterfaceNames as list for InstanceDiscovery, I receive an error that I am not using a whole number in GetInterfaceObject(). That's expected, as it requires the interface index, not the name.
If I use Net.InterfaceList instead, I get the same error and a whole number of DCIs with names like "1 127.0.0.1/8 24(2147483647) 000000000000 Loopback Pseudo-Interface 1" (that's just the {instance} part of it, which appears to mix index, IP addresses and MAC address).

If I use FindObject, for all I can tell I should be getting an interface object.
After going through some older forum posts I thought I'd test that as follows:
i = FindObject($1,$node);
trace (0,i->name);
trace (0,classof(i));

The logs then give me the interface name and "NetObj" in the logs.
That also explains why none of the interface attributes (short of the NetObj ones) were accessible - I got the wrong object type back. Based on the documentation I would have thought this should be "Interface"?

Looks like my issues are related to previously reported bugs regarding server crashes on deleting Instance DCIs and templates applying DCIs twice.
Have updated Bugtracker accordingly. Happy to help out in any way to resolve those.

Prior to finding that, I tried to just start fresh with the template by returning false on the auto-apply script. The result is that right now our NetXMS is pretty much unusable - it crashes within a minute of starting. In between it manages to delete some of the DCIs that is has in it's queue for deletion (turned on debug logging to level 9 to see the queries).
I'm running netxmsd in a while loop now to restart within 15 seconds of crashing. I'm not expecting to get any useful data out of this, but do hope it will eventually catch up with the deletions... :|
If it still has issues after a day, I'll probably have to dig into the database to work out what I need to remove and do it manually.

Personally I haven't done this yet, but I would try this:
- Create a PowerShell script that collects all the data you want/need. The script should either push all that information into a separate event log entry or mail it straight out (I would assume both of these would work with PRTG monitoring, too?)
- Create an Action in the agent's configuration file to run that PowerShell script
- Create a new event and configure event processing policies to trigger the action you just created when your newly created event is triggered
- Configure the CPU DCI to probably check every 5 seconds, set the threshold to trigger the event you created on three consecutive values over 80%

If your script just sends a mail directly, that'd be it.

If the script creates an event log entry, you'd also have to set up event log monitoring in NetXMS for your Windows system and create another event (in NetXMS) and action to be triggered (moving the email/SMS or whichever action you wish to trigger to the NetXMS server). See https://wiki.netxms.org/wiki/UM:Log_Monitoring

Thanks for the snippet.

Not sure how well this would work inside of an instance filter script.
Instance Discovery will loop through the list of all interfaces and return the names, one by one. It's inside that loop that the instance filter script runs (for all I understand).
I guess I could loop through all node interfaces for each interface on the node discovered by Instance Discovery, then compare names and on a match check the expectedState. Seems a bit inefficient though. If I could directly retrieve the correct interface object from within the instance filter script, it would be a fairly quick check.

From what I read about FindObject, that should have worked using the interface name provided by Instance Discovery.  But I could not use any of the object's properties afterwards. 
I might give it another go later today and provide the code I used. Maybe I've had some typo or logic error in there - wouldn't be the first time. 

Hi,

I am trying to filter out interfaces which are adminState down as well as expectedState down via instance filter scripting.
I'm using the Net.InterfaceNames Agent List to get a proper name for the DCI itself and am having issues retrieving those interface states in the filter script.
As $1 is only the interface name, I used the FindObject function hoping to get the interface object to then allow me to check for adminState and expectedState.
Unfortunately that didn't work out, so I tried GetInterfaceObject, but that requires an interface index - which I don't get with the Net.InterfaceNames list.
Switching to Net.InterfaceList didn't help me either.

Does anyone have a code snippet to point me in the right direction?

Thanks

Set the "Source Node" in your third screenshot to be your NetXMS server.
This will tell NetXMS to run your check on the NetXMS server, but the results will display on the DCI on your netxms.org node.

You will not see any available parameters on your netxms.org node, as it does not have an agent running on it.
However, you can right-click on your NetXMS server node and go to Tools -> Info -> Agent -> Supported parameters.
This will give you a list of what's available. You will have to manually enter/type the one you want to use into the DCI on your netxms.org node.

That will depend on the database you use, but usually the actual disk space usage won't decrease.
Even if something is deleted from the database, the database file size itself will generally remain the same.

For Postgres, a VACUUM FULL will do what you are looking for, but it will lock tables while processing them.
For MySQL you may have to dump the data and re-import. It's been a while.

Hi,

Not quite sure if these figures actually qualify as "lots".

I am trying to modify a template that (now) has 21 DCIs (8 of them are for instances) and is applied to around 300-400 systems at present.
The idea was to remove four DCIs (i.e. it used to have 25 DCIs) as they are not required.

Pretty much as soon as I close the template's DCI configuration, NetXMS doesn't react to anything (throws an error if I want to look at things) and after that the GUI says the server is not responding and disconnects. On the server itself I can see that NetXMS indeed simply crashed.
Restarting NetXMS leaves the template at now 21 DCIs, but the nodes assigned to the template still have all 25. Manually removing them works, but is very tedious.

For testing purposes I changed DebugLog to 6, then simply renamed one of the DCIs in the template (I also tested a different template with a similar number of nodes).

The result is that the logs are full of entries like these:
Node::onDataCollectionChange[..]: executing data collection sync
Node::onDataCollectionChange[..]: executing data collection sync for SNMP proxy [..]
ApplyTemplateThread: template=[..] updateType=0 target=[..] removeDci=false
Apply 21 items from template "[..]" to target "[..]"
Applying DCO "[..]" to target "[..]"
With the last one repeating once for each DCI.

After around 300 "executing data collection sync (for SNMP Proxy)" lines, logging simply stops and the NetXMS process is gone.
It looks like the updates for each node are not put into some queue/pool to be worked through, but the system tries to update everything at once and fails at doing so?

Switching to NetXMS 2.0.4 made no difference.

However, changing the SyncInterval in the Server Configuration from 60 to 300 made those Syncer Thread messages disappear completely.
Does that mean the Syncer Thread/system was simply too busy to get its work done within the default minute interval?

Looks like Dashboards completely ignore the "Invert Values" checkbox as well as the difference between Line and Area chart.
All I see is a non-inverted line chart, no matter what I configure. Running NetXMS 2.0.4 server and console.

Any Ideas?

Hi,

We keep seeing systems reporting "SNMP agent is not responding", even though SNMP polling is working fine.
It appears this happens when a Windows Server, that act as its own proxy for SNMP connectivity, reboots.

Any ideas?
Thanks

Ok, I think I narrowed down at least the SNMP one. For all I can tell so far, this seems to happen when a system reboots, i.e. a Windows Server with an agent which acts as its own proxy for SNMP connectivity (so we don't have to port forward SNMP).

That means this one is probably not related to the Syncer Thread issue, so I'll copy and paste this part of it into a new post with a more meaningful subject.

Hi,

I keep receiving alerts on 'Thread "Syncer thread" is not responding'. Happens every few minutes and a few seconds later it's back to "Thread "Syncer Thread" was returned to running state'.

Not quite sure if it's related or not, but we also see systems that alert on "SNMP agent is not responding" and even when SNMP is back up and it is happily collecting data, the alert just stays until it is manually resolved. That doesn't happen for all SNMP alerts, but enough to be noticeable. Basically every morning I go through the alerts and remove those false positives.

We also have some systems that sometimes report that the NetXMS agent is not responding. However the agent is in fact up and running.
Running a "Status Poll" returns an "UNKNOWN" state. The only thing that brings such systems back is a full configuration poll.
It feels like the system is "stuck" in some state which is not reset unless a full poll is run.

Not sure if these are related to the Syncer Thread problem or if they are all independent issues?
(Still running NetXMS 2.0.3)

Hi,

I am still having trouble upgrading my NetXMS installation on Ubuntu 14.04.4 LTS.
When I run apt-get update followed by upgrade, it tells me there is nothing to update and leaves NetXMS at version 2.0.3.

Content of /etc/apt/sources.list.d/netxms.list:
deb http://packages.netxms.org/ubuntu trusty main

What am I missing?

Thanks