NetXMS Support Forum

Про очереди: есть объект "node", который представляет сам NetXMS сервер - он создается автоматически. У него так-же автоматически создаются DCI для мониторинга внутренних очередей. Надо найти этот объект и посмотреть текущие значения этих DCI.

Currently it's possible via "management packs". In console, select Tools -> Create management pack, and add templates you wish to export. You will get .nxmp file with templates and related custom events if necessary. On other system, select Tools -> Import management pack and you will have all templates and events from it created.

Btw, if you have templates which may be useful for others, you can post them on the forum.

Best regards,
Victor

Interesovalo chto takoe sobitie bilo i ego timestamp. Poskol'ku ispol'zuetsja localtime(), ne mozet bit' kakogo-nibud' prikola s time zone servera?
Ja tol'ko-chto u sebja takuju konstrukciju proveril - rabotaet.

a kak vigljadit zapis' dlja sootvetstvujushego sobitija v event log'e?

Quote from: Anth0ny on June 18, 2008, 10:17:19 AM
+ проявились странности при опросе ACPI.ThermalZone.CurrentTemp

настроено как NetXMS Agent \ Integer

судя по настройке, параметр температуры должен опрашиваться ровно точно также, как и всё остальное... 1 раз в минуту (Polling and Storage = 60 seconds)...

а вместо этого получаем вот что: (даю результаты с нескольких серверов, с тех, что ответили, может удастся вычислить закономерность? и плиз, на будущее, пока идёт отладка: нужны возможности экспорта ото всюду, а то скрины делать не всегда удобно, а так бы экспортировал список и сюда постнул)

A kak ostal'nie parametri, sobirajutsja reguljarno? Esli da, to problema skoree vsego na storone agenta, a esli net - to eto obschaja problema servera. U ob'ekta kotorij predstavljaet sam NetXMS server dolzni bit' avtomaticheski sozdannie DCI so statistikoj po vnutrennim ocheredjam NetXMS servera - kakie tam znacvhenija?

Ok, poprobuju primerchik. Itak, u nas est' Microsoft Cluster iz dvuh uzlov: NODE_A i NODE_B. Na kazdom uzle stoit NetXMS agent. Sam klaster nazivaetsja CLUSTER. Obe nodi vkljucheni v obschuju set' 192.168.1.0/24, u nodi A adres 192.168.1.11, u nodi B - 192.168.1.12. Krome togo, mezdu nodami est' otdel'nij sync interfeis s setkoj 10.0.0.0/8, noda A imeet adres 10.0.0.1, noda B - 10.0.0.2. Eta setka potencial'no perekrivaetsja s drugimi setjami i v principe iz ostal'nogo mira nedostupna. Est' 3 resursnie gruppi:
1. Cluster group, imja: ClusterGroup, virtual'nij IP 192.168.1.10
2. Shared disk, imja: SharedDisk, virtual'nij IP 192.168.1.20. Na aktivnoj node viden kak disk X:
3. Exchange server, imja: Exchange, virtual'nij IP 192.168.1.30. Na aktivnoj node rabotajut Exchange servisi + viden disk E:

Zadacha: monitorit' dostupnost' resursov, mesto na diske.

Chto delaem:

1. Sozdaem ob'ekt tipa "Cluster", nazivaem ego CLUSTER.
2. V properties CLUSTER dobavljaem Cluster Interconnect Network 10.0.0.0/8
3. Tam-ze na zakladke Resources opredeljaem resursi (pari imja - IP adres):
    ClusterGroup 192.168.1.10
    SharedDisk 192.168.1.20
    Exchange 192.168.1.30
4. Teper' mozno sozdavat' nodi NODE_A i NODE_B. Sozdaem ih pod ob'ektom CLUSTER. V kachestve Ip adresov ukazivaem 192.168.1.11 i 192.168.1.12 (t.e. ih fiksirovannie adresa).
5. Esli posmotrim ih konfiguraciju, to virtual'nih adresov v spiske interfeisov bit' ne dolzno. Esli vibrat' ob'ekt CLUSTER v Object Browser, to v zakladke Cluster dolzni videt' pravil'noe polozenie resursov po nodam.
6. teper' mozem opredeljat' parametri. Vibiraem "Data Collection" u ob'ekta CLUSTER, i dobavljaem DCI dlja monitoringa clusternih resursov. Poskol'ku sobirat' informaciju skazem po svobodnomu mestu na diske X: s nodi gde etogo resursa sejchas net bessmislenno, to pri nastrojke DCI ukazivaem k kakomu resursu on otnositsja v pole "Associate with cluster resource". Dannie budut sobiratsja tol'ko s togo uzla, gde v dannij moment aktiven ukazannij resurs.
7. V ostal'nom nodi konfigurjatsja kak obichno.

S klasterami svjazani takze neskol'ko sistemnih sobitij:

SYS_CLUSTER_DOWN
SYS_CLUSTER_UP
SYS_CLUSTER_RESOURCE_DOWN
SYS_CLUSTER_RESOURCE_UP
SYS_CLUSTER_RESOURCE_MOVED

Pri neobhodimosti mozno ih obrabativat'.

Vot vrode i vse.

Best regards,
Victor

Da, imenno tak. Esli installjacija delajetsja pod Windows cherez installer, to v okoshke konfiguracii bazi nado vibrat' "Use existing database" i vikljuchit' opciju "Initialize database". Nu i starij i novij servera ne dolzni rabotat' odnovremenno.

Pro fermu serverov - u nas eto nazivaetsja distributed monitoring - eto plani na buduschee. Poka-chto server mozet bit' tol'ko odin.

Quote from: Anth0ny on June 18, 2008, 12:55:24 PM
+ складывается впечатление, что та проблема, о которой я раньше писал (неправильный статус, должен быть Warning а получается на деле всегда Minor), несколько глубже...

я начинаю подозревать, что есть отдельный статус для сервиса и отдельный статус для ноды вцелом. т.е. если многократно для какого-то из DCI повторяется любое событие со статусом Warning - это переводит ноду, к которой относится данный DCI, в состояние Minor.

иначе я никак не могу объяснить, почему при мониторинге диска (% свободного места) при достижении порога определённого в Event'ах как "Warning" нода сразу помечается как "Minor":

%s выдаёт "1"
%S выдаёт "Minor"

я прав? =) если нет, прошу поправить. если да, то возникает резонный вопрос: а как задаётся порог, после которого нода переводится из одного состояния в другое? Я ниразу ещё не получал извещений о состоянии Warning, всегда начинается с Minor.

Eto bug v obrabotke macrosa %S - Minor i Warning pereputani mestami. %s vozvrashaet pravil'noe znachenije statusa:

0 = normal
1 = warning
2 = minor
3 = major
4 = critical
5 = unknown
6 = unmanaged
7 = disabled
8 = testing

Esli server na UNIX'e, to v faile src/server/core/events.cpp nado stroki


const char *g_szStatusText[] = { "NORMAL", "MINOR", "WARNING", "MAJOR", "CRITICAL", "UNKNOWN", "UNMANAGED", "DISABLED", "TESTING" };
const char *g_szStatusTextSmall[] = { "Normal", "Minor", "Warning", "Major", "Critical", "Unknown", "Unmanaged", "Disabled", "Testing" };


zamenit' na


const char *g_szStatusText[] = { "NORMAL", "WARNING", "MINOR", "MAJOR", "CRITICAL", "UNKNOWN", "UNMANAGED", "DISABLED", "TESTING" };
const char *g_szStatusTextSmall[] = { "Normal", "Warning", "Minor", "Major", "Critical", "Unknown", "Unmanaged", "Disabled", "Testing" };


i peresobrat'. Esli na Windows, to podozdat' versii 0.2.22, skoro dolzna bit'. Spasibo chto prislali oba znacvenija - i %s, i %S, a to bi ja v zizni ne ponjal bi v chem problema

Still only a plans unfortunately....

No, you cannot use URL. For monitoring www.netxms.org, ypu should use request like


www.netxms.org:/


Service should be bound to node object. If you wish to check remote web server without creating node object, you can just create DCI for ServiceCheck.HTTP parameter on your management server and use normal threshold processing.

Best regards,
Victor

P.S. Please use English or post questions in Russian forum. No offence, just reminder

C правами что-то странное, вроде всегда это работало. Попробую у себя смоделировать и буду задавать дополнительные вопросы.

Интерфейс unmanaged означает что он исключен из status polls, но не из configuration polls, которые и находят неправильную маску. Можно отменить или исправить обработку события SYS_INVALID_NETWORK_MASK что-бы не создавать ненужные алармы.

Тогда способ №2 - т.е. трешолд срабатывает всегда, но в event policy ставим дополнительную проверку на текущее время. Скрипт может выглядеть так:


sub main()
{
   t = localtime();
   return ((t->tm_hour >= 11) && (t->tm_hour <= 23)) ? 1 : 0;
}


можно использовать gmtime() если время нужно в GMT.

Да, все хранится в базе. Предназначение конфига - обеспечить доступ сервера к базе.

Если базы одинаковые, то можно воспользоваться средствами самой базы (mysqldump, etc.).

Если базы разные, то да, это лучше делать собственной утилитой.

Is WMI service running? Is there any WMI-related messages in agent's log? Also, if start agent in debug mode (by adding -D switch), it will produce additional diagnostics.

DCI создаются на объекте кластера. Фактически объект кластера работает как шаблон для своих узлов, т.е. как только закрываем DCI editor, сразу обновляется конфигурация узлов. Единственное дополнение - можно связать DCI с ресурсом, тогда этот DCI будет собираться только с той ноды, где сейчас активен этот ресурс.
Активность ресурса определяется по IP адресу, узел на котором находится IP счмтается текущим владельчем ресурса.