Я имел ввиду, стоимость коробки со всеми функциями.
Zabbix полностью бесплатный, но компании надо заработывать, они предлагаю доп.услуги по внедрению, разработки и поддержки.
Nagios и ELK разделает ветки, урезанный функционал бесплатно и со всеми интересными фитчами за денежку.
С nodata соглашусь, но count и diff должны получить значение, чтобы запустить расчет триггера.
nodata это страшная функция, мы ее стараемся не используем:
1) Она слишком тяжелая, для обработки
2) Если падает или тормозит прокся, то мы получаем ложное цунами с событиями о недоступности (триггер настроен — если нет данных, то говори, что не работает)
Мы знаем об этой проблеме, но никак ее исправить не можем, это внутренности логики Zabbix Server. Мы расцениваем ситуацию следующим образом, лучше иметь неактуальный value cache, чем иметь потерю сервиса мониторинга.
1. Спасибо, это наш первый опыт, учтем при выпуске следующего материала.
2. Есть продукты платные, есть условно-бесплатные (nagios), есть бесплатные (zabbix).
Мы команда разработки систем мониторинга и мы можем себе позволить постоянно переписывать код Zabbix (язык C) с выходом новой версии, но в большинстве случаев, у наших клиентов команда мониторинга не имеет разработчиков, которая может поддерживать свою ветку Zabbix.
Посмотрите на решения:
— Более сложный с patroni habr.com/ru/post/322036
— Стандартными инструментами postgres habr.com/ru/post/188096
Есть больше вариантов, надо отталкиваться от вашей задачи, но выше предложенные решения дадут Вам понимание, как можно реализовывать отказоустойчивость.
20 лет назад ни ZAbbix, ни PaceMaker не было :)
Поделитесь, какие решения вы используете?
P.S. Мы рассматриваем, только опенсоурс решения
P.S.S Выше пишут в комментарии, что 60к NVPS это слишком много, для потока данных в системе мониторинга
обработка проблем будет происходить без ошибок, т.к. на Zabbix Server, инициатором обработки событий являются новые данные. На второй ноде (резервной), прием данных не выполняется, он регулируется VIP или балансировщиком, смотря какую архитектуру вы выберете.
Отказоустойчивость БД — совсем другая история. Все внедренные нами системы мониторинга Zabbix базируются на POstgreSQL. У POstgres есть документация с описанием разных стратегий резервирования. Также на Хабр есть много статей с интересными решениями HA DB Postgres.
Почему велосипед? Это архитектура работает в продакшен инстансе.
Почему мы ее создали? Все просто, любая продакшен система должна иметь резервирование, а Zabbix из коробки ничего подобного не имеет. Вот мы решили за Zabbix это сделать. Согласен, если бы Zabbix это сделал, то это было бы более красивое решение. Но у нас правильно в команде, не трогать внутренности Zabbix, строить все вокруг Zabbix, чтобы каждый модуль был отдельным и не было больших проблем с миграцией на новую версию.
60к NVPS это не так много
Сухая арифметика. У нас есть объект с 30 метриками, собираем метрики раз в минуту — это, примерно, 0.5 NVPS. Итого, 60к NVPS это 120к объектов мониторинга. В реальной жизни количество метрик больше и интервалы сбора чаще.
Инфраструктура Сбера является одной из крупных в России, возможно, и в Европе.
Мы следим за потоком данных и постоянно его оптимизируем. Ничего лишнего в него нет. Перед внедрением пакета метрик, шаблон проходит многоэтапный анализ. Мы понимаем, что нужно быть аккуратными с двух сторон. С одной стороны, мы не должны нагрузить объект мониторинга, чтобы мониторинг не оказывал лишнюю нагрузку на бизнес приложение или на инфраструктурный сервис, а с другой стороны сбор/логика/экшен не должен оказывать лишней нагрузки на ядро системы мониторинга.
Согласны, мы попробовали разные системы мониторинга (вендорные, опенсоурсные), выбрали самую подходящую, универсальную, и самостоятельно заточили под требования.
Мы выбрали Zabbix по ряду основных причин:
1) самая лучшая система мониторинга с открытым исходным кодом и централизованным управлением объектов мониторинга
2) открытый исходный код и хорошо описанные протоколы взаимодействия позволяют создавать дополнительную функциональность без изменения ядра
Zabbix растет и приобретает дополнительные фичи очень активно. Любая система имеет свои недочеты, для разных организаций они разные, кому-то нужен Standby, а кому-то нет.
Вендорные системы, к сожалению, недостаточные гибкие и любая новая фитча стоит дополнительных денег и реализовывается очень долго.
Zabbix полностью бесплатный, но компании надо заработывать, они предлагаю доп.услуги по внедрению, разработки и поддержки.
Nagios и ELK разделает ветки, урезанный функционал бесплатно и со всеми интересными фитчами за денежку.
наверно, это не тема спора
изначальный комментарий, «почитал и понял что вернулся 20 лет назад»
любой продукт имеет свою историю и текущую зрелость. Мы выбирая решение опирались на критерии в данный момент, на актуальную версию
nodata это страшная функция, мы ее
стараемсяне используем:1) Она слишком тяжелая, для обработки
2) Если падает или тормозит прокся, то мы получаем ложное цунами с событиями о недоступности (триггер настроен — если нет данных, то говори, что не работает)
Мы знаем об этой проблеме, но никак ее исправить не можем, это внутренности логики Zabbix Server. Мы расцениваем ситуацию следующим образом, лучше иметь неактуальный value cache, чем иметь потерю сервиса мониторинга.
2. Есть продукты платные, есть условно-бесплатные (nagios), есть бесплатные (zabbix).
Мы команда разработки систем мониторинга и мы можем себе позволить постоянно переписывать код Zabbix (язык C) с выходом новой версии, но в большинстве случаев, у наших клиентов команда мониторинга не имеет разработчиков, которая может поддерживать свою ветку Zabbix.
— Более сложный с patroni habr.com/ru/post/322036
— Стандартными инструментами postgres habr.com/ru/post/188096
Есть больше вариантов, надо отталкиваться от вашей задачи, но выше предложенные решения дадут Вам понимание, как можно реализовывать отказоустойчивость.
Поделитесь, какие решения вы используете?
P.S. Мы рассматриваем, только опенсоурс решения
P.S.S Выше пишут в комментарии, что 60к NVPS это слишком много, для потока данных в системе мониторинга
Почему мы ее создали? Все просто, любая продакшен система должна иметь резервирование, а Zabbix из коробки ничего подобного не имеет. Вот мы решили за Zabbix это сделать. Согласен, если бы Zabbix это сделал, то это было бы более красивое решение. Но у нас правильно в команде, не трогать внутренности Zabbix, строить все вокруг Zabbix, чтобы каждый модуль был отдельным и не было больших проблем с миграцией на новую версию.
Сухая арифметика. У нас есть объект с 30 метриками, собираем метрики раз в минуту — это, примерно, 0.5 NVPS. Итого, 60к NVPS это 120к объектов мониторинга. В реальной жизни количество метрик больше и интервалы сбора чаще.
Мы следим за потоком данных и постоянно его оптимизируем. Ничего лишнего в него нет. Перед внедрением пакета метрик, шаблон проходит многоэтапный анализ. Мы понимаем, что нужно быть аккуратными с двух сторон. С одной стороны, мы не должны нагрузить объект мониторинга, чтобы мониторинг не оказывал лишнюю нагрузку на бизнес приложение или на инфраструктурный сервис, а с другой стороны сбор/логика/экшен не должен оказывать лишней нагрузки на ядро системы мониторинга.
1) самая лучшая система мониторинга с открытым исходным кодом и централизованным управлением объектов мониторинга
2) открытый исходный код и хорошо описанные протоколы взаимодействия позволяют создавать дополнительную функциональность без изменения ядра
Zabbix растет и приобретает дополнительные фичи очень активно. Любая система имеет свои недочеты, для разных организаций они разные, кому-то нужен Standby, а кому-то нет.
Вендорные системы, к сожалению, недостаточные гибкие и любая новая фитча стоит дополнительных денег и реализовывается очень долго.