NetXMS Support Forum

Доброго дня
Настроены два EPP для группы хостов и ивентов SYS_AGENT_UNREACHEBLE, SYS_AGENT_UP - скрины прикрепил
По журналу ивентов видно, что с нужной группы генерируются уведомления о недоступности\работоспособности агента, периодически и с нужной для срабатывания уведомления длительностью. Но! EPP на отправку уведомления о недоступности не срабатывает, при этом уведомления о восстановлении коннекта до агента отправляются. В списке сервер-действий нет записей о попытках отправить уведомление о падении агента. При этом если руками на хосте выключить агент, то оба EPP спокойно отрабатывают - ивент-таймер-аларм-уведомление, все ок. Но в условно "пассивном" виде в чат с уведомлениями только UP часть падает, без UNREACHABLE

В таком же шаблоне мониторятся ивенты SYS_NODE_DOWN и SYS_NODE_UP по той же группе хостов и таких проблем там не возникает, все отрабатывает корректно

Что проверить можно?

Hi,

is there any update on this ??

Regards
Richard

I was looking more into the AI feature of NetXMS 6 and noticed a distinction between Assistant and Agent


Starting from NetXMS v6, MCP and AI assistant capabilities are provided in the open-source version. The AI agent module is available only as part of the NetXMS Enterprise Edition.


Could you clarify what the difference is and why one should be considered above the other

Не помогло. что еще можно проверить?

Сделал это, проверяю. Отпишусь.
Я наоборот понял из документации что прокси ноды всегда должны быть в зоне default.

That's wonderful! I'm looking forward to the next version update, and thank you so much for your tremendous help!

Problem is with device processing SNMP GET NEXT requests incorrectly; standard requires that GET NEXT should return OID that is strictly higher than previous one; however, device returns entries in FDB in random order:

1.3.6.1.2.1.17.7.1.2.2.1.2.67.180.5.93.216.211.69 [INTEGER]: 15
1.3.6.1.2.1.17.7.1.2.2.1.2.70.28.131.65.44.65.209 [INTEGER]: 53
1.3.6.1.2.1.17.7.1.2.2.1.2.64.180.5.93.216.211.179 [INTEGER]: 53

third entry actually less than first one.

In version 6 we did some optimizations to SNMP walk, including stricter checks for loop detection, this is why walk on H3C start failing. In next patch release we will relax it to handle buggy devices like this one.

Hi,

i have problems when using the log parser.
I try to catch Error 251 from the windows Application Log and forward to NetXMS.

When i just change the EventID to 404 or 406 it is working and i see an entry in the Monitor from Server.
I cant figure out why it is not working with "Error" "EventID 251".
I never see a entry in the Debuglog from client with EventID 251.
I tried with Filter of Source "LSA_MONITOR" or without, doesnt change anything.
Logwatch is enabled in Client Agent.

Thank you!

Sorry i forgot: client and Server are 6.1.1

I tested the command nxsnmpwalk -v 2c -c stonewell2000 10.61.43.131 1.3.6.1.2.1.17.7.1.2.2.1 separately on version 5.0.8 and 6.1.1, and there are obvious discrepancies between the two results. Only version 5.0.8 can retrieve the complete data normally.The packet capture logs of v6.1.1 have been uploaded as an attachment. Thank you so much!

It looks like regression in SNMP library. Could you please try same SNMP walk from command line using nxsnmpwalk tool? Ideally do walk on same device using nxsnmpwalk from v5 as well.
If there will be discrepancies between v5 and v6, send me packet capture from v6 walk if possible.