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