Ad Widget

**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)}<{STOPB ACK}

{Template_linux_general:agent.ping.nodata(120)}=1 & {Template_linux_general:agent.ping.time(0)} < {STARTBACK} & {Template_linux_general:agent.ping.time(0)}>{STOPB ACK}

Но подход, какой-то, имхо, кривой

а если 480 секунд не хватит, или заббикс будет тормозить не во время бэкапа?

**costas** · 24-05-2010, 10:36

Если мне не изменяет память то nodata() имеет отношение только к активной проверке и итем который проверяется должен иметь тип "Zabbix trapper", поэтому в обычном режиме nodata() может вести себя не так как Вы ожидаете..

**dima_dm** · 24-05-2010, 11:19

Originally posted by costas

Если мне не изменяет память то nodata() имеет отношение только к активной проверке и итем который проверяется должен иметь тип "Zabbix trapper", поэтому в обычном режиме nodata() может вести себя не так как Вы ожидаете..

Это не так. Функция nodata() срабатывает, если нет новых данных за заданный интервал времени. У меня она работает и на Zabbix Agent и на SNMP проверках.

**sHaggY_caT** · 24-05-2010, 11:46

Спасибо за ответы,

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

**noname** · 24-05-2010, 11:58

Та же самая проблема. Пока не думал на эту тему, как улучшить, но был бы благодарен за удобное решение.

**costas** · 24-05-2010, 16:08

Originally posted by shaggy_cat

Спасибо за ответы,

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

А у Вас какого типа СУБД и какого типа бэкапы?

**sHaggY_caT** · 24-05-2010, 16:23

Originally posted by costas

А у Вас какого типа СУБД и какого типа бэкапы?

MySQL innodb, lvm-снапшот, Zabbix сервер в OpenVZ контейнере (тормозит, понятно, когда бэкапится все вместе, сам бы Zabbix бэкапился быстрее, если бы был один).

Тут речь о другом: любая внешняя, к Zabbix-серверу проблема, делает использование nodata неудобным, а подобных альтернатив я не знаю:

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

Пока вижу решение проблемы, написать свою реализацию agent.ping через UserParametr, или попросить разработчиков сделать так, что бы nodata что-то выдавала, что бы можно было принимать решение в триггере на основе agent.ping.last(0)

**costas** · 24-05-2010, 17:08

Originally posted by sHaggY_caT

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

Originally posted by costas

Думаю простои сервера мониторинга связанные с бэкапами - это основная проблема.

Но концептуально, согласитесь, не единственный вариант этой проблемы.

Originally posted by costas

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

Естественно, нужны данные(а не только мониторинг доступности), иначе мы бы использовали, например, Nagios.

Originally posted by costas

Если Вы хотите таки бэкапить данные то можно реализовать например Online non-blocking backup для СУБД MySQL без падения производительности и отдельно конфигурацию самого сервера (любыми средствами: bash, bacula, amanda, etc..). Для переноса бекапов на внешнее хранилище использовать второй интерфейс, если оного нет то обзавестись таким, всё сводится к минимизации нагрузки во время бэкапа и получения бэкапа с которого можно будет развернуть копию.

У нас не так много собственного железа, тем более подходящего под требования Zabbix.
Поэтому Zabbix живет в OVZ контейнере, и, в целом, чувствует себя там достаточно хорошо.

Отменить бэкап OpenVZ сервера нельзя, так как там куча других критичных сервисов. Собственно, мы можем решить проблему влоб, купив/арендовав более мощное железо, но концептуально проблема с ложными срабатываниями, когда у Zabbix-сервера растет очередь (а причин может быть много, например, сетевые проблемы) никуда не денется.

Originally posted by costas

Вы хотите избавиться от ложных срабатываний средствами системы мониторинга в то время как сама система у Вас работает с перебоями, ИХМО это не правильный подход.

Конечно, неправильный...

Originally posted by costas

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

Мне кажется, лучше всего убедить разработчиков, что это _проблема_ и идея с nodata изначально порочная, и попросить исправить это.

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

**ugh** · 24-05-2010, 19:18

реплики бд мб?)

**sHaggY_caT** · 24-05-2010, 19:25

Originally posted by ugh

реплики бд мб?)

Да мы же не можем не бэкапить "хост-систему"(хотя обычно это называют HardwareNode, пишу, что бы было понятнее), так как там есть и другие, кроме Zabbix, сервисы, в других соседних контейнерах.

Выделять под Zabbix отдельную железку(особенно сервер, а не "сервер" без ECC памяти), банально жалко денег, тем более, что все остальное время дисковой производительности всегда хватает и с большим избытком, и iowait крутится около нуля. Мы могли бы использовать его в виртуалке с dm-ioband драйвером под KVM-гипервизором, с жесткими лимитами на ввод-вывод, что бы и свои iops получил, и соседям не мешал, и работал бы всегда с одинаковой скоростью, но, увы, на этой железке SATA-зеркало со всеми вытекающими (Zabbix вообще нормально работать не сможет, или увеличивать интервалы проверок, что не хочется)

Сейчас ложных срабатываний, с увеличенными интервалами во время бэкапа, нет, но 50-60 SMS за короткое время, это слишком, даже если это только угроза.

Но не об этом речь, повторюсь, считаю концепцию того, что агент ничего не пишет в базу при неудачном соединении концептуально неверной.
Если бы проверка agent.ping.last(0) выдавала осмысленный код при недоступности, его можно было бы использовать в триггере независимо от наличия очереди на Zabbix сервере, которая может возникнуть по сотне причин.

Имхо, единственный некривой метод решения проблемы, исправление логики работы agent.ping, так как дописывать функционал для Zabbix через какой-нибудь скрипт мне кажется концептуально неправильным.

**ugh** · 24-05-2010, 19:39

незнаю, сложно как-то у вас все
вот например я - в терзаниях - как бэкапить все свои 100-200-300 гигов history_uint

**sHaggY_caT** · 24-05-2010, 19:46

Originally posted by ugh

незнаю, сложно как-то у вас все
вот например я - в терзаниях - как бэкапить все свои 100-200-300 гигов history_uit

IT-Аутсорс, стартап, поэтому проблемы со своим железом и рентабельностью, а клиентских железок куча, и будет, надеюсь, еще больше.

В общем-то, все в OpenVZ хорошо, и по cpu, и по памяти, если нормально настроено, никогда нет проблем, да и диск хорошо шедулится, пока iops хватает, но когда их становится катастрофически мало, cfq начинает глупить, и выдавать всем VE слишком мало iops(хотя это, прежде всего, проблема lvm снапшотов)

У Вас, наверное, с железом чуть по-проще, как и с бюджетом, может для такого лучше СХД? И снапшот с lun заббикс-сервера?

============================

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

**costas** · 25-05-2010, 05:53

Originally posted by sHaggY_caT

Но не об этом речь, повторюсь, считаю концепцию того, что агент ничего не пишет в базу при неудачном соединении концептуально неверной.
Если бы проверка agent.ping.last(0) выдавала осмысленный код при недоступности, его можно было бы использовать в триггере независимо от наличия очереди на Zabbix сервере, которая может возникнуть по сотне причин.

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

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

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

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

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

.. а если нет, есть повод идти к начальству с докладом о предстоящих расходах

Ad Widget

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment