agent.ping.nodata,как быть при тормозах Zabbix?

[sHaggY_caT]

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

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

Не только у меня, у noname, например, тоже... Да и многие отказываются от Zabbix по причине проблем с производительностью (достаточно погуглить, что бы найти десятки примеров), но я считаю, что они поступают неверно, а нужно только дать возможность, при наличии очереди на Zabbix (может быть, как-то скоомбинировать с внутренними проверками?), реализовать эту логику немного по-другому, либо изменить поведение agent.ping.

Что делает agent.ping? По сути дела возвращает информацию о доступности хоста. То, что другие проверки молчат, либо временно отключаются по причине Zabbix_Not_supported, это правильно, но почему(!?) проверка доступности всегда возвращает одно значение?

Еще раз повторюсь, проблема дисковой производительности, это маленький частный случай. А если сеть? А если любая другая проблема с Zabbix-сервером? Почему мощнейшее, без преувеличения средство мониторинга _других_ объектов, не дает увязать мониторинг других объектов с собой?

Почему лишили возможности даже просто сделать выборку из истории agent.ping?
Зачем таким искусственным способом ограничен функционал?

У меня например на 1.6.7 версии дополнительно стоит проверка по tcp порту для zabbix агентов и соответвенно висит триггер о том что агент не доступен со всеми вытекающими последствиями.

Спасибо, я думала о таком варианте, но он не нравится, так как ответ сервера по одному порту все равно ничего не гарантирует, хотя, наверное, это единственный вариант.

Если Вы внимательно посмотрите на возможные проверки со стороны сервера (включая tcp) то найдёте решение для своей проблемы, но повторюсь, можете забыть о том что у вас будет информация о стотоянии сервисов/хостов на момент бэкапа и лечится это отнють не средствами zabbix.

Ответьте на вопрос сами себе: почему средство _мониторинга_ никогда не может ответить _четко_ средствами итемов (а не триггеров), был ли доступен хост, или нет? Имхо, это абсолютно ненормально.

З.Ы. Если компания в которой Вы работаете Ваша, то я Вам сочувстую.. а если нет, есть повод идти к начальству с докладом о предстоящих расходах

Она наша с мужем, но это означает лишь то, что придется потратить кучу времени, разбираясь в исходниках, что бы заставить agent.ping что-то возвращать.
Было бы хорошо, если бы кто-то из разработчиков дал свой комментарий, пусть и негативный....

[costas]

Спасибо, я думала о таком варианте, но он не нравится, так как ответ сервера по одному порту все равно ничего не гарантирует, хотя, наверное, это единственный вариант.

Он гарантирует что у Вас не будет данных и есть проблемы, Вы можете использовать несколько портов разный сервисов для комплексных тригеров, у нас например работа web-сервера проверяется по порту-процессу-времени отклика, увы но пока выбор не велик, либо смотреть в сторону других систем...

[alex-rterm]

Как agent.ping будет что-то возвращать, если узел, на котором установлен агент, недоступен?

[costas]

Как agent.ping будет что-то возвращать, если узел, на котором установлен агент, недоступен?

именно...
agent.ping ничего не может возвращать потому что zabbix сервер не может получить коннект к агенту и проверка не выполняется, так было в версии 1.6.х, как в 1.8.х не знаю ибо исключил эту проверку.

[sHaggY_caT]

Как agent.ping будет что-то возвращать, если узел, на котором установлен агент, недоступен?

Не знаю, еще не смотрела, как в Zabbix это вообще устроено, и пока не представляю, на сколько сложно будет добавить такую обработку/хак в код. А что, Вы знаете, что это действительно не тривиально?

Он гарантирует что у Вас не будет данных и есть проблемы, Вы можете использовать несколько портов разный сервисов для комплексных тригеров, у нас например работа web-сервера проверяется по порту-процессу-времени отклика, увы но пока выбор не велик, либо смотреть в сторону других систем...

Но Вы согласны, что Было бы удобнее, если бы была возможность сделать так, что бы agent.ping возвращал что-то при недоступности агента?

Повторюсь, воспользоваться преимуществами OpenSource хорошо, но тянуть потом этот код из релиза в релиз, без шанса, что появится в апстриме, не приятно. У нас уже просто есть такие изменения, которые не брали в некоторые OSS проекты(хотя кое-что и брали)

[alex-rterm]

Не знаю, еще не смотрела, как в zabbix это вообще устроено, и пока не представляю, на сколько сложно будет добавить такую обработку/хак в код. А что, Вы знаете, что это действительно не тривиально?

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

[sHaggY_caT]

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

Но это удобно Мы всегда сможем дать однозначный ответ, был ли доступен agent в такую-то секунду времени в прошлом: в конце концов, agent.ping только этим и занимается, как итем. Почему для этого итема нужно делать исключение, делая его неполнофункциональным, сообразуясь с тем, что остальные итемы ничего не пишут, при отсуствии данных?

А еще, это решает проблему. Если кто-то знает, как решить проблему красиво, через мониторинг очередей Zabbix (причем для отдельного хоста), буду благодарна, если этот кто-то поделится.

[costas]

Но это удобно Мы всегда сможем дать однозначный ответ, был ли доступен agent в такую-то секунду времени в прошлом: в конце концов, agent.ping только этим и занимается, как итем. Почему для этого итема нужно делать исключение, делая его неполнофункциональным, сообразуясь с тем, что остальные итемы ничего не пишут, при отсуствии данных?

А еще, это решает проблему. Если кто-то знает, как решить проблему красиво, через мониторинг очередей Zabbix (причем для отдельного хоста), буду благодарна, если этот кто-то поделится.

Вы немного заблудились, дело в том что agent.ping это не то же самое что в привычном понимании icmp ping, это запрос к агенту и если он ответил утвердительно то значит пинг прошёл, а если Вам не откликается порт то это не значит что проверка не прошла, просто Вы не получили данных по этой проверке и она будет отложена.

Пинг агента на стороне сервера с гарантией возврата результата:

Description: agent.ping (tcp check)
Type: Simple check
Key: tcp,10050

note:
0 - the serivce on the port is down
1 - the service is running


Аналогично можно использовать
пардон, исправленно
net.tcp.service[service,<ip>,<port>]
в качестве service надо ставить tcp

service - one of ssh, service.ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp
ip - IP address (default is 127.0.0.1)
port - port number (by default standard service port number is used)

возвращает
0 - service is down
1 - service is running
2 - timeout connecting to the service

проверенно работает...

[sHaggY_caT]

Вы немного заблудились, дело в том что agent.ping это не то же самое что в привычном понимании icmp ping, это запрос к агенту и если он ответил утвердительно то значит пинг прошёл, а если Вам не откликается порт то это не значит что проверка не прошла, просто Вы не получили данных по этой проверке и она будет отложена.

А зачем она вообще тогда нужна, если она никогда не может вернуть однозначный результат, а вместо нее предлагается использовать суррогат (nodata)?

Пинг агента на стороне сервера с гарантией возврата результата:

note:
0 - the serivce on the port is down
1 - the service is running


Аналогично можно использовать
пардон, исправленно
net.tcp.service[service,<ip>,<port>]
в качестве service надо ставить tcp


возвращает
0 - service is down
1 - service is running
2 - timeout connecting to the service

проверенно работает...

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

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

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

[costas]

А зачем она вообще тогда нужна, если она никогда не может вернуть однозначный результат, а вместо нее предлагается использовать суррогат (nodata)?

Я в свое время получил благодаря этой проверке (agent.ping) прядка 1000 SMS сообщений в одни руки, для себя и моих колег, и дело бы не закончилось потому что полетели сообщения о том что проблема решена, пришлось принудительно остановить отправку sms/e-mail/jabber и чистить очередь ручками, а потом ждать когда всё нормализуется и сервер перстанет спамить... теперь даже знать не хочу что она есть....

[sHaggY_caT]

Я в свое время получил благодаря этой проверке (agent.ping) прядка 1000 sms сообщений в одни руки,

Лол, у нас только 56 в две руки в виде sms, хотя тоже без уведомления о восстановлении
Почта это не страшно, и чистится, а вот оплаченные sms тогда почти закончились, плюс прервался спокойный мирный сон

для себя и моих колег, и дело бы не закончилось потому что полетели сообщения о том что проблема решена, пришлось принудительно остановить отправку sms/e-mail/jabber и чистить очередь ручками, а потом ждать когда всё нормализуется и сервер перстанет спамить... теперь даже знать не хочу что она есть....

Ну ясно, так у Вас теперь все работает хорошо?

[costas]

Лол, у нас только 56 в две руки в виде sms, хотя тоже без уведомления о восстановлении
Почта это не страшно, и чистится, а вот оплаченные sms тогда почти закончились, плюс прервался спокойный мирный сон

Ну ясно, так у Вас теперь все работает хорошо?

Пока не жалуемся

[evilman]

Использую заббикс около года. Пару недель назад начали хаотично срабатывать триггеры о не доступности агента. Прочитал данную ветку, начал копать в сторону производительности. Но, так не к чему не пришел.

Количество узлов сети (под наблюдением/без наблюдения/шаблоны) - 152 77/5/70
Количество элементов данных (активных/деактивированых/не поддерживаются) - 2194 1669/525/0
Количество триггеров (активированных/деактивированных)[проблема/неизвестно/ок] - 616 615/1 [2/9/604]
Количество пользователей (подключенных в данный момент) - 9 4
Требуемое быстродействие сервера, новые значения в секунду 47.39

Сервер, обычный ПК (Pentium E6700, G41, 4Гб ОЗУ, 2x250Гб HDD SATAII). Работает под FreeBSD 8.3 (amd64, zfs mirror), mysql 5.5.15, zabbix 1.8.8.
Вывод top:

last pid: 39520;  load averages:  0.01,  0.02,  0.00                        up 6+21:59:27  09:48:13
87 processes:  1 running, 86 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.5% interrupt, 99.5% idle
Mem: 932M Active, 377M Inact, 2478M Wired, 2856K Cache, 125M Free
Swap: 2048M Total, 141M Used, 1907M Free, 6% Inuse

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

[dima_dm]

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

Используйте решение

http://blog.zabbix.com/monitoring-how-busy-zabbix-processes-are/457/

Чтобы найти каких процессов zabbix не хватает.

[evilman]

Используйте решение

http://blog.zabbix.com/monitoring-how-busy-zabbix-processes-are/457/

Чтобы найти каких процессов zabbix не хватает.

Спасибо, пытаюсь разобраться.