NetXMS Support Forum

In NXSL script you can use $dci->instance (or $dci->instanceData depending on your configuration) to get instance value.

Best regards,
Victor

Hi,

you can execute two actions for sending emails - one immediately, and one with specific timer and key (set to delay when you want your reminder). With SYS_NODE_UP event you can cancel that timer. If SYS_NODE_UP happens before timer expires then second email will not be sent.

Best regards,
Victor

Yes, NetXMS uses explicit cutoff points for dropping chunks. But please note that TimescaleDB support in 2.2.16 is quite immature - we have improved it significantly in 3.0 branch.

Best regards,
Victor

Hi,

you have to provide actual configuration for those DCIs and information about node you are collecting them from - otherwise it's hard to tell what goes wrong.

Best regards,
Victor

Hi,

interface alias is not passed to SYS_IF_DOWN. You can create script in script library called GetInterfaceAlias with the following code:

return GetInterfaceObject($node, $event->parameters[5])->alias;


and then use macro %[GetInterfaceAlias] in message text.

Best regards,
Victor

Очень странно. Можно смотреть что в логах сервера на высоком уровне дебага, 5 и выше. Возможно у второго сервера где-то нет доступа или не прописаны community strings.

Правый клик на линке - Properties - Data Sources - Add - Добавляем DCI с нужных нод. Если помимо значения надо вывести текст, то в свойствах конкретного data source можно вписать свой format string (значение подставить как %s или %*s если ножна конвертация в K/М/G).

Да, конечно исправим.

Hi,

this is bug in agent cache mode - agent ignores custom schedule and use fixed collection interval. We will fix that.

Best regards,
Victor

Depending on how you are using server it could be commit 3ab06f4e1c ("fixed server deadlock after action configuration import", 2019-06-19).

Best regards,
Victor

Quote from: Akira on August 09, 2019, 09:52:04 AM

Quote from: Victor Kirhenshtein on August 09, 2019, 09:50:31 AM
Похоже на 2019 проблема с доступом к PDH, System.Uptime берется оттуда-же.

это можно поправить?

Наверняка можно. Надо будет ставить Server 2019 и смотреть что там.

Quote from: Akira on August 09, 2019, 09:51:25 AM

Quote from: Victor Kirhenshtein on August 09, 2019, 09:49:35 AM
System.IO.Devices - это список, его не будет в списке параметров. Если сделать

nxget -l ip_address System.IO.Devices

с Server 2019, что он выдаст?

выдает 0
как кстати идентифицировать какой номер диска, соответствует какому физическому?

Значит там один диск, с номером 0. Можно посмотреть таблицу Hardware.StorageDevices, будет что-то такое:

victor@netxms:~$ nxget -T fin Hardware.StorageDevices
| NUMBER | TYPE | TYPE_DESCRIPTION | BUS_TYPE | REMOVABLE | SIZE        | MANUFACTURER | PRODUCT          | REVISION | SERIAL                           |
| 0      | 0    | Direct-access    | SAS      | 0         | 85899345920 | VMware       | Virtual disk     | 1.0      | 6000c298b14cbc6f88a1e26bb24a8cd8 |


Hi,

no updates yet. Closest thing we have now is graph templates - can help in some situations.

Best regards,
Victor

Yes, it is there for some time already: https://track.radensolutions.com/issue/NX-593.

Best regards,
Victor

Hi,

flag names didn't change since 2.2, just moved to separate "state" attribute. Runtime flag names from 2.2:

#define NDF_QUEUED_FOR_STATUS_POLL     0x000001
#define NDF_QUEUED_FOR_CONFIG_POLL     0x000002
#define NDF_UNREACHABLE                0x000004
#define NDF_AGENT_UNREACHABLE          0x000008
#define NDF_SNMP_UNREACHABLE           0x000010
#define NDF_QUEUED_FOR_DISCOVERY_POLL  0x000020
#define NDF_FORCE_STATUS_POLL          0x000040
#define NDF_FORCE_CONFIGURATION_POLL   0x000080
#define NDF_QUEUED_FOR_ROUTE_POLL      0x000100
#define NDF_CPSNMP_UNREACHABLE         0x000200
#define NDF_RECHECK_CAPABILITIES       0x000400
#define NDF_POLLING_DISABLED           0x000800
#define NDF_CONFIGURATION_POLL_PASSED  0x001000
#define NDF_QUEUED_FOR_TOPOLOGY_POLL   0x002000
#define NDF_DELETE_IN_PROGRESS         0x004000
#define NDF_NETWORK_PATH_PROBLEM       0x008000
#define NDF_QUEUED_FOR_INSTANCE_POLL   0x010000
#define NDF_CACHE_MODE_NOT_SUPPORTED   0x020000
#define NDF_NEW_TUNNEL_BIND            0x040000

In both 2.2 and 3.0 "unreachable" means that NetXMS server cannot reach the node for any reason. NETWORK_PATH_PROBLEM is an additional indicator to show that most likely node cannot be reached because of network problem on the path between NetXMS server and node (router down. etc.). Server reads routing tables from intermediate routers and builds path between itself and each node, so there is only one such path, and it either has problem or not. If there is redundant link routing eventually changes and node became reachable again, so both "unreachable" and "network path problem" flags will be cleared. NETWORK_PATH_PROBLEM flag determines what event will be generated - SYS_NODE_DOWN (if not set) or SYS_NODE_UNREACHABLE (if set).
To detect problems with non-working links you have interface objects and corresponding events.

Best regards,
Victor