NetXMS Support Forum

Можно собирать статистику с интерфейса (принятые/отосланные байты или пакеты), при необходимости считать среднее за минуту или секунду. Собственно трафик снимать и анализировать нельзя.

Нет, неправильно (или пропущены шаги в описании конфигурации). Событие будет сгенерировано агентом и обработано в policy, threshold тут ни при чем. Выше речь шла о том, что событий надо два. Примерно такая конфигурация:

1. Созданы события (шаблоны событий) Event_1 и Event_2.
2. Включен субагент logwatch.nsm на сервере. Настроен парсер на отсылку события Event_1 при обнаружении нужной записи.
2. Правило в policy для Event_1 с действием "execute NXSL script". Скрипт примерно такой:

SetCustomAttribute($node, "LastParserDetectionTime", time());

3. Создан DCI с source "Script". Скрипт для него используется такой:

return time() - GetCustomAttribute($node, "LastParserDetectionTime");

4. На DCI добавлен threshold, он генерирует Event_2.
5. В policy добавлено правило по отсылке письма по Event_2.

Попробуем у себя повторить.

Это параметр DataDirectory, по умолчанию <prefix>/var/lib/netxms

Можно при нахождении записи генерировать событие как обычно. По этому событию обновлять custom attribute на ноде в текущее время. Сделать скриптовый DCI на ноде со скриптом вида

return time() - GetCustomAttribute($node, "LogTimeAttribute");

он будет возвращать количество секунд с момента последнего обнаружения записи. Ну и поставить на него threshold как обычно.

Please show also "General" page of link properties. Also, if it is based on interface status, did you check what was actual interface status at that moment?

Best regards,
Victor

Hi,

looks like packets actually got duplicated and sent via both links. You can check that using packet capture tool (Wireshark for example). If this is the vcase then it is network misconfiguration.

Best regards,
Victor

Hi,

it needs detailed investigation by analyzing actual LLDP and other topology data from switches and checking how server process it. I don'yt have much time for that right now, please remind me later next week.

Best regards,
Victor

Hi all!

NetXMS version 2.2.10 is released. Changes since previous release:

- Improved server startup time
- Added server startup event SYS_SERVER_STARTED
- New method readInternalParameter in NXSL classes Node, Cluster, MobileDevice
- Improved cached agent data reconciliation
- Fixed DCI instance discovery issues
- Fixed issues:
        NX-1477 (Offline data collection does not cleanup old data if there are no connection with the server)
        NX-1514 (Predefined graph tree displayed incorrectly)

Best regards,
Victor

Hi,

what exact parameter you are using (ICMP.AvgPingTime, ICMP.LastPingTime, etc.)? And what is agent version?
Please also provide content of agent table ICMP.Targets (you can get it from command line with command nxget -T agent_ip_address ICMP.Targets).

Best regards,
Victor

Hi,

most likely that means that agent process does not have write access to it's data directory. Agent uses SQLite database to keep some persistent information. Most important use of this database it to keep data collection configuration and collected data if agent cache mode is on and agent collects information with server being disconnected. Default location for database file is $prefix/var/lib/netxms

Best regards,
Victor

Hi,

yes, I've found possible cause for that issue. Should be fixed in next release.

Best regards,
Victor

Hi,

from your description it's hard to tell if that was misconfiguration or a wrong data received from agent. If you get this issue next time check raw data of parameter and event log for the node for generated events.

Best regards,
Victor

Предположительно это исправлено в 2.2.9 - но нельзя сказать наверняка не зная в чем причина здесь.

High number of active alarms can also be an issue as server will cache them on startup. But usually you should not have many active alarms, if you do it's likely some flaw in your event processing logic.

Best regards,
Victor