Сравнение Zabbix vs Prometheus

К своим статьям по Zabbix регулярно получаю комментарии о том, что это устаревший продукт и надо переходить на Prometheus -  там все современно, модно, молодёжно. Я знаком с этим мониторингом, ставил его, тестировал, поэтому могу провести обзорное сравнение Zabbix vs Prometheus. Последний хороший продукт, не хочу заниматься критикой и убеждением кого-то в том, что Zabbix лучше, хуже и т.д. Сравнивать их в лоб не имеет смысла, так как это разные продукты под разные задачи. Они схожи тем, что оба считаются системами мониторинга, но у них масса отличий.

Онлайн-курс по устройству компьютерных сетей

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Авторизация и аутентификация

Простой пример значительной разницы между Prometheus и Zabbix. На обучении по Прому (1,5 года назад) я спросил у лектора, как обеспечить аутентификацию и авторизацию пользователей. Про второе вообще ничего не сказал, а насчет первого предложил настроить ограничения на firewall или сделать basic_auth при проксировании через nginx. Сравните это с готовой системой пользователей и групп в Zabbix, где можно настроить права доступа вплоть до отдельной группы или хоста.

Авторизация и аутентификация в zabbix
В Prometheus вам эту задачу придется решать отдельно, даже не знаю как. Возможно есть какие-то готовые удобные решения, о которых я не слышал. Если есть, прошу подсказать. Статью пишу в том числе для того, чтобы собрать обратную связь и расширить свои знания по упоминаемым продуктам.

Панель мониторинга

Zabbix сразу включает в себя панель мониторинга с возможностью настраивать Dashboards. Этот функционал присутствует изначально и ничего дополнительно устанавливать и настраивать не придется. Для Prometheus вам придется использовать сторонние приложения для визуализации данных. Согласен, что это не проблема, так как интеграция с Grafana очень простая. А последняя дает удобную визуализацию, лучше чем встроенная в Zabbix. Но тем не менее, это принципиальное отличие Zabbix от Prometheus, о котором стоит упомянуть.
Zabbix Dashboard

Prometheus это только значения временных рядов

Идем далее. Еще одно отличие Prometheus от Zabbix в том, что первый хранит у себя только значения временных рядов. Он не подходит для текста, логов, журналов событий. Да, согласен, что для логов лучше использовать специализированные продукты, типа ELK. Но это отдельное, большое и сложное приложение, которое вот так с пол тычка не поставишь для того, чтобы к примеру мониторить логины по ssh или winbox.
Но даже если внедрить ELK, там отдельно придется решать вопросы аутентификации, уведомлений и т.д. В общем, для простых случаев, когда хочется хранить какие-то текстовые значения, анализировать их и настраивать триггеры, zabbix отлично подходит, предоставляя готовый функционал из коробки и сразу.
Текстовые метрики в zabbixТак что важное отличие Prometheus от Zabbix - последний поддерживает сбор и хранение разнородной информации, в том числе в текстовом виде.

Уведомления

В истории с уведомлениями тоже наглядно видна разница Zabbix от Prometheus. У первого огромное количество встроенных уведомлений и интеграций с различными сервисами. В случае с Prometheus вам придется решать этот вопрос отдельно. К примеру, с помощью alertmanager. Я не берусь оценивать его функционал и возможности, так как знаком очень поверхностно. Но на первый взгляд, настройка будет посложнее, чем аналогичная через web интерфейс заббикса. Туда по дефолту завезли в том числе уведомления в telegram.
Способы оповещений

Долгосрочное хранение данных

Изначально Prometheus был рассчитан на краткосрочное (неделя-две) хранение метрик и работы с ними. У него для этого есть TSDB, отлично оптимизированная под временные ряды и добавление данные по модели pull. То есть это продукт для оперативного мониторинга. Если вы хотите хранить исторические данные месяцы и годы, вам придется искать какое-то отдельное решение для этого. Они существуют, их относительно много, но придется отдельно потрудиться, чтобы выбрать что-то подходящее и настроить.
В Zabbix с этим проще. Он изначально рассчитан на долгосрочное хранение. Конечно, там есть свои сложности с высокой нагрузкой на базу (это его узкое место, так как там честный SQL) и долгосрочным хранением больших объемов. Но тем не менее, эти вопросы прорабатываются и развиваются. К примеру, 5-я версия Zabbix поддерживает в качестве базы данных PostgreSQL + TimescaleDB.
Долгосрочное хранение данных в zabbix

Zabbix способен объять всю инфраструктуру

Zabbix можно считать системой мониторинга общего назначения, на которую можно замкнуть всю инфраструктуру. Например, настроить мониторинг ssl сертификатов и время делегирования домена. Недавно я решал задачу мониторинга промышленных контроллеров, которые отдают данные по протоколу ModBus. Заббикс его поддерживает после установки дополнительного модуля. Как такие вещи сделать в Prometheus, я даже не представляю.
Сбор метрик по протоколу Modbus
Таким образом, у вас есть универсальная система мониторинга, которая объединяет в себе вообще всю инфраструктуру. Плюс, можно сразу подключить какие-то внешние метрики через API удаленных систем. У Prometheus все же более узкая специализация под конкретные задачи.

В чем преимущество Prometheus?

Прочитав мое сравнение этих двух систем мониторинга, может показаться, что Zabbix по всем статьям лучше Prometheus. Конечно, это не так. Стоит принять во внимание то, что Zabbix я использую очень давно и хорошо знаю, поэтому я не объективен. На мой взгляд, Prometheus похож на некий framework, на базе которого строится полноценная система мониторинга. Вот его наиболее сильные стороны:

  1. Prometheus query language. Это свой язык запросов, очень крутая штука, аналогов которой вроде и нет нигде. С его помощью очень удобно и быстро можно построить запрос на выборку данных. В Zabbix ничего и близко нет.
  2. Service discovery. Прометеус отлично подходит для динамических систем, например Kubernetes. Он автоматически находит необходимые таргеты и ставит на мониторинг.
  3. Exporters. Формат данных Prometheus поддерживает огромное количество софта. Они сразу из коробки выдают все метрики для Prometheus. Вам остается их только направить в него. Zabbix движется в этом направлении, создает шаблоны для приема данных с экспортеров prometheus, пишет свои шаблоны, но тут он в роли сильно отстающего.
  4. Highload. За счет TSDB, Prometheus может принять и обработать несравнимо больше метрик, чем Zabbix. Правда, актуально это становится для тех, у кого реально очень высокая нагрузка.

Вот преимущества Prometheus, которые сходу пришли мне на ум. Думаю, этот список можно дополнить. Поделитесь в комментариях информацией, которую я упустил.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

На этом по сравнению Zabbix vs Prometheus у меня все. Сел писать небольшую заметку в Telegram, но, как обычно, не смог ограничиться его форматом. Чтобы раскрыть тему, нужна полноценная статья, которая в итоге и получилась. Надеюсь, она вам была полезна. Про Прометеус не так много информации на русском языке, в отличие от Zabbix. Так что если не знакомы с продуктами, быстро сравнение сделать не получится, придется погружаться.

Углубленный онлайн-курс по MikroTik.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

26 комментариев

  1. Максим

    По поводу аутентификации в прометеусе
    https://prometheus.io/docs/prometheus/latest/configuration/https/

  2. На самом деле авторизация да существует ,раньше это было base auth и имя пользователя пароль ( кроме блокировки файрволом) можно было ставить как на сам прометей 9090 так и на экспортеры без установки дополнительных веб серверов тип Апача или Nginx .
    При этом data source с графаны работает нормально с этим .
    Чуть меньше года назад появилась возможность работать с oauth2 ,tls и другие решения для авторизации.

  3. Константин

    Владимир, снимаю шляпу как вам удаётся сдерживаться не послав этих новообращённых адептов. ) Спасибо за взвешенную статью.

  4. Авторизация и аутентификация
    1. В комментариях выше уже указали, что это цель графаны
    2. Закрыть API можно firewall, нужность RBAC вызывает вопросы
    3. А зачем вообще закрывать? Приведите примеры атак.

    Панель мониторинга
    1. Графана и куча готовых и полуготовых dashboard

    Prometheus это только значения временных рядов
    Ну да. В этом же смысл - применяя математику мы отлично высчитываем любые нужные нам метрики.

    Уведомления
    Корректно рассматривать в разрезе alertmanager
    В нём имеются интеграции с популярными сервисами. Главное отличие - конфиг в yaml.

    Долгосрочное хранение данных.
    Прометей создан для краткосрочного хранения метрик - это факт.
    Однако хочется видеть пример, когда надо хранить не бизнесовые метрики больше 2-3 недель?

    Zabbix способен объять всю инфраструктуру
    Ну тут вообще мимо кассы.
    1. Под большинство популярных вещей есть экспортеры для прома
    2. Если нет, то экспортер пишется самостоятельно за короткий срок.

    Важное отличие заббикса от прометея - конфигурирование.
    В случае прометея всё хранится в yaml и может отлично раскатываться через IaC из git.
    Логика конфигов стройная и внятная, а хранение их в гите позволяет достаточно атомарно выяснить кто что правил.
    В то же время в заббиксе надо искать нужные менюшки и прочее.
    Тут важное уточнение: тем кто выучил за годы менюшки заббикса будут страшны конфиги в yaml.
    Так что заббикс и прометей они не для разного они для разных.

    • Так вы все мои отличия только подтвердили, а аргументы свели к тому, чтобы я рассказывал, кому это надо. У меня не было цели в статье рассказывать, кому что надо. Zabbix активно развивается и успешно применяется в бизнесе любого масштаба, что только подтверждает его актуальность и востребованность, в том числе за счёт перечисленных мной особенностей.

      Буквально вчера на хабре была статья от Beeline, где они свой большой мониторинг построили на базе Zabbix. Таких примеров масса. Zabbix переведён практически на все языки мира. Представительства в куче стран. Система обучения и сертификации. Это зрелый и востребованный продукт, который нужен рынку.

      Уж самый наглядный пример - Zabbix идеален для компаний аутсорсеров, о чем они сами неоднократно заявляли. Как я и сказал в статье - prometheus нишевый инструмент, а Zabbix полноценная система мониторинга общего назначения. Несмотря на то, что она полностью не соответствует современному подходу IaC, актуальности своей не теряет. Шаблоны, кстати, они уже перевели на yaml. Думаю и дальше будут двигаться в этом направлении.

      • Хлопушки. Beeline построил монитроинг на zabbix потому что
        1. У них уже была тонна алертов на момент выхода прометея
        2. Им проще дать денег Аблееву на допил заббикса.

        А вот в каком месте заббикс идеален для аутсорсеров я бы послушал.

        • У аутсорсеров и послушайте. Они его активно используют. Вот пример крупного аутсорсера, сидящего на zabbix - https://habr.com/ru/company/southbridge/blog/468207/ Это просто то, что вспомнил, так как хорошо знаю southbridge. Абсолютно все аутсорсеры, с которыми я сталкивался в виде сервиса по поддержке инфры и подключения к своему мониторингу использовали Zabbix, потому что это банально очень удобно. Завел все хосты заказчика в систему, в отдельную группу. Сделал группу безопасности, добавил туда юзеров. Идеально.

          • Аутсорсер ушёл - мониторинг ушёл с ним.
            Очень удобно :)

            • Это в первую очередь вопрос денег. Заплатишь - сделают тебе то же самое. Каждый свое выбирает. Вся облачная инфра - аутсорс железа. И ничего, активно пользуются.

    • Нам их немножко жаль, а вот Вас сразу видно как чела со знанием синтаскиса yaml с детского садика. Правда вы не одиноки, сейчас время такое - чем запутанней, тем драйвовее. Да и спецы буду востребованы.

  5. Владимир

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

  6. Анатолий

    "Недавно я решал задачу мониторинга промышленных контроллеров, которые отдают данные по протоколу ModBus."
    Здравствуйте! Очень интересно было бы увидеть статью вот по этой теме. Заранее благодарю!

    • В версии 5.2 появилась встроенная поддержка modbus, так что никаких особенностей и нюансов нет. Вы просто выбираете в качестве сборщика данных mudbus и все. Лично мне далее контроллеры просто отдавали json.

  7. Андрей

    Про первую часть статьи про автоизацию и аутентификацию.
    Не совсем понял зачем это нужно в проме - у него как таковой визуализации и нет, для этого есть графана та же самая например где способов аутентификации хоть ж***й жуй :). достаточно что бы на пром могла ходить только графана и это легко решается FWнапример.

    Не увидел, поправьте меня если читал через строку :) (сильно не пинайте :)) прометей соответствует подходу IaС, с заббиксом все сложнее...

    • Тем не менее, доступом к метрикам все равно надо управлять. Нельзя же дать всем подряд читать метрики с прома. Надо каким-то образом ограничивать доступ. А тут, кроме фаервола, инструментов нет. Получается, надо только графане на уровне ip разрешить доступ, остальным закрыть. А если они не в одном сегменте сети? Все это очень не гибко. Так что проблема, как ни крути, но с этим есть. Нужен какой-то встроенный механизм аутентификации и авторизации.

      • Андрей

        Это да, но частенько он развернут где нить в k8s и просто так уже туда не попасть, если его не прокидывать наружу.
        А вообще если подливать масла в огонь node_exporter's тоже висят просто в виде открытой странички, тогда и их тоже нужно закрывать как то.
        Но смотря о каких метриках идет речь, если мы скажем пишем метрики CPU\RAM\network - да и пусть смотрят...а если это какие то бизнес метрики например с финансовыми показателями... хм ну они совсем не подходят под философию прома и их уже как то по другому агрегировать надо.

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

        • Ничего нигде не отмирает. Каждому решению свое применение. Тот же комбайн, все в одном - NewRelic очень неплохо себя чувствует и развивается.

          Глупо считать авторизацию средством борьбы от утечек. Даже комментировать не буду. Конечно, когда админишь свой локалхост, вопросов с доступом не возникает. Закрыл фаерволом и все. Но существуют информационные системы посложнее.

          • >Конечно, когда админишь свой локалхост,
            Э нет, это вы пишете статьи про то как докер установить на центось, а не я ;)

            • >Что до авторизации, то тут я, конечно, вам не завидую, раз вам ваши же данные приходится защищать от утечки через собственных сотрудников.

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

  8. если коротко, ИМХО, то Забикс - это мониторинг железа: актива, серверов (ОС и все что там типа дисков, озу и прочего), а Прометей удобен для снятия метрик с софта и микросущностей типа контейнеров, в которых крутятся "однозадачные" приложения.
    использовать надо и то и то.
    простой пример - мой домашний кластер кубернетес: сервер, ноды (виртуалки на нем) и доп виртуалки - забикс, а все, что на кластере (приложения) - Прометей.
    последний отлично встраивается как параллельно приложению (блак-куб), так и в само приложение, что, несомненно, удобно для понимания, где у кого какие затыки для разработчиков.

    • Справедливости ради, Prometheus тоже умеет неплохо мониторить сервера на уровне ОС. Так что если нет метрик по snmp или ipmi, память, проц и диски можно мониторить промом. Другое дело, что если надо что-то сложнее, то уже будет трудно. Например, мониторинг mdadm, raid контроллеров через их утилиты, SMART дисков и т.д. Я все это на zabbix замыкаю, создавая общий шаблон для конкретной железки.

  9. Пользуюсь обоими, они хорошо дополняют друг друга, а после того как Zabbix стал поддерживать агентов Prometheus - так вообще песня.

    Если коротко, то главное достоинство Zabbix в его гибкости и завершённости как продукта. Из коробки работают 80% хотелок, а если нужно что-то специфичное, то легко написать свой скрипт для одиночного итема, а минусом является замороченное написание своих скриптов по авто-обнаружению.

    У Prometheus всё наоборот. Из коробки автоматичекси определяется 99% всего, что только можно мониторить, однако свою кастомную метрику сделать намного сложнее (нужно писать маленький веб-сервер с выводом метрик в формате Prometheus), а авторизация и прочее в зачаточном состоянии.

    Что касается Grafana, она с помощью плагинов хорошо объединяет оба продукта, и на сегодняшний день в мире опенсорц в ряд ли есть лучший тандем.

    • Да, графана крутая штука. С ее помощью можно в общие дашборды выводить метрики из разных систем. Аналогов у нее по сути и нет. Kibana может быть, но она для другого.

    • Для своих метрик - не нужно писать маленький веб-сервер, для этого есть:
      1. опция "collector.textfile.directory" для node_exporter - читает просто текстовый файл с метриками
      2. pushgateway - принимает по http-post любые метрики
      нет проблем на bash/bat написать скрипт, создающее текстовый файл или post запрос на http (curl в помощь)
      3. ну или всё-таки написать web-скрипты для того же apache/nginx на php/perl/ruby/c++/brainfuck

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar