Вчера на прогулке прослушал длиннющий вебинар на тему, которую я никак не мог пропустит... — 28 мая 2026 г. в 15:30:01.979
Вчера на прогулке прослушал длиннющий вебинар на тему, которую я никак не мог пропустить. Она тут на канале обсуждалась раз 10 в разное время: ⇨ Zabbix vs Prometheus на практике Особо чего-то полезного и интересного, чего бы не знал, я не услышал. Автор сразу признался, что с Zabbix не работает, знает его приблизительно по старой памяти, когда сталкивался с ним по работе много лет назад. Из-за этого был в некоторых местах необъективен и никто не поправил в чате. Например, он открыл из какого-то шаблона Zabbix старые графики, которые никто уже не использует, которые выглядят, как графики из начала двухтысячных и показал, как он мог бы быстро и удобно создать дашборд с визуализацией в Grafana в противовес тому, что он увидел на этих графиках. А факт в том, что в Zabbix в современных дашбордах можно получить так же быстро точно такой же дашборд ровно с такими же виджетами, как в его примере. Так же был продемонстрирован как пример удобства - сквозной запрос в Prom по какой-то метрике в разрезе сразу всех узлов. Zabbix тоже в какой-то момент после смены синтаксиса научился так делать. Не то, чтобы я защищаю Zabbix. Он в этом не нуждается. Я и то, и другое активно использую и более-менее прилично знаю. Это инструменты под свои разные задачи. Я тут за объективность. Пишу заметку, чтобы акцентировать внимание на ключевом отличии с точки зрения автора вебинара между этими двумя системами. Никогда не смотрел на них под этим ключом. В Zabbix всё крутится вокруг айтема, который привязан к метрике и по сути ей и является. Тебе обязательно надо подготовить систему мониторинга и конкретно узел, создав на нём тем или иным способом айтем - вручную, через шаблон, через правило автообнаружения или ещё как-то. И только после этого ты можешь принимать данные. Без этого ничего не получится. В Prometheus принципиально другой подход - туда без всякой подготовки можно лить разные метрики. На сервере под каждую метрику не нужно создавать никаких сущностей. Хочешь 10 метрик отправляй, хочешь через минуту - 100. Серверу всё равно, он примет все без какой-либо донастройки. Это экономит время и организационно выглядит проще, что имеет решающее значение для динамических сред при выборе инструмента сбора метрик. Архитектурно всё так и есть, это отличие ключевое. Я обычно на этот вопрос смотрю с точки зрения пользовательского опыта и воспринимаю Zabbix как полноценную систему мониторинга, где из коробки есть всё, что для неё нужно с удобной панелью управления. А Prometheus больше похож на фреймворк, который только собирает метрики, вокруг которого тебе предстоит самому из разных компонентов создать систему мониторинга. Как по мне - это ключевое отличие. Просто взгляд на продукты под другим углом. Сколько лет прошло, а это принципиальное отличие не меняется. Из-за него у Prometheus появилось несколько совместимых взаимозаменяемых продуктов, которые можно безболезненно менять местами в системе мониторинга, не трогая остальные компоненты. А Zabbix как был сам собой, так и остался. Никто его не форкнул, не доработал, не написал совместимую замену. Были попытки, но все они остались местечковыми и не получили широкого распространения. Второе заметное отличие с точки зрения практической работы с ним - Prometheus полностью совместим с подходом IaC, Zabbix - нет. Ну и ещё один полезный момент. На вебинаре кто-то в чате написал, что активные агенты меньше нагружают сервер, так как сами шлют метрики, что упрощает процесс сбора. На самом деле это не так. Пассивные проверки архитектурно проще и если есть возможность забирать метрики сервером, то лучше делать именно так. Сервер обратился к агенту и забрал метрики. Если агент сам их отправляет, то он сначала стучится к серверу, забирает у него набор настроенных для него метрик и потом только их отправляет. Это больше итераций. Плюс, под нагрузкой у сервера меньше вариантов разрулить её, когда на него постоянно валится поток данных. Проще самому им управлять. #zabbix #prometheus