NetXMS Support Forum

Since upgrading to 3.0 I notice that network map link bend points seem to be a bit wonky.

If you insert or move a bend point the link label no longer closely follows the path of the link.  Instead it stays close to the original 'direct mode' path of the link before the bend point was inserted.  In 2.x it used to stay attached to the path.

Dragging bend points or adding removing sometimes seems to snap the link itself back to being direct mode although the bend point circles will stay in place.  This then flickers back and forth sometimes.

I found bend points useful to map diverse VPN paths between two locations and separate them enough to read the labels clearly.

I assume its a client console issue?  Although the two screenshots show two maps generated in the java console and web console so issue is common to both.

NXCM: 3.0.224
Server: 3.0.2292

Edit: created NX-1691

Hi, I could only try status polls as configuration polls were unavailable as the node was classed as unreachable.  Any other nodes polled would only say that the proxy was unreachable.

It is directly reachable through an L2TP VPN.  Tried with or without dst-nat on the client router (currently no nat from server to agent as non-overlapping IP space).

Tried both creating the node in the zone and setting as node proxy or moving into the zone from root zone. 

So far since adding ZoneUIN to agent config its been holding steady for a few hours now.  The only mention in the docs regarding that attribute I can find is with regard to syslog source mapping?

I think I've got this working now, just testing to be sure.

Looks like I have to specify an undocumented ZoneUIN value in the agent? 

https://github.com/netxms/netxms/blob/85ad72844ebe7361d714efac575e8f69f15517cb/src/agent/core/nxagentd.cpp#L337

At least after setting that and restarting and then moving the agent into the zone it now seems to have kept the connection working.

Looking at the query in postgres we have a large syslog table (>20GB), and it seems the main issue is the scan back through all timestamps by default when right clicking on a zone or subnet and choosing syslog:



netxms=# explain SELECT msg_timestamp,source_object_id,zone_uin,facility,severity,hostname,msg_tag,msg_text FROM syslog WHERE msg_id<=399610423 AND (source_object_id IN (45902, 45930, 45940, 45948, 45953, 45967, 46061, 46106, 46107, 46109)) ORDER BY msg_timestamp DESC LIMIT 1000;
                                                                    QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------
Limit  (cost=0.57..15744.67 rows=1000 width=160)
   ->  Index Scan Backward using idx_syslog_msg_timestamp on syslog  (cost=0.57..18440640.31 rows=1171273 width=160)
         Filter: ((msg_id <= 399610423) AND (source_object_id = ANY ('{45902,45930,45940,45948,45953,45967,46061,46106,46107,46109}'::integer[])))
(3 rows)



If I manually build a search in the syslog window its a much shorter scan (and a lightly different query constructed):


netxms=# explain SELECT msg_timestamp,source_object_id,zone_uin,facility,severity,hostname,msg_tag,msg_text FROM syslog WHERE msg_id<=399611781 AND ((source_object_id = 45948) OR (source_object_id = 45940) OR (source_object_id = 45930) OR (source_object_id = 46109) OR (source_object_id = 46107) OR (source_object_id = 46106)) AND (msg_timestamp BETWEEN 1569333600 AND 1569419999) ORDER BY msg_timestamp DESC LIMIT 1000;
                                                                                                           QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit  (cost=0.57..1418.03 rows=48 width=160)
   ->  Index Scan Backward using idx_syslog_msg_timestamp on syslog  (cost=0.57..1418.03 rows=48 width=160)
         Index Cond: ((msg_timestamp >= 1569333600) AND (msg_timestamp <= 1569419999))
         Filter: ((msg_id <= 399611781) AND ((source_object_id = 45948) OR (source_object_id = 45940) OR (source_object_id = 45930) OR (source_object_id = 46109) OR (source_object_id = 46107) OR (source_object_id = 46106)))
(4 rows)




Could there be a preference to set a default date range for syslog/event log searches (so that any right click of a container/subnet/zone defaults to say 1 day or 1 week).  Or could you not immediately execute the search when right clicking and instead take you to the populated syslog search window to allow you to enter a time range?

Or is there some index-fu that could speed this up?

Not sure what the most usable approach is here.

Cheers.

If I select a single node and right click to get to syslog it loads really quickly.  If I right click on a container or subnet and view syslog it never seems to complete.  I haven't looked at the SQL but I assume there are missing indexes for container/subnet and its doing a full table scan?

I came across this old thread talking about adding the indexes to source: https://www.netxms.org/forum/feature-requests/syslog-table-index/

Is it feasible to add one to containers and/or subnets too?

Cheers.

Hi have upgraded to 3.0.2292 and am trying to create a node in a zone and set it as the zone proxy and it doesn't seem to work if the proxy is in the zone.

eg: I have zone 1 and 2.  Netxms server is in zone 1.  If I create the proxy node in zone 1 and set it as the zone proxy for zone 2 (the old way as I understand it) then I can successfully poll all zone 2 nodes and things like the internal topology show the connection going via the proxy.

If I create the node in zone 2 as a zone proxy (or move the node into the zone 2) then the proxy itself can't be reached in a status poll and the whole zone goes unreachable.

My understanding is that the new way is to create the proxy for the zone inside that actual zone?  Doesn't seem to be working for me.

Have tried setting the zone 2 proxy to be its own proxy for polling/services and also tried the netxms server proxy.  Only thing that works is to put the proxy in the root zone 1 as we used to.

Is this something Grafana would be useful for?  Keep the NetXMS access for ops internal and then publish zone specific dashboards to Grafana for customers? 

I suppose in the future the WebAPI might allow someone to write a customer focused client interface?

Has anyone done something like that now?

In the console, when deploying agent packages with the package manager I'm getting an error status "failed" "Agent's version doesn't match package version after upgrade".

The 3.0 agents seem to be installed on the clients and look to be working (polls work and send back 3.0 agent version) but summary tables show 3.0-2258-gc5516133f2 agent verison, would that be cause of error if 'package version' is something like 3.0-2258 only?

Not to hijack, but I like the idea of a connection history feature a lot, is there an issue number I can vote on at all?

Just to answer my own question, as usual the problem was PEBKAC.

I had opened the syslog monitor next to the parser window during testing and conflated the severity column in the syslog window with the severity tag in the parser window. 

A debug log reveled the match was missing on the severity and I realised the parser severity is a bit mask and not representative of the syslog window.  So a semantic difference with the same name.

Correcting that has the rules working now.

Cheers.

Hi all the apt-key process seems to have fixed it on the jessie machines I have, but installing the netxms relase package on stretch doesn't seem to help.

apt update
Ign:1 http://ftp.iinet.net.au/debian/debian stretch InRelease
Hit:2 http://ftp.iinet.net.au/debian/debian stretch-updates InRelease
Hit:3 http://ftp.iinet.net.au/debian/debian stretch Release
Hit:4 http://security.debian.org/debian-security stretch/updates InRelease
Ign:5 http://packages.netxms.org/debian stretch InRelease
Get:7 http://packages.netxms.org/debian stretch Release [2,671 B]
Get:8 http://packages.netxms.org/debian stretch Release.gpg [819 B]
Ign:8 http://packages.netxms.org/debian stretch Release.gpg
Reading package lists... Done
N: Ignoring file 'netxms.list.old' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension
W: GPG error: http://packages.netxms.org/debian stretch Release: The following signatures were invalid: EXPKEYSIG 179C0A80CDFADDB1 NetXMS Automatic Signing Key <[email protected]>
E: The repository 'http://packages.netxms.org/debian stretch Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.


Hi, when doing an apt-get update this morning on some debian wheezy machines, I'm getting a key expired error for netxms repo?

W: GPG error: http://packages.netxms.org wheezy Release: The following signatures were invalid: KEYEXPIRED 1522252127 KEYEXPIRED 1522252127 KEYEXPIRED 1522252127

Are those versions no longer maintained now?

Ha! you're right I did skim the post, apologies for not really helping!

I suppose the challenge is that all different types of equipment/vendor might have spikes to different values depending on how their SNMP implementation works in certain situations.  Differentiating a real spike vs an artifact could be hard to do.  I guess finding a generic one-size-fits all solution is the problem (no hardcoded values).

Thinking out loud, is there any way in NXSL to retrieve the node's current interface link speed and use that to dynamically set the max interface value in the transformation script.  Anything over and above that (maybe by a certain factor) is transformed as per the first link?

Guess it depends if there's any way to map a given SNMP DCI (maybe interface name) back to the relevant Node Interface object in order to retrieve the link speed value?

I've used the scripts in this blog post when searching for DCI spike removal.
https://lasiszm.wordpress.com/2017/10/22/netxms-template-for-monitoring-mikrotik-interfaces/

Looks like this question has been asked in the forums too:
https://www.netxms.org/forum/feature-requests/dci-spike-removal/

Don't worry Dani, PEBKAC .

I was not putting the compiled netxms.mib file in the right debian directory under /var/lib/netxms.  Left it in the /usr/share/netxms.

It's all working fine with the latest MIB you had edited.

Thanks again.