Мониторинг с высокой доступностью. Опыт компании СберСервис

    СберСервис – крупнейшая сервисная компания федерального значения, оказывающая услуги по комплексному техническому обслуживанию широкого спектра информационно-телекоммуникационного оборудования, рабочих мест, офисной техники, серверов и телефонии. Компания является единственным на территории СНГ премиум-партнером компании Zabbix, в ней работает самая крупная команда в России в сфере ИТ-мониторинга, разрабатывая уникальные технические решения в области комплексного внедрения систем мониторинга для организаций с высоконагруженной ИТ-инфраструктурой. Данный факт объясняет, почему в качестве основной платформы для мониторинга СберСервис выбирает Zabbix.

    О чем эта статья?

    Как следует из названия, в статье предлагается концепция организации мониторинга с высокой доступностью. В роли «подопытного» выступает Zabbix Server, для организации Active-Active кластера применяется Corosync и Pacemaker, а работает это всё на Linux. Данное ПО является OpenSource, поэтому такое решение доступно каждому.

    В процессе эксплуатации Zabbix для мониторинга высоконагруженной ИТ-инфраструктуры (рост количества элементов данных, рост числа узлов сети, большая глубина хранения сырых данных, постоянно растущие потребности пользователей) многие сталкиваются с проблемами производительности сервера Zabbix во время старта или перезапуска. В условиях High Load (>60k NVPS) обычная перезагрузка сервера Zabbix превращается в весьма длительную, хотя и штатную процедуру. Время от запуска службы до появления данных в мониторинге может достигать 15-20 минут.

    Столкнувшись с этим, и проанализировав ситуацию, команда мониторинга пришла к решению, что поможет кластеризация по принципу Active-Active. Кроме того, была поставлена цель добиться Disaster Recovery путем переноса на разные ЦОДы.

    Задача

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

    Существует множество схем и способов как обезопасить сетевую среду сервиса от падения. Команда решила идти по пути адаптации мощной и высоконагруженной системы мониторинга Zabbix к аппаратным и программным возможностями кластеризации, существующим на рынке ИТ-сферы, СберСервис создал кластер высокой доступности. Выбор пал на OpenSource-решения, а точнее на Pacemaker и Corosync.

    Требования

    При создании кластера необходимо учесть два важных критерия:

    • управление нодами ZabbixServer без видимого прерывания сервиса мониторинга на время проведения различных технических работ по обновлению, правке конфигураций и т. д., именно поэтому не подойдет виртуализация в чистом виде;

    • бесшовное переключение трафика между инстансами ZabbixServer в случае выхода из строя одной из нод, желательно автоматически.

    Встроенный функционал схемы кластеризации ресурсов в режиме Active-Passive с использованием Pacemaker и Corosync рассматривался уже много раз и в частности на Хабре есть подробная статья для случая кластеризации БД и статья про кластеризацию Заббикса (вместо Corosync использовался cman, но смысл тот же).

    Как уже упоминалось выше, применительно к системе мониторинга на базе Zabbix данное решение попросту не подходит, если у вас «Большой мониторинг», так как во время старта инстанса ZabbixServer выполняется проверка и применение конфигурации сервера, выделения памяти, кэша, запуск заданного количества различных подпроцессов – и все эти предпусковые задачи составляют львиную долю времени для полноценного запуска системы. А это время фактического простоя мониторинга, отставание данных и заполнение кэшей.

    Команда смогла придумать схему и реализовать логику работы всех компонентов и модулей системы для воплощения в реальность отказоустойчивого кластера, работающего в режиме Active-Active как с применением в схеме аппаратного балансировщика нагрузки (LoadBalancer), так и без него.

    Полученное решение реализует два важных для системы мониторинга свойства:

    • Непрерывность мониторинга

    • Отказоустойчивость мониторинга

    Рассмотрим реализацию решения High Available ZabbixServer в режиме Active-Active без LoadBalancerПринципиальная схема взаимодействия компонентов:

    Принцип работы

    Использование в схеме «менеджера управления кластерными ресурсами» (Cluster resource) подразумевает развертывание компонентов управления кластером на виртуальном сервере. Таким образом достигается отказоустойчивость управляющего модуля.

    В кластере существует 2 ноды. При подготовке нод следует учитывать свойства stonith и quorum — их необходимо отключить.
    Свойство quorum применяется для схемы кластера от 3х нод и более. Если в схеме кластера, состоящего из 2х нод использовать данное свойство, тогда при «падении» одной ноды произойдёт выключение всех ресурсов.

    Свойство stonith обеспечивает принудительное завершение рабочих процессов на серверах, которые в свою очередь не смогли самостоятельно их завершить. К вышедшей из строя ноде запросы поступать не будут, т. к. она изолируется до тех пор, пока не выйдет из аварийного состояния с отправкой сообщения о том, что нода снова в рабочем состоянии.
    В каждой ноде создаются кластерные ресурсы:

    ocf::heartbeat:ZBX-IPaddress
    ocf::heartbeat:ZBX-Instance

    При аварийном выходе из строя основной ноды, кластерные ресурсы перемещаются на резервную ноду. Ресурс ZBX-IPaddress управляет виртуальным ip-адресом и входит в стандартный набор кластерных ресурсов (IPaddr2). ZBX-Instance — самописный кластерный ресурс для сервиса zabbix-server и управления подключениями к БД. На каждом Zabbix-сервере в конфигурационном файле прописаны разные пользователи БД, при этом, в любой момент времени пользователь основного Zabbix-сервера имеет права Read/Write, а пользователь резервного права ReadOnly, поэтому на обеих нодах служба zabbix-server может находиться в запущенном состоянии (привет, Active-Active).

    Перевод кластерных ресурсов в случае сбоя выглядит следующим образом. Ресурс ZBX-IP-address переводит виртуальный IP-адрес на другую ноду, а ресурс ZBX-Instance переводит пользователя БД резервного zabbix-сервера в режим Read/Write, а пользователя БД основного zabbix-сервера в режим ReadOnly, при этом закрывая имеющиеся к БД старые сессии подключения. Таким образом мониторинг инфраструктуры не прекращается. Непрерывность записи информации достигается за счет буферизации снятых метрик с объектов мониторинга на стороне ZabbixProxy. После того как прокси получает подключение к серверу, он передает накопленные данные.

    Важный нюанс — применение данной схемы подходит только в случае нахождения master и slave ZabbixServer-нод в одной подсети.

    Рассмотрим реализацию решения High Available ZabbixServer в режиме Active-Active с LoadBalancer

    Принципиальная схема взаимодействия компонентов:

    Принцип работы

    Решение с применением аппаратной балансировки сетевой нагрузки на основе «сигнального порта» выглядит следующим образом. Аппаратный балансировщик нагрузки отправляет трафик на ноду, на которой доступен «сигнальный порт», если порт доступен на обеих нодах, LoadBalancer не будет отправлять трафик на какую-либо из нод. Решение можно использовать, когда ноды кластера находятся в разных подсетях, что позволило развернуть высокодоступный кластер для работы в «географически распределенном ЦОД».

    В Pacemaker создаются кластерные ресурсы:

    ocf::heartbeat:ZBX-Cluster-Socket
    ocf::heartbeat:ZBX-Instance

    Ресурс ZBX-Cluster-Socket — управляет «сигнальным портом» на ноде — нужен для работы LoadBalancer-а.

    Ресурс ZBX-Instance управляет процессом zabbix-server-а и правами доступа к БД.

    Принцип работы данной схемы похож на схему «без аппаратного балансировщика нагрузки», но имеет ряд особенностей.

    Ресурс ZBX-Cluster-Socket создаётся с помощью встроенной в Pacemaker функциональности по созданию ресурсов из системного процесса (службы). Служба «сигнального порта» — обыкновенная самописная служба, которая просто открывает на хосте соответствующий порт, за состоянием которого будет наблюдать LoadBalancer. Осуществлена «привязка» ресурса ZBX-Cluster-Socket к ресурсу ZBX-Instance посредством ограничения (constraint) для того, чтобы кластерные ресурсы «перемещались» совместно. Corosync, управляя ресурсом ZBX-Cluster-Socket, поддерживает в открытом состоянии только порт 101 на основной Master-node и в закрытом состоянии порт 201 на резервной Slave-node. Для LoadBalancer сигналом на переключение/отправку трафика являются: открытый порт 101 — на первой ноде или открытый порт 201 — на второй ноде, если оба порта на обеих нодах открыты, или оба закрыты, трафик никуда не отправляется.

    Переключение ресурсов с текущей Master-node на текущую Slave-node происходит следующим образом:

    При падении Master-node, порт 101 становится недоступным, тогда сигналом для LoadBalancer на переключение трафика будет являться открытый порт 201 на Slave-node. Corosync, определив, что Master-node недоступна, переключает ресурсы ZBX-Instance и ZBX-Cluster-Socket вместе на Slave-node, а благодаря скрипту «resource_movement», на основе которого Pacemaker создал ресурс ZBX-Instance происходит смена прав пользователей User_A и User_B в базе данных, при этом закрываются все старые сессии подключения к БД.

    Что произойдет в случае потери связности между нодами кластера при условии полной работоспособности нод?

    Схема та же: кластер состоит из 2-х нод Master-node (пользователь User_A) и Slave-node (User_B), на Master-node запущены кластерные ресурсы.

    При потере связи каждая из нод определит, что другая нода недоступна, тогда обе запустят у себя кластерные ресурсы. Master-node перезапускать ничего не будет и продолжит работу, определяя свою роль главной. Slave-node тоже посчитает себя главной и запустит у себя кластерные ресурсы. При этом LoadBalancer определит, что на Master-node и Slave-node доступны порты ZabbixServer и управляющий порт, соответственно LoadBalancer прекратит передачу сетевого трафика.

    Следует отметить важный момент — какими будут права доступа к базе данных соответствующих пользователей? Одна из нод по-прежнему будет иметь доступ к БД с правами Read/Write, а другая с правами ReadOnly, так как:

    • Если связь Slave-node с БД не была потеряна, то Slave-node во время включения у себя кластерных ресурсов произведет смену прав пользователей: для User_A права изменятся на ReadOnly, а для User_B права изменятся на Read/Write.

    • Если связь Slave-node с БД потеряна, следовательно Slave-node не сможет выполнить переключение прав пользователей.

    • После восстановления связности кластерные ресурсы снова «переместятся» на Master-node, LoadBalancer определит, что управляющий порт доступен только на Master-node и начнёт передавать ей сетевой трафик.

    Заключение

    Данный кейс иллюстрирует принципиальную идею и концепцию придуманного решения (а точнее 2-х реализаций), и не является прямым руководством к действию. Инфраструктуры и ограничения у всех разные, а инженеры, перед которыми ставятся похожие задачи не нуждаются в «How to».

    В заключение стоит добавить, что в современном мире технологий нет почти ничего невозможного. Необходимы лишь желание и ресурсы.

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

      0

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

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

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

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

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

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

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

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


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

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

                0

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

                  0

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

                    0

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

                0

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

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

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

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

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

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

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

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

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

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

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

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


                      • ну мы эта, прикинули и сделали две ноды и в разные дц что б ежиль один того то оно все норм там еще влан между дц растянули и hsrp там и ежиль че сразу скриптик там переключает.
                        И вот мы картинки для утверждения проекта рисовали, тоже добавь.

                      Так не пойдет, сейчас я сама, пиши:


                      • проанализировав ситуацию, команда мониторинга пришла к решению, что поможет кластеризация по принципу Active-Active. Кроме того, была поставлена цель добиться Disaster Recovery путем переноса на разные ЦОДы.

                      Вы уж извините, но у меня сложилось такое впечатление :)


                      Нашел пример для NVPS в 60к и заббикса.
                      ~66k 72 x Intel® Xeon® Platinum 8124M CPU @ 3.00GHz; AWS EC2 c5.18xlarge


                      Интересно, что вам пишет на 60к в секунду? Вы все банкоматы на этот заббикс повесили? Интересно было бы прочитать как о причинах так и о процессе выборе решения, что рассматривали, можно ли было уменьшить поток данных, может вы собираете много не нужного? Оптимизации? Как сравнивали? Или просто — мы умеем в заббикс, все прикрутим к нему? Я к тому, что это случаем не та ситуация, когда у вас есть молоток, то все вокруг превращается в гвозди? Я собственно не про прометеус упомянутый выше, а в целом, есть же разные решения?

                        0

                        Полностью согласен. Ребята построили очередной велосипед из заббикса. Ну, и про отказоустойчивость БД ничего не рассказали, хотя это тоже очень интересная тема

                          0
                          Отказоустойчивый кластер РСУБД — это утопия.
                            0

                            Ваши предложения — как строить отказоустойчивый заббикс, если под капотом постгрес?

                              0
                              Посмотрите на решения:
                              — Более сложный с patroni habr.com/ru/post/322036
                              — Стандартными инструментами postgres habr.com/ru/post/188096
                              Есть больше вариантов, надо отталкиваться от вашей задачи, но выше предложенные решения дадут Вам понимание, как можно реализовывать отказоустойчивость.
                                0

                                как Вы правильно заметили ранее — недостаточно построить отказоустойчивое хранилище (=БД), сам заббикс надо еще правильно сконфигурировать. И поэтому вопрос комплексный, а не просто — подложим под заббикс патрони и все будет хорошо (спойлер — нет, не хорошо)

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

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

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

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

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

                                        0
                                        20 лет назад ни ZAbbix, ни PaceMaker не было :)
                                        Поделитесь, какие решения вы используете?
                                        P.S. Мы рассматриваем, только опенсоурс решения
                                        P.S.S Выше пишут в комментарии, что 60к NVPS это слишком много, для потока данных в системе мониторинга
                                          0
                                          20 лет назад ни ZAbbix

                                          У Вас там кнопка что ли залипает на клавиатуре?
                                          Касательно Z — он 20 лет назад был ) Но может быть не был так популярен. Пруф


                                          https://ru.wikipedia.org/wiki/Zabbix
                                          Первый выпуск 1998


                                          Pacemaker — да, согласно https://en.wikipedia.org/wiki/Pacemaker_(software) он появился в 2004, но здесь могу порекомендовать слова коллеги воспринимать не буквально, а образно. Ну, серьезно -какая разница — 20 или 15 лет? ВСЕ РАВНО МНОГО!

                                            0
                                            20 лет назад ни ZAbbix, ни PaceMaker не было :)

                                            Как сказали в соседнем комментарии — это образно, просто где-то в начале 2010-х уже использование заббикса считалось немного моветоном, к 2015 у меня среди друзей-знакомых не осталось никого кто бы на нем сидел.

                                            Поделитесь, какие решения вы используете?

                                            Я боюсь на текущем месте работы решение нерелевантно совсем, потому что оно полностью самодельное и все что о нем есть — это пара (точное количество не знаю, кажется что ровно два) докладов и один whitepaper (см. Monarch).

                                            На прошлом месте работы достаточно неплохо чувствовал себя графит на потоке, в терминологиях заббикса, 2.5М NVPS (последняя цифра которую разрешили в свое время опубликовать, а не говорить абстрактно «миллионы»). Можете поискать старые доклады по ключевым словам «Graphite@Scale» — были на FOSDEM 2017 и еще на паре конференций, +- одинаковый уровень подробностей к сожалению.

                                            Ну и почти уверен, что сейчас народ из Букинга тоже почитывает хабр и может рассказать что нового, может быть даже были доклады какие-то с тех пор (как я слышал там где-то появился Prometheus рядом, но деталей не знаю).
                                          0
                                          первый выпуск Zabbix, как продукт на рынке — 2004 год, согласно статье на вики
                                          наверно, это не тема спора

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

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

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое