Как стать автором
Обновить

Комментарии 44

А почему вы выбрали Zabbix, а не nagios? Он же ещё старее! (В то время, когда всё остальное комьюнити переходит на пром).

Ну, то что сообщество выбирает — не всегда повод бежать за ним сломя голову. Переходит ради чего (это просто вопрос, без всяких там подвохов — лично мне Nagios более близок, при том что я далек на сегодня от мониторинга как никогда :)?

nagios хорош тем, что там value added сервисы в дашборде (особенно с чем-то вроде thruk'а). Но в вопросах мониторинга нагиос намертво застрял в host-парадигме, а уж про грустные вещи происходящие где-то в параметрах command даже говорить нечего (начинаем с абстракций, заканчиваем вопросом "как бы нам баша заэскейпить").

>намертво застрял в host-парадигме
Насколько я понимаю, Zabbix же тоже?

Уточню — мой вопрос скорее был про то, куда сообщество переходит, и _почему_.
На схемке — SNMP, Network, OS, etc.
Для этих задач пром не очень заточен. При всей моей любви к прому.
Согласны, мы попробовали разные системы мониторинга (вендорные, опенсоурсные), выбрали самую подходящую, универсальную, и самостоятельно заточили под требования.
Мы выбрали Zabbix по ряду основных причин:
1) самая лучшая система мониторинга с открытым исходным кодом и централизованным управлением объектов мониторинга
2) открытый исходный код и хорошо описанные протоколы взаимодействия позволяют создавать дополнительную функциональность без изменения ядра

Zabbix растет и приобретает дополнительные фичи очень активно. Любая система имеет свои недочеты, для разных организаций они разные, кому-то нужен Standby, а кому-то нет.

Вендорные системы, к сожалению, недостаточные гибкие и любая новая фитча стоит дополнительных денег и реализовывается очень долго.
1) самая лучшая система мониторинга с открытым исходным кодом и централизованным управлением объектов мониторинга

субъективщина


2) открытый исходный код и хорошо описанные протоколы взаимодействия позволяют создавать дополнительную функциональность без изменения ядра

аналогично есть и у конкурентов (TICK, Prometheus etc. — сотни их)

Вот только не надо TICK в пример ставить. Уж лучше нагиос, чем капаситор.

капаситор мне самому не очень нравится, если что )
А у инфлакса есть свои проблемы.
Из их стека мне реально только Telegraf нравится, но я знаю МНОЖЕСТВО внедрений TICK. И ничего — народ как-то живет и не особо страдает

Значит, они просто не тестируют свои конфигурации. Конфигурации kapacitor невозможно тестировать из-за скрытого неконтролируемого состояния нод. Телеграф — самый здравый продукт. С инфлюксом можно жить во многих ситуациях. kapacitor — обещает, но критически underdeliver, кто юзает chronograph, поднимите руку, так сказать. Т.е. из всего TICK остаётся T(i).

Я пытаюсь понять из вашего ответа, какой из вариантов (нагиос/пром) является "вендорной", и не очень понимаю.

1. Обоснования этого момента нет в статье. А это как раз самое интересное в подобных статьях — что сравнивалось, какие причины решений, что не устроило в других и так далее.

Ну и решение очень субъективное, потому что у Заббикса в текущий момент репутация скажем так не лучшего решения на рынке.

2. Так это свойство всех более-менее взрослых решений. Впрочем что страшного в изменении кода? Мне кажется команда мониторинга в том числе и нужна для того чтоб допиливать выбранное решение под изменения задач и нагрузок, которые будут проходить.
1. Спасибо, это наш первый опыт, учтем при выпуске следующего материала.
2. Есть продукты платные, есть условно-бесплатные (nagios), есть бесплатные (zabbix).
Мы команда разработки систем мониторинга и мы можем себе позволить постоянно переписывать код Zabbix (язык C) с выходом новой версии, но в большинстве случаев, у наших клиентов команда мониторинга не имеет разработчиков, которая может поддерживать свою ветку Zabbix.
есть бесплатные (zabbix).

заббикс бесплатен? Я не уверен, что корректно так называть ) Потому что сами разработчики предлагают платные услуги пруф
Т.е. он может быть бесплатен с точки зрения отсутствия прямых лицензионных отчислений на его использование, но с точки зрения ТСО его эксплуатации — он точно ни разу не бесплатен (как минимум в кадры, которые будут с ним работать — надо вкладываться)

Я имел ввиду, стоимость коробки со всеми функциями.
Zabbix полностью бесплатный, но компании надо заработывать, они предлагаю доп.услуги по внедрению, разработки и поддержки.
Nagios и ELK разделает ветки, урезанный функционал бесплатно и со всеми интересными фитчами за денежку.

Nagios и ELK разделает ветки, урезанный функционал бесплатно и со всеми интересными фитчами за денежку.

в случае ELK уже нет — есть же opendistro :-) но это, конечно, не очень честно сравнивать )

1. Я бы сказал, что первый шаг в этом направлении можно сделать уже сейчас — рассказать хотя бы вкратце об этом в комментариях. Потому что принятое вами решение мягко говоря не очень популярное, а цифры совсем не впечатляют (хотя они конечно в отрыве от железа) и поэтому вопрос «почему такое решение?» очень интересный.
2. Для систем мониторинга это нормально держать в компании одну команду, которая пилит систему для нужд всех, а всем остальным дает либо готовые рецепты как поднять, либо просто централизованную точку входа, полностью скрывая что там в ядре творится.
НЛО прилетело и опубликовало эту надпись здесь

А есть ли в этом смысл, когда рассказывают о концепции? Это же не пошаговая инструкция.

Тестировали на 4 и 5 версиях. В продакшене работает на 5 версии

Я бы хотел сначала просто поделиться впечатлением, потому что статья честно говоря оставляет чувство полного нежелания инженеров что-либо рассказывать или писать и боль копирайтера от переписывания оригинала, прям воображение рисует картину:


  • ну мы эта, прикинули и сделали две ноды и в разные дц что б ежиль один того то оно все норм там еще влан между дц растянули и 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, чтобы каждый модуль был отдельным и не было больших проблем с миграцией на новую версию.
Отказоустойчивость БД — совсем другая история. Все внедренные нами системы мониторинга Zabbix базируются на POstgreSQL. У POstgres есть документация с описанием разных стратегий резервирования. Также на Хабр есть много статей с интересными решениями HA DB Postgres.
Инфраструктура Сбера является одной из крупных в России, возможно, и в Европе.
Мы следим за потоком данных и постоянно его оптимизируем. Ничего лишнего в него нет. Перед внедрением пакета метрик, шаблон проходит многоэтапный анализ. Мы понимаем, что нужно быть аккуратными с двух сторон. С одной стороны, мы не должны нагрузить объект мониторинга, чтобы мониторинг не оказывал лишнюю нагрузку на бизнес приложение или на инфраструктурный сервис, а с другой стороны сбор/логика/экшен не должен оказывать лишней нагрузки на ядро системы мониторинга.
60к NVPS это не так много
Сухая арифметика. У нас есть объект с 30 метриками, собираем метрики раз в минуту — это, примерно, 0.5 NVPS. Итого, 60к NVPS это 120к объектов мониторинга. В реальной жизни количество метрик больше и интервалы сбора чаще.
Предполагал, что под Active-Active кластером автор имеет в виду распределение нагрузки на разные инстансы Zabbix Server. Но нет, Active-StandBy.

Это ещё что, вот обработка евентов на якобы второй ноде, будет выполняться с ошибками. Я бы посмотрел на дебаг лог их стендбай нод, вот где все косяки этих "специалистов" сразу всплывут.

обработка проблем будет происходить без ошибок, т.к. на Zabbix Server, инициатором обработки событий являются новые данные. На второй ноде (резервной), прием данных не выполняется, он регулируется VIP или балансировщиком, смотря какую архитектуру вы выберете.
Не всегда инициатором обработки событий являются новые данные. Например, для триггеров, содержащих функцию nodata.
Могу предположить, что для триггеров, содержащих функции nodata, count, diff и некоторые другие, переход ноды StandBy в состояние Active приведет к труднопредсказуемым событиям (причина — неактуальность value cache на ноде StandBy).
С nodata соглашусь, но count и diff должны получить значение, чтобы запустить расчет триггера.
nodata это страшная функция, мы ее стараемся не используем:
1) Она слишком тяжелая, для обработки
2) Если падает или тормозит прокся, то мы получаем ложное цунами с событиями о недоступности (триггер настроен — если нет данных, то говори, что не работает)

Мы знаем об этой проблеме, но никак ее исправить не можем, это внутренности логики Zabbix Server. Мы расцениваем ситуацию следующим образом, лучше иметь неактуальный value cache, чем иметь потерю сервиса мониторинга.
Да, триггеры с функциями count и diff вычисляются при поступлении нового значения. Но в описанной в статье схеме при переходе ноды StandBy в состояние Active и последующем поступлении первого нового значения элемента данных начнется вычисление diff, но diff использует не только последнее, но и предпоследнее значение элемента данных, а вот оно-то в кэше только что ставшей Active ноды очень старое и вероятно неактуальное. И то, что оно очень старое и вероятно неактуальное как раз и приведет к труднопредсказуемым событиям. Аналогично и с count и со всеми функциями, которые используют не только последнее значение элемента данных. Поэтому в своем предыдущем комментарии я и сделал предположение, что не только nodata, но и diff, count приведут к неожиданностям.
С тем, что nodata нужно очень аккуратно использовать соглашусь.
Вы совершено правы, Active-StandBy.
Спасибо за статью, понастальгировал. Словно вернулся лет на 20 назад, во времена когда 60k NVPS были хай-лоадом и pacemaker с corosync'ом считались хорошим решением.

pacemaker вполне себе решение, кстати, и сейчас. Т.к. у него state-machine не имеет undefined состояний, то его поведение можно лучше предсказывать. Правда, 90% потребителей pacemaker'а юзают его в неподдерживаемом режиме (без stonith).

20 лет назад ни ZAbbix, ни PaceMaker не было :)
Поделитесь, какие решения вы используете?
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 рядом, но деталей не знаю).
первый выпуск Zabbix, как продукт на рынке — 2004 год, согласно статье на вики
наверно, это не тема спора

изначальный комментарий, «почитал и понял что вернулся 20 лет назад»

любой продукт имеет свою историю и текущую зрелость. Мы выбирая решение опирались на критерии в данный момент, на актуальную версию
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории