NetXMS Support Forum

Hi,

this could indicate bottleneck when objects are being saved to database. Try to enable parallel writes by increasing values of parameters ThreadPool.Syncer.BaseSize and ThreadPool.Syncer.MaxSize (I would recommend starting with 3 or 4 and see if there will be any difference). You may also increase value of SyncInterval to reduce number of writes. It also probably worth checking database performance.

Best regards,
Victor

Hi,

you can use script like this:

for(d : FindAllDCIs($node, null, "Signal - * Transceiver Receive Power Sensor"))
{
   value = GetDCIValue($node, d->id);
   if (vmin == null or vmin > value)
      vmin = value;
   if (vmax == null or vmax < value)
      vmax = value;
}
// Here vmin and vmax variables contains min and max values for matching DCIs


Best regards,
Victor

Hello,

yes, it's possible. I can take a look tomorrow at your server. Will send you PM with contact details.

Best regards,
Victor

Hi all!

We just published minor patch release for version 3.8. Only server and agent on FreeBSD 13 are affected. Changes since previous patch release:

- Fixed potential data loss in InfluxDB driver
- Fixed invalid memory access in NXSL VM when using expression variables
- Fixed interface counters access by agent on FreeBSD 13
- Fixed bug in CAS server access
- Fixed bug in report definition processing
- Fixed server deadlock during proxy load rebalancing
- Read system description before interface list during configuration poll
- Separate debug tag for SMTP sender

Best regards,
Victor

Hi,

you can create script DCI that will collect all necessary information into table. For example, create script in script library:

table = new Table();
table->addColumn("Node", DCI::STRING, "Node", true);
table->addColumn("Interface", DCI::STRING, "Interface", true);
table->addColumn("Speed", DCI::INT32, "Speed");

for(n : GetAllNodes())
{
   if (!n->isSNMP)
      continue;
   for(i : n->interfaces)
   {
    row = table->addRow();
    table->set(row, 0, n->name);
    table->set(row, 1, i->name);
    table->set(row, 2, i->speed);
   }
}

return table;


Then create table DCI on any node (I usually use node representing NetXMS server itself) with origin "Script". and set script name as parameter name. Value of this table DCI will contain list of all interfaces on all SNMP capable nodes with their speeds. By changing script you can add more columns and change conditions for inclusion as needed.

Best regards,
Victor

Hi,

I just fixed it. Fix will be included into next release.

Best regards,
Victor

Most likely you are trying to delete event itself, which is not possible, because it is system event. I was talking about processing rule (go to Configuration -> Event Processing policy, and look for SYS_TUNNEL_SETUP_ERROR in rule conditions - there will be rule that generates alarm from that event).

Best regards,
Victor

Then it looks like some agents or even unrelated to NetXMS application attempts to connect to port 4703. Most likely can safely ignore this. To avoid spamming disable or delete EPP rule that process SYS_TUNNEL_SETUP_ERROR event. Alternatively, you can block access to port 4703 on firewall.

Best regards,
Victor

Are you actually using agent tunnels? Usually this error indicates problem with server certificate or one of trusted CA certificates.

Best regards,
Victor

Мне хочется его доделать, просто руки не дошли пока. Постараюсь найти время в ближайшую неделю.

Quote from: sds on June 02, 2021, 09:23:53 AM
Только потом не получается удалить нарисованную связь. Приходится удалять узел с линком с карты, а потом добавлять его назад

Можно выделить сам линк на карте, и правой кнопкой мыши на нем вызвать меню, там будет пункт "remove". Главное попасть в линк чтобы именно он выделился.

Еще если выделено два объекта на карте, томожно нажать на клавиатуре CTRL + L вместо нажатия иконки вверху.

Quote from: sds on June 02, 2021, 09:11:42 AM
After upgrading to version 3.8.2, the server for some nodes began to issue the error "Error setting up agent tunnel from ... (Cannot configure TLS context)". It is issued for client computers with agents of different versions.
How can this be fixed?

You should check server log for more details (turn on debug level 7 for tag agent.tunnel.* if needed). Most likely you had those tunnels before, in version 3.8.382 we just have added event and alarm for those cases.

Best regards,
Victor

Quote from: lweidig on June 01, 2021, 11:49:33 PM
An update to my last post, decided to live on the edge and run nxdbmgr -X upgrade which resulted in:

Code Select Expand

# nxdbmgr -X upgrade
NetXMS Database Manager Version 3.8.382 Build 3.8-382-gc0100d1389 (UNICODE)

Upgrading database...
Upgrading from version 38.16 to 38.17
SQL query failed (Duplicate column name 'rule_description'):
ALTER TABLE alarms ADD rule_description varchar(255)
SQL query failed (Data too long for column 'rule_description' at row 75):
UPDATE alarms SET rule_description=(SELECT REPLACE(REPLACE(REPLACE(REPLACE(comments, ?, ' '), ?, ' '), ?, ' '), '  ', ' ') FROM event_policy WHERE event_policy.rule_guid=alarms.rule_guid)
Database upgrade succeeded

Server now starts, but concerned what the long term impact of this might be...

Should be no long-term impact. Some existing alarms will be missing rule description, but nothing more.

Best regards,
Victor

Terminated alarms are kept in alarm log and cleaned by housekeeper (by default after 90 days, this period can be changed). You can access them via "Alarm Log" view or directly in database.

Best regards,
Victor

Автоматическое обнаружение в такой ситуации будет работать только если создать отдельную зону и указать агент как прокси этой зоны.