NetXMS Support Forum

Several options:
1) Script threshold. In that script you can use GetDCIValues() to get values for some period, e.g. 10 minutes 1 or 2 days ago. Get average for that period and compare it with the current. It's possible that there were collection issues and GetDCIValues() will not return anything - script should check for that.

2) Get some baseline initially and store it in a custom attribute. The custom attribute name should be like signal_level::GigabitEthernet1/0/1 - so some text::instance name.
The value can be stored in transformation script by checking if such custom attribute exists.

Then in the threshold you can use %{custom_attribute:default_value} macro. This macro has a special behavior (not yet documented) - first of all it will try to find custom attribute named "custom_attribute::instance", where instance is the instance name from DCI properties.
If not found, it will try custom attribute with "custom_attribute" name, if that is not found, will take the default_value, if it's given.

Current implementation does not support adding XML to events. I've created an issue to add this:
https://track.radensolutions.com/issue/NX-2072
also there's no exact plan when this could be implemented.

This has been implemented in developers version and will be released soon.

DCI properties have two places where multiplier mode is set - in "performance tab" and "other options".

It could be necessary to reload Last values tab for that settings to have effect.

I've just tried in Last Values - it looks to be working for me.

No, the XML is not available for parsing. It could be possible to pass it as a parameter of generated events, but that won't be much of use, as analysis should be done at Log Parser level and Log Parser does not allow parsing using NXSL.
What exactly field(s) do you need from the XML?

Права на ноду собираются со всех родительских объектов ноды. Это может быть из трех деревьев:  Entire Network, Infrastructure services и Templates (если на ноду наложен хотя бы один шаблон). Наследование прав от дерева шаблонов планируется убрать в одной из будущих версий.

Да, сбор этих данных был написан только под Windows (т.к. клиенту, который заказывал эту разработку требовалось только на эту платформу).
Сделал ишшую на этот счет: https://track.radensolutions.com/issue/NX-2069 но точных сроков вооплощения тут нет.

Summary table does not perform any requests to collect data on it's own. It just find DCIs present on nodes by matching DCI's parameter and showing these.

So it means that your nodes need to have DCIs with corresponding parameters, e.g. .1.3.6.1.2.1.31.1.1.1.15.1

Does all your equipment has only one network interface? Are OIDs same for all nodes? Or there could be several interfaces on a node? Which should be in the summary table then?

There are two things that can be configured on agent:
- ExternalParameter (gets executed when server or nxget is requesting the value from agent. Or with AgentReadParameter() from NXSL)
- ExternalAction (gets executed by nxaction, server action (e.g. from EPP rule) or NXSL AgentExecuteAction

Hi!

What version of console? Is it on Win or Linux? What java version used?

try running
tcpdump host your.smtp.server.address port 25
in the console of your server and making an attempt to send email.
Console output should show communication with mail server.

Check Event Log, may be there are SYS_SMTP_FAILURE events. These can give some information on the reason.

classof($object function should have closing bracket: classof($object). Output of this function is string which is compared to "Node"

Each interface has "Expected state" in it's properties. If it's set to IGNORE, events won't be generated when this interface goes down or up.
So it might be sufficient to set this to Ignore on all interfaces except the one that you want to monitor.

No, getnext is currently not implemented. It's possible to do snmpwalk somewhere at a higher level which would include all the branches you need and then parse it's output. Will this work in your situation?