NetXMS Support Forum

Hi!

Yes, its the right parameter to set. If you wish to have an email if node is down for 5 minutes or more, you should set it to 5 (it means that 5 status polls should fail, and status polls by default goes every 60 seconds).

Best regards,
Victor

Дополнительный вопрос: а в то время, когда шли 0 вместо нормальных значений, остальные параметры собирались?
У меня тоже обнаружился один сервер, который иногда так себя ведет - раз в неделю примерно. Похоже на проблему с агентом, но я пока-что не могу повторить ее и понять почему так происходит.

При обработке трапов событие ищется только по 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: к какому-нибудь ресурсу?