Комментарии 41
Сколько же этих систем мониторинга существует — жуть.
Вот тут 51 насчитали.
Вот тут 51 насчитали.
Сравнивать клоны игрушечной системы типа Nagios не предназначенной для настоящей работы и Zabbix глупо. Zabbix — система мониторинга продакшен-левела, с сильной командой за ней, с платной поддержкой, с курсами, с собственными железными решениями с заббиксом на борту(до сих пор только в Японии вроде продающимся, правда) и нагиос написанный фриком для фрика и не способный работать больше чем с пятком серверов.
Использовал и то, и другое. О нагиосе вспоминаю, как о страшном сне. Хвала Владышеву и его команде, что есть Zabbix.
Использовал и то, и другое. О нагиосе вспоминаю, как о страшном сне. Хвала Владышеву и его команде, что есть Zabbix.
нагиос написанный фриком для фрика и не способный работать больше чем с пятком серверовЧтобы писать о Nagios такое, надо либо ничего про него не знать, либо быть обиженным неосилятором. В любом из этих двух случаев, лучше взять себя в руки и промолчать.
Знаете, какая штука, вы еще учились в школе, а я уже админил *nix-like системы. Вот я до сих пор админю, а вы до сих пор не выросли из школьного уровня.
Я использовал нагиос около пяти лет, так что я могу очень хорошо судить об этой поделке. Извините, но поделие в котором для добавления адреса алерта нужно править конфиги на сервере, а не сказать секретарю «Добавь там в веб-морде» не имеет право на существование. И это я молчу про все остальное.
Лучше молчите, чем говорите глупости. Я понимаю, что вы админите свой локалхост и там этой глючной поделки хватает за глаза и уши, но однажды родители перестанут вас кормить и вам придется пойти работать, а там нагиос использовать не выйдет.
Я использовал нагиос около пяти лет, так что я могу очень хорошо судить об этой поделке. Извините, но поделие в котором для добавления адреса алерта нужно править конфиги на сервере, а не сказать секретарю «Добавь там в веб-морде» не имеет право на существование. И это я молчу про все остальное.
Лучше молчите, чем говорите глупости. Я понимаю, что вы админите свой локалхост и там этой глючной поделки хватает за глаза и уши, но однажды родители перестанут вас кормить и вам придется пойти работать, а там нагиос использовать не выйдет.
нужно править конфиги на сервере, а не сказать секретарю «Добавь там в веб-морде»Сколько хостов можно добавить с помощью веб-морды? 10, 50, 100? Веб-морда как раз более ассоциируется с «пятком серверов». Когда нужно связать CMDB с сотней хостов и систему мониторинга, то в первую очередь думаешь об автоматически генерящихся конфигах или API, а в последнюю — о добавлении объектов через веб.
И у заббикса есть API, а у Нагиоса нет. Как-то неудачно вышло с вашей защитой этой поделки.
Ничего не имею против Zabbix. Четыре года не испытывал проблем с конфигами Nagios. Сейчас использую Icinga, с apply… where массовое управление стало ещё удобнее, а потребности что-то конфигурять из веба так и не возникло.
Изначально вы пытались оскорблять меня защищая глючную поделку под названием Nagios. Я понимаю, что делать это вас заставляет подростковый комплекс неполноценности, ведь вы же на локалхосте его используете, а тут кто-то посмел о нем сказать правду. Или вы уже забыли, что делали несколько комментов назад?
Изначально вы пытались оскорбить разработчиков и пользователей Nagios. Если отбросить желчный неконструктив, то останется одна претензия — отсутствие настройки из веба. Вот мне и интересно, в каких случаях на масштабах больше «пятка серверов» может остро понадобиться такая настройка.
Я могу выложить тут список на сотню пунктов претензий к этой детской поделке. Только это смысла не имеет.
Поймите вы, что это поделие используют только мамкины какиры на своих локалхостах. Оно не работает в продакшене. Как только вы начнете админить хотя бы один реальный сервер вы забудете о нагиосе и поделиях на его основе.
Поймите вы, что это поделие используют только мамкины какиры на своих локалхостах. Оно не работает в продакшене. Как только вы начнете админить хотя бы один реальный сервер вы забудете о нагиосе и поделиях на его основе.
Знаете… Я вот тоже начинал с нагиоса. И один из критериев моего выбора тогда был — правка конфигов, а не внесение хостов через веб-морду. Тогда я к заббиксу относился на «так себе» как раз, потому что думал, что запарюсь его настраивать через веб морду. Да и любитель консоли я, а не мышки. Но когда серверов перевалило за 30, я задумался…
Вспомнил про заббикс, прочитал документацию и понял, что эта система на много гибче и лучше нагиоса. После настройки я не добавляю хосты совсем, заббикс их сам обнаруживает и добавляет, автоматически настраивает необходимые элементы данных (что мониторим) и триггеры, автоматически обнаруживает новые диски, интерфейсы и т.п., автоматически обнаруживает виртуальные машины на гипервизорах и начинает отслеживание их состояния и много чего другого.
Все, что нужно было сделать — это один раз настроить/создать несколько шаблонов и низкоуровневое обнаружение. Все! Дальше заббикс самостоятельно обнаруживает и начинает мониторить все, что мне необходимо. И все это сделано средствами самого заббикса, без каких-либо вспомогательных инструментов.
Вспомнил про заббикс, прочитал документацию и понял, что эта система на много гибче и лучше нагиоса. После настройки я не добавляю хосты совсем, заббикс их сам обнаруживает и добавляет, автоматически настраивает необходимые элементы данных (что мониторим) и триггеры, автоматически обнаруживает новые диски, интерфейсы и т.п., автоматически обнаруживает виртуальные машины на гипервизорах и начинает отслеживание их состояния и много чего другого.
Все, что нужно было сделать — это один раз настроить/создать несколько шаблонов и низкоуровневое обнаружение. Все! Дальше заббикс самостоятельно обнаруживает и начинает мониторить все, что мне необходимо. И все это сделано средствами самого заббикса, без каких-либо вспомогательных инструментов.
Какой апи и конфиги? Качайте вот это и подключайте хоть миллион машин к заббиксу с одной команды. Заходить на вебморду при этом не придётся.
У Zabbix как минимум 4 варианта добавления хостов.
1) Ручками через веб (по одному)
2) XML файлом через веб (пачками)
3) API (пачками)
4) LLD (пачками)
1) Ручками через веб (по одному)
2) XML файлом через веб (пачками)
3) API (пачками)
4) LLD (пачками)
Кажется вы чего-то не знаете про нагиос — это давно уже система энтерпрайз-класса и она в принципе платная, то что доступно в опен сорс вообще не сравнимо с их готовым решением
Также есть замечательный плагин для связи Zabbix и Grafana — grafana-zabbix, который позволяет реализовать дополнительные дашборды, алерты и прочее, комбинация классического интерфейса Zabbix и Grafana помогает, когда надо наблюдать много параметров(вроде как в классическом интерфейсе Zabbix еще нет возможности на один график наложить несколько метрик сразу от нескольких узлов?) и в том числе визуализировать проблемы производительности какой либо системы.
Это если говорить про плюсы…
Про минусы — до сих пор нельзя сделать нормальную выгрузку событий, которые не умещаются на одной странице… экспортируется в CSV стабильно первая страница. Приходится извращаться с API и прямой выгрузкой из базы.
Это если говорить про плюсы…
Про минусы — до сих пор нельзя сделать нормальную выгрузку событий, которые не умещаются на одной странице… экспортируется в CSV стабильно первая страница. Приходится извращаться с API и прямой выгрузкой из базы.
У всех опенсорсных решений, с которыми я сталкивался, есть общая беда — нельзя одним продуктом покрыть все задачи мониторинга.
У Nagios-подобных не хватает статусов (critical/warning/ok недостаточно для кластеров).
У Zabbix не хватает возможности вывести подробное описание ошибки (mysql не работает, потому что: connection refused, connection timed out, no route to host, проблемы с dns или сам mysqld себя плохо чувствует?). Хотя здесь могу быть не прав — работал с Zabbix редко.
В обоих системах нельзя красиво реализовать уведомления на страшные вещи, наподобие «Пришел OOM Killer и всех убил».
В итоге использую связку Sensu + InfluxDB (grafana, telegraf) + Graylog (rsyslog), все уведомления от которых прилетают в alerta. С такой связкой у эксплуатации есть оперативный мониторинг с правильными приоритетами и максимумом информации, у разработчиков есть доступ к логам приложения с поиском, у тестировщиков есть APM c разрешением в 10 секунд.
У Nagios-подобных не хватает статусов (critical/warning/ok недостаточно для кластеров).
У Zabbix не хватает возможности вывести подробное описание ошибки (mysql не работает, потому что: connection refused, connection timed out, no route to host, проблемы с dns или сам mysqld себя плохо чувствует?). Хотя здесь могу быть не прав — работал с Zabbix редко.
В обоих системах нельзя красиво реализовать уведомления на страшные вещи, наподобие «Пришел OOM Killer и всех убил».
В итоге использую связку Sensu + InfluxDB (grafana, telegraf) + Graylog (rsyslog), все уведомления от которых прилетают в alerta. С такой связкой у эксплуатации есть оперативный мониторинг с правильными приоритетами и максимумом информации, у разработчиков есть доступ к логам приложения с поиском, у тестировщиков есть APM c разрешением в 10 секунд.
Угу, вот и приходится собирать мониторинг из 5 разных продуктов.
Подробного описания ошибок Zabbix действительно не хватает. Ситуация улучшается, но всё равно для диагностики проблем самой системы мониторинга нужно иметь довольно большой объём знаний — много нюансов, и сообщения об ошибках дают только необходимый минимум информации.
По моему опыту, можно обходится и одной системой, если дописывать свои обвязки к ней. У нас возле Zabbix крутится порядка двадцати разных скриптов и есть штук шесть-восемь патчей к коду (большинство опубликовано в zabbix-patches и в соответствующих ZBX- и ZBXNEXT-), я ещё подумаю, и, скорее всего, напишу о них отдельную запись — пока непонятно, будет ли это полезно\интересно сообществу.
У нас аналогично крутятся обвязки для sensu, по API скармливающие результаты проверок.
Если нужен только инфраструктурный мониторинг и базовый APM — тогда Zabbix может и подойти. Если же нужно с сотни серверов собирать 100-200 метрик с разрешением в 10 секунд и потом собирать данные в один dashboard — заббиксу с большой вероятностью станет плохо. InfluxDB такую нагрузку даже не замечает.
Если нужно собирать логи с серверов и делать поиск по ним — опять же, нужна еще одна система.
Опять же, для APM нужно вывести breakdown вида «10 самых тяжелых запросов в базу», плюс по statsd получать метрики самого приложения.
Если нужен только инфраструктурный мониторинг и базовый APM — тогда Zabbix может и подойти. Если же нужно с сотни серверов собирать 100-200 метрик с разрешением в 10 секунд и потом собирать данные в один dashboard — заббиксу с большой вероятностью станет плохо. InfluxDB такую нагрузку даже не замечает.
Если нужно собирать логи с серверов и делать поиск по ним — опять же, нужна еще одна система.
Опять же, для APM нужно вывести breakdown вида «10 самых тяжелых запросов в базу», плюс по statsd получать метрики самого приложения.
Для метрик есть Graphite, мы делим мониторинг и метрики, поскольку метрик очень много. В системе мониторинга есть только то, что важно (то есть то, по чему есть триггеры).
Я пока не видел живых систем, где всё пишется в метрики и мониторинг смотрит ровно туда же, куда и люди — думаю, это интересный подход, хотя и не без своих недостатков.
Вот, то есть у вас уже минимум две системы для мониторинга :)
> Я пока не видел живых систем, где всё пишется в метрики и мониторинг смотрит ровно туда же, куда и люди
Я примерно такой подход реализую — в Sensu напрямую заводятся только те проверки, в которых nagios хорош: отпинать порт; проверить код ответа http; подключиться к БД; проверить, что на хосте нормально собираются метрики (запущены все агенты); плюс пара критичных проверок CPU/LA (на случай, если telegraf по какой-либо причине упадет).
Остальные метрики попадают в InfluxDB, дальше отдельная проверка делает select метрик и по API отправляет статусы (а-ля external check в nagios).
Из плюсов — не обязательно, чтобы на машине стоял агент sensu, достаточно отправлять метрики; можно делать довольно сложные запросы к метрикам (influxdb умеет по абсолютным значениям высчитывать изменение и количество операций в секунду); плюс метрики не собираются два раза.
Из минусов — для полноценного мониторинга надо два агента на сервере — telegraf и sensu, плюс rsyslog.
> Я пока не видел живых систем, где всё пишется в метрики и мониторинг смотрит ровно туда же, куда и люди
Я примерно такой подход реализую — в Sensu напрямую заводятся только те проверки, в которых nagios хорош: отпинать порт; проверить код ответа http; подключиться к БД; проверить, что на хосте нормально собираются метрики (запущены все агенты); плюс пара критичных проверок CPU/LA (на случай, если telegraf по какой-либо причине упадет).
Остальные метрики попадают в InfluxDB, дальше отдельная проверка делает select метрик и по API отправляет статусы (а-ля external check в nagios).
Из плюсов — не обязательно, чтобы на машине стоял агент sensu, достаточно отправлять метрики; можно делать довольно сложные запросы к метрикам (influxdb умеет по абсолютным значениям высчитывать изменение и количество операций в секунду); плюс метрики не собираются два раза.
Из минусов — для полноценного мониторинга надо два агента на сервере — telegraf и sensu, плюс rsyslog.
Как каждый из этих сервисов выглядит в контексте #monitoringsucks, упомянутого в этой статье?
Не знаю. Я всегда думал, что проблемы с плохим мониторингом — не технические, хорошему мониторингу мешает плохое видение, а не ограничения или архитектура системы. Конечно, если вы не используете Nagios.
Что у Zabbix, что у Nagios-подобных есть большие ограничения в плане архитектуры :)
Zabbix хочет, чтобы результат проверки был числом (и хочет иметь локальную копию этого числа), Nagios же хочет видеть exit code 0-3.
У Enterprise таких ограничений нет — в них системы генерируют Event-ы с произвольным текстом и метаданными. Под капотом может быть как проверка числовых метрик (Zabbix-like), так и проверка статуса (Nagios-like), так и единичные события, полученные из логов (Out of memory: kill process XXXX).
Более того, такой подход позволяет делать корреляцию событий, идеальная система может сразу искать root cause: «Сервис поиска выдает ответ более чем за 5 секунд, потому что одна VM лежит (гипервизор упал — нет питания), а вторая виртуалка упирается в I/O (на гипервизоре ребилдится raid)»
Zabbix хочет, чтобы результат проверки был числом (и хочет иметь локальную копию этого числа), Nagios же хочет видеть exit code 0-3.
У Enterprise таких ограничений нет — в них системы генерируют Event-ы с произвольным текстом и метаданными. Под капотом может быть как проверка числовых метрик (Zabbix-like), так и проверка статуса (Nagios-like), так и единичные события, полученные из логов (Out of memory: kill process XXXX).
Более того, такой подход позволяет делать корреляцию событий, идеальная система может сразу искать root cause: «Сервис поиска выдает ответ более чем за 5 секунд, потому что одна VM лежит (гипервизор упал — нет питания), а вторая виртуалка упирается в I/O (на гипервизоре ребилдится raid)»
Zabbix может хранить какие угодно значения и делать очень продвинутые условия срабатывания, в случае с OOM killer — парсится dmegs на предмет сообщений об OOM, любые новые записи в моём случае поднимают триггер (и в сообщении приходят строки, которые увидел мониторинг на момент срабатывания триггера).
Другое дело, что OOM — очень плохой алерт, он говорит о проблеме с тысячей возможных причин, но это скорее тема для упомянутого #monitoringsucks.
Корреляция событий также возможна и в Zabbix, отличить "просел disk IO" от "просел disk IO из-за перестройки raid" можно, однако это никакая не магия — тебе нужно знать, чем одно событие отличается от другого, и соответствующим образом настроить триггеры. Насколько я понимаю, абсолютно везде делается так же, серебряной пули не существует — все системы требует вдумчивой настройки и продолжительной подгонки для нормальной работы.
> Другое дело, что OOM — очень плохой алерт, он говорит о проблеме с тысячей возможных причин, но это скорее тема для упомянутого #monitoringsucks.
Здесь соглашусь, если в случае OOM пришел один alert (и он про OOM) — надо допиливать мониторинг.
Я его привожу в качестве примера event-а который пуляется один раз и висит в консоли независимо от метрик/проверок.
> Корреляция событий также возможна и в Zabbix.
Насколько я помню, там довольно базовая корреляция в рамках одной ноды. Если можно делать связь гипервизор — вм, то это уже хорошо. У enterprise строится граф зависимостей между узлами в системе.
Здесь соглашусь, если в случае OOM пришел один alert (и он про OOM) — надо допиливать мониторинг.
Я его привожу в качестве примера event-а который пуляется один раз и висит в консоли независимо от метрик/проверок.
> Корреляция событий также возможна и в Zabbix.
Насколько я помню, там довольно базовая корреляция в рамках одной ноды. Если можно делать связь гипервизор — вм, то это уже хорошо. У enterprise строится граф зависимостей между узлами в системе.
Ну Ok, а что по поводу DevOps? Мне, например, кажется, что Zabbix API (других способов вроде нет) слишком сложен для постоянного изменения и деливери настроек мониторинга. Мне приходится выписывать вот такие кренделя каждый раз, когда мне что-то надо:
не перебор? нужно жить системой мониторинга, чтобы в ней быстро ориентироваться и что-то менять. В Nagios это проще, но там свои проблемы тоже есть.
for node_type in node_types_list:
groups_list = zapi.hostgroup.get(
{
"output": "extend",
"filter": {"name": [node_type]}
})
groupid = next(item for item in groups_list if item["name"] == node_type).get('groupid')
templates_list = zapi.template.get({"output": "extend"})
templateid = next(item for item in templates_list if item["name"] == 'Template_Fides_{}'.format(node_type)).get('templateid')
try:
zapi.action.create(
{
"name": "Auto registration {}".format(node_type),
# https://www.zabbix.com/documentation/3.2/manual/api/reference/event/object#event
"eventsource": 2, # 2 - event created by active agent auto-registration
"status": 0,
"esc_period": 120,
"def_shortdata": "Auto registration: {HOST.HOST}",
"def_longdata": "Host name: {HOST.HOST}\r\nHost IP: {HOST.IP}\r\nAgent port: {HOST.PORT}\r\n",
"filter": {
"evaltype": 0,
"conditions": [
{
# https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
"conditiontype": 22, # 22 - host name.
"operator": 2, # 2 - like
"value": node_type
}
]
},
"operations": [
{
# https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
"operationtype": 0, # 0 - send message
"esc_period": 0,
"esc_step_from": 1,
"esc_step_to": 2,
"evaltype": 0,
"opmessage_grp": [
{
"usrgrpid": "7" # Group 7 is Zabbix Admins
}
],
"opmessage": {
"default_msg": 1,
"mediatypeid": "1"
}
},
{
# https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
"operationtype": 2, # 2 - add host
"evaltype": 0,
},
{
# https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
"operationtype": 4, # 4 - add to host group
"evaltype": 0,
"opgroup": [
{
"operationid": 1,
"groupid": groupid,
}
]
},
{
# https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object#action_operation_condition
"operationtype": 6, # 6 - link to template
"optemplate": [
{
"operationid": 0,
"templateid": templateid,
},
],
},
]
},
)
tools.log('Action for {} has been imported to Zabbix.'.format(node_type))
except ZabbixAPIException as e:
tools.error(e)
не перебор? нужно жить системой мониторинга, чтобы в ней быстро ориентироваться и что-то менять. В Nagios это проще, но там свои проблемы тоже есть.
не смог отредактировать комментарий. Дополню: обратите внимание, что я подписываю каждое значение, чтобы не ковыряться в документации каждый раз. И это еще только импорт экшенов. А есть еще десятки других сущностей. Я все же считаю, что мониторинг должен служить человеку, а не человек мониторингу. Потому что читая местные комменты я вижу глубокий уровень понимания мониторинга. И именно это меня пугает. Люди явно намучались с этим вместо того, чтобы писать свои основные приложения.
С sensu/nagios очень просто добавлять мониторинг через систему управления конфигурациями, причем это делается в том же месте, где устанавливается нужный компонент: Пример для Postgres на puppet, примерно то же самое можно и через ansible/salt stack делать.
С Zabbix сложнее, но вроде бы есть puppet-модуль, который умеет лезть в API Zabbix и добавлять нужные сущности.
С Zabbix сложнее, но вроде бы есть puppet-модуль, который умеет лезть в API Zabbix и добавлять нужные сущности.
Puppet тут не причем. Он мне даст возможность сделать это на тысячах Zabbix'ов. Но на каждом из тысячи я встречусь именно с этой же проблемой. Потому что проблема не дуплицировать изменения, а автоматизировать. Соответственно, всё равно, чтобы добавить какую-то сущность, я должен каждый раз лезть в документацию к Zabbix API и вспоминать какой код что значит и какие параметры он принимает в каждом конкретном случае.
> Puppet тут не причем. Он мне даст возможность сделать это на тысячах Zabbix'ов.
Здесь вы не правы. Puppet даст возможность сконфигурировать один Zabbix-мастер на основании информации с тысячи агентов — для этого есть:
Вот документация по exported resources, один из предполагаемых use-кейсов — настроить сервер мониторинга.
> Соответственно, всё равно, чтобы добавить какую-то сущность, я должен каждый раз лезть в документацию к Zabbix API
Для этого есть модули puppet, которые абстрагируют вызовы API в понятные ресурсы.
Здесь вы не правы. Puppet даст возможность сконфигурировать один Zabbix-мастер на основании информации с тысячи агентов — для этого есть:
- В puppet — exported resources
- В salt stack — salt mine
- В ansible — delegation
Вот документация по exported resources, один из предполагаемых use-кейсов — настроить сервер мониторинга.
> Соответственно, всё равно, чтобы добавить какую-то сущность, я должен каждый раз лезть в документацию к Zabbix API
Для этого есть модули puppet, которые абстрагируют вызовы API в понятные ресурсы.
С экспортированными ресурсами в puppet будет примерно такой flow (предположим, что модуль умеет такое делать):
На сервере с агентом:
На сервере Zabbix:
На сервере с агентом:
@@zabbix_action { 'Auto registration ..'
...
}
На сервере Zabbix:
Zabbix_action <<| |>>
Спасибо. Попробую.
На всякий случай напишу для будущих поколений: это всё костыли, данная система может ломаться, и, скорее всего, будет ломаться в странных местах — Zabbix очень плохо подготовлен к такому использованию, вдобавок ко всему при таком тяжёлом использовании API отдельно встаёт вопрос производительности.
По поводу глубины знаний: я подозреваю, что многие участники дискуссии занимаются только и только мониторингом (и соответствующими частями ITIL), альтернатива этому не разработка основного приложения (это не в нашей зоне ответственности), а внедрение практик SRE.
> На всякий случай напишу для будущих поколений: это всё костыли, данная система может ломаться, и, скорее всего, будет ломаться в странных местах — Zabbix очень плохо подготовлен к такому использованию
Я не вижу никакого смысла отказываться от управления чем-либо в обход puppet. Если action должны оказаться в zabbix — лучше пусть это будет заливаться централизованно, заббиксу ничего не станет от сотни вызовов API раз в час.
> По поводу глубины знаний: я подозреваю, что многие участники дискуссии занимаются только и только мониторингом (и соответствующими частями ITIL)
В современных командах человек, который занимается только мониторингом — слишком большая роскошь. Да и ни к чему хорошему это не приводит — для того, чтобы поставить приложение на мониторинг, нужно уметь его поднимать и укладывать руками.
Я не вижу никакого смысла отказываться от управления чем-либо в обход puppet. Если action должны оказаться в zabbix — лучше пусть это будет заливаться централизованно, заббиксу ничего не станет от сотни вызовов API раз в час.
> По поводу глубины знаний: я подозреваю, что многие участники дискуссии занимаются только и только мониторингом (и соответствующими частями ITIL)
В современных командах человек, который занимается только мониторингом — слишком большая роскошь. Да и ни к чему хорошему это не приводит — для того, чтобы поставить приложение на мониторинг, нужно уметь его поднимать и укладывать руками.
Пользовался icinga2.
Удобно добавлять удалять сервера и сервисы.
Из минусов хочу отметить:
1. веб-интерфейс очень плохо оптимизирован и зачастую кладёт базу. Может быть уже и исправили.
2. активные коммиты — хорошо, но иногда приводят к сегфолтам, что несколько неприятно.
Удобно добавлять удалять сервера и сервисы.
Из минусов хочу отметить:
1. веб-интерфейс очень плохо оптимизирован и зачастую кладёт базу. Может быть уже и исправили.
2. активные коммиты — хорошо, но иногда приводят к сегфолтам, что несколько неприятно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение систем мониторинга: Shinken vs Sensu vs Icinga 2 vs Zabbix