Ad Widget

**costas** · 09-03-2011, 11:11

Originally posted by operator

Добрый день форум!
имеется самодельный триггер:
{centos:system.cpu.load[all,avg1].nodata(420)}=1 | {centos:system.cpu.load[all,avg1].count(600,0,"ge")}<4 | {centos:tcp,10005.avg(420)}<0.5

Пробую им мониторить доступность хоста. Проверяю нагрузку процессора раз в минуту, доступность по порту 10005 - раз в 2 минуты. Имею такую статистику:
Процессор:
2011.Mar.09 08:39:09 0.0000
2011.Mar.09 08:37:41 0.0200
2011.Mar.09 08:37:00 0.0500
2011.Mar.09 08:36:03 0.0000
2011.Mar.09 08:34:28 0.0000
2011.Mar.09 08:32:23 0.0000
2011.Mar.09 08:30:10 0.0000
2011.Mar.09 08:25:15 0.0000
2011.Mar.09 08:24:09 0.0000
2011.Mar.09 08:23:09 0.0200
2011.Mar.09 08:22:16 0.0500
2011.Mar.09 08:21:10 0.1600
Доспупность порта:
2011.Mar.09 08:37:11 1
2011.Mar.09 08:35:41 1
2011.Mar.09 08:32:06 1
2011.Mar.09 08:26:57 1
2011.Mar.09 08:24:00 1
2011.Mar.09 08:22:00 1

В 8:37 срабатывает, а в 8:38 - отбой.
Пожалуйста, подскажите почему?

Зачем используете загрузку CPU для определения доступности хоста

?

{centos:system.cpu.load[all,avg1].count(600,0,"ge")}<4

здесь вы сравниваете количество значений равных или больше '0' за промежуток 10 мин с "4", отсюда и сработка.

Считайте сколько тут вхождений и сравните с "< 4"

2011.Mar.09 08:37:00 0.0500
2011.Mar.09 08:36:03 0.0000
2011.Mar.09 08:34:28 0.0000
2011.Mar.09 08:32:23 0.0000
2011.Mar.09 08:30:10 0.0000

Знак "|" это логическое ИЛИ в выражении триггера.

для проверки порта можно использовать
{centos:tcp,10005.sum(#5)}<5
сработка будет если хотя бы один раз порт не был доступен в течении последних 5-ти проверок
это более наглядно...

**operator** · 09-03-2011, 11:49

Originally posted by costas

Зачем используете загрузку cpu для определения доступности хоста

?

до сих пор не нашел как это делать по-другому в версии 1.6. Я проверяю не только доступность сервера, а еще и доставку данных. Если доступен порт агента и хост пингуется, то это еще не значит, что агент работает... Буду очень благодарен, если подскажете правильное решение, исходя из того, что системы доступны через Инет: т.е. недоступность систем в течение скажем 5 минут - нормально.

Originally posted by costas

здесь вы сравниваете количество значений равных или больше '0' за промежуток 10 мин с "4", отсюда и сработка.

Считайте сколько тут вхождений и сравните с "< 4"

хм. Я видно что-то не понимаю: я думал, что я считаю значения 0 или большие за последние 10 минут. Их-5. А 5 !< 4 . Или нет?

Originally posted by costas

Знак "|" это логическое ИЛИ в выражении триггера.

для проверки порта можно использовать
{centos:tcp,10005.sum(#5)}<5
сработка будет если хотя бы один раз порт не был доступен в течении последних 5-ти проверок
это более наглядно...

можно, только см. выше: в моем случае сильно много ложных срабатываний.

**costas** · 09-03-2011, 12:04

Originally posted by operator

до сих пор не нашел как это делать по-другому в версии 1.6. Я проверяю не только доступность сервера, а еще и доставку данных. Если доступен порт агента и хост пингуется, то это еще не значит, что агент работает... Буду очень благодарен, если подскажете правильное решение, исходя из того, что системы доступны через Инет: т.е. недоступность систем в течение скажем 5 минут - нормально.

Для 1.6 в своё время использовали nodata() для значения с опросом в минуту за последние 5-10 мин + agent.ping +zabbix

ort с логическим И иначе будет куча ложных сработок.

Для доступности хоста "icmp ping" внешняя проверка - обычно достаточно.

Но лучше рекомендую обновиться до 1.8.4, если есть возможность то на вновь оставленную систему путём переноса шаблонов, а потом и хостов, апгрейд существующей системы как показывает практика гладко не проходит.

**operator** · 09-03-2011, 12:31

Originally posted by costas

Для 1.6 в своё время использовали nodata() для значения с опросом в минуту за последние 5-10 мин + agent.ping +zabbix

ort с логическим И иначе будет куча ложных сработок.

в этом случае не будет видно скажем того, что отвалился агент, если хост все еще пингуется.

Originally posted by costas

Но лучше рекомендую обновиться до 1.8.4, если есть возможность то на вновь оставленную систему путём переноса шаблонов, а потом и хостов, апгрейд существующей системы как показывает практика гладко не проходит.

переход на 1.8 пока не грозит, по техническим причинам.
Так возвращаясь к моему вопросу: а почему же у меня триггер срабатывает?

**gdgsoft** · 09-03-2011, 13:43

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

ИМХО, данная проблема может быть связана с тем, что после того, как какая-нибудь проверка не смогла получить данные, триггер получает статус unknown и его обработка не попадает под описанные условия срабатывания триггера вообще. Триггер начнет срабатывать только после того, как станет получать значения: Ok/problem.

Мне кажется, что в Вашем примере, после 8:37, то есть в 8:38, элемент данных не смог получить знаечение от железки, после чего он "уснул" на 5 минут. Эти 5 минут триггер был в состоянии unknown, и соответственно все описанные условия просто игнорировались. После того, как через 5 минут элемент начал получать данные, все ваши условия начали обрабатываться, но без интервала, когда триггер был в состоянии unknown.
Я решил бороться с такой ситуацией, путем добавления условия для триггера в виде: {trigger.value}=2. Двойка, это как раз для статуса unknown.

Я не анализировал работу триггеров в заббиксе при условии, что триггер имеет статус unknown. Но тот момент, что при потери коннекции с устройством, когда элемент данных перестает получать данные, и триггера перестают нормально обрабатываться из-за значения unknown, я заметил. Мне кажется, что Ваша проблема связана на 99.9% именно с этим.

**costas** · 09-03-2011, 14:51

Originally posted by operator

в этом случае не будет видно скажем того, что отвалился агент, если хост все еще пингуется.

Имелось ввиду две разные проверки, одна для доступности хоста, другая для агента.

Вот эта тема как раз ваш случай, было но давно, всего и не вспомнишь..

We’ll be back soon!

http://www.zabbix.com/forum/showthread.php?t=17134&highlight=agent.ping+nodata

**operator** · 10-03-2011, 11:39

Originally posted by gdgsoft

Я решил бороться с такой ситуацией, путем добавления условия для триггера в виде: {trigger.value}=2. Двойка, это как раз для статуса unknown.

Звучит интересно.
Можно попробовать. Как раз имею ситуацию, когда вот этот триггер не срабатывает,

{centos:system.cpu.load[all,avg1].count(600,0,"ge")}<4

хотя машина не получает значение загрузки процессора уже несколько часов. Только вот никак не пойму, как должно выглядеть мое условие?

{centos:system.cpu.load[all,avg1].prev(#3)}=2

Так это вроде должно обозначать нагрузка процессора = 2...

Ad Widget

Непонятное поведение триггера.

Непонятное поведение триггера.

Comment

Comment

Comment

Comment

Comment

Comment

Comment