Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Victor Kirhenshtein

#61
Hi,

definitely, should be available soon.

Best regards,
Victor
#62
One possibility that I see is out of order execution of hook scripts which is theoretically possible. Server schedules execution of hook script in background thread pool, passing copy of alarm in its current state to the script. It is possible that due to database problems thread pool was full with tasks waiting on database, so earlier script execution task was waiting on free thread, next task was scheduled in the meantime, and then both were started in parallel, possibly in wrong order.
I will think about it, but probably we have to serialize executions of alarm state change hooks.

Best regards,
Victor
#63
According to log server got two timeouts - at 09:57:18 and 09:58:23 (status=2 means timeout). Next ping was successful again. Do you think there was a possibility of network issues at that time that could cause loss of ICMP packets? Also, if you change poll count to 3 or 4, will it fix the situation?

Best regards,
Victor
#64
General Support / Re: openssl
June 13, 2023, 06:37:19 PM
Hi,

I suppose you mean Windows version, because on Linux platforms NetXMS uses whatever OpenSSL version is installed as system package. Current version shipped with OpenSSL 3.0.7, we will switch to 3.0.9 in next release (should be in June).

Best regards,
Victor
#65
You should be able to do that with object tools. Create tool that will call a script, define necessary input fields, and when user will run the tool he will be asked for additional input. This input will be available in a script.
You can even create context dashboard and add those tools as action buttons.

Best regards,
Victor
#66
This is normal behavior - for some reasons PDH reports temporary objects that cannot actually be accessed. You can safely ignore those errors.

Best regards,
Victor
#67
General Support / Re: Ubiquity Topology
June 13, 2023, 06:31:08 PM
Yes, we have that "sponsor" button on github :)

Best regards,
Victor
#68
Sorry for delay, just get back to issues that piled up.
Looks like switch returns FDB information, so problem is within server. Can you set debug level 6 for tag "topology.fdb", run topology poll on switch node, and show me server log?

Best regards,
Victor
#69
General Support / Re: Ubiquity Topology
May 29, 2023, 03:30:58 PM
Currently it is not possible to inject topology information from hook script, but I see how that could be beneficial. Another option which I consider for some time already is to extend driver concept beyond SNMP, to allow SSH commands and possibly other protocols. This may help with reading VLAN information on Mikrotik switches for example, and probably lot of other cases with devices that have marginal SNMP support.
Added note to myself to think about it for one of next releases :)

Best regards,
Victor
#70
Connection information for end nodes that does not support LLDP or CDP is obtained from FDB, so root cause is FDB not being retrieved from the switch.
What driver is selected for the switch? Also, what is walk output for .1.3.6.1.2.1.17.4.3.1?

Best regards,
Victor
#71
I cannot reproduce this - in my test alarm list on dashboard shows alarms correctly according to checked severity in element configuration. Could you please provide step by step instruction on how to reproduce this issue?

Best regards,
Victor
#72
General Support / Re: Alarms based on Topology
May 29, 2023, 02:46:35 PM
Normally it should happen automatically for events SYS_NODE_DOWN if topology is known to the server. If server is able to determine route from itself to unreachable node, it will check all intermediate nodes, and generate SYS_NODE_DOWN only for router closest to the server, and SYS_NODE_UNREACHABLE for nodes down the line.
For more complex logic you can use script filters - all kind of topology information is available in scripts, so you can filter events based on peer nodes, routing information, etc.

Best regards,
Victor
#73
Copy constructor is not a problem in executing AlarmStateChange hook - script is executed from Alarm::executeHookScript, which in turn only called after m_state for source alarm was changed.
I currently cannot see how hook could have been called with state 3 for new alarm. In described sequence of events, when did you restart the server?

Best regards,
Victor
#74
Can you try to set debug level to 7 for tag poll.icmp, and when problem repeats, send me extract from the server log filtered by object name?

Best regards,
Victor
#75
Can you please describe use case for that? Usually NXSL scripts are non-interactive, the only place where user normally invokes NXSL script is script based object tool - but there you can use input fields.

Best regards,
Victor