NetXMS Support Forum

Hi!

There are description of how to use ServiceCheck.HTTP(): https://www.netxms.org/forum/index.php/topic,28.msg87.html#msg87

Best regards,
Victor

Hello!

Here are translation of mentioned post, should be enough to setup shared resource monitoring.

It's an example of cluster monitoring configuration.

Case:
We have two cluster nodes: NODE_A and NODE_B. Cluster itself is called CLUSTER. Both nodes have NetXMS agents installed. Nodes are connected to public network 192.168.1.0/24, node A has address 192.168.1.11, node B - 192.168.1.12. Also, both nodes has private network 10.0.0.0/8, node A has address 10.0.0.1, node B - 10.0.0.2. There are 3 resource groups:
1. Cluster group, name: ClusterGroup, virtual IP 192.168.1.10
2. Shared disk, name SharedDisk, virtual IP 192.168.1.20. On active node seen as drive X:
3. Exchange server group, name: Exchange, virtual IP 192.168.1.30. On active node run Exchange services and drive E: contains shared Exchange data.


Requirement:
Monitoring service availability and disk space.


Configuration steps:

1. Create object of type "Cluster", call it CLUSTER (it is no necessary to match AD cluster object name)
2. In CLUSTER object properties add cluster interconnect network 10.0.0.0/8
3. In CLUSTER object properties on "Resources" page define resources (name - IP pairs):
    ClusterGroup 192.168.1.10
    SharedDisk 192.168.1.20
    Exchange 192.168.1.30
4. Now we can create nodes A and B. They should be created under CLUSTER object. As Ip addresses for new nodes should be used their fixed IP addressesd (192.168.1.11 and 192.168.1.12 in our example).
5. Check configuration of new nodes - virtual addresses of cluster resources should not appear as interfaces. If you select CLUSTER object in object browser, on "Cluster" page should be displayed correct position and status of cluster resources.
6. Now DCIs for cluster resources can be defined. Select "Data Collection" for CLUSTER object, and create DCIs as usual, except one: you should select correct cluster resource in "Associate with cluster resource" field. Fo example, for monitoring disk space on shared disk X:, you should set "Associate with cluster resource" to "SharedDisk" in our example. DCIs configured that way will be collected only from node which is current owner of associated resource.
7. All other configuration for cluster nodes can be done as usual.


There are also some predefined events related to cluster monitoring:

SYS_CLUSTER_DOWN
SYS_CLUSTER_UP
SYS_CLUSTER_RESOURCE_DOWN
SYS_CLUSTER_RESOURCE_UP
SYS_CLUSTER_RESOURCE_MOVED

You can process them as usual in event processing policy.

Best regards,
Victor

Hello!

Looks like compiler tries to use incorrect _CONTEXT definition from WinNT.h. Such result can occur if you have _M_X64 defined instead of _M_IX86 when compiling StackWalker.cpp. Maybe you have 64bit version of cl.exe first in your path?

Best regards,
Victor

1. Normal'no etogo sdelat' nel'zja. Ja podumaju nad patchem chtobi dobavit' takuju vozmoznost'.

2. V MasterServers nado ukazivat' IP proxy agenta, prichem tot adres, s kotorogo pridet connect. Naprimer, dlja shemi:

server --- (83.153.17.1) [fw + proxy agent] (192.168.1.1) --- (192.168.1.10) [remote agent]

so storoni servera dlja hosta 192.168.1.10 proxy budet vistavlen 83.153.17.1, a v konfige 192.168.1.10 MasterServers budet 192.168.1.1.

Best regards,
Victor

A mozno startanut' server s debug'om urovnja hotja-bi 7 (netxmsd -D 7) i prislat' log?

Sorry, https://www.netxms.org/download/rc/nxagent-0.9.0-rc1-x64.exe

Сразу нет. Но можно централизованно рестартить агентов через actions. Из консоли можно сделать рестарт агента через меню Tools -> Restart Agent, а с командной строки так:

nxaction <agent_address> Agent.Restart


Еще один вариант - использовать возможность агента принимать upgrade package. Можно сделать скрипт, который будет обновлять конфиг, npi файл для него, и сделать deploy как обычному upgrade package'у.

Агент может при старте забирать конфигурацию с сервера. Для этого он дожен быть запущен с ключом -M. Например, для запуска агента как сервис, с конфигурацией, предоставленной сервером 10.0.0.2:

nxagentd -M 10.0.0.2 -d


При получении запроса на конфиг, сервер проходит по порядку все конфиги, которые у него есть, и запускает скрипт, связанный с конфигом. Если скрипт возвращает ненулевое значение, то конфиг передается агенту.

Пример скрипта для конфига, который надо отдать агенту на Windows:

$2 like "windows-*"


Начиная с версии 0.2.24, при инсталляции агента на Windows, в инсталляторе можно отметить пункт "Download configuration file from management server on startup", тогда инсталлятор сделает сервис, у которого будет ключ -M в командной строке. Если используется unattended install, то можно инсталлятору указать ключ /CENTRALCONFIG для получения такого-же результата.

Выложил патч для x64: https://www.netxms.org/rc/nxagent-0.9.0-rc1-x64.exe.
Должен работать

Quote from: Anth0ny on December 19, 2008, 02:52:09 PM
нет никаких предположений почему именно кластерный мониторинг отписывает каждый раз при рестарте сервиса мониторинга?

Потому что именно их состояние не сохраняется в базе Я это к следующему релизу исправлю.

Hello!

Most likely nxagentd.exe is locked and therefore cannot be deleted - because it contains message texts for Windows Event Log, it can be opened by mmc.exe if someone leave Event Viewer open. It also can be any other process which uses Event Log. As a workaround, rename nxagentd.exe, and then run installation again.

Best regards,
Victor

Push-параметры упоминались несколько раз на форуме:

https://www.netxms.org/forum/index.php/topic,48.msg145.html#msg145
https://www.netxms.org/forum/index.php/topic,22.msg62.html#msg62

Название "агент" здесь не очень уместно, но я ничего лучше не придумал. Это просто программа, которая может посылать данные для DCI на сервер. Т.е. смысл в том, что не сервер запрашивает данные у агента, а агент предоставляет данные когда считает нужным.

Пример использования:

Есть некий датчкик, с которым работает собственная программа, которая может вызывать внешний скрипт, которому передает текущее значение. Мы хотим это значение собирать на сервер. Для этого:

1. Делаем DCI с именем, например, Test, и источником Push Agent;
2. Делаем скрипт, который принимает текущее значение и отсылает на сервер:


#!/bin/sh
nxpush -u login -P password netxms_server_address Test=$1


все.

да, правильно

В теге event надо указывать код NetXMS события - это и есть та самая связь. Код события виден в конфигураторе событий (см. скриншот).

Ну, собственно я уже писал, что это баг в 64 битном агенте. Надо ждать патч. А так конфиг выглядит правильно, единственно у меня вызывают подозрение коды событий 100 и 101 - из консоли события с такими кодами создать нельзя.