NetXMS Support Forum

You should be able to use internal parameters ICMP.PacketLoss and ICMP.ResponseTime.Last. Usually you'll need variants without instance - they will return data for primary IP address. Variants with instance should be used when you have configured additional ping targets on a node and want to get information for those targets.

Best regards,
Victor

I think that it could be good idea to ignore notPresent interfaces by default on the server level. We will discuss that internally and likely add as configurable option. But for now hook script is a way to go.

Best regards,
Victor

Hi all!

We just published new patch release of version 4.1 - 4.1.404. Changes since previous patch release:

- Fixed full screen dashboard display on startup in desktop client
- Improved database consistency checks for business services
- Added Oracle driver option to disable OCI statement caching
- Fixed slow appearance of discovered nodes
- Fixed bugs in database schema upgrade from pre-4.0 versions
- Fixed bug in map options property page
- Fixed incorrect string encoding during SNMP SET operation
- Fixed SQLite upgrade issues
- Fixed issues:
        NX-755 (Network discovery may not stop immediately)

Best regards,
Victor

We plan it for this week.

Best regards,
Victor

Just fixed it, next patch release will contain the fix.

Best regards,
Victor

If you are interested in sponsoring development of new features, please contact me via PM and we can discuss work scope and price.

Best regards,
Victor

Currently only via API - but it should be relatively easy nxshell script or Java app.

Best regards,
Victor

When interface is down, we have two contradicting requirements: one is to show what was connected to that interface before it went down, and other is to show actual connectivity. First requires to keep showing link between disconnected interfaces, second requires to delete that link immediately after interface goes down. As NetXMS server has no way of knowing if disconnect is permanent or temporary, and there are seems to be more requests to provide access to last known connection information, NetXMS server keeps that connection until it will know that topology was changed (for example, one of previously connected interfaces will go up and LLDP will report different peer).
One possible solution could be configurable topology expiration time - i.e. if interface is down for N days, remove any known topology information from it.
Currently as a workaround you can delete interface that is disconnected - configuration poll will find it and re-create, but peer information will be erased.

Best regards,
Victor

Collector is there, but we didn't get to actually processing flow data. I still want to add this functionality, it is question of available resources and priorities.

Best regards,
Victor

From what you show it looks like mail relay successfully received mail from netxmsd, so if you didn;t receive it it was either not sent by relay, or rejected/dropped by receiving server. Do you have any logs from relay regarding forwarding of this mail?

Best regards,
Victor

Hi,

do you mean database lock in the DB so server complains that database is locked by another instance? If yes, you should list peer IP address in netxmsd.conf on cluster nodes. For example, if you have cluster nodes with addresses 10.0.0.1 and 10.0.0.2 (with whatever VIP moving between them), on node 10.0.0.1 you should add

PeerNode = 10.0.0.2

to netxmsd.conf and on node 10.0.0.2 add

PeerNode = 10.0.0.1

That way server will read the lock, check if server is running on peer node (by attempting to connect to agent and check running processes and by connecting to port 4701), and remove stalled lock if netxmsd is not running on peer node.

Best regards,
Victor

Hi,

it's a bug, just fixed it. Fix will be included into next patch release.

Best regards,
Victor

I can confirm that changing server is not implemented yet in new web UI.

Best regards,
Victor

Hi!

This is queue for processing discovered addresses. If you have discovery filters some (or most) of them could be filtered out and then re-discovered again and again. This can create permanently non-empty discovery queue, but this is fine.

Best regards,
Victor

Dashboards created in old versions (likely before 4.x) may render as empty in GUI client version 4.1.377. We have fixed it in version 4.1.380, so if you experienced that issue, upgrade should have it fixed. No changes to dashboards are required.

Best regards,
Victor