NetXMS Support Forum

На 7 уровне дебага на агенте видны подробности, там openssl вызывается:

2023.02.15 00:46:09.805 *D* [comm.cs.98        ] Requesting metric "HTTPS.CertificateExpireDate(host)"
2023.02.15 00:46:09.805 *D* [comm.cs.98        ] H_ExternalMetric called for "HTTPS.CertificateExpireDate(host)" "openssl s_client -showcerts -servername $1 -connect $1:443 </dev/null 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d = -f 2"
2023.02.15 00:46:09.805 *D* [exec              ] RunExternal called for "HTTPS.CertificateExpireDate(host)" "openssl s_client -showcerts -servername $1 -connect $1:443 </dev/null 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d = -f 2"
2023.02.15 00:46:09.806 *D* [exec              ] RunExternal: command line is "openssl s_client -showcerts -servername host -connect host:443 </dev/null 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d = -f 2"
2023.02.15 00:46:09.809 *D* [procexec          ] ProcessExecutor::execute(): process "openssl s_client -showcerts -servername host -connect host:443 </dev/null 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d = -f 2" started
2023.02.15 00:46:09.827 *D* [procexec          ] ProcessExecutor::readOutput(): stopped on read (rc=0 err=Success)
2023.02.15 00:46:09.827 *D* [comm.cs.98        ] GetMetricValue("HTTPS.CertificateExpireDate(host)"): 0 (SUCCESS) value = "unable to load certificate"

Можно агента оставить с дебагом на 7 уровне, там будет видно что возвращается. Или просто погонять на эту команду на системе.

А может быть есть возможность дать нам на несколько дней доступ к одному из таких девайсов?

1. It's taking interface names from node object when map is generated. You can have a script that is executed in Hook::CreateInterface (for newly created interfaces) or in Hook::ConfigurationPoll and rename interfaces there.

2. Subnets are always displayed.

3. Actually, instead of script it's possible to set discovery radius to 1.

vlans kinda go beyond the scope of L2 map - devices only report physical connections on it's ports. For bridged ports it depends - some equipment reports bridged ports, some do not.

В логе нам интересны строчки с тегом ndd.common:

netxmsd.log.txt:2022.11.17 01:08:14.118 *D* [ndd.common        ] NetworkDeviceDriver::getInterfaces(0x7f6ec203ee80,0,true)
netxmsd.log.txt:2022.11.17 01:08:18.635 *D* [ndd.common        ] NetworkDeviceDriver::getInterfaces(0x7f6ec203ee80): invalid interface count 0 received from device
netxmsd.log.txt:2022.11.17 01:08:23.165 *D* [ndd.common        ] NetworkDeviceDriver::getInterfaces(0x7f6ec203ee80): SNMP WALK .1.3.6.1.2.1.2.2.1.1 failed
netxmsd.log.txt:2022.11.17 01:08:23.165 *D* [ndd.common        ] NetworkDeviceDriver::getInterfaces(0x7f6ec203ee80): completed, ifList=(nil)


A если на сервере запустить:
snmpwalk -v 3 -u public IP_ADDRESS  .1.3.6.1.2.1.2.2.1.1
он отработает? Можно на это время в NetXMS сделать unmanage для этой ноды, чтоб одновременно запросов не было.

Ну и еще можно попробовать выключить а оборудовании шифрование для SNMP V3, сделать Configuration Poll и собрать трафик с помощью tcpdump.

Конфигурация в первом сообщении как раз и соответствовала всем трем пунктам
- когда нода уходит в даун, заводится уведомление с таймером
- если она поднимается раньше, чем через 5 минут, то уведомление не посылается, т.к. таймер еще в силе
- если поднимается через 5+ минут, уведомление посылается, т.к. таймер уже истек

Если что-то работает не так, можно у сервера поднять уровень дебага для определенных тегов:

event.* 7
scheduler 6

и в серверном логе будет информация о том, что происходит в EPP и с таймерами

3. There is filter script in map properties. It works in a way that this script is executed for each node that is about to be put on the map. If script returns true, node will be added to the map, if false, will not be added. Here's an example script:

rootNode = FindNodeObject($node, "your_root_node_name");
if (!rootNode) return false;

for (i : $node->children) {
  if (classof(i) == "Interface") {
    p = i->peerNode;
    if (p and p->id == rootNode->id) return true;
  }
}

return false;
This script finds your root node by name. Then for each node it's getting all interfaces, and check peer nodes for them. If your root node is peer node for one of the interfaces, script will return true.


1. and 2. seem to be not customizable, but I will check.

Since Debian uses systemd, After=   parameter in netxmsd.service should help.
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=

Pls update, if you need an example

Agent communication DCIs are counters (similar as in SNMP), they are always increasing, that's fine. The interesting part is how fast it's increasing. As an option, you can add additional DCIs with enabled delta calculation.

Would be interesting to see graphs for these two Agent communication DCI for the same period as memory usage above.

This was just fixed, will be available in 4.3.1 when it will be released.

Most probable reason is that database engine gets stopped first. After that netxms waits for reconnection to the DB to write data prior to shutdown.

Странно все это.

Выглядит, как будто правило номер 3 вообще не сработало и не завело таймер. Можете на всякий случай показать еще то правило EPP которое для одной ноды на 2 минуты и правила номер 1 и 2.

You may try to run netxmsd under valgrind:

valgrind --leak-check=full --undef-value-errors=no --log-file=vg.log netxmsd -D1

Running it for a day will collect enough information, then when process is stopped, valgrind will collect log file with information about memory leaks.
The problem is that valgrind requires much more RAM then netxmsd itself, as it keeps information about every allocated piece of memory, so chances are that it won't start at all.


The other option is to compile netxms from sources, adding --enable-sanitizer to ./configure command. This would print information about memory leaks to the console and consumes a bit less memory then valgrind approach.


Also can you give a list of things that you use in your monitoring - agent tunnels, snmp, agent monitoring, actions that execute commands on management server, notification channels - any functionality that is not configured out of the box.

What version of Ubuntu are you using?

Это парные события, SYS_AGENT_OK должен быть только после SYS_AGENT_UNREACHEABLE. Можно проверить в Event Log по конкретной ноде, какие событие происходили.

У вас во втором правиле на 1 ноду больше, возможно дело в этом. В Event Processing Policy в качестве source object можно указывать не только отдельные ноды, но и контейнеры. Можно сделать специальный контейнер этих целей и даже автоматизировать добавление нод в него с помощью autobind script.

Was unable to replicate this.
Is this background image configured as rack Passive Element? Can you show properties of that passive elements?
Do you also have some other nodes that are present in this rack? Do they use default images or custom? Can you also show screenshots of their rack properties?