Comments 9
Есть штатный механизм отключения оповещения: Maintenance
С его помощью не получится отключить конкретный триггер, но это, за частую, и не нужно.
С его помощью не получится отключить конкретный триггер, но это, за частую, и не нужно.
Мне кажется, автор некорректно сформулировал название заголовка и тем самым породил неверное восприятие.
Maintenance нужен для полного отключения триггеров, но не на период бэкапа или иных штатных действий, а на период отключения сервисов, т.е. нештатных (хотя и запланированных) работ.
Для бэкапов же правильнее было бы сделать отдельные триггеры (или задавать значения через макросы), которые будут работать только во время бэкапа.
Maintenance нужен для полного отключения триггеров, но не на период бэкапа или иных штатных действий, а на период отключения сервисов, т.е. нештатных (хотя и запланированных) работ.
Для бэкапов же правильнее было бы сделать отдельные триггеры (или задавать значения через макросы), которые будут работать только во время бэкапа.
Только им и пользуюсь. Проще в настройке.
Если мешают лишние уведомления, то лучше всё-таки выключать оповещения (Actions), а не триггеры. У меня так сделано. Менеджерам не приходят ночные уведомления, так как там постоянная нагрузка из-за расчетов, а мне как админу уведомления идут 24 часа в сутки. Если менеджер захочет ночью посмотреть нагрузку то он это делает через веб-интерфейс. А выключать триггеры я считаю немного опасно, можно пропустить реальную проблему.
Вот так это сделано у меня:
Вот так это сделано у меня:
Это совершенно разные функции для совершенно разных целей. Отключение экшенов нужно для группировки по различным видам ответственности (неайтишный сотрудник, дежурный сисадмин, программист, дневной сисадмин, и т.п.), на каждом из которых нужны различные группы оповещений в различные интервалы времени. Т.е. мы задаём что-то типа: «то, что между сервером А и Б в 2 часа ночи попёрло 600 мегабит трафика — это не нормально и возможно сигнализирует об аварии, но дневному менеджеру от этого можно и не просыпаться, пусть спит дальше».
А автор рассказывает именно о настройке, задающей «то, что между сервером А и Б в 2 часа ночи каждую среду прёт 600 мегабит трафика — это совершенно нормально, прогнозируемо, и никакой аварии в этом заключаться не может, потому что это льются бекапы». Такое можно реализовать либо мейнтенансом (если все пошатывания более-менее сгруппированы по времени), либо задачей дополнительных условий в самих триггерах.
А автор рассказывает именно о настройке, задающей «то, что между сервером А и Б в 2 часа ночи каждую среду прёт 600 мегабит трафика — это совершенно нормально, прогнозируемо, и никакой аварии в этом заключаться не может, потому что это льются бекапы». Такое можно реализовать либо мейнтенансом (если все пошатывания более-менее сгруппированы по времени), либо задачей дополнительных условий в самих триггерах.
Настраивал так еще давно и при такой же настройке возникла проблема, когда выражение тригера переходит в состояние «ОК» из-за того, что не выполняется условие по времени. Хотя проблема остается. Решается изменением выражения восстановления, где нужно просто убрать привязку ко времени.
Меня, честно говоря, удивляет способность людей написать статью на ровном месте.
Ни в коем случае не в укор автору, скорее укор себе. Я бы эту статью уложил в фразу «В Zabbix есть „Периоды обслуживания.“ :)
Я прочел, что не про maintenance, но тем не менее.
Я еще отлично помню статью про то, что в OpenVPN есть опция multihome.
Ни в коем случае не в укор автору, скорее укор себе. Я бы эту статью уложил в фразу «В Zabbix есть „Периоды обслуживания.“ :)
Я прочел, что не про maintenance, но тем не менее.
Я еще отлично помню статью про то, что в OpenVPN есть опция multihome.
Есть дефолтные шаблоны, в которых действительно удобно вставлять макросами какие то не уникальные для хоста данные, но вот время бекапов таким же способом делать увы не получается. Слишком много работы по настройке получается.
Если у нас собственный бекап сервер, то у него есть определённое количество ресурсов и запускать бекапы одновременно всего вы физически не сможете так как исчерпаете их(скорость сети и дисков). Поэтому для триггеров на статусы слейвов при бекапе в одно время на одном сервере, в другое на другом и вы никак это не автоматизируете без кода который по апи из бекап сервиса забирает данные и помещает их по апи в заббикс. А такой код будет жёстко завязан на конкретные продукты и расширить его или опубликовать будет не целесообразно.
У нас старт бекапов бд делаются не в конкретное время, а в некотором диапазоне когда освободятся ресурсы и длительность их зависит от типа бекапа, инкремент или полный. Соответственно макросы должны меняться динамически и для каждого триггера должны быть уникальны, что без автоматизации напрочь убивает все инсинуации аналогичные вашим. И это верно не только для текущей компании в которой я работаю.
Если у нас собственный бекап сервер, то у него есть определённое количество ресурсов и запускать бекапы одновременно всего вы физически не сможете так как исчерпаете их(скорость сети и дисков). Поэтому для триггеров на статусы слейвов при бекапе в одно время на одном сервере, в другое на другом и вы никак это не автоматизируете без кода который по апи из бекап сервиса забирает данные и помещает их по апи в заббикс. А такой код будет жёстко завязан на конкретные продукты и расширить его или опубликовать будет не целесообразно.
У нас старт бекапов бд делаются не в конкретное время, а в некотором диапазоне когда освободятся ресурсы и длительность их зависит от типа бекапа, инкремент или полный. Соответственно макросы должны меняться динамически и для каждого триггера должны быть уникальны, что без автоматизации напрочь убивает все инсинуации аналогичные вашим. И это верно не только для текущей компании в которой я работаю.
Sign up to leave a comment.
Отключаем тригеры в ZABBIX по расписанию