Представлена новая версия системы мониторинга с открытым исходным кодом Zabbix 5.0 LTS с большим количеством нововведений. Вышедший релиз включает существенные улучшения безопасности мониторинга, поддержку single sign-on, поддержку сжатия исторических данных при использовании TimescaleDB, интеграции с системами доставки сообщений и службами поддержки и многое другое...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52930
>Оптимизация производительности интерфейса для миллионов устройств мониторингав дашбордных графиках появились поиск и фильтрация метрик для отображения? Кастомной инвенторизации как не было так и не будет да?
зочем вы тгавите? и дай угадаю - по прежнему дурацкие дэшборды невозможно экспортировать, по прежнему autodiscovered screens добываются перанусным способом.
Зато новый-модульный-агент-на-игогогого!(потому что последний программист сбежал из проекта, а нанять удалось только обезьянку)
> зочем вы тгавите?по просьбам телезрителей :)
> дурацкие дэшборды невозможно экспортироватьодна из причин почему я предпочитаю графану
да, но обратная сторона медали - забыл экспортнуть нечто, на что пол-ночи потратил - а с утра графана уже не работает, потому что что-то там себе испортила в своей чудо-базе.С жабиксом такого не то чтоб "никогда не было", но мне оба раза удавалось починить.
Бегите, глупцы.
Крайне специфичная штука этот заббикс, для небольшого количества серверов он оверхэд, для большой и сложной сети поддержка превращается в АД с кучей костылей и ограничений. Это не то ПО которое предоставит вам идеальный мониторинг. Используется в основном как легаси, потому что в 2014 он был самый адекватный, в новых проектах крайне не рекомендую.
>Бегите, глупцы.
>Это не то ПО которое предоставит вам идеальный мониторинг.и вот сейчас ты называешь ПО, которое предоставит нам идеальный мониторинг.
А какие альтернативы ты предложишь?
https://netxms.org/
Это счастье загнётся уже на первой тысяче хостов, на каждом из которых по 50-100 элементов мониторинга. Мимо.
>Both server and agent packages for all current versions of Debian and Ubuntu are available in our repository.
>Server Binaries: Windows (x64)под линукс они как-то по другому называются или без винды оно не работает?
Раз никто не упомянул, но кому-то может пригодиться -- в своё время и для своих задач пришёл к связке collectd+monit, где monit обеспечивает активный локальный мониторинг, а collectd -- пассивный распределённый.PS: я понимаю, что это совсем другая весовая категория, если что :-)
А что вы рекомендуете ? Я перепробовал все, и везде есть свои костыли и ограничения, тот же Prometheus при большой и сложной сети превращается в еще больший ад с которым уже и костыли не помогут, а вот Zabbix по крайней мере куда более гибок.
IBM Tivoli.
Ограничен, в основном, наличием прямых рук и светлой головы (а также кучи денег).
Можно строить огромные системы.
Очень гибок, но он как Gentoo, будет тем, что ты из него соберёшь.
Очень дорогое решение со всех точек зрения: лицензии, кадры, обучение, чрезвычайно долгий процесс планирования и внедрения. Zabbix вы сегодня установили и уже завтра получаете реальную пользу практически с нулевыми вложениями.
Я знаю. Я с этими продуктами работал.
У нас же тут речь шла про гибкое ПО с минимумом костылей и ограничений, а не про "завтра".
Про цену тоже речи не шло (но про неё я написал).
А минимум ограничений - это всегда конструктор. Сложный для понимания и для сборки (и в конкретном случае крайне дорогой), но тем не менее.
> Я знаю. Я с этими продуктами работал.
> У нас же тут речь шла про гибкое ПО с минимумом костылейну опиши путь к успеху - мне вот было б интересно послушать.
А то я с этим протухтом работал, точнее с людьми которым полагалось через него реагировать на проблемы в моей сети (я не из отдела-по-тиволям, я по сети, если кто не понял - и это первая большая проблема. Что мониторить - знаю я. Как реагировать - знаю я. А крутит гайки - специалист по кручению гаек, причем только с левой резьбой - если гайка с правой - надо писать заявку в другой отдел и два года ждать. Вторая большая проблема - что эти специалисты слишком дорогие, чтобы заставить их круглосуточно смотреть в монитор. И смотрит в монитор в результате ТРЕТИЙ отдел. Догадываешься, чем это заканчивается?)
Если кому интересно, я могу рассказать как то же самое выглядит в случае жабикса - но там, разумеется, ничего необычного.
Всё бы ничего, но на него отдельный отдел нужен.
Это да, но речь шла, в основном, только про гибкость.
Про такие вещи, как "время настройки", "цена" (во всех смыслах), и.т.д - речи не было.
Гибкость, когда костыли интегрируются в инструмент это очень интересный путь
Ну, путь, когда инструмент ограничен настолько, что там даже костыли некуда впихнуть - несомненно, ещё интереснее :)))
> Это да, но речь шла, в основном, только про гибкость.
> Про такие вещи, как "время настройки", "цена" (во всех смыслах), и.т.д -
> речи не было.Ну вы же понимаете, что сферическая система в вакууме особо не интересно. Речь шла про гибкость + совокупность прочих минимум равных.
Как сказать.
Зависит от того, с кем ты общаешься.
Если у тебя болтовня "за жизнь" с техническими специалистами (как, например, здесь на OpenNET) - по умолчанию обсуждаются, в основном, технические моменты.
Если ты общаешься с руководителями - там уже другой подход. Тут уже и стоимость, и людские ресурсы, и всякое такое начинает играть серьёзную роль.В изначальном комментарии, на который я отвечал - в качестве "тех. задания" стояли: огромные внедрения, сложные сети и относительно малое количество костылей.
Не, ну если надо пильнуть по-крупному, Tivoli самое то :)
В этом не силён.
Могу поддерживать беседу лишь в технической и организационной плоскости
Да, ещё.> Всё бы ничего, но на него отдельный отдел нужен
Естественно. А как по другому обслуживать мониторинг "огромного внедрения, сложных сетей, и.т.д"? Особенно, когда всё это активно меняется...
Если у вас такую задачу будут выполнять 1-2 человека, они при любом раскладе и с любой системой мониторинга не справятся.
>> Всё бы ничего, но на него отдельный отдел нужен
> Естественно. А как по другому обслуживать мониторинг "огромного внедрения, сложных сетей,вам рассказать, по опыту внедрения и эксплуатации в двух сложных и одной просто большой, по тем временам, сетях? Я недорого возьму, за консультацию-то. Причем не с "инженерной", а именно с практической точки зрения - кто что крутил, как это синхронизировали между подразделениями и что получилось.
> и.т.д"? Особенно, когда всё это активно меняется...
Да, особенно в этом случае. (когда меняется, разумеется - сеть, а не происходит бурная деятельность в отделе изменения применений систем мониторинга)
> Если у вас такую задачу будут выполнять 1-2 человека, они при любом
> раскладе и с любой системой мониторинга не справятся.удивительное рядом, у меня эту задачу всегда решали НОЛЬ человек. И они - справлялись, те конторы банкротами стали вовсе не потому что плохо мониторили (и далеко не на заре своего существования).
А вот с prtg, tivoli и, ни к ночи будь помянут, prime - не справились и специально выделенные человеки (ну да, их было не пятьдесят - бюджет, знаете, и так трещал после покупок того что само должно было еще и за курвуазье бегать). Зато один получил непыльную работу с приятным окладом после ухода от наших развалин. Нет, нет, он не в отделе мониторинга ;-)
вопрос был адресован не мне, но ничего гибче graphite не видел. все компоненты являются полностью взаимозаменяемыми и расширяемыми. Любой компонент можно заменить на аналог, который больше подходит именно тебе и просто интегрировать с любым другим сервисом (экосистема достаточно развита и понятна). Круто и практически неограниченно может масштабироваться, сбор метрик с многих источников доступны из коробки(используя https://github.com/influxdata/telegraf), а которых нет, добавляются очень легко самостоятельно. Используя любую систему управления конфигурациями у тебя с добавлением нового сервиса добавляется и его мониторинг. В отличии от Prometheus не нужно добавлять ендпоинты для сервисов вне k8s, т.к. используется push вместо pull и если для сервиса начали приходить метрики, то сервис автоматом мониторится.
Поверь мне, ты не смасштабируешь его на провайдерскую сеть, где куча разнородных устройств, которые надо ещё знать, как опрашивать, желательно на ходу, и чтобы руками не трогать.
Не сложнее чем у других решений, в частности того же забикса. Под масштабируемостью имелось ввиду возможность переваривать любое количество метрик за счет добавления дополнительных серверов (Горизонтальное масштабирование).
Не сложнее, но сильно дороже.
Разводить целый зоопарк ради учёта метрик с лишней тысячи хостов - так себе затея.
Поэтому применяющих это полтора человека.
> Не сложнее, но сильно дороже.
> Разводить целый зоопарк ради учёта метрик с лишней тысячи хостов - так
> себе затея.
> Поэтому применяющих это полтора человека.можешь как и заббикс сделать на 1 хосте, если не нужна отказоустойчивость. Будет кушать даже значительно меньше ресурсов при том же количестве метрик.
Ну и да, масштабируемость - это не просто способность "переваривать" метрики, их ещё надо агрегировать, отображать, эскалировать.
> Ну и да, масштабируемость - это не просто способность "переваривать" метрики, их
> ещё надо агрегировать, отображать, эскалировать.Каждая из вышеупомянутых характеристик без особых проблем масштабируется горизонтально.
А почему я тебе сказал, что не смасштабируешь - да всё просто, все эти поделки заточены на отрисовку полутора графиков для менеджера среднего звена. Когда в них приходит раз в 5 секунд пинг 10000 хостов, который надо ещё с другими метриками скоррелировать - у тебя банально его кривая-косая "подложка", которая попытка "эффективно" похранить time series, загнётся.
> А почему я тебе сказал, что не смасштабируешь - да всё просто,
> все эти поделки заточены на отрисовку полутора графиков для менеджера среднего
> звена. Когда в них приходит раз в 5 секунд пинг 10000
> хостов, который надо ещё с другими метриками скоррелировать - у тебя
> банально его кривая-косая "подложка", которая попытка "эффективно" похранить time series,
> загнётся.всего 200к метрик в минуту? Для мониторинга это даже не хайлоад. Как уже писал ранее любой компонент можно заменить на более подходящий для конкретно твоих задач и по-факту дефолтные компоненты никто не юзает... Если говорить о хранилище для хранения метрик, то лично я использую clickhouse, который достаточно производительный для работы с time series.
Как сложность сети влияет на необходимость накликивать все в интерфесе вместо простого и понятного кода для прометея который может сам находить таргеты?
Пока у тебя 50 таргетов в известных подсетях - всё просто. Как только у тебя становится 10000 хостов с разнородными сервисами, интерфейсами, связностями, весь твой "простой и понятный" код превращается в тыкву, да и движкам разных хипстерских недомониторилок от такого количества плохеет.
> Пока у тебя 50 таргетов в известных подсетях - всё просто. Как
> только у тебя становится 10000 хостов с разнородными сервисами, интерфейсами, связностями,
> весь твой "простой и понятный" код превращается в тыкву, да и
> движкам разных хипстерских недомониторилок от такого количества плохеет.хстате, а расскажи - как у тебя host discovery устроен? Или ручками все десятьтыщ?
Так разбейте на кластеры, зачем всё класть в одну корзину?!
Дай угадаю, вам лень пальцем о палец ударить, подавай чтоб в один клик и усё работало!
если инженер с прямыми руками то и zabbix работает нормально.
> если инженер с прямыми руками то и zabbix работает нормально.к работе заббикса претензий как раз таки нет, а вот к пользовательскому фидбеку стоит отнестись посерьезней.
На принципе, "хавайте, что дают и скажите спасибо", далеко не уедут, а заказчику всегда можно пихнуть любое другое коммерческое решение.
А если ещё и с незамутнённой головой - то и без zabbix всё норм.
> Бегите, глупцы.А с каких это пор аноним стал экспертом мониторинга, почему я должен верить Вашим утверждениям?
Представьтесь, расскажите о своём опыте - я подумаю, стоит ли Ваше мнение внимания.
P.S. Так-то очевидно, что это тролль.
А с каких это пор Moomintroll стал экспертом мониторинга, почему я должен верить Вашим утверждениям? Мне не интересен ни ваш опыт, ни ваше имя, интересны только аргументы.
P.S. Так-то очевидно, что это тролль.
> ПредставьтесьВсегда улыбало это требование)
И что ты с этими данными делать будешь?
>И что ты с этими данными делать будешь?например почитать твои сообщения в других темах или на форуме и по ним сформировать первичное отношение к человеку. Если ты постоянно неадекватен, то и советы от тебя могут быть соответствующими.
>>И что ты с этими данными делать будешь?
> например почитать твои сообщения в других темах или на форуме и по
> ним сформировать первичное отношение к человеку. Если ты постоянно неадекватен, то
> и советы от тебя могут быть соответствующими.А если не всегда неадекватен?
гранаты тоже не всегда взрываются, это ж не повод носить такую в кармане :)
Хотя можно подойти более продуманно — построить графики зависимости неадекватности от черных пятен на Солнце.
и напрашивающийся вопрос:
а ежели он всегда адекватен? будешь ли ты считать его источником, заслуживающим доверия?
А почему вы решили, что доверие основывается только на адекватности? С адекватным человеком приятно просто поговорить на различные темы, возможно узнать от него что-то новое или поделиться своими мыслями.Он просто переходит в следующий раунд и источником, заслуживающим доверия в той или иной области, он может стать как минимум после формирования представлений о его компетентности. Что опять таки можно сделать на основе того как он ведет дискуссии, аргументирует свою позицию, как часто его исправляют оппоненты и т.д. Также можно собственноручно проверить часть его советов на "кошках".
Я не имею в виду, что наличие ошибочных суждений мгновенно делает человека "не доверенным" источником. Если он дает советы по делу и они помогают решить проблему, то это повод прислушаться к нему в дальнейшем.
> Бегите, глупцы.куда бечь-то, вот в чем вопрос?
В 2014 еще можно было купить за миллион нефти старый, не веб-онли, whatsup, но сейчас-то куда деваться прикажете?
Вацап голд ничо такой. Кое-кто ещё пользуется. Созревающие хосты на схеме - это классно )
да я бы им тоже пользовался, если б можно было купить за деньги.Но они тоже уволили программистов и наняли веб-макак - теперь немое кино в виде виндовс-приложения кончилось, а звуковое все никак не настанет, поскольку половину того что умело делать старое немодное - новое стильное молодежное никак ниасиливает, и к тому же дико глючит и тормозит новый-модный вебтриноль интерфейс.
Не будь влэш таким re:шетом, на нём можно было бы замутить идеальный интерфейс для дашборда. Хоть тыща иконок. И можно качество отрисовки выбирать. Но эх... (
> Не будь влэш таким re:шетом,всем пох. У меня, знаешь ли, система мониторинга умеет командочки от рута запускать. Поэтому флэшовую морду, иф эни - увидели бы только те, кто от рута командочку и сам может.
Но на практике - циска что-то х-евертела, получилось как обычно - г-но. Впрочем, дальше они вертели на жабе-ээ (с jnlp), то же ж в общем прекрасное средство рисования мигающей-переливающейся хрени - опять оно же. Да что ж такое - место, что-ли, проклято?
На самом деле интерфейс жабикса версии 1 в 2008м году был вполне приемлемый, на том древнем js, ему не интерфейса а функционала не хватало что тогда, что сейчас.
Причем то, чего не хватает - оно не на js, а на пехепе пишется, и местами на сях - и ничего там военного нет. Начать и кончить - да, поэтому я этим займусь воплощений этак через пятнадцать (уверен что горе-разработчики и к тому моменту ниасилят - зато попереписывают все что не нужно на игогого)
Вот как раз для "большой и сложной сети" (с десятками тысяч хостов) это вообще чуть ли не единственное решение, которому альтернатив на данный момент не видится.
На, поешь.
Что-то я не понял, а что нового то, собственно?)
Ты вот чо - вообще слепой? Менюшку сверху перенесли налево!Сразу видно повод поменять major release - инновации, прям сразу видно.
Где Docker ???
Уже есть )
Есть docker образы.
Да блииинн!.....Только я собрался zabbix 3 обновить до 4 версии...
Что ж они LTS релизы так часто выпускают то?
Горшочек, не вари!
Я только недавно до 3.4. обновился, всего 3 года назад, а тут уже 5я
Зависимость хостов похоже так и не осилили, хотя вроде обещали.
Очень печально...
Никто там не обещал. Тот тикет в джире открыт чёртову тучу лет и никто из реальных девелоперов туда не писал.
А вообще эти зависимости можно сделать и так, просто работы по кликанью мыши больше
Ну вообще когда такие вещи нужны, уже проще API юзать :)
План развития 5.0 LTS
https://www.zabbix.com/ru/roadmapAdvanced event correlation
ZBXNEXT-46 , 1891 Host and proxy level dependencies
It says it all.
См.: https://support.zabbix.com/browse/ZBXNEXT-46Может в миноре добавят, а может слишком сложная фича, которая требует передела многих строк кода в разных местах. Поэтому отложили чтобы не задерживать релиз.
Без этой фичи на мажорный релиз слабо тянет :-(
Я эту фичу очень ждал. Но увы и ах. За 10 лет так и не реализовали.
Всякие свистелки пирделки реализовывают бесполезные, а нужные вещи так фиг.
Проверил -- http://support.zabbix.com/browse/ZBXNEXT-2253 с патчами, которые ещё к 2.2 делали -- открыт и на месте. Понятно, что патчи не шибко тривиальные, но и функциональность-то полезная была сделана...
> Проверил -- http://support.zabbix.com/browse/ZBXNEXT-2253 с патчами,
> которые ещё к 2.2 делали -- открыт и на месте. Понятно, что патчи не
> шибко тривиальные, но и функциональность-то полезная была сделана...Допинали в 6.0-alpha ;-) Но уже в http://support.zabbix.com/browse/ZBXNEXT-6755
Появилась зависимость мониторинга доступности хостов от доступности прокси.Что касается зависимости хостов, то, наверное, это будет решено на уровне корреляции событий в будущих релизах. Дело в том, что зависимости между хостами в наше время не так важны (если речь не идёт о сетях), как зависимости между сервисами.
Наличие зависимостей от отдельного хоста, а не от прокси, хорошо простотой пользования. Куда проще и наглядней накидать зависимостей между хостами, чем между кучей тригеров для этих же хостов. Чтобы не забыть случайно чего-нибудь и быстро найти где исправить, если нужно.Могли бы например какой-нибудь тригер пометить как "тригер доступности" и сделать его обязательным для каждого узла, а в зависимых хостах просто указывать родительский хост. Внутри вся эта кухня может продолжать работать как и сейчас, сугубо на зависимостях тригеров.
Так чем макросы не устраивают?
А макросы как помогут упростить жизнь с зависимостями хостов?
Для сервисов возможно не важно. А для хостов касаемо сетей это первостепенная потребность.
А зависимость от прокси так это вообще какой то костыль не нужный.
зависимость от прокси - очень нужный костыль, иначе без специальных ручных костыликов оно могло вообще не замечать что прокси и все что за ним - три дня как сдохло.(или наоборот - что оно давно работает, а сдох именно прокси, и не надо спамить всяким мусором во все дырки)
если бы ваш жабикс мониторил _сервисы_ - это было бы разумным аргументом.
Но он, к сожалению, мониторит именно хосты. Даже банальная вещь "сервис переехал с хоста а на хост б" - в нем невозможна, поскольку айтимы прибиты гвоздем именно к хосту.
>айтимы прибиты гвоздем именно к хостуНет же. Прибиты гвоздем к шаблону. А поменять шаблон у хоста реализуется в два клика.
причем здесь поменять шаблон? (К шаблону вообще ничего в современных версиях не привязано, шаблон просто заставляет жабикс создать айтимы по образцу - айтимы привязаны к _хосту_ и вообще ничем не отличаются от точно таких же, созданных тобой вручную, кроме флага (за эти флаги отдельно надо убить изобретателя, а потом изнасиловать) что их нужно обновить если изменился шаблон)
Был сервис - на хосте а. Уехал из-за перераспределения нагрузки на хост б, сервис не прерывался, и я хочу по прежнему видеть один и тот же график нагрузки и те же самые триггеры (+1 мелкий вида "случился свитчовер") и ту же самую историю состояния. Каким нахрен шаблоном ты это сделаешь?В жабиксе нет даже банальной возможности _вручную_ ткнуть что вот это, вот это и вон то - уехало на вон тот хост, поменяйте уже нахрен hostid у этих параметров.
Мне когда-то пришлось изображать это вручную, чтобы не потерять историю и состояния - было очень приятно обнаружить что структура базы данных "прекрасно документирована ее кодом". Как сами разработчики ухитряются работать без документации - полнейшая загадка.
(кстати, кому надо - обращайтесь, я вроде сохранил набор заклинаний - разумеется, без гарантий что в пятой версии не переделали структуру базы и все не придется реверс-инжинерить снова)
>поменяйте уже нахрен hostid у этих параметров.а зачем мешать историю с нескольких хостов?
>хочу по прежнему видеть один и тот же график нагрузки и те же самые триггеры
только ведь это может быть не тот же график нагрузки, если условия на новом и старом серверах отличаются (ну там пропускная способность сети, более мощный процессор, больше оперативы)
А если у вас сервис работал на 2 хостах, но на втором хосте вы его удалили, а с первого перенесли на второй?Ну и костыль без лазанья в базу: ставится что-то типа графаны и там выводится график с нескольких хостов, по цвету линии поймете, где было переключение. Правдя работает не для частых переключений
потому что речь о приложении, а хосты - нахрен никому неинтересны.> только ведь это может быть не тот же график нагрузки, если условия на новом и старом
> серверах отличаютсяможно я как-нибудь сам разберусь? Я вот вчера в физический хост докинул памяти и дисковую полку переключил - что, давайте по этому поводу грохнем всю хистори и заново начнем с чистого листа, условия ведь отличаются? Хорошо что жабикс ничего не заметил - с его точки зрения хост где был там и остался.
> А если у вас сервис работал на 2 хостах, но на втором хосте вы его удалили,
> а с первого перенесли на второй?значит вы опять мониторите не сервис, а ненужно-хосты.
А в сервисной архитектуре - должно быть ровно наоборот - хост - мелкая малозначащая деталька сервиса. Их могут быть вообще сотни.
> Ну и костыль без лазанья в базу: ставится что-то типа графаны и там выводится график с
> нескольких хостовхоста нет, удалил я его нахрен - вместе с хостоспецифичными айтимами и триггерами и прочей требухой, потому что там agent not reachable, и вообще физически нет его больше, и мне неинтересно специфичные для него параметры хранить, и постоянно натыкаться на неработающие отключенные хосты.
>Я вот вчера в физический хост докинул памяти и дисковую полку переключил - что, давайте по этому поводу грохнем всю хистори и заново начнем с чистого листа, условия ведь отличаются?а почему бы и нет? Зависит от того, как вы используете исторические данные
>Хорошо что жабикс ничего не заметил - с его точки зрения хост где был там и остался.
ну это у вас, у нас он неплохо замечает большую часть изменений в конфигурации. И эти изменения довольно хорошо отображаются на UI, правда он у нас свой.
>хоста нет, удалил я его нахрен
ну а я не удалил. Программистам заббикса надо предусмотреть все больные фантазии?
>потому что там agent not reachable
но вы же знаете, что хост можно отключить ...
>постоянно натыкаться на неработающие отключенные хосты.... как и отфильтровать
Ой, вы не понимаете о чем он говорит, любезнейший. Нах просто поленился объяснить, впрочем, как обычно.
Это примерно как юному начинающему разработчику объяснять разницу между TDD и BDD с объяснением что есть откуда и зачем их 2. =)Давайте представим себе элементарную систему представляющую из себя:
1. Два балансировщика нагрузки работающих в c применением DNAT (2 подсети) на keepalived с отказоустойчивостью по VRRP
2. Два кэширующих реверспрокси фронтенда производящие SSL Offloading и разделяющие траффик по URI на п.3 и п.4.
3. Два вебсервера со статическими данными
4. Четыре бекенда с вебсервисами и вебприложениями
Для простоты сделаем всё в маленьких цифрах и не будем сейчас тут про SSI и базульки прочие сложности =)Behaviour Driven Monitoring это когда, например:
1. Нужно создать предупреждение о том что в связи с недоступностью с недоступностью хоста 3 приложения УСПЕШНО обслуживаются остальными бекендами
2. Предупреждение о том, что в связи с превышением количества HTTP-соединений на фронтендах TCP сессии были автоматически замедлены.
3. В связи с неизвестной сетевой проблемой keepalived успешно отчитался о смене основного балансировщика по SNMP
4. Одна соплекуха на бекенде объелась оперативной памяти и поэтому этот бекенд не принимает новых соединений по URI этой соплекухи.
5. Всё это связано с непрерывной интеграцей и доставкой.
6. Поведенческие тесты формируют поведенческий мониторинг.Вот а теперь попытайтесь добавить ко все этой инфраструктуре возможность увеличивать и уменьшать количество "хостов" автоматически с новым релизом. Даже такая элементарная инфраструктура начинает расти по мониторингу. Ой, я понимаю, что можно обложиться шаблонами, сделать дискаверы, чтобы упростить процедуру добавления удаления. Можно написать ручные метрики на каждый случай жизни. Можно-можно. Всё можно.
Вот только всё никак не связано с приложением и его реальной работой, потому что заббикс мониторит чёртовы хосты!!! Эти хосты в случае п.4 интересны, а в случае п.1-3 в разрезе сервиса вообще не интересны.
Заббикс не удобен для работы с приложениями. Мне аж интересно как они кубик мониторить собрались, что у них там "хостами" будет. Или они там как обычно до приложений не дойдут...
Нах, опять же утрирует вот тут:
> Даже банальная вещь "сервис переехал с хоста а на хост б" - в нем невозможна, поскольку айтимы прибиты гвоздем именно к хостуРазрабы пользуются <ругательное слово по вашему вкусу> бесплатным nginx-ом (просто вангую). Легаси мониторилке нужны очень подробные метрики, используйте HAproxy она вам всё подробно расскажет даже через zabbix. Благо её конфиг позволяет всё нарисовать так чтобы оно работало в разрезе приложений. Вот только источник события (хост) будет вам погоду показывать =)
Был сервис - на хосте а. Уехал из-за перераспределения нагрузки на хост б
Зачем вы так делаете? Один хост/контейнер = 1 сервис уже не модно?
В самом крайнем случае вы можете в заббиксе создать 1 "хост" на сервис, и прибить к нему нужный IP с нужного хоста. На агента - пассивные чеки, им пох, какой там реально хостнейм на сервере. Активные чеки так конечно работать не будут, но в условиях маленького колхоза они вполне себе взаимозаменяемы.
хосты и сервисы - в общем и целом никак между собой не связаны. Совать жабиксные агенты внутрь контейнеров, превращая еще и их в "хосты" - спасибо, нет.Окей, я готов терпеть архитектуру, завязанную на концепцию хоста, за неимением другой - но дайте ж возможность поменять хост, если эти параметры теперь связаны с другим хостом.
Создайте хост с каким-нибудь виртуальным (от балды) ip и наполняйте его айтемы SEND'ами изнутри Вашего сервиса/приложения через простейший Zabbix API.
> Создайте хост с каким-нибудь виртуальным (от балды) ip и наполняйте его айтемы
> SEND'ами изнутри Вашего сервиса/приложения через простейший Zabbix API.да я могу его ip привязать непосредственно к тому настоящему хосту, где агент крутится - и, собственно, кое-где так и приходится делать. То есть идея с "хостами" порождает монстров, где у "хоста" три разных адреса (потому что связанные именно с этим хостом события собираются не на нем самом, а там где они видны) и ни один не настоящий (потому что то что настоящее вообще не в моем ведении, это хардварный балансировщик другого отдела)
Ну зашибись, чо.
>> Создайте хост с каким-нибудь виртуальным (от балды) ip и наполняйте его айтемы
>> SEND'ами изнутри Вашего сервиса/приложения через простейший Zabbix API.
> да я могу его ip привязать непосредственно к тому настоящему хосту, где
> агент крутится - и, собственно, кое-где так и приходится делать. То
> есть идея с "хостами" порождает монстров, где у "хоста" три разных
> адреса (потому что связанные именно с этим хостом события собираются не
> на нем самом, а там где они видны) и ни один
> не настоящий (потому что то что настоящее вообще не в моем
> ведении, это хардварный балансировщик другого отдела)
> Ну зашибись, чо.Сорян, но я так и не понял чем Вас не устраивает вариант с SEND'ами изнутри Вашего приложения.
Ваше приложение САМО может регулярно отправлять на zabbix-сервер те данные, которые Вы хотите мониторить. Достаточно знать только ip адрес (или FQDN) Zabbix-сервера (он же у Вас не меняется наверное). Вас вообще может не волновать на каком именно узле крутится Ваше приложение.
И да, Zabbix изначально исходил из того, что мониторится хост, но для особых случаев он предоставляет и альтернативные способы сбора данных.
См.:
https://www.zabbix.com/documentation/current/ru/manual/conce...
https://www.zabbix.com/documentation/current/ru/manual/api/r...
> Сорян, но я так и не понял чем Вас не устраивает вариант с SEND'ами изнутри Вашего приложения.это не мое приложение. И, знаете, я лучше не буду тем милым людям ничего про send рассказывать.
А то придется им отдельный жабикс поднимать, чтоб они его хотя бы отдельно роняли.
И еще и его фейловерить и прикрывать балансировщиком - а то если он сдохнет, приложение начнет таймаутиться - ну его нахрен.
> Окей, я готов терпеть архитектуру, завязанную на концепцию хоста, за неимением другой
> - но дайте ж возможность поменять хост, если эти параметры теперь
> связаны с другим хостом.Делаешь заббиксовый "хост" на сервис, в нём указываешь IP, где этот сервис крутится. В общем-то и всё, главное активные чеки с агента не использовать.
костыли-подпорочки
> костыли-подпорочкиугу. Особенно удобные в случае когда изначально приложение помещалось в один сервер, и никто такое не нах..евертил в предвидении его экстенсивного развития. И теперь вот у тебя не сервер а кластер, и ты даже не можешь посмотреть что изменилось при переходе на него - исключая черезанусные решения, типа вечного хранения ненужно-хоста, который из сети давно отключен.
> если бы ваш жабикс мониторил _сервисы_ - это было бы разумным аргументом.
> Но он, к сожалению, мониторит именно хосты. Даже банальная вещь "сервис переехал с хоста а на
> хост б" - в нем невозможна, поскольку айтимы прибиты гвоздем именно к хосту.Мониторинг активного агента в этом случае не может помочь?
не поможет, тут всю систему менять надо - предварительно поперевешав все политбюро.
В Zabbix есть понятия сервиса, но в ином смысле: https://www.zabbix.com/documentation/current/ru/manual/web_i...А Вы как определяете, что есть сервис? Мигрирующая виртуальная машина с внутренностями в виде Linux? Или что это за субстанция?
Тоже только ради этого и мониторил новости про 5-ку
>Установка новых агентов не потребуется.А новые агенты к старой версии сервера теперь не цепляются.
Zabbix никогда не гарантировал работу старых версий сервера с новыми агентами. В большинстве случаев это будет работать, но иногда приходится менять протокол общения, что ломает совместимость.
Ну ХЗ, второй агент пятой версии вполне с 4.4 сервером работает
кто что скажет в сравнении с check_mk ?
> кто что скажет в сравнении с check_mk ?А чего там сравнивать-то. Хомячка (check_mk) с грузовиком - так себе сравнение.
Начал читать комменты и, о боже, вот они герои, которые избавят нас от этого злобного Заббикса, который, фи, не может даже миллиона хостов и вообще ужасен! Вот они - спасители всего ИТ! Сейчас они назовут имя того софта, который спасет всех нас!!! Мессия уже на подходе!!!...
А нет, нифига никто ничего из этих "героев" не предложил...
ну так наиболее ненавидят как раз тот софт, который и всех достал, и бечь с него некуда.Я бы вот тоже хотел хоть примерный списочек - и не надо мне сотен тыщ хостов, мне хватит сотни. (не хватит, будем расширяться экстенсивно)
Но нету же ж вообще нихрена. :-(
тебе уже сказали промитей исинга и т.д. выбирай подстать себе
и да НАГИОСССССССССС
> Начал читать комменты и, о боже, вот они герои, которые избавят нас от этого злобного ${subject_name}, который, фи, не может даже ${feature_name} и вообще ужасен! Вот они - спасители всего ИТ! Сейчас они назовут имя того софта, который спасет всех нас!!! Мессия уже на подходе!!!...
> А нет, нифига никто ничего из этих "героев" не предложил...Шаблон сценария обсуждения анонимусами любой новости на опеннете.
Oбещали мониторинг кубернетеса, но видимо не смогли.
Интересно: переход с Zabbix 3.2.11 будет сопровождаться какими-либо неурядицами?
еще какими кмк
а смысл такого перехода?Если в новых шаблонах и новых фичах - будет, поскольку ни шаблоны ни тем более существующие хосты не апгрейдятся, и даже просто выкладывать на сайт экспортированные дефолтные шаблоны от новых версий стало немодно.
То есть если тебе эти фичи и шаблоны нужны - ставь новую версию рядом, и пересоздавай все с нуля - другого способа у этих альтернативно-одаренных не предусмотрено.
А если не нужны - нахрен не надо и апгрейдить.
(но вообще-то та lld что была в тройке - это такой п-ц, что я бы на твоем месте именно поставил рядом вторую машину и переносил бы на нее мониторинг - заново, потому что тебе наверняка захочется его сделать совсем по другому. Причем это надо было сделать еще во времена 4.0)
Одна из причин ставить новую версию. В дистрибутивах агенты уже новой версии и старую версию сервера zabbix не поддерживают.
вот ради этого я бы точно не стал апгрейдиться.
(я бы сдаунгрейдился чтобы не видеть этих уродливых пикеров вместо старых двигаемых мышью графиков, но, к сожалению, мне таки нужен новый lld)Пересобрать под все используемые дистрибутивы единственно-верный агент представляется мне значительно меньшей головной болью.
(отдельный вопрос - а нахерна ж было ломать совместимость - первый раз это действительно было обосновано, но это было очень давно - так давно, что разработчики еще снисходили объяснять свои действия. Каких волшебных фич не хватало в протоколе, что понадобилось все поломать аж дважды за последние полтора года? Ау, ребята - система мониторинга это не то ради чего апгрейдят операционные системы!)
Смысл - в ползучей адаптации существующих шаблонов под новые LLD и прочее.
Мы так с 2.x едем :)
// своих существующих шаблонов //
Коробочные годны на 1.5 хоста по праздникам.
коробочные хороши как затычка - ты его привесил, все - хост как-то худо-бедно мониторится, и даже вовремя чирикнет, если что-то пошло не так. А тебе освобождается время и вдохновение делать нетривиальные вещи.
Если у меня хотя бы 1% хостов "чирикнет", хелпдеск повесится. Поэтому взяли за правило делать все шаблоны с 0 и чирикать только по делу. Но это не общая ситуация, естественно, большинству "из коробки" может быть и пригодится, да.
Если чуть отпочемучить - на каждый "чирик" заводится тикет...
у меня практически нет ложных алармов от стандартных триггеров. Есть неложные, причем чаще всего в ситуациях когда я что-то проспал (типа стало кончаться место на диске, на котором оно кончаться не может, если бы не забытая там взбесившаяся софтина - замониторить которую правильно впопыхах забыли - и очень хорошо что аларм пришел вовремя, хотя и неточный)Единственные которые я правил или повыключал везде - алармы на число процессов, они из какого-то 2000го года с четырехядерных ксеонов и линуксного ведра без миллиарда неведомых "процессов", видимых в ps, но делающих непонятно что.
Остальное управляется глобальными макросами, не требуя править сами шаблоны.
А не из коробки у меня только мониторинг приложений - которые как раз я бы рад бы был убрать нахрен из жабикса, оставив ему только то что он умеет делать без лишних телодвижений, но пока ниасиливаю.
ну там же реально надо было все выкрасить и выбросить уже минимум дважды?
Те, старые, где айтимы были наглухо прибиты к lld их создавшему (и удалялись вместе с ним, если вдруг) - это ж ад и п-ц.Это был самый неожиданный подарочек (похоже, последний) от разработчиков заббикса, когда они внезапно переделали так, как надо было - глядя на предыдущий ад, было трудно поверить что они это смогут.
Но все старые ручные поделки при этом отправились в помойку.
(мне повезло, я эту эпопею пересидел в сторонке, и то что потом апгрейдил - не использовало старые lld - либо вручную все айтимы создавались, либо это был дефолтный шаблон и его не жалко)
А я поэтому и говорю что нахер штатные шаблоны, надо мониторить то, что надо мониторить, а не то, что авторам софта заблагорассудилось. Благо заббикс это легко позволяет.
Обновите ОС на свежую и установите новые пакеты. Всё!
> Обновите ОС на свежую и установите новые пакеты. Всё!...потом заново добавлять хосты, группы, карты, комплексные экраны, оповещения, правила...
Да?
> Всё!а если я еще поработать в конторе планирую, а не вот это ваше "Всё!"?
С 3.2 рекомендую сначала съехать на 4.0, потом на 4.2, потом на 4.4, и только потом на 5. На каждом этапе читая релизнотесы и выправляя перекосившееся, если таковое будет.
а вот расскажи, чего я такого не вижу чего ради стоит куда-то ехать? (живу с 4.0)
> а вот расскажи, чего я такого не вижу чего ради стоит куда-то ехать? (живу с 4.0)4.2:
1) Вообще просто наиохереннейшее изменение: препроцессинг на Javascript. Подобного хотелось просто вечность.
Половина внешних скриптов, использовавшихся для дискавери или хитрой трансформации ответов - банально съехали, потому что трансформировать специфичный текстовый вывод (например с SSH консоли девайса, ничего другого не умеющего) теперь можно прямо в Zabbix так, как душе угодно
2) Тротлинг item'ов. Второе "давно хотелось".
Можно опрашивать часто, а сохранять в хистори только отличающиеся значения, + опционально одно значение в энный интервал времени, чтобы например nodata при этом успокоить. Размер таблиц хистори ныне сократился раз в 10 минимум, и это при том, что включили только для самых частых опросов. Кое-где этим удалось время реакции сократить, там где опрашивалось раз в пять минут, теперь опрашивается раз в минуту, но хранятся только изменившиеся значения.
3) Отработка ошибок в препроцессинге - можно например дефолтное значение подсунуть если регулярка не срослась.
4) Dependent'ы для LLD.
Теперь можно выгребать одну портянку в один текстовый item, трансформить JS, и из этой единой портянки фигачить разные LLD, возможно с дополнительной трансформацией через JS. Больше не надо 100500 раз опрашивать одно и то же устройство для каждого LLD.
5) JSONpath в LLD.
Преобразовав заранее портянку в JSON, можно сразу её разгрести по параметрам LLD без дополнительных ухищрений.
6) Теги на хосты. Мелочь, а приятно.
7) Проверка данных регулярками при авторегистрации хостов.
Тоже удобно, когда много разнотипных хостов и темплейтов.
> 1) Вообще просто наиохереннейшее изменение: препроцессинг на Javascript. Подобного хотелось
> просто вечность.хм, у меня скрипты никуда не денутся (жабикс не умеет ходить в базы данных, не умеет сложные процедуры вида вопрос-ответ) - поэтому нет проблемы выплюнуть результат как ему хочется.
> Тротлинг item'ов. Второе "давно хотелось".
а, да. Мне, правда, на самом деле хотелось бы базу, которая в нем не нуждается, и это ни разу не sql, но хоть такой костылик. Да, пожалуй, все же повод апгрейдиться.
> JSONpath в LLD.
был же ж xml, мне вполне хватало...
> хм, у меня скрипты никуда не денутся (жабикс не умеет ходить в базы данных, не умеет сложные процедуры вида вопрос-ответ)Для первого сделаны web item'ы, можно опрашивать прямо API сервиса, не костыляя скриптами на заббиксе :)
А результат трансформировать "на месте".Второе да.
> Мне, правда, на самом деле хотелось бы базу, которая в нем не нуждается, и это ни разу не sql, но хоть такой костылик
TimescaleDB, но это мерзкий постгрес.
>> хм, у меня скрипты никуда не денутся (жабикс не умеет ходить в базы данных, не умеет сложные
>> процедуры вида вопрос-ответ)
> Для первого сделаны web item'ы, можно опрашивать прямо API сервиса, не костыляяа веб и апи мне самому написать? ;-) Я бы тогда уж писал апи, напрямую в жабикс и складывающее.
> А результат трансформировать "на месте".
select ab, cd, ef.gh from ... | awk ... - вот тебе xml, обтрансформируйся ;-)
where можешь подставить из ключа айтима по вкусу.>> Мне, правда, на самом деле хотелось бы базу, которая в нем не нуждается, и это ни разу не sql,
>> но хоть такой костылик
> TimescaleDB, но это мерзкий постгрес.причем в результате будет мерзкий постгрез для всего,а не только айтимов - а вот этого я точно не хочу.
Ну и timescale - тоже костыль, только теперь уже на уровне постгреза. Причины понятны - переписывать код лень, да и некому уже давно, одни менеджеры остались и рисователи темплейтов по 600 евро в сутки, а тут поменял одно слово в create table, опа, мы уже модные-молодежные-поддерживаем time series db, плевать что одну и самую угребищную на свете, но все равно очень жаль.
Ну и кстати да, заббикс умеет ходить в базы данных :)
если ты про odbcшное убожество - то нет, спасибо, вариант с select|awk еще и побыстрее окажется.
Ну вот, всё-то вам не угодишь :)
ODBC убожество, да.
(по 4.2 - это было всё, что конкретно мы используем, реально там больше всего)4.4 (то же самое, только то, что пригодилось):
1) Web-реквест (webhook) как media type - заливаем кое-какие эвенты в чат через него.
2) Подняли лимит dependent items на item.
Ага, в 999 мы не вписывались (или сколько там было), у нас железка отдаёт одну-единственную портянку для всех телефонных транков, которых больше 1000. В 29999 ещё долго будем вписываться. Можно было тупо запатчить, конечно, что и делалось, но стало проще, теперь ванильный.
3) Наконец-то добавили возможность задать отдельно realtime (стандартное - problem time) сообщения для триггеров, которые берут текущие ITEM.LASTVALUE, очень удобно для мониторилки событий в трее, можно показывать и текущую ситуацию, а не только на момент проблемы.
4) CSV в JSON (препроцессинг). Странненькое себе, но конкретно нам пригодилось.
А в чём смысл такого поэтапного обновления? С 3.2 поддерживается обновление напрямую до 5.0, зачем эти промежуточные телодвижения?
> А в чём смысл такого поэтапного обновления? С 3.2 поддерживается обновление напрямую
> до 5.0, зачем эти промежуточные телодвижения?Там, скажем так, есть слегка "incompatible changes". Мне удобнее лечить их понемножку, кому-то, конечно, может оказаться удобнее сразу получить весь ворох и разгребать.
А можно примеры? Просто мне в голову приходит только вынесенный в 4.2 препроцессинг на прокси, да формат JSON LLD у агента.
Ну вот тот же формат LLD меняющийся.
У nodata с прокси в 5.0 поведение немножко меняется.
Там их есть, причём не всё оно описано. В каждой версии могут вылезти свои тараканы.
все больше и больше становится похож на исингу что неможет не радовать(в итоге забикс нах схлопнет сам себя).
по поводу:Oбещали мониторинг кубернетеса, но видимо не смогли - это сам кубер не предоставил нормальных средств мониторинга себя любимого
> Oбещали мониторинг кубернетеса, но видимо не смоглиТак налепите шаблонов самостоятельно, в чём проблема?
Хм. Надо заглянуть в баг-трекер, починили ли баг с удалением хоста, для которого есть правила сетевого обнаружения?
А ползунок для перемещения по графику вернули? А то вот эти вот "последний один день", "предыдущий год", и прочее - абсолютно неюзабельный отстой.
хрен тебе - это ж копипаста с графаны-инсигны, это менеджер велел запилить именно в таком уродливом виде, и очень гордится поебдой.
> хрен тебе - это ж копипаста с графаны-инсигны, это менеджер велел запилить
> именно в таком уродливом виде, и очень гордится поебдой.В графане (хотя бы) можно быстро вбить даты руками. В промежутках между зависонами )
Мы тут попробовали графану с инфлуксом на наши нужны. По***лись, ещё по***лись с тормозами, поматерились, и всё равно получили жуткое тормозное удолбище. Решили пока дальше сидеть на собственном кастоме, который из заббикса тянет хистори в RRD, благо оно работает и не жужжит, в отличие от.
> Мы тут попробовали графану с инфлуксом на наши нужны.я графаной, если что - в жабикс хожу (потому что его модные дэшборды - очень плохой и, главное - неэкспортируемый косплей графановских).
Разумеется, там как в анекдоте про линкор с заклинившими стволами - "персонал проинструктирован ноль в это поле не вводить" (только наоборот - "запросов больше чем за сутки не делать, а то все повиснет к хренам")
но, опять же, это претензия к жабиксу и его sql для хранения метрик вместо нормальной nosql базы для именно метрик.
В наших условиях даже influx загибается напрочь, а шардить это хипстерское нечто на кучу серверов смысла не видно. Прикрутили свою in-house кастомную приблуду, которая тянет постоянно данные с хистори заббикса, и раскладывает их в RRD, и далее просмотрщик к этому счастью. Сначала думали с кактусом сгибридить, но кастом показался интереснее, у кактуса интерфейс так себе.
Просто ради интереса - есть несколько страниц, на которых >1000 графиков :)
Обновился. (К чести заббикса - предыдущее обновление было с 2.х на 4.4 и прошло гладко и почти без вмешательства).
Так вот. Не нашел раздела "графики". Charts.php, который занимался этим в предыдущей версии, пропал вместе с пунктом меню. Посмотрел скрины в новости - тоже нет. Погуглил - ничего не нашел. Неуж отдельный раздел с графиками больше не нужен? Или я плохо ищу?
Через "последние данные" построить можно, но по одному параметру и мало. Неуж виджетами всех заново добавлять?
Навигация к графикам устройства и веб мониторингу через Monitoring-> Hosts.
добавлю, что через "latest data" можно понастроить себе, понатыкав галок, не по одному параметру, а по скольки хочешь, и хостов тоже может быть не один - кнопки внизу, мотай тщательней.
Поэтому ценность графиков, не привязанных к lld, упала почти до нуля.Но вот со скринами - беда-беда (графики у нас снова привязаны, мать его, к хосту, блин - а надо видеть сразу пачку). А эра звукового кина пока даже экспортом не оборудована.
Зачем был вообще нужен плохой косплей графаны, когда графана и сама вполне может нарисовать то же самое - Алексей, ау! Вы ведь пять(!) лет назад обещали что дэшборды их заменят как надо.
Спасибо тебе, добрый Алексей! Недостаточно старательно искал.
Все графики хоста на одной странице, непривычненько. С одной стороны, если их менее десятка, то перетыкивать для просмотра нескольких (да, лень комплексный экран) быстрее и удобнее. Но на хосте с тремя десятками ради просмотра двух мотать пришлось долго, а фильтр не сохраняется. Ну да ладно, приберусь наконец и раскидаю по экранам. Спасибо!
Debian 10 с MySQL обновился со свистом. Пошел на радостях обновлять следующий, на CentOS 7, но yum испугался зависимостей. Zabbix-web-pgsql в репе прежний, версии 4.0.
По описанию из-за устаревшего php в репах рекомендуется ставить zabbix-web-pgsql-scl, который тянет за собой php из тех самых software collections. А php уже и без того свежий и сторонний, но из remi. Среднему юзеру оно, конечно, удобнее, в одну команду, но средний админ вполне может добыть нужную версию сам. В ногу себе выстрелить не даюююют :(
Лучшая софтина для подлых пердунов...
Я поставил https://getnoc.com и мне норм.
Скажите, а там интерфейс все так же, на выпадающих списках?
Уже нет.
Я вот никогда не понимал этого подхода. Ну почему у них все лежит по частям в разных разделах. Ну неужели непонятно, что если я вижу Error от железки, мне хочется нажать кнопку и попасть на ее графики или в ее настройки. Почему мне приходится каждый раз лезть в хосты или в мониторинг чтобы посмотреть что творится то?
Старческий маразм разработчиков zabbix видимо не излечим.
о, неистово плюсую. Отсутствие связности между одними и теми же хостами/айтимами в разных разделах - безумно бесит.
Что мешает залинковать одно на другое - кроме непонимания альтернативно-одаренных веб-разработчиков, для чего на самом деле служат системы мониторинга - неизвестно.
Алексей, а что, вы сами начали выкладывать msi?
нормальные конфиги не завезли еще? это по прежнему проще конфигурировать непосредственно в sql?
примечание для особо одаренных - нормальные это:
1. текстовые!!!
2. удобочитаемые!!!
3. удобомашинногенерируемые!!!в противном случае - прошу наконец уже рассказать как это настроить и не сойти с ума от кликов.
дружочек, не хотел бы тебя огорчать, но "конфиги" такого размера не будут удобочитаемыми, если их сделать текстовыми. Я понимаю, попоболь осваивать что-то новое через двадцать лет "генерации" совершенно нечитаемых (хоть и текстовых) "машинногенерируемых" (только надо написать код для каждого чиха вручную, и нельзя перепоручить эту работу отделу мониторинга - они не умеют make/perl/awk) конфигов nagios, но проснись, голубчик - его писали во времена, когда компьютеры были большие, и было их два на всю контору.А конфиг zabbix-server/agent - он да, текстовый, удобочитаемый и, в принципе, даже машинногенерируемый, если так назвать пару вызовов sed в постинсталле.
> в противном случае - прошу наконец уже рассказать как это настроить и не сойти с ума от кликов.
прочитать наконец документацию, разделы "templates", "low level discovery", "autodiscovery".
Если после этого тебе все еще покажется что что-то тут можно автоматизировать дополнительно, можешь прочитать раздел "API". В целом нет ничего сложного в том чтобы вместо этого генерить sql-команды, и многие предпочитают этот способ как более прямой, но, к сожалению, структура базы "хорошо документирована исходным кодом", меняясь от версии к версии, а вот апи описан и зафиксирован.
Но обычно его используют не для этого, а для того чтобы новосозданные системы сами себе настраивали мониторинг тех параметров, которые понадобились их разработчку - вообще без возни с какими-то там "конфигами".
templates, говорите... а возможным стало уже прямо в темплейтах задать графики, так, чтобы они применились сразу при применении темплейта к конкретному хосту/сервису?
давно не смотрел просто. если стало возможным - то замечательно.
графики - с самого появления темплейтов, afair. Только зачем, если график любого сорта можно себе понакликать на ходу из latest data, включая график, объединяющий данные _разных_ хостов?Вот _screens_ (где как раз можно разные хосты в одну картинку) - там есть, хехехе, ньюансы. То есть создать его из lld можно, а увидеть потом - нельзя. Спросите у Алексея, что он про это гнал ПЯТЬ лет тому назад. Воз все там же. Ну нет больше у жабикса - программистов. Остались либо программисты-на-игого, либо разработчики персонализированных темплейтов по 600 евро в день. Поди плохо, и хотел бы ты после этого работать программистом?!
А dashboard из шаблона или lld - не, хрен там.
> в противном случае - прошу наконец уже рассказать как это настроить и
> не сойти с ума от кликов.Рассказываю:
https://www.zabbix.com/documentation/current/manual/api/refe...
И можно лепить любой удобный ___лично вам___ (!!!) текстовый "удобочитаемый" конфиг.
С машинной генерацией вопрос вообще не стоит - можно и без конфига генерировать.
Нет смысла настраивать Zabbix через текстовую простыню на десятки мегабайт. Такая простыня явно не пригодна для ручного редактирования. Если её каждый раз перегенерировать, то генерироваться она явно будет по базе данных. Если из одной базы надо перегонять данные в другую, то лучше пользоваться API.Если ещё учесть количество фишек в Zabbix'е, то для написания сколь-нибудь сложных правил мониторинга в этой гипотетической текстовой простыне придётся ещё пройти несколькомесячный курс обучения синтаксису.
Я для рабочих нужд написал несколько модулей: один извлекает описание хоста из БД, другой по этому описанию в соответствии с правилами контроля генерирует описание для сверки с Zabbix, третий модуль извлекает из API Zabbix текущее состояние хоста, сверяет его со сгенерированным и меняет изменившееся. Как только в БД меняется описание хоста, по нему прогоняется вся цепочка действий. Можно руками запускать на обработку хосты из БД массово, когда правила контроля меняются.
Конечно, написание всей этой интеграции заняло немалое количество времени, оплаченного работодателем, но в результате получена более высокая по сравнению с шаблонами гибкость, экономия на ручной работе по обновлению содержимого Zabbix'а и снижена вероятность человеческих ошибок.
Если вы думаете, что вас спасут текстовые конфиги, то скорее всего вы ошибаетесь. Писать генератор конфига для Zabbix'а всё равно придётся, он будет сложный, а т.к. весь файл нужно будет перегенерировать при любом даже самом мелком изменении, то обновления в конфигурацию Zabbix'а будут вноситься очень долго и вы скорее всего упрётесь в тормоза БД, по содержимому которой будете всё это генерировать.
Может, предложите наработки в апстрим хотя бы "как есть"?
Или отдельным проектом опубликуете?
PS: имени работодателя :-)// непользователь, но мало ли...
А смысл? Оно там наверняка завязано на их внутреннюю кухню (которую еще и светить не хочется), и только им такое и нужно.
(У меня во времена оны - наоборот, база хостов бралась из жабикса, куда они попадали либо из discovery, либо при создании хоста автоматикой деплоя - тогда еще не было возможности просто дернуть апи, приходилось лазить в базу)А апи и так опубликован - пишите кто хотите.
...как тут напоминают -- уже опубликовано такое:
http://altlinux.org/Категория:Инструментарий_для_развёртывания_Zabbix-ноды
в т.ч. grow-zabbix-node
http://packages.altlinux.org/alterator-zabbix-node
вот нихера непонятно - ни что это, ни как работает, ни нахерна вообще нужно.
Да доскеры, альтераторы, и т.п. Часть отрасли сама себе роет могилу, потому что такими темпами разбирающихся как оно реально работает останется полтора человека.