NetXMS Support Forum

I just set this up on an IIS server here and tested Active Requests and Requests / Sec.
Both are working for me. Tested using integer as well as floating point and there was no need for sample count.

We're still running 2.05 server and agents though.

Sorry, wish I could be of more help.

I hardly use bar graphs, but I have seen the same thing happen.
Sometimes resizing the window "fixes" it until the next occurrence.
In my case, it appears to be a "either it happens when you open the chart or it doesn't happen at all" thing.

For systems with a certain status the following should work:

if ( $node->status == 4 ) return true;
return false;

See https://wiki.netxms.org/wiki/NXSL:NetObj for possible status values (the above is for "Critical").
I couldn't actually see any way to get the actual Maintenance status, yet for all I recall NXSL does allow you to set/unset maintenance status on a node, so I would expect there to be a way to query the current status. However, the above $node->status does not give you that, e.g. it returned "Normal" on a node that was in Normal state when I put it into maintenance mode.

Also keep in mind that this won't exactly give you a live view either. These rules are only applied when a configuration poll runs against a system, so there could be quite a delay.

For that, maybe a Dashboard with a Status Map would be more suitable. You can select which severity you want to see. Grouping is available per container, but if you have lots of Critical systems. I am not sure about the refresh here - I can't configure it. But it seems to "flicker" all the time, so that seems more live?
That map doesn't have an option for "Maintenance" though.

Not sure if this applies to this particular counter, but as mentioned  on a previous post, I found that with quite a few performance counters (even some that do not say they are "averages"), I still have to configure the "Sample count" in the DCI to 2 to make them return useful data. Not sure if that will help in your case.

As you suggested, I'd create Containers and use auto-apply rules/scripts on those.
I've done similar things to group some systems at our end, not for maintenance though.

I found that with quite a few performance counters (even some that do not say they are "averages"), I still have to configure the "Sample count" in the DCI to 2 to make them return useful data.
Maybe it's the same in your case?

Once you open any graph, you can right-click in it, select Properties and under Data Sources add any data source to it.

You can also save the graph for later use (if you want to organise them, give them names like "A -> B -> C". This will create a graph "C" underneath a "folder structure" A\B in the "Graphs" tab on the left (or View -> Predefined Graphs).
Unfortunately this kind of structuring comes with a drawback on permissions. At least I haven't managed to set permissions on such a "folder". I have to set them per graph - and if I don't set any, the only user who will be able to see those saved graphs is myself. Of course that might not be an issue for you.

We're running 2.0.5.

The templates are configured to be removed if auto-bind no longer applies, which is fine.
The issue is just that if the system is unreachable and NetXMS cannot detect if the template should still apply, it seems to remove it.

I'll see if I can run some more tests to confirm if this happens all the time or if something else is required to trigger this.
Maybe a race condition with an active Configuration Poll just as the system goes down.

The most recent one I ran into was a Cisco which was offline for a weekend (remote, non-critical office, closed over weekend) and basically all data was wiped and started fresh on Monday after it was rebooted.

Hi,

I have encountered this several times now:
- A system has all its DCIs applied via templates. The templates are configured to remove the DCIs if the node no longer matches a certain condition
- The device becomes unreachable for an extended period of time (as in hours or even days). Reasons can be internet connection problems, dead routers, the NetXMS agent not running for whatever reason or a server being shutdown "temporarily".
- Eventually the NetXMS server will remove the templates from the node.

I originally assumed that the server would not remove the templates from an unreachable node for that reason: it is unreachable. It therefore cannot determine if the condition that lead to the template being applied is still valid or not. If I try to run a manual Configuration Poll in such a scenario, it actually tells me it is not going to poll, because the node is unreachable - and then it goes ahead and wipes the template anyway. (That one just happened to me today)

I am not sure how I can configure the templates so they are not neither removed nor assigned when a node is actually unreachable?

Any ideas? Or is this a misconfiguration or bug of sorts?

Thanks

I decided to re-enable the template in 2.0.5 and unfortunately the issue persists.
Once I enable the template, the NetXMS server crashes within a few hours.
When I disable the template again, NetXMS runs stable and without issues.

This is driving me nuts... I'm not exactly a code/debug whiz, so what do I have to do to get some debugging data that would help with fixing this?

Have you tested polling the node with the setting (under "Polling" on the node) "Use ifXTable for interface polling" either on "Enable" or "Disable"?
I don't have a access to a Cisco 3750, so I can't test this directly.

I am starting to wonder if this is related to this one: https://www.netxms.org/forum/general-support/clearing-threshold-column-re-alerting/ ?

How can I, if necessary manually in the database, ensure that NetXMS doesn't think that it may have alerted on this already?

The issue is still present on my system.
First row is in Predictive Failure state for Smart Status and Status. No alert in the system that I can see. Any changes to alerting only affect the last three rows, not the first one.

Thanks for pointing this out. I used the global setting, as all DCIs were already configured to use the "Default", which appears to be 0, i.e. never repeat.
Does this also apply to alarms triggered by table thresholds, which do not seem to have a configurable repeat event option?

Something like this should work under Windows if you run it inside PowerShell and in the actual directory holding the MIBs.
Otherwise you'll have to pass the full path  to Get-ChildItem instead of *.txt.

ForEach ($file in Get-ChildItem *.txt ) { Get-Content $file |Select-String -Pattern "^RFC-1215 DEFINITIONS" }

The asmib.txt imports fine for me.
Based on the MIB file itself, TRAP-TYPE is being imported from RFC-1215.
It's possible that this one is somehow missing on your system or you might have the same MIB (maybe different file names) in your folder twice, with one of them not actually having this object defined properly - and the "wrong one" is being used. That can happen if you copy a whole range of MIBs from a vendor which happen to also include the basic ones (Cisco does that in their zipped MIB collections).

I tend to have that kind of issue after every NetXMS upgrade with the SW-MIB.mib (as I have a different MIB file from Brocade for SW-MIB, which is referenced by other Brocade MIBs).

Does
grep ^RFC-1215\ DEFINITIONS /usr/share/netxms/mibs/*.txt
return more than one result (assuming /usr/share/netxms/mibs/ is the directory holding your mibs)?