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 ()
Последнее исправление: alexvl (всего исправлений: 1)

Хорошая новость! Вот тут https://www.zabbix.com/download_agents пока что нету предварительно откомпилированных агентов версиии 4.0 LTS, а только 3.4 самая новая. Кто скажет, можно от 3.0 LTS агенты заюзать для только что вышедшего релиза?

Infra_HDC ★★★★★
()

Крайнее неудобство (мягко говоря) доставляет отсутствие возможности выбрать версию SNMP на уровне интерфейса хоста. Планируется ли реализовать ZBXNEXT-2613? Если да, то когда?

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

Планируется, но не могу обещать когда.

alexvl
() автор топика

надо чтоб агент умел сам hostname смотреть. Руками вбивать не айс. Впринципе очень много ручной работы. Зачем-то инвентаризация встроенная. Проще инфраструктуру под заббикс подгонять, чем наоборот. И вообще пока не понял, чем он лучше голых скриптов, ну если только хранением истории. Единственное чем хорош заббикс - это затыкание дыры среди систем мониторинга в опенсорсе.

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

Ничего странного в этом нет. Странно как раз, что вы об этом не знаете. Постоянно при апгрейде базы происходит всякая фигня. То тут не смогло, то там упало. На 4 даже боюсь апгрейдиться, неохота опять все это чинить.

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

Мы оставили на заббиксе только базовый мониторинг хостов. И то только потому, что лень переносить. Остальное уехало на clickhouse + grafana. Небо и земля просто.

Это, так скажем, отзыв за 6 лет использования. Далеко не первые впечатления.

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

Ну и сам продукт оставляет желать лучшего. Гибкости в настройке никакой.

не самая главная беда. главная в том, что проектированием занимаются странные люди- взяли, сломали UserParameter в 3.4, считая что всегда должен возвращаться 0. ну да, вернули, но ... а уж бага с правами на карты в 3.4, которая , как выяснилось, тоже ошибка совсем не реализации.

обновился кто до 4 то? как оно?

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

Обновился с 3.4 на 4.0.

Пока тестовый стенд, но приближенный к реальным условиям. Проблем не увидел, кроме необходимости перезапуска mуsql, иначе ругалось на нерабочую базу.

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

И там скорее всего десяток патчей своих (исходя из собственного опыта с несколько меньшей инсталяцией говорю в 3ей версии из коробки, например, завезли ui который на тысяче хостов много десятков мегабайт json грузит при загрузке дефолтной дашборды)

P.S. В любом случае будем посмотреть 4.0. Опять патчи ковырять видимо. P.P.S не прошло и 20 лет как в заббиксе появились алерт лвл мнт и ручной перезапуск актив чеков.

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

Неплохо бы тогда где-то прямо на сайте выложить набор xml для стандартного комплекта, кому надо - развернут.

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

Обновил здоровую инсталляцию. Полёт нормальный.

AlexAT
()

Раз уж сам основатель тут, напишу хитрый фичреквест сюда, а не в багтрекер. Так, на подумать.

Все по сути крутят партиционирование под хистори, так или иначе. Очень хотелось бы вместо одной группы history_* иметь что-то вида history_YYYYMMDD_*, автоматически. И то же самое для events. По сути, сделать это в синхронизаторе данных - вообще не проблема, основная проблема - нужно будет выгребалку данных делать так, чтобы она даты начала-конца брала посуточно, и фигачила вместо одного запроса N на каждый день. По производительности будет в итоге лучше, и не нужно будет мучаться с удалением данных в хаускипере - определил последний день, выгреб из него distinct itemid, посмотрел кого из них удалить, удалил. Или наоборот - выгреб для каждого itemid первый день хранения, и покоцал из всех более ранних.

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

Агент умеет смотреть хостнейм, go rtfm :) HostnameItem=system.hostname вроде

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

Ну у меня ничего не упало :) Апгредилось часа 4 только, табличка events зело большая.

AlexAT
()

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

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

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

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-системах.

Что появилось: красивые графики, содержимое которых по прежнему вытаскивается тяжеленными запросами в РСУБД или в Эластик, какая-то ещё более забубённая и непонятно кому нужная логика закрытия «Проблем», развитие катастрофически реализованной с т.з. СУБД темы тэгов (тэг - не наследуемый объект, на который ссылаются из таблиц, тэг - это копируемая сущность без всех нормальных реляционных привязок, реализованы чуть лучше, чем откровенный треш с «ирерархическими группами», но всё равно на уровне ниже первого hello, world'а на тему СУБД). Сжатие притащили - видимо, из-за того, что его было просто реализовать, а не из-за того, что тьмы несметные пользователей об этом просили (мне это точно не нужно было никогда, но наверняка есть 1.5 человека, которым нужно). vfs.dir.count - замечательно, но смешно хвалиться такими изменениями при выходе мажорной версии системы мониторинга.

Фронтенд стал ещё более безальтернативным и незаменимым, ключевые возможности ядра системы не реализованы, хотя о многих из них просили давным-давно.

Очень надеюсь на подвижки в 4.2, как это было с Zabbix 3.2, когда в 3.0 ничего по сути не поменялось, а в 3.2 «приплыла» тонна важных и нужных изменений.

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

Никто в 2018-м году не пишет history в СУБД, это подход, который был актуален хоть как-то при совсем других потоках данных.

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

Как видишь, легко пишется. Без особых проблем. Просто хотелось бы автоматизации сего хозяйства.

Если мне понадобится - я поверх того же MariaDB приверну хранилку для timebased. Но это только если понадобится.

А накручивать на мониторинг десяток докеров со смузи ради «не писать в БД» - это только если совсем уж делать нечего.

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

В Zabbix хороший функционал для инфраструктурного мониторинга что называется «в моменте». Для мониторинга приложений и анализа инцидентов он не годится, но его никто и не позиционирует в этом качестве.

Тем не менее я полностью согласен с тем, что развитие zabbix происходит совсем не по тем направлениям, которые нужны всем, а как-то хаотично и с явным упором на managers-related популизм: в первую очередь пилится «крутая» веб-морда, на которую легко клюнут менеджеры, а на развитие ключевого функционала тупо забивается болт даже не годами, а больше десяти лет.

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

1) Кластерный zabbix (помните nodeid's до 2.2?)

2) Мониторинг VMware (убог как не знаю что)

3) IT Services (могла быть просто killer-feature для open source'а-то, но заброшена с концами)

4) API на стороне сервера - движение в эту сторону декларировалось на протяжении всей истории zabbix, но в итоге всё остановилось на 4-х или 5-ти API-вызовах, о существовании которых 99% заббиксоидов даже не знают

5) MIB-загрузчик (преобразователь в шаблоны) - был в старых версиях zabbix, но выпилен по причине «нам лень возиться с чужим кодом». Загрузчик был написан человеком со стороны, а не «своим», что предопределило его печальную судьбу.

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

Вы точно в курсе существования timeseries db и того факта, что 100% современных систем мониторинга их используют? Рекомендую въехать в тему, она действительно очень интересна и поучительна.

А чтобы у вас «не работало» - попробуйте вычислять хотя бы метрики-перцентили, ну или триггеры с выражениями типа max(#10) - и приходите, делитесь впечатлениями. Только лучше заранее приготовьте вазелин и валидол.

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

Загрузчик MIB вполне можно запилить самостоятельно :)

С другой стороны, на моей практике мне ещё ни один MIB даже руками загрузить линейно не удавалось, очень многое делается на LLD, а они меняют подход.

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

Без всякого вазелина вычисляются. Просто не надо вычислять их каждую секунду за годовой период, и всё.

max(#10) тоже есть, даже avg(#четырёхзначные числа) местами

Всё это прекрасно в пул движка БД ложится. Ну и опять же, не каждую секунду делается.

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

Ну и предвкушая тему про графики - у нас своё решение. Завязанное как раз на ту самую хистори БД, но проходящее её однократно по мере накопления.

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

И какой VPS?

Насчёт переноса таблиц history_* в timeseries типа InfluxDB средствами самой MariaDB не слышал, похоже немного на чудеса. Не подскажете направление мыслей?

Относительно #кол-во метрик - проблема возникает абсолютно стабильно, например, при банальном заведении нового хоста. Мне для обхода этой проблемы пришлось написать патч, уменьшающий глубину поиска до недели. По дефолту там поиск ведётся на месяц, год, а потом вообще «в бесконечность». Это особенно «логично» когда считается триггер по метрике, обновляемой раз в 30 секунд. Ничего разумнее придумать нельзя: если такой метрики нет ни за прошлый час, ни за день, то надо просто искать до упора назад - а вдруг найдётся?

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

К счастью, меня эта тема интересует меньше всего, поскольку у нас весь мониторинг на триггерах и алертах, на графики смотрим по каким-то определённым случаям, и чаще всего хватает простых trend'овых значений.

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

Загрузчик MIB вполне можно запилить самостоятельно

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

С таким же успехом самостоятельно делается взвод триггеров по приёму SNMP-трапов через обычный swatch и метрики-трапперы на zabbix'е, поскольку это гораздо удобнее штатного «функционала».

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

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

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

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

1500+ VPS.

Нормально. У нас на одном инстансе чуть меньше, на втором - больше. Правда, достигнуто просто искусственным урезанием частоты сбора метрик, стараемся не насиловать СУБД и там, где можно было бы долбить раз в 30 секунд, долбим раз в минуту-две.

Насчёт поиска по #10 - какой движок БД?

$ mysqld --version
mysqld  Ver 5.7.17-enterprise-commercial-advanced for Linux on x86_64 (MySQL Enterprise Server - Advanced Edition (Commercial))
DRVTiny ★★★★★
()
Ответ на: комментарий от AlexAT

Хотя нет, одну удобную штуку я планирую выкатить в паблик сразу же, как только время появится, но она опять же изначально под свои нужды делалась, поэтому не универсал.

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

Ну, если говорить о штуках, у меня есть охрененная штука для ITSI, сделанная поверх примитива IT Services. У нас так все иерархические дашборды построены :)

Часть выложил на github, часть нет («древорасчётный» движок не выложил).

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

Да, чистый InnoDB. Ну и у нас не SSD, обычные SAN'ы с обычными дисками, просто в Raid'ах.

Про TokuDB почитаю, очень интересная тема.

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

А у нас SSD, про запас, потому что быстро растём, год назад было всего 1200+ VPS.

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

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

Для мониторинга приложений и анализа инцидентов он не годится

в итоге всё остановилось на 4-х или 5-ти API-вызовах

Удивительно, но именно с помощью этих нескольких апи-вызовов получалось построить вполне рабочую схему мониторинга именно приложений. И что не так с анализом инцидентов, если есть данные по метрикам работоспособности и перформанса приложений?

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

Интерфейсик для хелпдеска в виндовый трей. Сколько ни искал - ничего вменяемого не нашлось, запилил сам.

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

Удивительно, но именно с помощью этих нескольких апи-вызовов получалось построить вполне рабочую схему мониторинга именно приложений.

О каких вызовах речь? Я надеюсь, Вы не путаете протоколы взаимодействия прокси<->сервер, агент<->прокси/сервер с API?

Там по-моему только remote command полезен. Который до 3.4 ещё и можно было толкать без авторизации, на тему чего баг висел долго-долго. Ну и сам формат вызовов немного удивляет: это явно внутренний технический функционал, который не предполагалось, что кто-то извне будет юзать.

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

Прикольная штука :) Классический GUI уже давненько не встречал, все что-то в тотальную веботу подались.

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

И что не так с анализом инцидентов, если есть данные по метрикам работоспособности и перформанса приложений?

У нас каждая дневная партиция что-то уже порядка 8Gb в день, и представьте, что нужно посмотреть исторические данные за 25 дней назад. Не тренды, а именно реальные данные.

Движку БД нужно подгрузить как минимум этот файлик в 8Gb, считать индексы в нём, построить структуры данных необходимые - и выдать ответ. Обычно это происходит... не быстро, мягко говоря.

А как это работает без партиционирования - мне даже представить сложно.

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

заббикс для любителей «готовых решений»

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

А где почитать про переезд на TokuDB?
От забикса что то нужно или достаточно поменять со стороны мускуля?

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

у нас, насколько я знаю от dba, history тоже партицирована в оракле, при nvps чуть больше 6к летает вполне сносо, на базе время отклика по дискам не превышает 2ms.

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

Для мониторинга приложений и анализа инцидентов он не годится

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

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

Ну ты же обычно не за год строишь графики? У меня большой дашборд в графане (~300 items, большая часть собирается раз в 30с) за две недели отрисовывается секунд за 20, что как по мне, вполне приемлимо

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