Комментарии 44
А почему вы выбрали Zabbix, а не nagios? Он же ещё старее! (В то время, когда всё остальное комьюнити переходит на пром).
nagios хорош тем, что там value added сервисы в дашборде (особенно с чем-то вроде thruk'а). Но в вопросах мониторинга нагиос намертво застрял в host-парадигме, а уж про грустные вещи происходящие где-то в параметрах command даже говорить нечего (начинаем с абстракций, заканчиваем вопросом "как бы нам баша заэскейпить").
Для этих задач пром не очень заточен. При всей моей любви к прому.
1) самая лучшая система мониторинга с открытым исходным кодом и централизованным управлением объектов мониторинга
2) открытый исходный код и хорошо описанные протоколы взаимодействия позволяют создавать дополнительную функциональность без изменения ядра
Zabbix растет и приобретает дополнительные фичи очень активно. Любая система имеет свои недочеты, для разных организаций они разные, кому-то нужен Standby, а кому-то нет.
Вендорные системы, к сожалению, недостаточные гибкие и любая новая фитча стоит дополнительных денег и реализовывается очень долго.
1) самая лучшая система мониторинга с открытым исходным кодом и централизованным управлением объектов мониторинга
субъективщина
2) открытый исходный код и хорошо описанные протоколы взаимодействия позволяют создавать дополнительную функциональность без изменения ядра
аналогично есть и у конкурентов (TICK, Prometheus etc. — сотни их)
Вот только не надо TICK в пример ставить. Уж лучше нагиос, чем капаситор.
капаситор мне самому не очень нравится, если что )
А у инфлакса есть свои проблемы.
Из их стека мне реально только Telegraf нравится, но я знаю МНОЖЕСТВО внедрений TICK. И ничего — народ как-то живет и не особо страдает
Значит, они просто не тестируют свои конфигурации. Конфигурации kapacitor невозможно тестировать из-за скрытого неконтролируемого состояния нод. Телеграф — самый здравый продукт. С инфлюксом можно жить во многих ситуациях. kapacitor — обещает, но критически underdeliver, кто юзает chronograph, поднимите руку, так сказать. Т.е. из всего TICK остаётся T(i).
Я пытаюсь понять из вашего ответа, какой из вариантов (нагиос/пром) является "вендорной", и не очень понимаю.
Ну и решение очень субъективное, потому что у Заббикса в текущий момент репутация скажем так не лучшего решения на рынке.
2. Так это свойство всех более-менее взрослых решений. Впрочем что страшного в изменении кода? Мне кажется команда мониторинга в том числе и нужна для того чтоб допиливать выбранное решение под изменения задач и нагрузок, которые будут проходить.
2. Есть продукты платные, есть условно-бесплатные (nagios), есть бесплатные (zabbix).
Мы команда разработки систем мониторинга и мы можем себе позволить постоянно переписывать код Zabbix (язык C) с выходом новой версии, но в большинстве случаев, у наших клиентов команда мониторинга не имеет разработчиков, которая может поддерживать свою ветку Zabbix.
есть бесплатные (zabbix).
заббикс бесплатен? Я не уверен, что корректно так называть ) Потому что сами разработчики предлагают платные услуги пруф
Т.е. он может быть бесплатен с точки зрения отсутствия прямых лицензионных отчислений на его использование, но с точки зрения ТСО его эксплуатации — он точно ни разу не бесплатен (как минимум в кадры, которые будут с ним работать — надо вкладываться)
Zabbix полностью бесплатный, но компании надо заработывать, они предлагаю доп.услуги по внедрению, разработки и поддержки.
Nagios и ELK разделает ветки, урезанный функционал бесплатно и со всеми интересными фитчами за денежку.
2. Для систем мониторинга это нормально держать в компании одну команду, которая пилит систему для нужд всех, а всем остальным дает либо готовые рецепты как поднять, либо просто централизованную точку входа, полностью скрывая что там в ядре творится.
Я бы хотел сначала просто поделиться впечатлением, потому что статья честно говоря оставляет чувство полного нежелания инженеров что-либо рассказывать или писать и боль копирайтера от переписывания оригинала, прям воображение рисует картину:
- ну мы эта, прикинули и сделали две ноды и в разные дц что б ежиль один того то оно все норм там еще влан между дц растянули и hsrp там и ежиль че сразу скриптик там переключает.
И вот мы картинки для утверждения проекта рисовали, тоже добавь.
Так не пойдет, сейчас я сама, пиши:
- проанализировав ситуацию, команда мониторинга пришла к решению, что поможет кластеризация по принципу Active-Active. Кроме того, была поставлена цель добиться Disaster Recovery путем переноса на разные ЦОДы.
Вы уж извините, но у меня сложилось такое впечатление :)
Нашел пример для NVPS в 60к и заббикса.
~66k 72 x Intel® Xeon® Platinum 8124M CPU @ 3.00GHz; AWS EC2 c5.18xlarge
Интересно, что вам пишет на 60к в секунду? Вы все банкоматы на этот заббикс повесили? Интересно было бы прочитать как о причинах так и о процессе выборе решения, что рассматривали, можно ли было уменьшить поток данных, может вы собираете много не нужного? Оптимизации? Как сравнивали? Или просто — мы умеем в заббикс, все прикрутим к нему? Я к тому, что это случаем не та ситуация, когда у вас есть молоток, то все вокруг превращается в гвозди? Я собственно не про прометеус упомянутый выше, а в целом, есть же разные решения?
Полностью согласен. Ребята построили очередной велосипед из заббикса. Ну, и про отказоустойчивость БД ничего не рассказали, хотя это тоже очень интересная тема
Ваши предложения — как строить отказоустойчивый заббикс, если под капотом постгрес?
— Более сложный с patroni habr.com/ru/post/322036
— Стандартными инструментами postgres habr.com/ru/post/188096
Есть больше вариантов, надо отталкиваться от вашей задачи, но выше предложенные решения дадут Вам понимание, как можно реализовывать отказоустойчивость.
Почему мы ее создали? Все просто, любая продакшен система должна иметь резервирование, а Zabbix из коробки ничего подобного не имеет. Вот мы решили за Zabbix это сделать. Согласен, если бы Zabbix это сделал, то это было бы более красивое решение. Но у нас правильно в команде, не трогать внутренности Zabbix, строить все вокруг Zabbix, чтобы каждый модуль был отдельным и не было больших проблем с миграцией на новую версию.
Мы следим за потоком данных и постоянно его оптимизируем. Ничего лишнего в него нет. Перед внедрением пакета метрик, шаблон проходит многоэтапный анализ. Мы понимаем, что нужно быть аккуратными с двух сторон. С одной стороны, мы не должны нагрузить объект мониторинга, чтобы мониторинг не оказывал лишнюю нагрузку на бизнес приложение или на инфраструктурный сервис, а с другой стороны сбор/логика/экшен не должен оказывать лишней нагрузки на ядро системы мониторинга.
Сухая арифметика. У нас есть объект с 30 метриками, собираем метрики раз в минуту — это, примерно, 0.5 NVPS. Итого, 60к NVPS это 120к объектов мониторинга. В реальной жизни количество метрик больше и интервалы сбора чаще.
Это ещё что, вот обработка евентов на якобы второй ноде, будет выполняться с ошибками. Я бы посмотрел на дебаг лог их стендбай нод, вот где все косяки этих "специалистов" сразу всплывут.
Могу предположить, что для триггеров, содержащих функции nodata, count, diff и некоторые другие, переход ноды StandBy в состояние Active приведет к труднопредсказуемым событиям (причина — неактуальность value cache на ноде StandBy).
nodata это страшная функция, мы ее
1) Она слишком тяжелая, для обработки
2) Если падает или тормозит прокся, то мы получаем ложное цунами с событиями о недоступности (триггер настроен — если нет данных, то говори, что не работает)
Мы знаем об этой проблеме, но никак ее исправить не можем, это внутренности логики Zabbix Server. Мы расцениваем ситуацию следующим образом, лучше иметь неактуальный value cache, чем иметь потерю сервиса мониторинга.
С тем, что nodata нужно очень аккуратно использовать соглашусь.
pacemaker вполне себе решение, кстати, и сейчас. Т.к. у него state-machine не имеет undefined состояний, то его поведение можно лучше предсказывать. Правда, 90% потребителей pacemaker'а юзают его в неподдерживаемом режиме (без stonith).
Поделитесь, какие решения вы используете?
P.S. Мы рассматриваем, только опенсоурс решения
P.S.S Выше пишут в комментарии, что 60к NVPS это слишком много, для потока данных в системе мониторинга
20 лет назад ни ZAbbix
У Вас там кнопка что ли залипает на клавиатуре?
Касательно Z — он 20 лет назад был ) Но может быть не был так популярен. Пруф
https://ru.wikipedia.org/wiki/Zabbix
Первый выпуск 1998
Pacemaker — да, согласно https://en.wikipedia.org/wiki/Pacemaker_(software) он появился в 2004, но здесь могу порекомендовать слова коллеги воспринимать не буквально, а образно. Ну, серьезно -какая разница — 20 или 15 лет? ВСЕ РАВНО МНОГО!
20 лет назад ни ZAbbix, ни PaceMaker не было :)
Как сказали в соседнем комментарии — это образно, просто где-то в начале 2010-х уже использование заббикса считалось немного моветоном, к 2015 у меня среди друзей-знакомых не осталось никого кто бы на нем сидел.
Поделитесь, какие решения вы используете?
Я боюсь на текущем месте работы решение нерелевантно совсем, потому что оно полностью самодельное и все что о нем есть — это пара (точное количество не знаю, кажется что ровно два) докладов и один whitepaper (см. Monarch).
На прошлом месте работы достаточно неплохо чувствовал себя графит на потоке, в терминологиях заббикса, 2.5М NVPS (последняя цифра которую разрешили в свое время опубликовать, а не говорить абстрактно «миллионы»). Можете поискать старые доклады по ключевым словам «Graphite@Scale» — были на FOSDEM 2017 и еще на паре конференций, +- одинаковый уровень подробностей к сожалению.
Ну и почти уверен, что сейчас народ из Букинга тоже почитывает хабр и может рассказать что нового, может быть даже были доклады какие-то с тех пор (как я слышал там где-то появился Prometheus рядом, но деталей не знаю).
наверно, это не тема спора
изначальный комментарий, «почитал и понял что вернулся 20 лет назад»
любой продукт имеет свою историю и текущую зрелость. Мы выбирая решение опирались на критерии в данный момент, на актуальную версию
Мониторинг с высокой доступностью. Опыт компании СберСервис