NetXMS Support Forum

OK, I don't know if that maybe helps, but I can definitely say that in version 2.0-M4 it was working.

Hi Victor,

I just figured out that the netxms server is ignoring the setting about how many polls are needed for the status change. In my case it's set to 5 polls. as well in the device settings and also as the standard setting globally. (see screenshot).

Is there somekind of server setting I need to set?

Greets,
Andreas

Hello again,

well i let it run without node up notifications over the weekend. I had 3 node_down's without that these nodes were really down (a let it scan 5 polls before status change). Then in the event log I have still multiple node_up's from nodes that never were down.

Any suggestion were to look first? As told, the proxy agents are one for each zone. These issues happen after the update to 2.0.1. Has been something changed about the event generation? At least according to the information in this thread, it has nothing to do with the event processing policy.

Greets,
Andreas

[email protected]? BOFH?!?!? Noooo wayyyyyyy! 

You mean the legendary "Bastard Operator From Hell"? That's funny!

Well, I consider doing that in the next few days!

Thank you very much, Alex.

Hi Alex,

I'd be interested to do it in my (not plenty of) spare time, but unfortunately I'm not part of the FreeBSD community or I don't know how to become a ports tree maintener there. :/

Greets,
Andreas

Hi Victor,

I have my agents set as proxies per zone. For two reasons:

1. Keeping a clean Zone and network structure.
2. Saving time, because I don't need to set the proxy node in each node individually.

But I think you know the benefits of "zoning" better than me, because you are the developer. Excellent and good understandable coding style by the way. It's not a compliment, just my honest opinion and a true fact. I was a developer too before starting to work in the company I'm now.

I wish I had some time too to work with C++ and Java code occasionally, but I have enough to do with administrating, maintening and scripting Unix and Linux boxes here. But somehow... It's really fun and learning a lot of new things every week.

Greets from Germany,
Andreas

Hello Alex,

do you know if the new stable will be available in the FreeBSD ports tree too?

Greets from Germany,
Andreas

OK, I think I can leave with this first. Just took out the server actions when node is UP again. Maybe it's better to be only informed when node is down. The reason I used to notify node up, is just to know if a colleage has managed to solve the problem (or if there is a temporary uplink interruption) while not in the office.

But anyway, it would be good if somebody who knows about that, would inform us here. Just for the sake of curiosity.

Hello and thanks for your help again tomaskir.

Well, you are right, there are "node up" events in the event log (now I start understanding how things really work). The processing for SYS_NODE_UP events is also right, but... before I upgraded from 2.0-RC1 to 2.0.1, when a proxy agent was offline, the nodes which were polled from this agent were just marked as "status unknown", till the proxy agent came up again. But even then, they didn't trigger the node up event. So it was fine, because i was only notified about the proxy node going offline and not about all the polled nodes behind it.

Since the update, the polled nodes are not marked as "status unknown" anymore and trigger node_up immediately after the proxy node came online again.

In the mean time, I didn't change anything in the EPPs since the updates (and even before them). It was running fine.

Is there any way to suppress triggering sys_node_up (or even sys_node_down) when the proxy agent is failing? Or is there something I need to further check in the EPP configuration? I mean... It's only the sys_node_down and sys_node_up events I want to get notified about.

Hello again,

I have a problem (and I think it may be a bug):

Everytime I restart a specific nxagent proxy node (version 2.0.1 running on FreeBSD 10.2) the NetXMS server is sending "Node up" notifications for each node this agent is monitoring, although they had never a node down status (it is set to 5 polls for status change, this means I would have about 5 minutes time for restarting).

Also important, there are also no "node up" events which apply to these SMS notifications in the Alarm Log. Could it be, that there is somekind of message queue for SMS notifications that has stuck and needs to be cleared? Rebooting nxagentd and netXMS server didn't solve the problem.

Maybe someone has an idea.

Here is the nxagentd.conf of the proxy node:


MasterServers = XXX.XXX.XXX.XXX

MaxSessions = 1024
StartupDelay = 60

EnableProxy = yes
EnableSNMPProxy = yes

SubAgent = /usr/local/lib/libnsm_ping.so
SubAgent = /usr/local/lib/libnsm_ecs.so
SubAgent = /usr/local/lib/libnsm_freebsd.so
SubAgent = /usr/local/lib/libnsm_logwatch.so
SubAgent = /usr/local/lib/libnsm_filemgr.so

*PING
Timeout = 1000
PacketRate = 12
Target = XXX.XXX.XXX.XXX:some_node_name
...


Also note, I've set StartupDelay to 60 seconds, but this didn't help.

Greetings from Germany,
Andreas

Hello gmonk63,

are you polling all your nodes directly from the NetXMS Server or are you also using proxy agents? I advise you to use nodes proxy agents according to the subnets you are monitoring. There is a parameter in nxagentd.conf called MaxSessions. The default value is:

MaxSessions = 32

The highest value of max. sessions can be set till 1024. So try to set:

MaxSessions = 1024

But after that. As I already wrote. It's better to set up nodes as proxy agents.

Greets,
Andreas

Aaaaah, ok. Thank you very much tomaskir.

Have to admit, I really start loving NetXMS.

OK, sorry it was my mistake. It seems there is no need to write a policy script for it.

I think I only had alarms from maintenance nodes (which I shut down), because of a polling delay.

Thread can be considered as closed.

Hello and thank you for this awesome monitoring tool.

I have a question regarding the new maintenance mode.

Is there any posibility to add a script in the "event processing policy", that is doing the following?

- If node is in maintenance, then "return true", so that the action to be taken is "stop event processing"
- else return false, to proceed to the next policies, till rule match.

Greetings from Germany,
Andreas