NetXMS Support Forum

Из серверного скрипта (NXSL) этого сделать нельзя. Можно через nxshell, он предоставляет доступ к полному клиентскому API. Описание nxshell: https://wiki.netxms.org/wiki/Using_nxshell_to_automate_bulk_operations.

Can you please set debug level to at least 2, reset system again, and check agent's log for message like

LogWatch: reading old events between ... and ...

and possibly also like this:

LogWatch: EvtQuery failed (...)

and post those lines and timestamp of "unexpected shutdown" event.

Best regards,
Victor

If you build server from sources, you can try replace files src/server/include/nms_dcoll.h and src/server/core/nxsl_classes.cpp with attached and recompile the server. Other than that, there are no workarounds.

Best regards,
Victor

Yes, comments attribute was missing in DCI class. I've added it, will be available in 2.0-M5.

Best regards,
Victor

Just fixed this. If quick fix is needed, just replace file src/server/core/beacon.cpp with attached one and recompile server.

Best regards,
Victor

Only topology events are correlated - data collection events can be originated elsewhere (from script DCI for example) and may or may not be affected by network connectivity.

Best regards,
Victor

Hi,

yes, there was a bug in WINPERF subagent. I just fixed it. Fix will be included in 2.0-M5. Also, attached is winperf.nsm for 2.0-M4 x64 with a fix.

Best regards,
Victor

Hi,

I've fixed VPN connector issue. 2.0-M5 will contain this fix.

Best regards,
Victor

Hi,

most likely near end of June.

Best regards,
Victor

As it turns out event ID and root cause event ID are not shown in event log. I've fixed it for next release, but currently you can check server log for message like

CorrelateEvent: event SYS_NODE_DOWN id ...

followed by

CorrelateEvent: finished, rootId=...

Number after rootId= will be ID of root cause event. You can find it either in server log or select directly from database by running SQL

SELECT * FROM event_log WHERE event_id=<id>

Best regards,
Victor

Hi,

try to upgrade to 2.0-M4 which is just released.

Best regards,
Victor

So that's the problem - server found another event that is considered root cause and so mark this event as correlated. Correlated events do not pass through event processing policy. You can see root cause event ID in event log and check what is root cause event (and if it was correct).

Best regards,
Victor

Hi,

yes, connection information for last known port will be kept until either node reappears on different port or another node will be detected on same switch port.

Best regards,
Victor

Hi,

should be fixed in 2.0-M4.

Best regards,
Victor

Hi!

Yes, it is part of topology poll. It's actually a Cisco's non-standard feature to provide FDBs per VLAN - you should pass community string suffixed by @ character and VLAN ID to get FDB for that VLAN (or set context to "vlan-<id>" for SNMP v3) (Cisco example for reading FDB: http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/44800-mactoport44800.html). I'm not completely sure what Cisco devices requires this to get full FDB and what do not. It seems that we'll have to create separate driver for 6500 series - can you figure out what is correct way for reading full FDB from them?

Best regards,
Victor