Вышел Zabbix 4.0

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

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

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

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

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

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

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

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

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

Нет.

mariadb 10.1 уже идет с TokuDB, или не хватает чего то ещё?
Обновлять мускуль не хочется.

https://www.zabbix.com/documentation/3.4/manual/api/reference/item/create вот это вот, например. А вы о каком API речь ведете?

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

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

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

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

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

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

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

10.1 точно умеет TokuDB, возможно отдельным пакетом ставится

Если это вопрос - то да, умеет, ставиться отдельным пакетом.

Не, это был ответ )

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

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

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

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

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

Сформулирую по другому вопрос)
mariadb 10.2 минимальная версия для без проблемной миграции на TokuDB?

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

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

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

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

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

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

Как боженька смолвил.

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

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

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

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

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

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

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

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

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

zabbix agent

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

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

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

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

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

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

Очень многое, чего ждали от 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-системах.

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

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

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

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

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

Zenoss

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://rgho.st/8bfY9wqKF

Спасибо тебе большое.

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

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

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

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