Comments 24
Эта статья не про то, что Zabbix плохой (он нормальный, мощный и во многих местах идеально подходит). Статья про другое: как быстро и без лишней тяжести получить базовый мониторинг хостов в уже существующем стеке Grafana/Prometheus, когда поднимать ещё один большой сервис/зоопарк по разным причинам не хочется или нельзя.
Мне ещё кажется, что в RU-сегменте связка node_exporter → Prometheus → Grafana до сих пор заметно менее распространена, чем тот же Zabbix, поэтому и решил показать простой рабочий путь “с нуля до метрик”, чтобы у людей было больше вариантов.
>>наткнулся на связку «node_exporter → Prometheus → Grafana»
Это другая половина планеты)
в изначальном посыле в статье присутствует какой то разрыв в логике
Как центр мониторинга и реагирования на кибератаки, мы должны быстро и внятно видеть, что происходит с железом и ОС на хостах: не кончается ли место на диске, не улетела ли память и не уперся ли CPU в потолок. Как это реализовать, да еще и безопасно?
то есть есть парк серверов, который вообще не мониторится..никем? Ведь вышеописанное - относится не только к кибератакам, это базовые инфраструктурные метрики, которые нужны, в том числе, и для планирования нагрузки, расширения и т.п...
Замечание справедливое: формулировка в подводке могла создать впечатление, будто мониторинга не было вовсе. На практике мониторинг есть всегда, но разрозненный: разные контуры и заказчики, разные инструменты и регламенты доступа. Плюс встречался сценарий, когда с части серверов в SOC стабильно приходили только события безопасности, а инфраструктурные метрики (CPU/RAM/DISK/FS/сеть) в едином виде отсутствовали или собирались «как получится». В какой-то момент стало важно не просто “добавить мониторинг”, а централизовать и стандартизировать сбор базовых метрик по всем хостам, задействованным в работе SOC
"никто не горел желанием .. раскатывать агенты" и потом: "поставить на каждый хост node_exporter (один бинарник)" 🙂
раскатать агент, это буквально apt install zabbix-agent2 + изменить пару строк в конфиге
Согласен, при наличии repo zabbix-agent2 ставится просто. Но в реальной инфраструктуре repo есть не всегда, а кроме агента нужен еще и сам Zabbix Core, развертывание которого заметно сложнее, чем установка экспортера и графаны. Поэтому, думаю, в сценарии быстрого внедрения перевес по простоте останется за node_exporter.
Zabbix Core
Zabbix Server
развертывание которого заметно сложнее, чем установка экспортера и графаны
Да так же, как и у вас, через docker compose 🙂
Я не спорю, не возражаю. Конечно, если удобно, то вам grafana подходит. Но у вас три (4) компонента (exporter, prometheus, grafana), а у zabbix - два (3). И утверждение "поднимать еще одну систему, раскатывать агенты, подбирать шаблоны " - слегка вводит в заблуждение тех, кто не знает
А какая целевая аудитория вашей статьи?
Как упоминалось выше, мониторинг это база для всех работает с инфрой.
Чтобы потом не ставить кучу экспортеров и все их поддерживать, почему не Grafana Alloy сразу? Он из коробки столько всего умеет.
Alloy - это более комплексный коллектор телеметрии, а не просто экспортер host-метрик, который кстати использует под капотом node_exporter (https://grafana.com/docs/alloy/latest/reference/components/prometheus/prometheus.exporter.unix/). Он хорош для OTEL-подхода и единого сбора метрик, логов и трейсов, но здесь речь именно про базовый мониторинг хоста, где node_exporter остается более простым и уместным инструментом.
А как воспроизвести в графане те продуманные и провереные алармы на все случаи жизни и под все известные способы коммуникации? Которые кстати предустановлены в идущем в комплекте с заббиксом шаблоне линукс хоста (который вы почему-то хотели "подбирать").
Наверное долго и сложно создавать все правила руками?
Zabbix действительно силён тем, что это “всё в одном”: сбор, хранение, шаблоны, триггеры и уведомления. И да, Linux template можно включить почти сразу.
Но в статье я не пытался доказать, что Zabbix плохой или что его надо “заменить”. Задача другая: показать простой и быстрый способ стандартизировать базовые метрики хостов в уже имеющемся стеке Grafana/Prometheus и закрыть это безопасно, не поднимая ещё один тяжёлый сервис там, где он организационно может не зайти.
Про “всё руками и долго”, не совсем так: для node_exporter есть готовые дашборды, а базовые алерты обычно берут из готовых пакетов/шаблонов и уже потом подгоняют пороги под реальную инфраструктуру, но это как я уже писал выше, это творческий аспект зависящий от тех метрик которые интересуют в первею очередь и заслуживающий отдельную статью.
Эта статья не про то, что Zabbix плохой (он нормальный, мощный и во многих местах идеально подходит). Статья про другое: как быстро и без лишней тяжести получить базовый мониторинг хостов в уже существующем стеке Grafana/Prometheus, когда поднимать ещё один большой сервис/зоопарк по разным причинам не хочется или нельзя.
Мне ещё кажется, что в RU-сегменте связка node_exporter → Prometheus → Grafana до сих пор заметно менее распространена, чем тот же Zabbix, поэтому и решил показать простой рабочий путь “с нуля до метрик”, чтобы у людей было больше вариантов.
Для П1, кажется, нужно использовать пакеты, а не заниматься ерундой.
А почему не взяли VictoriaMetrics?
Хороший вопрос, я взял Prometheus, потому что он проще и быстрее для старта: один сервер сам собирает, хранит и отдает метрики без отдельного хранилища и лишних компонентов. VictoriaMetrics имеет смысл брать, когда метрик станет много, нужна длинная ретенция или Prometheus начнет упираться в ресурсы.
Zabbix тормоз, а prometheus шустрый парень. К тому же grafana позволяет вывести через плагины до фига всего, плагин zabbix тоже есть, :) который выглядит симпатичней на grafana,чем на родном движке.
Вместо:
Zabbix agent -> Zabbix server -> Grafana
Вы сделали:
node_expoter -> Prometheus -> Grafana
Но ваше решение полегче и менее костыльное, ибо для Zabbix в Grafana используется отдельный плагин, который довольно стрёмный и не очень поддерживается сейчас.
А так, Zabbix больше подходит для мониторинга инфраструктуры (ОС, БД, железки всякие через SNMP (сетёвка, ИБП и даже принтеры), доступность портов, чуть ущербная проверка доступности веба, и пр. - базовое в общем). А Prometheus больше адаптирован для мониторинга приложений, где разработчики что захотели, то и выдали в метрики, да и всё остальное связанное с куберами, докерами и пр. лучше мониторить в формате Prometheus.
Zabbix более юзерфрендли, в некотором смысле, без yaml и прочего, и по сути эдакий сельхоз комбайн, к которому через костыли можно прикрутить почти что угодно, и который едет, пыхтит и чадит, но едет. Можно и кастомные SQL запросы прикрутить, к примеру, без особых сложностей. Но дискавернинги там это отдельный вид мазохизма)
Сбор метрик в Prometheus уже больше похож на многоцелевой истребитель, который летает, но к которому примастырить что-то кастомное уже значительно сложнее. Отдельные экспортеры программировать и пр.
У нас есть и то и то, с Victoria Metrics правда. И каждый под свои нужды (инфра на Zabbix, а где актуален сбор метрик в формате Prometheus - там Victoria Metrics). Визуализируем всё в Grafana, как и вы. И если в планах масштабировать сбор метрик в формате Prometheus, если их будет действительно много, то лучше сразу на Victoria Metrics уходить - там всё на много лучше с большими объёмами данных.
А если со временем нырнёте ещё и в Zabbix, то это да - вообще отдельная история.
Так что для начала ограничиться Prometheus весьма и весьма разумно, но если на хостах потребуется мудрить кастомные метрики, то очень вероятно придётся подумать и о Zabbix, а там уж и до сбора логов не далеко, с отдельными системами мониторинга, типа Graylog.
Полностью согласен, для старта node_exporter -> Prometheus -> Grafana - как по мне, самый простой путь, хотя Zabbix действительно "умеет больше из коробки". И это еще без учета утилит, например, blackbox_exporter, которые позволяют мониторить не только метрики, но и доступность сервисов через HTTP/TCP/ICMP и другие кастомные проверки.
С логами история уже совсем другая: это отдельный контур, отдельные платформы и отдельная философия. У нас для этого используются SIEM (и не одна) и еще отдельные системы хранения "ИТ-логов", но Grafana по итогу всегда выступает как единая витрина, куда сходятся метрики и состояния самих сервисов и систем.
Ну и отдельно соглашусь насчет VictoriaMetrics (вместо Prometheus): если изначально понятно, что метрик будет много и система будет масштабироваться, то это действительно более удачный вариант как хранилище, на больших объемах она обычно выглядит сильнее и практичнее.
А почему бы не в докере все это разворачивать?
Гайд по быстрому мониторингу Linux-хостов в Grafana без Zabbix