NetXMS Support Forum

При обработке трапов событие ищется только по oid. Если нужно проверять конкретные переменные в трапе, то надо их добавлять в event и делать дополнительные проверки скриптом в event processing policy. Т.е. в описанном случае надо сделать одну запись в trap configuration:

OID = .1.3.6.1.4.1.318.0.173, Parameter bindings $2 = 1.3.6.1.4.1.318.1.1.10.2.3.4.1.2.2

а в event processing policy в скрипте написать например


$2 != ""


тогда правило отработает только если второй параметр будет содержать какое-то значение.

Если нужно просто увеличить значение на 600, то скрипт будет такой:


$1 + 600


GetDCIValue возвращает последнее значение DCI, записанное в базе, а $1 - это переменная, которая содержит текущее значение до трансформации. GetDCIValue используется обычно для трансформации, зависящей от другого DCI - например поделить объем свободной памяти на общий объем памяти и получить процент свободной памяти.

Mozno esche prislat' skrinshoti s konfiguraciej thresholdov dlja problemnih DCI i istoriju sobrannih dannih za period pered vozniknoveniem problemnogo alarma? Dannie mozno cherez export poluchit' v tekstovij fail.

Quote from: Anth0ny on July 21, 2008, 09:44:40 AM
+ ВОПРОС: применительно к мониторингу ресурсов и степени их занятости (заполненности).

Если используется несколько степеней важности (Warning, Minor, Major, Critical) загруженности ресурса, КАК можно указывать автоматом (через макрос) применительно к указанным выше шаблонам текста, что для всех степеней важности Эталонное пороговое значение (Threshold) - своё (понятно, что для каждого статуса - отдельное), а вот при подстановке в текст нужно иметь ввиду, что ОБЩЕЕ эталонное значение- отдельное и для всех одинаковое (нужно брать из статуса Normal)?

объясню:

сободно на диске (Threshold Condition) => 10 гб - Normal
при Threshold Condition =< 9 гб = Warning
при Threshold Condition =< 8 гб = Minor
при Threshold Condition =< 7 гб = Major
при Threshold Condition =< 6 гб = Critical

Соответственно Threshold Condition для каждого Threshold - свой. Но суть в том, что для всех них есть один единый ЛОГИЧЕСКИЙ Threshold, 10 гб. Который определяет НОРМАЛЬНОЕ состояние диска.

Было бы совсем неплохо иметь возможность размер этого базового Threshold подставить в текст... А то получается что в текст сейчас можно подставить только Текущий показатель и его эталонный Threshold.

вопрос возник потому, что у меня используется несколько разных схем мониторинга дисков, где-то - в %, где-то - в абсолютных величинах, при этом к разным серверам - разные требования (у сервером сильно различается объём дисков). а добиться хочется максимальной универсализации...

Это будет возможно начиная с версии 0.2.22 - там появится возможность делать custom attributes для объектов и иметь к ним доступ через скрипты.
Тогда можно будет сделать так:

1. добавить атрибут, скажем, disk_threshold_с
2. при создании сообщения использовать макрос, например, %[print_disk_threshold]
3. сделать скрипт print_disk_threshold:

GetCustomAttribute($node, "disk_threshold_" . $6)


В instance для DCI нужно будет указывать правильное имя диска, и все.

А можно более подробно описать конфигурацию? Или прислать скриншоты?

Дополнительный вопрос: а в Last Values данные показываются правильно? А то у меня есть подозрение что в момент отсылки таких писем сервер получает от агента пустую строку вместо данных и честно ее подставляет...

every 600 seconds means every 10 minutes, so you can put */10 instead of * for minutes in schedule, like


*/10 10-22 * * *


which means "collect value every 10th minute from 10:00 till 22:50".

Best regards,
Victor

Quote from: Victor Kirhenshtein on July 19, 2008, 10:35:16 AM
2. Ошибка в заголовке и теле письма
Описание: не все макросы заполняются данными, и поэтому нарушается подстановка

Шаблон почтового извещения полностью аналогичен предыдущему.

Используемый Event (Message template): Агент NetXMS не отвечает

получаю сообщение:

Subject: Minor (11-Jul-2008 20:01:06): параметр "" на сервере test3.server.ru

ВРЕМЯ ВОЗНИКНОВЕНИЯ: 11-Jul-2008 20:01:06
МЕСТО ВОЗНИКНОВЕНИЯ: test3.server.ru[10.100.143.162]
ИСТОЧНИК СОБЫТИЯ:
СТАТУС СОБЫТИЯ: Minor

Агент NetXMS не отвечает

Нельзя ли хоть чем-нибудь заполнять Event Source? Или это ошибка?

Makrosi %1 .. %9 - eto parametri sobitija. Kolichestvo i znachenie parametrov zavisit ot koda (tipa) sobitija. U sobitija SYS_AGENT_UNREACHABLE net parametrov, poetomu makros %2 raskrivaetsja v pustuju stroku.

Variantov reshenija dva - libo delat' raznie e-mail templeiti dlja raznih tipov sobitij, libo formirovat' zelaemij tekst pri pomoschi scripta.

Reshil perenesti kommentarii k opisannoj probleme v forum, tak udobnee budet. Original'nij report:

Не могу точно сказать где, но выглядит это примерно так же как и ошибка несоответствия %s и %S. Проявляется не регулярно и на разных нодах.

1. Ошибка в теле письма (макросы)

Описание: в случае, если в шаблонах почтовых извещений используется конструкция типа ...

поле "E-mail Subject":
%S (%t): параметр "%2" на сервере %n

поле "Message text":
ВРЕМЯ ВОЗНИКНОВЕНИЯ:\t%t\nМЕСТО ВОЗНИКНОВЕНИЯ:\t%n[%a]\nИСТОЧНИК СОБЫТИЯ:\t%2\nСТАТУС СОБЫТИЯ:\t\t%S\n\n%m

и в обрабатываемом Event'е (Message template) используется конструкция:
Внимание! Превышено допустимое значение параметра "%2"! Текущее значение: +%4C (допустимо: +%3C)

... то в основном приходит правильная почта (ну.. почти нормальная, так как Severity %s не равно %S):

Subject:
Minor (14-Jul-2008 17:09:18): параметр "[DL] [MB Ambient Temp] Температура Системы" на сервере test.server.ru

Body:
ВРЕМЯ ВОЗНИКНОВЕНИЯ: 14-Jul-2008 17:09:18
МЕСТО ВОЗНИКНОВЕНИЯ: test.server.ru[10.100.144.33]
ИСТОЧНИК СОБЫТИЯ: [DL] [MB Ambient Temp] Температура Системы
СТАТУС СОБЫТИЯ: Minor

ОПИСАНИЕ СОБЫТИЯ: Внимание! Превышено допустимое значение параметра "[DL] [MB Ambient Temp] Температура Системы"! Текущее значение: +40C (допустимо: +40C)

* * *

Но вот иногда где-то что-то заедает и вместо нормального ответа я получаю такой:

Subject:
нормальный, как в предыдущем примере

а вот текст...

Body:
ВРЕМЯ ВОЗНИКНОВЕНИЯ: 14-Jul-2008 17:09:16
МЕСТО ВОЗНИКНОВЕНИЯ: test2.server.ru[10.10.34.53]
ИСТОЧНИК СОБЫТИЯ: [DL] [MB Ambient temp] Температура Системы
СТАТУС СОБЫТИЯ: Minor

ОПИСАНИЕ СОБЫТИЯ: Внимание! Превышено допустимое значение параметра "[DL] [MB Ambient Temp] Температура Системы"! Текущее значение: +C (допустимо: +0x000005A7C)

2. Ошибка в заголовке и теле письма
Описание: не все макросы заполняются данными, и поэтому нарушается подстановка

Шаблон почтового извещения полностью аналогичен предыдущему.

Используемый Event (Message template): Агент NetXMS не отвечает

получаю сообщение:

Subject: Minor (11-Jul-2008 20:01:06): параметр "" на сервере test3.server.ru

ВРЕМЯ ВОЗНИКНОВЕНИЯ: 11-Jul-2008 20:01:06
МЕСТО ВОЗНИКНОВЕНИЯ: test3.server.ru[10.100.143.162]
ИСТОЧНИК СОБЫТИЯ:
СТАТУС СОБЫТИЯ: Minor

Агент NetXMS не отвечает

Нельзя ли хоть чем-нибудь заполнять Event Source? Или это ошибка?

--------------

v otvetah sejchas prokommentiruju.

V alarm timeout'ah dejstvitel'no bil bag, i ne odin: vo pervih, timeout ne sobljudalsja i srabatival nemedlenno, vo vtorih - vsegda posilalsja event SYS_ALARM_TIMEOUT. Vrode vse ispravil, rabotaet kak nado.

Chto kasaetsja alarmov, kotorie ostajutsja na node, to mozno ved' sdelat' avtomaticheskij terminate cherez kljuchi - ja tak ponjal chto u vas tak i sdelano, chto WWW_OK avtomaticheski terminiruet alarm, sozdannij po WWW_NOK. Pri zelanii vi mozete sdelat' toze-samoe i po WWW_WARN, esli ne hotite chtobi alarm ostavalsja aktivnim posle otsilki meila.

I don't see any need for separating exclusions - everything can be defined as one or more advanced schedule record. For example, if I need not to poll DCI from 10:00 till 12:00 (not including 12:00 itself), I can use the following schedule:


* 0-9,12-23 * * *


I don't sink that it's much more complicated then writing "exclusion" schedule


* 10-12 * * *


Best regards,
Victor

Quote from: Anth0ny on July 17, 2008, 10:57:28 AM

Quote from: Victor Kirhenshtein
Zdes' kakoe-to nesovpadenie terminov pohoze Nel'zja zapustit'/ostanovit' obrabotku sobitija - ona vsegda proishodit (t.e. kazdoe sobitie obrabativaetsja). Mozno po sobitiju zapuskat' vneshnie processi - cherez Actions, sozdavat' u ubirat' alarmi, menjat' sostojanija situacij.

Виктор, попробую объяснить, почему я использую данные термины именно так...

Если смотреть на просто Событие, то оно - вещь статическая и по сути никакой динамикой не обладает. Динамичным его делает Threshold, который помечает DCI указанным ему Событием при наступлении указанных в Threshold'е условии.

Далее: когда DCI помечается Threshold'ом указанным ему Событием, происходит Обработка События в Event Processing Policy.

Именно поэтому я использую оборот "Запуск События на обработку".
главный по мониторингу и готовлюсь.... =)

Вообще-то идея немного другая: событие - это как раз динамический объект (и с очень коротким временем жизни) - событие возникает, проходит через event policy, вызывая тем самым какие-то действия, записывается в лог - и исчезает. Не надо путать события с шаблонами событий (то что мы видим в Control Panel -> Events) - те действительно статические объекты.

Пороговые значения (thresholds) у DCI - это лишь один источник событий. События также генерируются при опросе статуса узлов (SYS_NODE_DOWN например), как результат обработки SNMP трапов, просто могут присылаться из внешних систем (например через nxevent).

Quote from: Anth0ny on July 17, 2008, 10:57:28 AM
Понял, проверил. Действительно всё так, Вы правы. Правда есть некоторые странности: при создании на уровне Кластера DCI для мониторинга диска С:, этот DCI почему-то обслуживает не обе ноды, а только одну. Не пойму почему. На второй ноду ошибки не выдаёт, но и данные не собирает...

А Вы случайно не привязали DCI для диска C: к какому-нибудь ресурсу?

Ochen' horoshaja ideja!

Proshu proshenija za bol'shie zaderzki s otvetami, bil ochen' bol'shoj zaval na rabote. Sejchas postarajus' v techenii dnja otvetit' na vse voprosi na forume.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
2. А усилять и расширять мониторинг кластеров не планируется? Кстати большое Вам спасибо за то, что уже реализовано!

Eto bilo-bi interesno, no ja poka ploho predstavljaju chto i kak tam mozno bilo bi uluchshit'. Mozno sdelat' otdel'noe obsuzdenie v feature request i pridti k novoj sheme monitoringa klasterov. Togda mozno budet ee i realizovat'.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
А можно поподробнее о SYS_ALARM_TIMEOUT? я уже отписал в теме по монитрингу HTTP, что получаю чрезвычайно странный результат при использовании данного параметра а также параметра Timeout. Может быть я их просто неправильно использую? Подскажите... =)

Ja segodnja/zavtra proverju etot funkcional, pohoze tam kakie-to strashnie bagi...

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
Запустить/остановить процесс - имелось ввиду Event Processing (запуск процессинга эвента и остановка процессинга эвента).

Zdes' kakoe-to nesovpadenie terminov pohoze Nel'zja zapustit'/ostanovit' obrabotku sobitija - ona vsegda proishodit (t.e. kazdoe sobitie obrabativaetsja). Mozno po sobitiju zapuskat' vneshnie processi - cherez Actions, sozdavat' u ubirat' alarmi, menjat' sostojanija situacij.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
3. Т.е. если я правильно понял, то ресурсы, которые входят в кластерную группу, можно мониторить ровно точно так же, как и обычные ресурсы, находящиеся на одиночной ноде? Но в таком случае на каком уровне нужно создавать DCI'и? На уровне кластера? Или на уровне каждой из нод? Прошу подсказать =).

DCI nado sozdavat' na urovne klastera, ukazivaja dlja kazdogo DCI k kakomu resursu on otnositsja. (Esli etogo ne delat', to skazem DCI na status servisa Exchange'a na neaktivnoj node vizovet srabativanie thresholda na to, chto servis ostanovlen, pojavlenie alarma, etc., hotja eto normal'naja situacija). Privjazka DCI k resursu vizivaet sbor dannih tol'ko s toj nodi, gde sejchas nahoditsja resurs.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
4. Не работает, однозначно =).

По крайней мере с опросом дисков.

Если вопрос о последовательности создания кластера, то всё делалось по Вашему описанию, точь-в-точь. Если имеется ввиду создание DCI на уровне Кластера, то тут всё было сделано абсолютно точно также, как для обычной ноды.

Создал DCI типа Disk.FreePerc. Пробовал и для диска C: (есть на обеих нодах, понятное дело) и для диска S: (есть только на одной из нод). Обе ноды кластера- активные.

После создания (интервал опроса- 60 секунд) DCI ничего не получает. При попытке посмотреть данные через Data Collection -> Show Data получаю ошибку: Unable to retrievecollected data: Database failure.

И в таблице Collected Data в поле Value получаю единственную запись: ERROR LOADING DATA FROM SERVER.

Dannie smotreli na node ja nadejus'? Poskol'ku na ob'ekte klastera dannih net - eto virtual'nij ob'ekt, tak-ze kak i template. Real'nie dannie sobirajutsja dlja uzlov - ob'ekt klastera s tochki zrenija nastrojki DCI rabotaet kak template + dopolnitel'nie pravila kogda sobirat' dannie a kogda net.

Best regards,
Victor