LINUX.ORG.RU

Вышел Zabbix 4.0

 , , ,


4

3

Состоялся релиз свободной системы мониторинга с открытым исходным кодом Zabbix 4.0. Zabbix – универсальная система для мониторинга производительности и доступности серверов, инженерного и сетевого оборудования, приложений, баз данных, систем виртуализации, контейнеров, ИТ-сервисов, Web-сервисов.

Система реализует полный цикл от сбора данных, их парсинга, анализа получаемых значений, и заканчивая их хранением, визуализацией и рассылкой оповещений, используя правила эскалации. Представляет гибкие возможности расширения методов сбора и оповещений, а также возможности по автоматизации через API. Единый веб-интерфейс реализует централизованное управление конфигурациями мониторинга и распределение прав доступа различным группам пользователей. Код проекта распространяется под лицензией GPLv2.

Zabbix 4.0 - это LTS версия с пятилетней поддержкой. Рекомендуется для пользователей, которые ориентируются на надёжность и длинный цикл внедрения программных продуктов.

Основные улучшения версии 4.0:

  • Новый встроенный тип элемента данных “HTTP агент” для универсального сбора данных по протоколам Rest API, XML, SOAP, JSON RPC, Prometheus и неструктурированных данных
  • Управление пользовательскими правами просмотра проблем, основанное на тэгах
  • Улучшение общей производительности сервера и прокси в среднем на 10-20%
  • Существенное ускорение передачи данных при использовании прокси благодаря компрессии передаваемых данных
  • Новый расширенный виджет для графиков: выбор элементов по шаблону, отображение проблем, и много других усовершенствований
  • Идентификация пользователей позволяющая интегрироваться с single signon решениями
  • Полноэкранный режим киоска для всех страниц секции мониторинга
  • Поддержка удобного просмотра списка проблем в сжатом виде
  • Новый очень практичный селектор выбора периода времени
  • Официальная поддержка ElasticSearch как движка для хранения исторической информации
  • Возможность использования инвентарной информации в тегах проблем
  • Более гибкая работа с проблемами: возможность комментариев без действий, ручного изменения важности проблем
  • Возможность форсирования выполнения проверки или LLD правила из интерфейса
  • Поддержка управления обслуживания устройств с помощью тегов
  • Улучшенные встроенные дашборды, доступные при установке
  • Гибкий фильтр про тегам в списке проблем с дополнительными возможностями
  • Оптимизация интерфейса для людей с нарушениями зрения плюс две дополнительные высококонтрастные темы
  • Возможность поиска проблем по имени
  • Возможность изменить принадлежность устройства к шаблонам при повторной авторегистрации
  • Более сдержанный дизайн виджетов без показа времени обновления
  • Новая проверка vfs.dir.count на стороне агента для рекурсивного подсчёта количества файлов (и не только!) в директории
  • Дублирование собранных данных (значения метрик, проблемы) в локальную файловую систему в режиме реального времени
  • Поддержка условия “не соответствует регулярному выражению” для правил LLD
  • Возможность отправки одного емайл сообщения сразу нескольким получателям
  • Более развёрнутое сообщение об ошибке в случае проблем с доступностью базы данных
  • Разрешено использовать главные элементы данных (master items) для прототипов элементов данных
  • Удалена секция Мониторинг->Триггеры из интерфейса
  • Увеличен размер DNS имени устройств
  • Поддержка макросов вида $1-$9 помечена как устаревшая и будет удалена в версии 5.0

Для перехода с более ранних версий необходима лишь установка новых серверных бинарных файлов (сервер и прокси) и нового интерфейса. Zabbix автоматически проведёт процедуру апгрейда базы данных. Установка новых агентов не требуется.

С полным списком всех изменений вы можете ознакомиться в документации.

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от user_undefined

Ну да, у меня по диску запас по nvps приличный тоже, в CPU упрётся раньше, придётся второй добавлять.

AlexAT ()
Ответ на: комментарий от stels

С переездом на TokuDB всё просто, если MariaDB 10.2+.

Ставим модуль TokuDB, конфигурим его .conf в my.cnf.d, выключаем transparent_hugepages, перезапускаем мускуль.

Далее делаем alter table history(_uint,_float,_str,...) engine=TokuDB. Но от партиционирования всё равно лучше не отказываться.

Не пытайтесь перевести на TokuDB другие таблицы - там куча foreign keys, а TokuDB в них не умеет.

AlexAT ()
Ответ на: комментарий от DRVTiny

При этом есть ошмётки разного рода функционала, развитие которого бросили на 30-50%, а иногда и просто сначала добавили, а потом выпилили:

инвентаризация еще, внятного отчёта так и нет.

anonymous ()
Ответ на: комментарий от WitcherGeralt

Что то не получилось...

ln -s /usr/bin/fping /usr/sbin/fping
zabbix_agentd -t icmppingloss[8.8.8.8,30,,,]
[m|ZBX_NOTSUPPORTED] [Unsupported item key.]

Какие то ещё настройки делали?

gobot ★★★★ ()
Ответ на: комментарий от DRVTiny

Хз, у нас объемы сопоставимые, подгрузка данных не то чтобы моментальная, но приемлемая. Правда, мы на серверах не экономим никогда.

leave ★★★★★ ()
Ответ на: комментарий от anonymous

Nginx шлет статистику по TCP в td-agent-bit (с помощью lua), который в свою очередь шлет на td-agent на сервере с clickhouse. Пишется все в одну таблицу из которой разбирается в другие материалайзед таблицы по разным критериям.

Приблизительно как здесь https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-c...

Perlovka ()
Ответ на: комментарий от mx__

Помню лет 7 назад на 500 хостах он тормозил конкретно так и >>пришлось nagios юзать, так там все летало ... и до сих пор >>летает а хостов уже намного больше.

Да, грузил он капитально. Хоть по функционалу и один из лучших.

ChAnton ★★ ()
Ответ на: комментарий от micronekodesu

Наоборот, это какие у grafana и прочих новомодных поделок преимущества перед zabbix, доказавшим свою состоятельность на деле.

ChAnton ★★ ()
Ответ на: комментарий от ChAnton

Так у меня вообще и вопрос о том сможет ли zabbix полноценно заменить grafana сейчас (так как теперь умеет в REST и прочие API).

micronekodesu ★★ ()
Ответ на: комментарий от DRVTiny

ах, как приятно тебя читать:) без шуток. я сам, к сожалению, не занимаюсь больше этой темой, так что могу только пофапать на чужие коменты)

про 8 гиговый партиции оценил. количество данных растет, а принцип хранения к сожалению не меняется.

crypt ★★★★★ ()

Довольно убого выглядит, хоть бы поддержку d3.js прикрутили.

Хотите нормальную систему мониторинга - используйте Zenoss Core. При небольшом тюнинге тянет 5к хостов как за здрасти. Неструктурированные хранилища прилагаются года 3 уже как.

Ej_Pulsar ()
Ответ на: комментарий от Ej_Pulsar

Выглядеть ? Я хз как вы там позиционируете сабж, для меня нагиос это алертик и его главная функция стукануть что не так и сделать заявку в ... Какой смысл графиков от 25 вентиляторов одного сервера ?

mx__ ★★★★★ ()
Ответ на: комментарий от ChAnton

Графана пашет, а заббикс дохнет. Надо глядеть в лицо тому что происходит

demrnd ()
Ответ на: комментарий от stels

Можно и 10.1, проблем при миграции быть не должно. Мы мигрировали на 10.0, потом апгрейды до 10.1, 10.2, 10.3 (без пропусков) - никаких проблем особых при апгрейде собственно замечено не было. В TokuDB был один хреновый баг, приводящий к неэффективности индексов, но оно сейчас вылечено уже.

AlexAT ()
Ответ на: комментарий от mx__

Девопсы любят красивые и бесполезные графики.

Задача мониторинга - мониторить и алертить, в т.ч. по сложным критериям. Все графаны, зеноссы и прочие eye candy в этом плане оказываются беспомощны и требуют костылей.

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

Ну и по контексту: 1. Графановская документация - она ужасна. Это не документация, это рекламный проспект скорее. У Zabbix документация разложена по полочкам, все детали реализации подробно описаны - после вдумчивого прочтения никаких вопросов, как забабахать ту или иную фичу, не остаётся. 2. Зеносс настолько не гибок в конфигурации, что сложные триггерные критерии в нём построить практически невозможно. Это скорее всё для тех же трёх с половиной серверов с софтом, покрываемым тем, что есть «из коробки».

AlexAT ()
Ответ на: комментарий от AlexAT

Девопсы любят красивые и бесполезные графики.

Задача мониторинга - мониторить и алертить, в т.ч. по сложным критериям. Все графаны, зеноссы и прочие eye candy в этом плане оказываются беспомощны и требуют костылей.

И как ты по алертами будешь оценивать, например, рост баз за год? Или рост потребления cpu/mem? Не зря тот же заббикс хранит историю, что очень сильно помогает в расследовании инцидентов, особенно если на каждом отдельном узле вроде бы все и хорошо, а все вместе тормозит.

Графана с ее шаблонами позволяет делать намного более удобные дашборды, нежели заббикс, в котором поддерживать в скрины в актуальном состоянии выливается в дикий гемор. А данные в графану прекрасно загружаются из того же заббикса.

К плючам заббикса я бы добавил поддержку почти любой ОС, никакие прометеусы тут и в подметки не годятся.

user_undefined ()
Ответ на: комментарий от AlexAT

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

Я же писал что давно когда пробывал сабж то он не справлялся с нагрузкой и остановились на nagios. Хз как сейчас.

На nagios ВСЕ мониторится без проблем, начиная с алертов всяких ip камер и заканчивая сессиями на потоке Е1 астерисков. А что у сабжа в качестве nrpe ?

mx__ ★★★★★ ()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

А что у сабжа в качестве nrpe ?

zabbix agent

anonymous ()

замечательная система!

DILIN ★★★★ ()
Ответ на: комментарий от AlexAT

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

Да и вообще, традиционная парадигма коврового мониторинга начала 90-х с этими шаблонами и штормами алертов, уходит в прошлое. Бал правят метрики из текстовой операционной даты (логи, очереди метаданные со span и тд). Динамические пороги, с профилированием узлов по модным алгоритмам, навроде MAD или ARIMA. Также транзакционный мониторинг: конкретного действия конкретного клиента, который измеряет проблему не в метриках ИТ систем, а в людях, деньгах, репутации и, как следствие, степени эскалации и напряжении булок ИТ.

Чтобы не оффтопить: а что там у заббикса с англоязычным коммьюнити? Оно достаточно развито? Можно ответ где-нибудь на stack overflow быстро получить?

Ej_Pulsar ()
Последнее исправление: Ej_Pulsar (всего исправлений: 4)

Странное обновление. Пришлось столбец «timeout» из «items» дропать, чтобы демон смог базу обновить.

post-factum ★★★★★ ()
Ответ на: комментарий от AlexAT

В том-то и дели, что нельзя это делать автоматически. К сожалению, все реализаций партиционирования (MySQL, PostgreSQL) страдают от одной простой проблемы - падения производительности при большом количестве партиций. Поэтому невозможно подобрать универсальное пратиционирование для всех сразу.

alexvl ()
Ответ на: комментарий от DRVTiny

Очень многое, чего ждали от 4.0, так и не случилось,и это несколько обескураживает:

Не всё сразу. Возможно, порадует то, что удалось сделать. :)

1) До сих пор нет возможности подключать любой драйвер для записи >timeseries-данных. Если бы это было возможно, и если бы механизм >был описан, сообщество само бы создало драйвер для записи в >нормальную time series db, раз уж в Риге на это никак не решатся >по каким-то неведомым причинам

Мы идём к этому.

Если очень хочется, то можно использовать протокол Elastic Search для прикручивания любых движков уже сегодня.

2) Elastic Search - не time series db, накладные расходы на >чтение истории метрик из неё тоже чрезмерно высоки, хотя и >поменьше, чем в случае с MySQL и прочими РСУБД, по определению не >предназначенными для хранения временных рядов

Это все понимают, поэтому и есть выбор того, какие именно данные (например только логи и строковые) хотите хранить в ES. Функциональность экспериментальная.

Если нужно в режиме реального времени параллельно лить собранные данные и события в другое хранилище, то используем для этого новую функциональность 4.0.

3) Нет подвижек в сторону развития малоюзабельных сейчас IT >Services, хотя тема ITSI давно уже является ключевой в планах >развития всех известных мне крупных систем мониторинга

Будет, подождите.

4) При наличии очень странного разделения на нормальный серверный >Zabbix API мизерных размеров и огромный тупой и неповоротливый >PHP Zabbix API на стороне фронтенда, ничего не сделано для отказа >от последнего в пользу первого. На мой взгляд, это не очень >здорово хотя бы по той причине, что делает фронтенд zabbix не >фронтендом, а по сути неотделимой от ядра компонентой. >Традиционная архитектура подобного рода приложений предполагает, >что можно легко выкинуть штатный фронтенд и заменить своим, но >zabbix-морда предоставляет безальтернативный «как бы API», >общающийся напрямую с базой данных, а не с сервером zabbix и к >тому же делает вовсе странные вещи типа расчёта SLA для IT >Services, хотя этим просто на 150% обязан заниматься сервер

Всё верно сказано.

5) Так и нет иерархии групп, как и не появилось даже проблеска >понимания того факта, что «группа» может быть таким же объектом >мониторинга, как и «хост». Привет, «сгруппированные»/ >агрегированные метрики, для которых по-прежнему нужно создавать >фейковый «типа хост»

Иерархия групп есть, но это не главное.

От понятия хоста мы постепенно уходим, но это пока не слишком заметно для стороннего наблюдателя. Тэги, которые появятся как на уровне шаблонов и «хостов», так и (но это не точно) на уровне метрик, позволят нам это сделать.

6) Триггеры, объединяющие метрики из разных шаблонов, триггеры по >состоянию IT-сервисов - всё в минус.

7) До сих пор нет встроенного SNMP-трапера и нет «ленты событий», >которая позволяла бы видеть временное окно с event'ами, >генерируемыми теми же входящими trap-сообщениями. Вся логика >событий безальтернативно триггерная, нельзя просто узнать о том, >что железка tell me something, нужно непременно строить логику >непонятно как закрываемых триггеров

Закрывайте в ручном режиме.

8) До сих пор нет мониторинга systemd-сервисов и вообще поддержки >systemd для мониторинга, хотя это вообще ключевая вещь в >современных Linux-системах.

Критика услышана.

alexvl ()
Ответ на: комментарий от alexvl

Будет, подождите

Готовый слоган для Zabbix!

muon ★★★★ ()
Ответ на: комментарий от DRVTiny

Очень многое, чего ждали от 4.0, так и не случилось,и это несколько обескураживает:

А что посоветуете фришное вместо Zabbix, где все хорошо?

linlin ()
Ответ на: комментарий от alexvl

Не надо делать партиционирование средствами движка. Проще разбивать историю на таблицы history_*_YYYYMMDD сразу. В голове бродит патчик, но он очень обструктивный получается, лучше конечно это dev team движка делать.

AlexAT ()
Ответ на: комментарий от Ej_Pulsar

Зеносс на гибок? Вы видимо питоновские алерты не осилили

Алерты на внешних скриптах - это адовый костыль. То есть мы признаём, что это не мониторинг, а скорее рисовалка дашбордов для менеджмента среднего звена.

AlexAT ()
Ответ на: комментарий от AlexAT

Думали мы над этим. Ни к чему хорошему такое решение не приведёт.

alexvl ()

Годно. Ждём ебилдов.

bsdfun ★★★★★ ()
Ответ на: комментарий от AlexAT

А заббиксе чего - они автомагически не внешние костыли? Те-же кривульки скрипты вызываемые из ${confdir}/alert.d/ на любой чих.

А так - как было УГ, так и осталось УГ. Добавили зелененького - убрали зелененького. Работа. А названия графиков как были максимум 128 символов - так и остались.

Да и список быстро пофикшенных багов к 4.0.1 - впечатляет.

LynxChaus ()
Ответ на: комментарий от linlin

Во фришном - так или иначе везде плохо, но всё-таки по разным причинам :)

DRVTiny ★★★★★ ()
Ответ на: комментарий от LynxChaus

А заббиксе чего - они автомагически не внешние костыли?

Самый распространённый вариант - отправку почты, - сделали внутренним механизмом, да ещё многопоточным, так что можно спамить просто по-чёрному (это ж довольно неплохой сишный код будет спамить хоть всеми ядрами процессора).

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

У меня, например, алерты передаются perl'овой утилитой на единую шину событий - канал Pub/Sub в Redis, откуда его забирают все желающие. Весьма удобно, универсально, легко добавить любую новую информацию о событии (публикуется JSON). Как бы это делал Zabbix?

Или, например, как насчёт того, чтобы в Zabbix для over 9000 мессенджеров сделать встроенные алерт-механизмы? И всё равно найдутся недовольные пользователи 9001-го IM'а...

Zabbix обеспечивает удобную настройку алертов, включая передачу любых параметров внешним приложениям. Что ещё требуется-то для счастья?

DRVTiny ★★★★★ ()
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Самый распространённый вариант - отправку почты, - сделали внутренним механизмом, да ещё многопоточным, так что можно спамить просто по-чёрному (это ж довольно неплохой сишный код будет спамить хоть всеми ядрами процессора).

Не, не будет. Встанет раком на перманентном «update alerts set status=%d where»... И смотри не собери заббикс без curl'a - а то авторизации не будет. И в 40 секунд уложись с отправкой алерта, а то дядя лучше знает - как у тебя все должно работать.

У меня, например, алерты передаются perl'овой утилитой на единую шину событий - канал Pub/Sub в Redis, откуда его забирают все желающие. Весьма удобно, универсально, легко добавить любую новую информацию о событии (публикуется JSON). Как бы это делал Zabbix?

Как-как. За 8000 евро и через жопу.

Или, например, как насчёт того, чтобы в Zabbix для over 9000 мессенджеров сделать встроенные алерт-механизмы?

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

Можно встроить ОДИН универсальный отправлятор JSON'а средствами curl в конфигурируемый с уёб-морды url с логином/паролем. Ибо curl уже прилинкован. Но 8000 евро - жмоты пишут скриптики.

LynxChaus ()
Ответ на: комментарий от AlexAT

Курите букварь, вы не в теме. Совсем. В зеносс эти механизмы встроены и редактируются прямо из интерфейса. Объекты РСМ доступны как объекты.

Ej_Pulsar ()
Последнее исправление: Ej_Pulsar (всего исправлений: 1)
Ответ на: комментарий от LynxChaus

И что делать с этим отправленным JSON'ом? Он как-то сам, без «скриптиков» превратится вдруг в почтовое сообщение? Или вся «крутизна» в том, что на другой стороне будет уёб-сервер, а это «по-пацански», даже если это какой-нибудь говёный django там?

DRVTiny ★★★★★ ()

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

mcdebugger ★★ ()
Последнее исправление: mcdebugger (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

И что делать с этим отправленным JSON'ом?

отослать в «запрещенно роскомпозором (тм)».

Он как-то сам, без «скриптиков» превратится вдруг в почтовое сообщение?

скрипач не нужен почта? пока она дойдет - этот алерт уже можно забыть. А если не можно - то зачем его высылать?

говёный django там?

да пофигу. Там можно напрячь другого пейсателя скриптиков за бабло, чтоб делал уведомления для любителей красивых картинок в красивых уеб-интерфейсах. через sms/ватсап/всякухрень которая там модна нынче. И показывал на «корпораффном партале» за 100500 денег.

Впрочем, разговор пустой. Тебе нравится почта - пользуй почту. Мне нравится вариант получить денег за скриптик. Но не нравится полное отсутствие архитектора в онном продукте. Но пипл хавает, конторы - донатят, программеры пишут портянки бесполезного кода в стиле «Yoda conditions» - все заняты. Работа ради работы, сэр.

LynxChaus ()
Ответ на: комментарий от Perlovka

сорян за офтоп. Михаил если есть возможность выложи свой старый конфиг fwvm, если не жалко/остался.

anonymous ()
Ответ на: комментарий от anonymous

Фига ты вспомнил, еле нашел по бэкапам ) Там три разной степени готовности вроде, тот который выглядит как винда, вроде был последним. Я хз, рабочее оно вообще или нет )

http://rgho.st/8bfY9wqKF

Perlovka ()
Ответ на: комментарий от DRVTiny

Но в конечном итоге из разного рода костылей и палок появляются Ябиксы, Магнитиксы, ОТМониксы и прочие, и прочие ответвления, наработки которых не возвращаются в исходный zabbix. По сути у любой крупной компании рано или поздно появляется свой Zabbix, который в лучшем случае тяжело апгрейдится из-за массы левых доработок.

Собсна, так и есть. Как, например, с помощью любой системы мониторинга контролировать передачу изображений между DICOM-сервером и клиентом? Как мониторить низкоуровневые сервисы серверов, к примеру, Hewlett Packard с их Insight Lights Out? Или рейд-контроллеры «нормальных» серверов, не hp? Или контроль качества передачи RTP через asterisk? Заббикс тут используется, как панель вывода информации, собранной в кучу собственными конструкциями. От этого, как мне кажется, никуда не денешься. Я считаю, что и замечательно, раз можно запиливать и допиливать свои сервисы под свои задачи, где Заббикс используется, как некий датацентр со сбором, хранением и анализом информации. И документация его написана шикарно, для того, чтобы запилить свои LLD и метрики под требуемый сервис. Немножко баша (если линуксы), немножко павершелла (если винды) — и работает.

Правда, вычитанный тут пост про загубленный UserParameter меня напряг — собственные скриптовые конструкции на баше для агента работают через UserParameter.

Что очень не понравилось в Заббиксе — куцый IT Services. Нет возможности запилить корректно свои интервалы времени сбора по алертам. Допиливание во фронтенде, когда сидишь и «пыхаешь» операторами в php-скриптах, действительно, приводит к ситуации, когда шаг влево, шаг вправо — расстрел.

AquaBlast ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.