В зеносс не отвалится, потому что плагины у моделера более-менее независимы и не ломают сосдение плагины. А вот вложенные шаблоны — вполне могут друг-друга: поправили что-то вверху иерархии, а внизу его либо нет, либо оно должно подчиняться другим правилам.
А я — вижу. В зеносс это решается намного элегантнее: он сам находит существующие разделы и сам начинает их мониторить (ну находит с помощью моделера, естественно)
И я не думаю что zennoss может предложить что-то лучше в этом случае.
В принципе — может. Но это несколько хитрее, чем я описал выше. В этом случае моделер не лепит шаблоны на устройства, а создаёт несколько более сложное описание устройства: добавляет в него компоненты, с которыми связаны определённые правила мониторинга. Описать это сходу я не смогу, буду сильно врать ;) Так что пока вам придётся мне поверить, что это намного удобнее иерархии шаблонов.
Я тут задумался, что могу несколько не то понимать под «конфигурацией системы». Ну да ладно…
Простота конфигурации обеспечивается за счёт роста сложности того, что обеспечивает эту конфигурацию. Тот же моделер может становится сложнее. Состав zenpack'ов увеличиваться. Но сложности работы с текущей конфигурацией это не добавляет: добавили устройство — отмоделили — получили рабочий мониторинг. И такого что «поменяли шаблон тут, а отвалилось там» тоже не бывает.
Хотя создать иерархию с переопределением различных параметров, от которых зависит мониторинг, — можно. Но лучше этого не делать.
В zenoss достаточно сложная процедура обработки получаемых данных.
Я немного неправильно выразился: процедура обработки данных достаточно простая. Потом события сложно обрабатываются. Основная логика в обработке событий.
Вот у меня есть данные они поступили. Что с ними можно сделать кроме создать событие при 80%?
Можно просто сконфигурировать условие возникновения определённого события. Собрали данные, если они соответствуют определённому условию — создали событие (или события).
Ну можно ещё на график нанести, если это нужно. Но это не для всех данных актуально.
Поправьте меня, если я тут неправ:
Шаблон изначально включает в себя фиксированное количество разделов. Их имена жёстко заданы (хотя, как я писал, можно получить 1 имя из 1 переменной). Если я добавляю раздел, то мне нужно создавать новый шаблон и линковать его к старому, либо править старый.
А кроме того, хорошо бы следить, чтобы на сервере где нет раздела его не пытались мониторить, иначе меня завалит предупреждениями.
К примеру 200 одинаковых свитчей
А если у вас 200 «чуть разных» свичей? Предположим, 6-7 разных типов (ядро, дистрибуция, доступа, последних — зоопарк из-за разного времени покупки). Вам делать 6-7 разных шаблонов? Или иерархию вложенных шаблоннов, где всё равно 6-7 конечных, используемых шаблонов с описанием «особенностей».
В зеносс сложность конфигурации не зависит от уровня детализации. Хотя сама система, безусловно, станет сложнее. Но эта сложность не мешает каждодневной работе.
ёжики
treshold — базовая вещь. Он говорит системе о том, что наступило какое-либо событие. Событие можно классифицировать по важности, например. Или по некоторым другим параметрам.
В зависимости от сочетания важности и других параметров события (или событий) можно выполнить «действие». Чаще всего, это оповещение, но можно любое другое действие (в заббиксе тоже можно, я в курсе).
Так, например, я могу иметь «warning» на 80% занятости и «critical error» на 90% занятости одного и того же тома. В первом случае система просто покажет событие, во втором — пришлёт ещё и e-mail.
В zenoss достаточно сложная процедура обработки получаемых данных. Но она удачно скрывается за дефолтными настройками первое время.
Как составить шаблон для нескольких таких разделов? 1 шаблон — 1 раздел, я правильно понимаю? Или всё таки есть возможность в 1 шаблоне мониторить сразу кучу разделов?
Завожу еще один источник данных, на тот же параметр добавлю активацию события на 60% и дальше его использую так?
нет, просто добавляете treshold на тот же источник данных. Ещё один «источник данных» добавлять смысла нет.
Под счетчиком подразумевается item. Это наиболее близкий аналог в русском языке. По сути дела в zabbix не собираются события. Собираются данные, а уже потом в триггере эти самые данные преобразуются в события,
То есть фразу:
В случае zabbix событие генерируется в зависимости от полученных данных и не привязано к конкретному счетчику
надо читать как:
В случае zabbix событие генерируется в зависимости от полученных данных и не привязано к конкретным данным
Это идентификатор ораклового инстанса. На хосте может быть несколько инстансов для одной или нескольких баз. В подобных каталогах можно хранить что-либо для упрощения восстановления этих инстансов.
То что можно получить список инстансов скриптиком — я в курсе. Но не факт, что для каждого из них будет эта папка.
Я помню. У меня уже были иерархии в духе: линукс-хттп-нгикс-фронт1. И рядом «фронт2». Хорошие были такие иерархии… Где-то после 15ой ветви этих деревьев я сломался. Но шаблоны могут быть вложенными, не спорю.
Вероятно, можно составить достаточно сложный набор правил или достаточно сложный шаблон, чтобы реализовать все нужные правила.
Можно ли изменять настройки уже обнаруженных устройств так же? Или механизм работает только для новонайденных?
Идентификаторы можно задавать через набор встроенных переменных у инстанса. Тут можно посмотреть какие доступны
Идентификатор задаётся вне системы мониторинга. Нужно просто добавить этот раздел в список наблюдаемых.
ну и тут ещё такой момент, вы не совсем понимаете, что я работал с заббиксом и понимаю зачем нужны data item'ы и чем они отличаются от trigger'ов. (Что ещё за «счётчики»?!).
В случае zenoss этим абстракциям есть вполне адекватная замена: события и оповещения.
Событие — «канал 1 занят на 80%», «канал 2 занят на 80%»
Оповещение — «события »..." и "..." активны последние 5 минут".
Бизнес логика больше в правилах оповещения, а не возникновения событий.
А этот кусок кода LSIArray.py на питоне зачем? В случае же zabbix шаблон автоматизировано тоже можно повесить.
Этот кусок кода объясняет моделеру, что если он нашёл такой-то oid, то нужно навесить такой-то шаблон. Шаблон можно повесить и руками, без моделера.
Про автоматизация «повески» шаблонов в заббиксе я не слышал. Как именно это делается? Чего почитать?
Что тут есть sid?
идентификатор инстанса. Не суть важно для данного примера. Пусть будет любая фиксированная строка: «abc1», например.
На всякий случай: добавление разделов в zenoss требует «перемоделить» сервер (делается автоматом раз в сутки или по команде пользователя). После этого новый раздел будет обнаружен и на него повесят нужные параметры мониторинга. Никакого «управления через шаблоны» и прочей мороки.
Вот задать отдельный уровень, при котором нужно слать оповещение, для каждого из разделов — задача хитрее. Но тоже делается красиво, через переменные в настройках групп или хостов (или там и там с логичными переопределениями значений).
Кстати говоря, в zabbix'е так же можно создать шаблон для мониторинга файловой системы, чьё имя задано переменной в шаблоне группе или где-либо ещё. Это несколько упрощает конфигурирование: шаблон 1, а значение переменных для серверов — разные. Одним шаблоном можно замониторить все сервера с одним «недефолтным» разделом.
Но в подобные переменные нельзя вписывать массивы значений, что очень раздражает. Да и создание этих шаблонов так же излишне кропотливо, на мой взгляд.
… дальше создаете триггер и пишете выражение с указанием при каких значениях счетчиков триггер должен срабатывать. Дальше создаете событие которое делает что-то при активации триггера.
Всё тоже самое я описал выше. Лезть в питон это не требует. В zenoss это просто создание шаблона мониторинга. Текст выше — про автоматизацию навешивания шаблона на устройства.
Суммировать значения счетчиков в триггере шаблона можно.
Про суммирование — не понял. Зачем оно тут? Мы можем создать триггер вокруг процентного показателя занятости раздела.
… удаления добавления рулятся из шаблона. Не вижу никаких проблем. Описанный функционал там существует давненько.
Не могли бы вы подробнее описать: я сделал отдельный раздел на сервере под /u01/backup/${SID}. Как и что нужно поменять в шаблоне для этого?
Если я на всех серверах добавил раздел под /var/spool/mail, сколько шаблонов мне придётся исправить?
А вот по возможностям это сейчас лучший открытый мониторинг. Особенно когда имеется много snmp оборудования и требуется что-то не тривиальное.
С этим я спорить не готов, так как объективной метрики не вижу ;) Если можно, договорим за мониторинг разделов, а потом обсудим «хорошесть».
Вы не могли бы написать, в двух словах, как в заббиксе реализовать то, что я описал выше? В смысле, как бы вы мониторили дисковые массивы на LSI контроллерах в zabbix'е.
Кроме того, вот хороший вопрос по заббиксу:
Предположим, у меня есть 5 групп серверов. На каждом из них есть отдельные разделы под /, /home, /var/log, /boot, /etc. Плюс, по 5-7 разделов специфичных для каждой из групп серверов (где-то /var/db, где-то /u0{1,2,3} и так далее).
Вопрос: какой простейший способ мониторить свободное место на всех разделах, которые есть на сервере? Какие действия надо предпринять при добавлении и удалении разделов?
Возможно, в заббиксе что-то изменили. Но последнее моё общение с ним закончилось лёгким раздражением: можно всё, но всё через задницу (чисто субъективно, сами понимаете).
Ок, я чую, я вас всё равно не переубежу. Используйте заббикс. В нём можно создавать очень сложные триггеры.
А я — вижу. В зеносс это решается намного элегантнее: он сам находит существующие разделы и сам начинает их мониторить (ну находит с помощью моделера, естественно)
В принципе — может. Но это несколько хитрее, чем я описал выше. В этом случае моделер не лепит шаблоны на устройства, а создаёт несколько более сложное описание устройства: добавляет в него компоненты, с которыми связаны определённые правила мониторинга. Описать это сходу я не смогу, буду сильно врать ;) Так что пока вам придётся мне поверить, что это намного удобнее иерархии шаблонов.
Простота конфигурации обеспечивается за счёт роста сложности того, что обеспечивает эту конфигурацию. Тот же моделер может становится сложнее. Состав zenpack'ов увеличиваться. Но сложности работы с текущей конфигурацией это не добавляет: добавили устройство — отмоделили — получили рабочий мониторинг. И такого что «поменяли шаблон тут, а отвалилось там» тоже не бывает.
Хотя создать иерархию с переопределением различных параметров, от которых зависит мониторинг, — можно. Но лучше этого не делать.
Я немного неправильно выразился: процедура обработки данных достаточно простая. Потом события сложно обрабатываются. Основная логика в обработке событий.
Можно просто сконфигурировать условие возникновения определённого события. Собрали данные, если они соответствуют определённому условию — создали событие (или события).
Ну можно ещё на график нанести, если это нужно. Но это не для всех данных актуально.
А что ещё вы хотите делать с исходными данными?
Шаблон изначально включает в себя фиксированное количество разделов. Их имена жёстко заданы (хотя, как я писал, можно получить 1 имя из 1 переменной). Если я добавляю раздел, то мне нужно создавать новый шаблон и линковать его к старому, либо править старый.
А кроме того, хорошо бы следить, чтобы на сервере где нет раздела его не пытались мониторить, иначе меня завалит предупреждениями.
А если у вас 200 «чуть разных» свичей? Предположим, 6-7 разных типов (ядро, дистрибуция, доступа, последних — зоопарк из-за разного времени покупки). Вам делать 6-7 разных шаблонов? Или иерархию вложенных шаблоннов, где всё равно 6-7 конечных, используемых шаблонов с описанием «особенностей».
ёжикиtreshold — базовая вещь. Он говорит системе о том, что наступило какое-либо событие. Событие можно классифицировать по важности, например. Или по некоторым другим параметрам.
В зависимости от сочетания важности и других параметров события (или событий) можно выполнить «действие». Чаще всего, это оповещение, но можно любое другое действие (в заббиксе тоже можно, я в курсе).
Так, например, я могу иметь «warning» на 80% занятости и «critical error» на 90% занятости одного и того же тома. В первом случае система просто покажет событие, во втором — пришлёт ещё и e-mail.
В zenoss достаточно сложная процедура обработки получаемых данных. Но она удачно скрывается за дефолтными настройками первое время.
нет, просто добавляете treshold на тот же источник данных. Ещё один «источник данных» добавлять смысла нет.
То есть фразу:
надо читать как:
я правильно понял?
То что можно получить список инстансов скриптиком — я в курсе. Но не факт, что для каждого из них будет эта папка.
Я помню. У меня уже были иерархии в духе: линукс-хттп-нгикс-фронт1. И рядом «фронт2». Хорошие были такие иерархии… Где-то после 15ой ветви этих деревьев я сломался. Но шаблоны могут быть вложенными, не спорю.
То вы конфигурируете событие о занятости канала на 60% и, если нужно, оповещение об этом событии.
Этого тоже не понял. Всё-таки что за «счётчики» вам лучше пояснить, видимо.
Вероятно, можно составить достаточно сложный набор правил или достаточно сложный шаблон, чтобы реализовать все нужные правила.
Можно ли изменять настройки уже обнаруженных устройств так же? Или механизм работает только для новонайденных?
Идентификатор задаётся вне системы мониторинга. Нужно просто добавить этот раздел в список наблюдаемых.
В случае zenoss этим абстракциям есть вполне адекватная замена: события и оповещения.
Событие — «канал 1 занят на 80%», «канал 2 занят на 80%»
Оповещение — «события »..." и "..." активны последние 5 минут".
Бизнес логика больше в правилах оповещения, а не возникновения событий.
Этот кусок кода объясняет моделеру, что если он нашёл такой-то oid, то нужно навесить такой-то шаблон. Шаблон можно повесить и руками, без моделера.
Про автоматизация «повески» шаблонов в заббиксе я не слышал. Как именно это делается? Чего почитать?
идентификатор инстанса. Не суть важно для данного примера. Пусть будет любая фиксированная строка: «abc1», например.
Вот задать отдельный уровень, при котором нужно слать оповещение, для каждого из разделов — задача хитрее. Но тоже делается красиво, через переменные в настройках групп или хостов (или там и там с логичными переопределениями значений).
Кстати говоря, в zabbix'е так же можно создать шаблон для мониторинга файловой системы, чьё имя задано переменной в шаблоне группе или где-либо ещё. Это несколько упрощает конфигурирование: шаблон 1, а значение переменных для серверов — разные. Одним шаблоном можно замониторить все сервера с одним «недефолтным» разделом.
Но в подобные переменные нельзя вписывать массивы значений, что очень раздражает. Да и создание этих шаблонов так же излишне кропотливо, на мой взгляд.
Всё тоже самое я описал выше. Лезть в питон это не требует. В zenoss это просто создание шаблона мониторинга. Текст выше — про автоматизацию навешивания шаблона на устройства.
Про суммирование — не понял. Зачем оно тут? Мы можем создать триггер вокруг процентного показателя занятости раздела.
Не могли бы вы подробнее описать: я сделал отдельный раздел на сервере под /u01/backup/${SID}. Как и что нужно поменять в шаблоне для этого?
Если я на всех серверах добавил раздел под /var/spool/mail, сколько шаблонов мне придётся исправить?
С этим я спорить не готов, так как объективной метрики не вижу ;) Если можно, договорим за мониторинг разделов, а потом обсудим «хорошесть».
Кроме того, вот хороший вопрос по заббиксу:
Предположим, у меня есть 5 групп серверов. На каждом из них есть отдельные разделы под /, /home, /var/log, /boot, /etc. Плюс, по 5-7 разделов специфичных для каждой из групп серверов (где-то /var/db, где-то /u0{1,2,3} и так далее).
Вопрос: какой простейший способ мониторить свободное место на всех разделах, которые есть на сервере? Какие действия надо предпринять при добавлении и удалении разделов?
Возможно, в заббиксе что-то изменили. Но последнее моё общение с ним закончилось лёгким раздражением: можно всё, но всё через задницу (чисто субъективно, сами понимаете).