Комментарии 27
Вот ZBXNEXT для добавления ClickHouse:
Add support for the preservation of historical data in Clickhouse
Так же:
В рамках проекта Glaber создан форк системы мониторинга Zabbix
Glabber немного посмотрели, очень сыро и для узких кейсов. И не очень с поддержкой. Хочется верить что наработки проекта попадут обратно в заббикс.
ИМХО:
в zabbix сами не знают, что им нужно, комьюнити для обкатки версий и баг репортов
фиче голосование? — есть… как сусли, есть и ок, голосвали — молодцы, а мы там посмотрим, что нам нужно для клиентов заносить…
Насчёт IaС — в ansible есть пачка модулей для zabbix: https://docs.ansible.com/ansible/latest/modules/list_of_monitoring_modules.html#zabbix
Там нет работы с пользователями, media и actions, но хосты, шаблоны, скрины — пожалуйста.
Надо честно признать, что ансибль это просто баш на YAML-е. Т.е. императивный язык по сути. Нам не надо работать с "ОБЪЕКТ", хотя мы и применяем эти модули, нам надо было "Загрузить всё из бэкапа".
Да ну, какая императивность? — что мешает описать все ваши шаблоны и объекты мониторинга в виде нескольких yaml-файлов? Применять их можно в любом порядке, с ними легко работать, их можно версионировать, хранить в vcs, следить за изменениями и работать с ними в разных окружениях.
Что не так-то?
Сейчас только храним объекты мониторинга в YAML-е. И это на данный момент 5к объектов (файлов). Можно конечно коммитить туда и импортировать объекты, но пока оказывается что проще скриптами через API создать полтора десятка объектов мониторинга для среднего клиента, чем писать это в ямле. Плюс с большой частью объектов модули ансибля не работают.
Оказывается, применять ямлы можно только в определённом порядке. Объекты — сложные, между ними много взаимозависимостей. Это сейчас не учитывается. Поэтому и смотрим на терраформ (как на образец для вдохновения) — разруливалку отношений между объектами.
Ансибл как раз-таки декоративный: "добейся такого-то состояния".
www.zabbix.com/whats_new_4_4
Почему не решились отказаться от заббикса?
Ну, не знаю — графит, прометеус, icinga?
Или может даже sensu?
Или это именно пожелалка клиентов, которые хотят иметь знакомый инструмент ?
Как будто прометеус — не про метрики.
Zabbix хорош своей гибкостью и подходом все данные.
звучит, как рекламные материалы. Давайте будем честны. Плюсы заббикса:
- это коробочное решение. Якобы ты его поставил, быстренько настроил и можешь работать. Хороший набор интеграций из коробки.
- из п.1 следует, что у разработчика можно купить поддержку. Хорошо для энтерпрайза.
- многие УЖЕ привыкли к заббиксу и его заебиксам.
Все. Остальное — это минусы. И прожорливость базы. И невозможность декларативно его настроить. И необходимость подпиливать его, а потом таскать свои доработки и проверять на совместимость с новыми версиями и т.п.
Как будто прометеус — не про метрики.
Да он про метрики. Но он про другие метрики. Простой пример у меня есть коммутатор у него 96 портов. У каждого порта есть три метрики
входящий трафик
исходящий трафик
состояние порта
Устройство тупое и умеет отдавать эти данные только по snmp. Как разложите?
звучит, как рекламные материалы.
Нет в том то и дело. Я много разных мониторингов видел еще когда прометеуса в проекте не было.
это коробочное решение. Якобы ты его поставил, быстренько настроил и можешь работать. Хороший набор интеграций из коробки.
Глубоко ошибочное мнение :) Zabbix требует чтения мануалов и вдумчивого подхода к настройке.
многие УЖЕ привыкли к заббиксу и его заебиксам.
Потому что долгое время ничего лучше вообще не было.
И невозможность декларативно его настроить.
Экспорт и импорт там внезапно есть и там где его используют декларативная настройка не нужна.
И необходимость подпиливать его, а потом таскать свои доработки и проверять на совместимость с новыми версиями и т.п.
Если вам такое требуется при работе с zabbix он вам не нужен.
Вы просто заходите не с той стороны. Если вы планируете мониторить какие-то контейнеры и микросервисы, то да можно использовать zabbix. Но это будет не очень удобно.
Зато когда у вас 100500 коммутаторов и 100500 однотипных серверов, тогда да zabbix хорошо и удобно. Zabbix это больше про телеком и инфраструктуру. К примеру там парой кликов можно добавить 100500 коммутаторов. Более того сейчас имеется большой наработанный каталог шаблонов для них. И больше про тупые устройства которые надо опрашивать.
Зато когда у вас 100500 коммутаторов и 100500 однотипных серверов, тогда да zabbix хорошо и удобно. Zabbix это больше про телеком и инфраструктуру. К примеру там парой кликов можно добавить 100500 коммутаторов. Более того сейчас имеется большой наработанный каталог шаблонов для них. И больше про тупые устройства которые надо опрашивать.
Тогда — icinga2 & nagios. Ну, и, да, я согласен, что есть сервисный мониторинг (прометеус именно про мониторинг сервисов в первую очередь, иначе приходится костылить экспортеры на все подряд), и есть инфраструктурный — но все равно без агентов или проб не обойтись (тем более, если инфра распределенная). А раз так, то разницы между агентом и экспортером по сути и нет (неожиданно, да?)
Экспорт и импорт там внезапно есть и там где его используют декларативная настройка не нужна.
Давайте еще бекапами базы кидаться друг в друга?
Потому что долгое время ничего лучше вообще не было.
ну, да
Глубоко ошибочное мнение :) Zabbix требует чтения мануалов и вдумчивого подхода к настройке.
Не так. Быстрый старт — да, возможен. Автодискавери и встроенные шаблоны помогают. Но вот продуктивная работа с Z и подгонка его под особенности конкретного предприятия — да, требуют чтения мануалов. Но так, вероятно, с любым продуктом. Автомагически ничего не работает :-/
Устройство тупое и умеет отдавать эти данные только по snmp. Как разложите?
Очевидно, что прометеуса одного будет недостаточно. Придется где-то snmp exporter поставить и настроить его. Но я об этом выше и писал.
Тогда — icinga2 & nagios. Ну, и, да, я согласен, что есть сервисный мониторинг (прометеус именно про мониторинг сервисов в первую очередь, иначе приходится костылить экспортеры на все подряд), и есть инфраструктурный — но все равно без агентов или проб не обойтись (тем более, если инфра распределенная). А раз так, то разницы между агентом и экспортером по сути и нет (неожиданно, да?)
У них подход получаем алярмы, а метрики это так сбоку. В случае zabbix метрики первичны их обработка внутри него. Этим он ближе как раз к прометеусу. Плюс там не важно что за метрика, можно строить какие угодно выражения для генерации событий.
Давайте еще бекапами базы кидаться друг в друга?
Там экспорт импорт шаблонов. Чего вполне достаточно на самом деле.
Очевидно, что прометеуса одного будет недостаточно. Придется где-то snmp exporter поставить и настроить его. Но я об этом выше и писал.
Который туповат и валит все подряд, дальше надо будет еще на сервере правила записи расшивать. Да это декларативно, но это еще надо будет написать.
Как итог возвращаемся к тому, что делается в zabbix неторопливо за час, потребует день писанины в прометеусе. При этом и там и там придется читать документацию.
Устройство тупое и умеет отдавать эти данные только по snmp. Как разложите?
github.com/prometheus/snmp_exporter
Но проблема prometheus-a или же юзверов — они в метриках, метрики как бы если верить приходу «церкви_метрик» — это цифры, а string/char — это не метрика, потому prometheus оптимизирован на данные в виде цифр, а zabbix/icinga/nagios/sensu — уже на значение, которое ты хочешь записать в базу.
zabbix/icinga/nagios/sensu — уже на значение, которое ты хочешь записать в базу.
За sensu не скажу, но у icinga/nagios первичны события, а не метрики. А в zabbix первична метрика. На долгом забеге и большом количестве устройств это реально стреляет.
Все. Остальное — это минусы. И прожорливость базы. И невозможность декларативно его настроить. И необходимость подпиливать его, а потом таскать свои доработки и проверять на совместимость с новыми версиями и т.п.
Zabbix предоставляет мониторинг.
Так что прожорливость базы это недоработка того, кто у Вас проектировал бэкэнд.
Хотя, стоит отметить, что неподдержка из коробки TSDB — это серьезная недоработка Zabbix-a. Все же метрики завязаны на времени.
Это все равно, что выпускать машину с тороидальными многогранниками, вместо колёс, при этом понимая что это для этого не совсем предназначено.
Ехать можно, но не очень.
Вы предлагаете отказаться от Zabbix в пользу:
- Graphite — это система для хранения и работы с метриками. Никаким мониторнгом тут не пахнет.
- Prometheus — сам по себе (без Alertmanager) только собирает, хранит и предоставляет инструменты для работы с метриками. Ну и с долговременным хранением метрик не всё гладко. Но сейчас Zabbix поддерживает работу с его экспортерами. Так что можно настроить работу этих двух систем чтобы они дополнли друг друга.
- Icinga — это вообще каменный век )) Форк Nagios, который имеет несколько полезностей, но в основном, по многим парметрам уступает предшественнику. Ну и сам подход к мониторнгу у этих систем уже устарел.
Я не пытаюсь сказать, что Zabbix — это наше всё, а другие системы — отстой. Всё ситуативно.
Zabbix хорош своей универсальностью и современным "metric-based" подходом.
Но иногда для мониторнга классической инфраструктуры вполне хватает того-же Nagios или Check_MK.
Вы только что взяли и перечеркнули все, что мы делали. Вот чем Вам графит не нравится как центральная часть системы мониторинга? Тем более, если его снабдить дополнительными компонентами — moira, alerta? Просто тот же заббикс сам по себе тоже не покрывает полностью все кейсы. Я когда говорю "графит" подразумеваю именно его не как отдельный продукт, а как экосистему — а там много чего навернуто на базе него и сбоку от него.
Ну, или давайте разбираться, что в Вашем понимании "система мониторинга" и как она может работать без "сбора и хранения метрик".
По прометеусу — согласен. Там есть нюансы именно с долговременным хранением. И мы сами думаем, как их решить. То ли графит рядом поставить, то ли писать в Timescaledb. Или может M3 от убера попробовать. Федерации — шмедерации посмотрели — но это тоже не про долговременное хранение. А! VictoriaMetrics еще в шорт-листе, но до нее руки не дошли
Как мы Zabbix обновляли