View Full Version : agent.ping.nodata,как быть при тормозах Zabbix?
sHaggY_caT
20-05-2010, 22:16
Задала так же вопрос:
http://www.zabbix.org/forum/showthread.php?t=17130
Этот вопрос (множественные срабатывания из-за тормозов Zabbix-сервера) не имеют отношения к ложным срабатываниям из-за проблем сети, про который та тема, поэтому решила двумя разными темами.
Если проверяем доступность хостов по agent.ping.nodata, и, например, Zabbix-сервер бэкапится, или что еще с ним происходит, что снижает его производительность, резко возрастает вероятность того, что у Zabbix образуется очередь, и пойдут множественные ложные срабатывания host down.
Решение, которое несколько раз встречается на форуме (нашла поиском) такого вида:
{HOSTNAME:agent.ping.last(0)}#1&{HOSTNAME:agent.ping.nodata(300)}=1
Не работает(по крайней мере в восьмой ветке), так как в документации так и написано, что agent.ping ничего не возращает, если хост не доступен (а жаль). Лучше бы agent.ping возвращал что-то осмысленное, что и попадало бы в БД при недоступности хоста.
Это было бы, конечно, лучшее решение проблемы. Обходной вариант, с чеком по ICMP хостов не подходит, так как иногда сознательно режем ICMP пакеты на наши хосты.
Как лучше решить проблему? Не давать срабатывать триггеру во время бэкапа Zabbix-сервера? А если клиентский хост правда в это время упадет? Ведь бэкап делается часто совсем не быстро, особенно нулевой.
Мониторить очередь на Zabbix-сервере? Кажется, уже теплее, но хотелось бы мониторить очередь только по этому хосту, так как иначе, при тормозах Zabbix, опять же, пропустим событие падения хоста.
sHaggY_caT
20-05-2010, 22:36
Временно решила проблему двумя разными триггерами в стиле:
{Template_linux_general:agent.ping.nodata(480)}=1 & {Template_linux_general:agent.ping.time(0)} > {STARTBACK} & {Template_linux_general:agent.ping.time(0)}<{STOPBACK}
{Template_linux_general:agent.ping.nodata(120)}=1 & {Template_linux_general:agent.ping.time(0)} < {STARTBACK} & {Template_linux_general:agent.ping.time(0)}>{STOPBACK}
Но подход, какой-то, имхо, кривой :( а если 480 секунд не хватит, или заббикс будет тормозить не во время бэкапа?
Если мне не изменяет память то nodata() имеет отношение только к активной проверке и итем который проверяется должен иметь тип "Zabbix trapper", поэтому в обычном режиме nodata() может вести себя не так как Вы ожидаете..
Если мне не изменяет память то nodata() имеет отношение только к активной проверке и итем который проверяется должен иметь тип "Zabbix trapper", поэтому в обычном режиме nodata() может вести себя не так как Вы ожидаете..
Это не так. Функция nodata() срабатывает, если нет новых данных за заданный интервал времени. У меня она работает и на Zabbix Agent и на SNMP проверках.
sHaggY_caT
24-05-2010, 11:46
Спасибо за ответы,
Может кто-нибудь посоветовать некривое решение проблемы?
У нас ситуации с приходом миллиона уведомлений во время бэкапа прекратились, но все равно остается их потенциальная возможность...
Та же самая проблема. Пока не думал на эту тему, как улучшить, но был бы благодарен за удобное решение.
Спасибо за ответы,
Может кто-нибудь посоветовать некривое решение проблемы?
У нас ситуации с приходом миллиона уведомлений во время бэкапа прекратились, но все равно остается их потенциальная возможность...
А у Вас какого типа СУБД и какого типа бэкапы?
sHaggY_caT
24-05-2010, 16:23
А у Вас какого типа СУБД и какого типа бэкапы?
MySQL innodb, lvm-снапшот, Zabbix сервер в OpenVZ контейнере (тормозит, понятно, когда бэкапится все вместе, сам бы Zabbix бэкапился быстрее, если бы был один).
Тут речь о другом: любая внешняя, к Zabbix-серверу проблема, делает использование nodata неудобным, а подобных альтернатив я не знаю:
а) ответ сервера по icmp вовсе не означает того, что он в порядке
б) проверять по сервисам? Тоже никаких гарантий, и универсального способа нет, так как серверы бывают с совсем разными сервисами
в) открывать icmp, особенно для некоторых машин, не хочется
Пока вижу решение проблемы, написать свою реализацию agent.ping через UserParametr, или попросить разработчиков сделать так, что бы nodata что-то выдавала, что бы можно было принимать решение в триггере на основе agent.ping.last(0)
MySQL innodb, lvm-снапшот, Zabbix сервер в OpenVZ контейнере (тормозит, понятно, когда бэкапится все вместе, сам бы Zabbix бэкапился быстрее, если бы был один).
Тут речь о другом: любая внешняя, к Zabbix-серверу проблема, делает использование nodata неудобным, а подобных альтернатив я не знаю:
а) ответ сервера по icmp вовсе не означает того, что он в порядке
б) проверять по сервисам? Тоже никаких гарантий, и универсального способа нет, так как серверы бывают с совсем разными сервисами
в) открывать icmp, особенно для некоторых машин, не хочется
Пока вижу решение проблемы, написать свою реализацию agent.ping через UserParametr, или попросить разработчиков сделать так, что бы nodata что-то выдавала, что бы можно было принимать решение в триггере на основе agent.ping.last(0)Думаю простои сервера мониторинга связанные с бэкапами - это основная проблема.
Какие цели Вы преследуете делая бэкап сервера и собственно на что работает Ваш сервер, на сбор статистики или же как система оповещений о сбоях тех или иных сервисов. Если бэкап нужен для развёртывания системы мониторинга в случае отказа последнего, то можно сократить издержки (вернее избавиться от отказов) и бэкапить только конфигурацию Вашего сервера минуя данные.
Если Вы хотите таки бэкапить данные то можно реализовать например Online non-blocking backup для СУБД MySQL без падения производительности и отдельно конфигурацию самого сервера (любыми средствами: bash, bacula, amanda, etc..). Для переноса бекапов на внешнее хранилище использовать второй интерфейс, если оного нет то обзавестись таким, всё сводится к минимизации нагрузки во время бэкапа и получения бэкапа с которого можно будет развернуть копию.
Вы хотите избавиться от ложных срабатываний средствами системы мониторинга в то время как сама система у Вас работает с перебоями, ИХМО это не правильный подход.
Вам проще выставить время сработки триггеров только в те часы когда у Вас не делается бэкап, но и в этом случаее такая система мониторинга не отвечает должным требованиям.
sHaggY_caT
24-05-2010, 18:30
Думаю простои сервера мониторинга связанные с бэкапами - это основная проблема.
Но концептуально, согласитесь, не единственный вариант этой проблемы.
Какие цели Вы преследуете делая бэкап сервера и собственно на что работает Ваш сервер, на сбор статистики или же как система оповещений о сбоях тех или иных сервисов. Если бэкап нужен для развёртывания системы мониторинга в случае отказа последнего, то можно сократить издержки (вернее избавиться от отказов) и бэкапить только конфигурацию Вашего сервера минуя данные.
Естественно, нужны данные(а не только мониторинг доступности), иначе мы бы использовали, например, Nagios.
Если Вы хотите таки бэкапить данные то можно реализовать например Online non-blocking backup для СУБД MySQL без падения производительности и отдельно конфигурацию самого сервера (любыми средствами: bash, bacula, amanda, etc..). Для переноса бекапов на внешнее хранилище использовать второй интерфейс, если оного нет то обзавестись таким, всё сводится к минимизации нагрузки во время бэкапа и получения бэкапа с которого можно будет развернуть копию.
У нас не так много собственного железа, тем более подходящего под требования Zabbix.
Поэтому Zabbix живет в OVZ контейнере, и, в целом, чувствует себя там достаточно хорошо.
Отменить бэкап OpenVZ сервера нельзя, так как там куча других критичных сервисов. Собственно, мы можем решить проблему влоб, купив/арендовав более мощное железо, но концептуально проблема с ложными срабатываниями, когда у Zabbix-сервера растет очередь (а причин может быть много, например, сетевые проблемы) никуда не денется.
Вы хотите избавиться от ложных срабатываний средствами системы мониторинга в то время как сама система у Вас работает с перебоями, ИХМО это не правильный подход.
Конечно, неправильный...
Вам проще выставить время сработки триггеров только в те часы когда у Вас не делается бэкап, но и в этом случаее такая система мониторинга не отвечает должным требованиям.
Мне кажется, лучше всего убедить разработчиков, что это _проблема_ и идея с nodata изначально порочная, и попросить исправить это.
В крайнем случае попробовать разобраться в коде, и протолкнуть патч в апстрим (мои патчи в других проектах уже брали, и, увы, не брали, поэтому кое-что мы уже вынужденно сопровождаем сами).
sHaggY_caT
24-05-2010, 19:25
реплики бд мб?)
Да мы же не можем не бэкапить "хост-систему"(хотя обычно это называют HardwareNode, пишу, что бы было понятнее), так как там есть и другие, кроме Zabbix, сервисы, в других соседних контейнерах.
Выделять под Zabbix отдельную железку(особенно сервер, а не "сервер" без ECC памяти), банально жалко денег, тем более, что все остальное время дисковой производительности всегда хватает и с большим избытком, и iowait крутится около нуля. Мы могли бы использовать его в виртуалке с dm-ioband драйвером под KVM-гипервизором, с жесткими лимитами на ввод-вывод, что бы и свои iops получил, и соседям не мешал, и работал бы всегда с одинаковой скоростью, но, увы, на этой железке SATA-зеркало со всеми вытекающими (Zabbix вообще нормально работать не сможет, или увеличивать интервалы проверок, что не хочется)
Сейчас ложных срабатываний, с увеличенными интервалами во время бэкапа, нет, но 50-60 SMS за короткое время, это слишком, даже если это только угроза.
Но не об этом речь, повторюсь, считаю концепцию того, что агент ничего не пишет в базу при неудачном соединении концептуально неверной.
Если бы проверка agent.ping.last(0) выдавала осмысленный код при недоступности, его можно было бы использовать в триггере независимо от наличия очереди на Zabbix сервере, которая может возникнуть по сотне причин.
Имхо, единственный некривой метод решения проблемы, исправление логики работы agent.ping, так как дописывать функционал для Zabbix через какой-нибудь скрипт мне кажется концептуально неправильным.
незнаю, сложно как-то у вас все
вот например я - в терзаниях - как бэкапить все свои 100-200-300 гигов history_uint
sHaggY_caT
24-05-2010, 19:46
незнаю, сложно как-то у вас все
вот например я - в терзаниях - как бэкапить все свои 100-200-300 гигов history_uit
IT-Аутсорс, стартап, поэтому проблемы со своим железом и рентабельностью, а клиентских железок куча, и будет, надеюсь, еще больше.
В общем-то, все в OpenVZ хорошо, и по cpu, и по памяти, если нормально настроено, никогда нет проблем, да и диск хорошо шедулится, пока iops хватает, но когда их становится катастрофически мало, cfq начинает глупить, и выдавать всем VE слишком мало iops(хотя это, прежде всего, проблема lvm снапшотов)
У Вас, наверное, с железом чуть по-проще, как и с бюджетом, может для такого лучше СХД? И снапшот с lun заббикс-сервера?
============================
Но повторюсь, имхо, наши железные проблемы, это десятое дело, а проблема в логике работы agent.ping: небольшая очередь команд, в течение получаса-часа в глухое время, я не вижу в этом ничего плохого, но я не понимаю, почему Zabbix не собирает информацию о недоступности хоста (даже просто с точки зрения логики agent.ping должен что-то возвращать и в проблемных случаях, иначе зачем он вообще нужен, как итем?)
Но не об этом речь, повторюсь, считаю концепцию того, что агент ничего не пишет в базу при неудачном соединении концептуально неверной.
Если бы проверка agent.ping.last(0) выдавала осмысленный код при недоступности, его можно было бы использовать в триггере независимо от наличия очереди на Zabbix сервере, которая может возникнуть по сотне причин.
Такой подход как раз является верным, потому как пишет в базу не агент а сервер, и если сервер не может досучаться до агента/сервиса то он откладывает попытки на некоторое время что видно из логов, по факту данные о состоянии агента/сервиса в базу не попадают сие и означает nodata и свидетельствует о том что есть проблемы с получением данных.
Ваш случай один на миллион, то что для Вас является неприемлимым и неудачной концепцией удовлетворяет современным требованиям систем монитринга, + необходимо выполнять условия запуска таких сервисов как система монитринга, и проблемы вызванные на сервере из-за бэкапов являются неприемлимыми.
У меня например на 1.6.7 версии дополнительно стоит проверка по tcp порту для zabbix агентов и соответвенно висит триггер о том что агент не доступен со всеми вытекающими последствиями.
Если Вы внимательно посмотрите на возможные проверки со стороны сервера (включая tcp) то найдёте решение для своей проблемы, но повторюсь, можете забыть о том что у вас будет информация о стотоянии сервисов/хостов на момент бэкапа и лечится это отнють не средствами zabbix.
З.Ы. Если компания в которой Вы работаете Ваша, то я Вам сочувстую:(.. а если нет, есть повод идти к начальству с докладом о предстоящих расходах ;)
sHaggY_caT
25-05-2010, 07:56
Такой подход как раз является верным, потому как пишет в базу не агент а сервер, и если сервер не может досучаться до агента/сервиса то он откладывает попытки на некоторое время что видно из логов, по факту данные о состоянии агента/сервиса в базу не попадают сие и означает nodata и свидетельствует о том что есть проблемы с получением данных.
Ваш случай один на миллион, то что для Вас является неприемлимым и неудачной концепцией удовлетворяет современным требованиям систем монитринга, + необходимо выполнять условия запуска таких сервисов как система монитринга, и проблемы вызванные на сервере из-за бэкапов являются неприемлимыми.
Не только у меня, у noname, например, тоже... Да и многие отказываются от Zabbix по причине проблем с производительностью (достаточно погуглить, что бы найти десятки примеров), но я считаю, что они поступают неверно, а нужно только дать возможность, при наличии очереди на Zabbix (может быть, как-то скоомбинировать с внутренними проверками?), реализовать эту логику немного по-другому, либо изменить поведение agent.ping.
Что делает agent.ping? По сути дела возвращает информацию о доступности хоста. То, что другие проверки молчат, либо временно отключаются по причине Zabbix_Not_supported, это правильно, но почему(!?) проверка доступности всегда возвращает одно значение?
Еще раз повторюсь, проблема дисковой производительности, это маленький частный случай. А если сеть? А если любая другая проблема с Zabbix-сервером? Почему мощнейшее, без преувеличения средство мониторинга _других_ объектов, не дает увязать мониторинг других объектов с собой?
Почему лишили возможности даже просто сделать выборку из истории agent.ping?
Зачем таким искусственным способом ограничен функционал?
У меня например на 1.6.7 версии дополнительно стоит проверка по tcp порту для zabbix агентов и соответвенно висит триггер о том что агент не доступен со всеми вытекающими последствиями.
Спасибо, я думала о таком варианте, но он не нравится, так как ответ сервера по одному порту все равно ничего не гарантирует, хотя, наверное, это единственный вариант.
Если Вы внимательно посмотрите на возможные проверки со стороны сервера (включая tcp) то найдёте решение для своей проблемы, но повторюсь, можете забыть о том что у вас будет информация о стотоянии сервисов/хостов на момент бэкапа и лечится это отнють не средствами zabbix.
Ответьте на вопрос сами себе: почему средство _мониторинга_ никогда не может ответить _четко_ средствами итемов (а не триггеров), был ли доступен хост, или нет? Имхо, это абсолютно ненормально.
З.Ы. Если компания в которой Вы работаете Ваша, то я Вам сочувстую:(.. а если нет, есть повод идти к начальству с докладом о предстоящих расходах ;)
Она наша с мужем, но это означает лишь то, что придется потратить кучу времени, разбираясь в исходниках, что бы заставить agent.ping что-то возвращать.
Было бы хорошо, если бы кто-то из разработчиков дал свой комментарий, пусть и негативный....
Спасибо, я думала о таком варианте, но он не нравится, так как ответ сервера по одному порту все равно ничего не гарантирует, хотя, наверное, это единственный вариант.
Он гарантирует что у Вас не будет данных и есть проблемы, Вы можете использовать несколько портов разный сервисов для комплексных тригеров, у нас например работа web-сервера проверяется по порту-процессу-времени отклика, увы но пока выбор не велик, либо смотреть в сторону других систем...
alex-rterm
25-05-2010, 08:36
Как agent.ping будет что-то возвращать, если узел, на котором установлен агент, недоступен?
Как agent.ping будет что-то возвращать, если узел, на котором установлен агент, недоступен?
именно...
agent.ping ничего не может возвращать потому что zabbix сервер не может получить коннект к агенту и проверка не выполняется, так было в версии 1.6.х, как в 1.8.х не знаю ибо исключил эту проверку.
sHaggY_caT
25-05-2010, 08:50
Как agent.ping будет что-то возвращать, если узел, на котором установлен агент, недоступен?
Не знаю, еще не смотрела, как в Zabbix это вообще устроено, и пока не представляю, на сколько сложно будет добавить такую обработку/хак в код. А что, Вы знаете, что это действительно не тривиально?
Он гарантирует что у Вас не будет данных и есть проблемы, Вы можете использовать несколько портов разный сервисов для комплексных тригеров, у нас например работа web-сервера проверяется по порту-процессу-времени отклика, увы но пока выбор не велик, либо смотреть в сторону других систем...
Но Вы согласны, что Было бы удобнее, если бы была возможность сделать так, что бы agent.ping возвращал что-то при недоступности агента?
Повторюсь, воспользоваться преимуществами OpenSource хорошо, но тянуть потом этот код из релиза в релиз, без шанса, что появится в апстриме, не приятно. У нас уже просто есть такие изменения, которые не брали в некоторые OSS проекты(хотя кое-что и брали)
alex-rterm
25-05-2010, 08:57
Не знаю, еще не смотрела, как в zabbix это вообще устроено, и пока не представляю, на сколько сложно будет добавить такую обработку/хак в код. А что, Вы знаете, что это действительно не тривиально?
Это будет не обработка и не хак, а костыль, причем очень кривой, на стороне сервера. Нарушается логика: агент недоступен, а данные от него приходят.
sHaggY_caT
25-05-2010, 09:09
Это будет не обработка и не хак, а костыль, причем очень кривой, на стороне сервера. Нарушается логика: агент недоступен, а данные от него приходят.
Но это удобно :) Мы всегда сможем дать однозначный ответ, был ли доступен agent в такую-то секунду времени в прошлом: в конце концов, agent.ping только этим и занимается, как итем. Почему для этого итема нужно делать исключение, делая его неполнофункциональным, сообразуясь с тем, что остальные итемы ничего не пишут, при отсуствии данных?
А еще, это решает проблему. Если кто-то знает, как решить проблему красиво, через мониторинг очередей Zabbix (причем для отдельного хоста), буду благодарна, если этот кто-то поделится.
Но это удобно :) Мы всегда сможем дать однозначный ответ, был ли доступен 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
25-05-2010, 12:12
Вы немного заблудились, дело в том что 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
проверенно работает...
Спасибо, я знала об этом способе, и поняла, что Вы имели ввиду именно его выше по переписке.
Наверное, это действительно самый лучший вариант из возможных, чем патчить Заббикс.
Возникают только опасения, связанные с тем, что как мне кажется, возможна ситуация, когда порт будет доступен, но сервис по-факту будет работать не верно из-за проблем на сервере-клиенте, но, наверное, этим можно пренебречь.
А зачем она вообще тогда нужна, если она никогда не может вернуть однозначный результат, а вместо нее предлагается использовать суррогат (nodata)?
Я в свое время получил благодаря этой проверке (agent.ping) прядка 1000 SMS сообщений в одни руки, для себя и моих колег, и дело бы не закончилось потому что полетели сообщения о том что проблема решена, пришлось принудительно остановить отправку sms/e-mail/jabber и чистить очередь ручками, а потом ждать когда всё нормализуется и сервер перстанет спамить... теперь даже знать не хочу что она есть.... :(
sHaggY_caT
25-05-2010, 12:53
Я в свое время получил благодаря этой проверке (agent.ping) прядка 1000 sms сообщений в одни руки,
Лол, у нас только 56 в две руки в виде sms, хотя тоже без уведомления о восстановлении :)
Почта это не страшно, и чистится, а вот оплаченные sms тогда почти закончились, плюс прервался спокойный мирный сон :)
для себя и моих колег, и дело бы не закончилось потому что полетели сообщения о том что проблема решена, пришлось принудительно остановить отправку sms/e-mail/jabber и чистить очередь ручками, а потом ждать когда всё нормализуется и сервер перстанет спамить... теперь даже знать не хочу что она есть.... :(
Ну ясно, так у Вас теперь все работает хорошо?
Лол, у нас только 56 в две руки в виде sms, хотя тоже без уведомления о восстановлении :)
Почта это не страшно, и чистится, а вот оплаченные sms тогда почти закончились, плюс прервался спокойный мирный сон :)
Ну ясно, так у Вас теперь все работает хорошо?
Пока не жалуемся ;)
Использую заббикс около года. Пару недель назад начали хаотично срабатывать триггеры о не доступности агента. Прочитал данную ветку, начал копать в сторону производительности. Но, так не к чему не пришел.
Количество узлов сети (под наблюдением/без наблюдения/шаблоны) - 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
Может есть какие нибудь идеи? Можно конечно выйти из положения способами изложенными в данном топике, но хотелось бы разобраться в чем дело...
Может есть какие нибудь идеи? Можно конечно выйти из положения способами изложенными в данном топике, но хотелось бы разобраться в чем дело...
Используйте решение
http://blog.zabbix.com/monitoring-how-busy-zabbix-processes-are/457/
Чтобы найти каких процессов zabbix не хватает.
Используйте решение
http://blog.zabbix.com/monitoring-how-busy-zabbix-processes-are/457/
Чтобы найти каких процессов zabbix не хватает.
Спасибо, пытаюсь разобраться.
Такие вот получились графики:
- Cache usage (http://radikal.ru/F/s019.radikal.ru/i625/1205/f2/d9f8fdab1fee.png.html)
- Internal process busy % (http://radikal.ru/F/s019.radikal.ru/i613/1205/c1/e32dba697a66.png.html)
- Data gathering process busy % (http://radikal.ru/F/s019.radikal.ru/i639/1205/90/fbae769411da.png.html)
Кажется все в норме, могут быть проблемы в сети?
Такие вот получились графики:
- Cache usage (http://radikal.ru/F/s019.radikal.ru/i625/1205/f2/d9f8fdab1fee.png.html)
- Internal process busy % (http://radikal.ru/F/s019.radikal.ru/i613/1205/c1/e32dba697a66.png.html)
- Data gathering process busy % (http://radikal.ru/F/s019.radikal.ru/i639/1205/90/fbae769411da.png.html)
Кажется все в норме, могут быть проблемы в сети?
Посмотрите Timeout-ы для zabbix_agent и zabbix_server
/etc/zabbix/zabbix_agentd.conf
Timeout=30
/etc/zabbix/zabbix_server.conf
### Option: Timeout
# Specifies how long we wait for agent, SNMP device or external check (in seconds).
#
# Mandatory: no
# Range: 1-30
# Default:
Timeout=30
И рестартовать zabbix_agent и zabbix_server
По умолчанию там 3 сек Timeout
P.S. Не забываете перезапускать zabbix_agentd и zabbix_server после каждого изменения конфигурации!!!!
не буду создавать новую тему и спрошу тут
Zabbix node watcher processes more than 75% busy
Zabbix icmp pinger processes more than 75% busy
точнее они 100%
и так постоянно, куда рыть?
Number of items (monitored/disabled/not supported) 1211 1077 / 102 / 32 - мелочи вроде
отвечу сам себе :)
за icmp pinger processes отвечает опция StartPingers=.. за вотчер пока не нашел :(
Спасибо, dima_dm, за советы. К сожалению ничего из предложенного не решило проблему. Буду пробовать пути решения, предложенные в начале топика.