Представлена новая версия свободной системы мониторинга с полностью открытым исходным кодом Zabbix 5.2. Вышедший релиз включает в себя поддержку синтетического мониторинга, функции долгосрочной аналитики, мониторинга IoT и промышленных устройств, хранения секретной информации в Hashicorp Vault, поддержку ролей пользователей для более гранулярного управлениями правами доступа, новыми интеграциями с системами доставки сообщений и службами поддержки и многое другое...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53969
все так же тыкаем мышью по визардам или завезли нормальную конфигурацию через код?
это не nagios, где все настройки хранятся в текстовых файлах, здесь хранится в бдхочешь, используй sql код ;) =D
Не обязательно. Почему-то все забывают про Zabbix API, через который можно почти всё.
api у него хороший. но да, уже написали
Адепты iaas все страдают... Напишите уже feature-request, и заплатите за нужную фичу.
iaas/iaac
Так было же, заббикс говорит используйте апи.
Раз фронт у заббикса не очень (инопланетный не очень отзывчивый, слабокастомизируемый интерфейс с кнопкой add неизвестно где, отвратные графики, много ручных действий, отсутствие нормальной группировки, аудитов и отчетов), бекэнд тоже (не очень быстрый, тяжело траблшутить, проверять триггеры, витиеватое апи, нет нормальной балансировки (похоже в этом патче добавили, но это еще предстоит проверить), 5 способов сделать одно и то же с разными нюансами, ограничения превращающие рефакторинг темплейтов в ручной квест по резрешению зависимостей, много и упорно пишет в базу не самым оптимальным образом, довольно костыльные средства оптимизации вроде LLD), невыдающийся, но капризный кастомный агент, требующий перед работой его настроить(с учетом многих нюансов) и принести все ему необходимое(предполагается что этим занимается система управления конфигурацией, которая не очень дружит с императивной стратегией управления бекэнда, но если и дружит то только через витиеватый апи со многими ограничениями) возникает вопрос зачем заббикс вообще нужен. Для простой системы из нескольких серверов он избыточен, для сложного энтерпрайза он не готов, разве что для какого-нибудь небольшого интегратора сгодится где вебинтерфейс важнее всего остального, развернуть можно и на мощностях клиента, а поддерживать придется кому-нибудь другому или за отдельную денежку.
Чем витиеватое API?
Честно говоря, максимально простое API, более простое встретить сложно.
Если понимать архитектуру Zabbix, конечно.
"Сделай мне одним вызовом зашибись и пару красивых графиков для босса" там нет.
Оно не для того предназначено.
А вот зафигачить 100500 SLA хостов и подначесать им нужных элементов очень даже не сложно.
> Честно говоря, максимально простое API, более простое встретить сложно.
> Если понимать архитектуру Zabbix, конечно.Так из-за его архитектуры оно и есть витиеватое, частично из-за этого и часть проблем с его фронтом которое по большей части(внезапно не полностью) и работает через апи.
Ну например далеко неочевидно что темплейты это хосты во внутреннем предсталении заббикса. Или например Description триггера в фронте внезапно в api оказывается Comment, при этом есть другое поле Description, которое внезапно в фронте обозначено как Name. Найти все аварии по триггеру? Ну что ж, у нас есть событие, проблема и триггер. А что так много проблем? Ну проблема может генерироваться по триггеру и внутреннему событию. А среди 3 причин внутренних событий есть...триггер! Зато время события и в наносекундах и в таймстемпе можно получить. Что это у нас событие погасло? Может быть выражение триггера прекратило выполняться, может быть сработало выражение восстановления, может быть сработал такой суперкостыль как глобальные правила корреляции. У события есть свой severity, который просто наследуется от триггера и изменить его нельзя (хочешь разные уровни для заполнения раздела на файлопомойке и критическиважном сервере? Делай два разных триггера). Создавать события и проблемы ты кстати не можешь(по-крайней мере раньше). Хочешь прочитать значение триггера с макросами? Ну так получили выражение триггера и сам подставь туда макросы (их тоже предварительно получи). И т.д. и и т.п. что превращает любую пустяковую вещь в тонну различных запросов.
> Оно не для того предназначено.
Не очень понятно для чего оно вообще предназначено. Самим ручками запросить не вариант, придется целый инструментарий для этого писать. Видимо предполагалось что на основе апи напишут удобные обертки, но все обертки делятся либо на упрощаю авторизацию, в остальном копирую апи заббикса (pyzabbix например), либо на "делаю захардкоженные фичи, все что не нужно автору библиотеки не умею" (вроде zabbix-cli). В теории наверное можно написать удобную и гибкую обертку, но я таких почему-то не встречал, в любом случае от тонны запросов с таким апи не уйти (не ушел и фронт заббикса, в тч поэтому он такой медленный на некоторых операциях), а без этого отзывчивый инструмент не написать.
> хочешь разные уровни для заполнения раздела на файлопомойке и критическиважном сервере? Делай два разных триггераВот это всё как бы и показывает.
Да, Zabbix - это мониторинг, никакой эмпирики в нём быть не должно.
Хочешь два разных уровня - делай два разных триггера. На каждый триггер вешай свой уровень, который между хостами ещё и отличаться может. И порог срабатывания может быть макросом забит для каждого хоста отдельно. А шаблон с двумя триггерами - один. Более того, два триггера на любые разделы. Потому что LLD, который видит все разделы сразу, не требуя их вбивать по одному. И макросы с порогами стоят по разделам. У файлопомойки в одном шаблоне, у критическихднейсервера - в другом. Который дополняет шаблон "заполнения разделов".Совершенно другой подход, нежели у manager-oriented.
Потом ты захочешь третий уровень, но на вот эти десять хостов. И ой. Заббикс таких может сколько хочешь, и с любыми пожеланиями, именно из-за того, что каждое срабатывание отдельно. А не гвоздями прибитое "вот здесь мы имеем уровень A на 10 кб, B на 20 мб, C на 30 гб... ой, а D не поддерживается, ой, а если кроме гб надо ещё имя раздела сверить...
> Потом ты захочешь третий уровень, но на вот эти десять хостовДа.
> А не гвоздями прибитое "вот здесь мы имеем уровень A на 10 кб, B на 20 мб, C на 30 гбКакой смысл в этом предложении относительно дискуссии? Такое пожелание у меня и сейчас есть и сейчас оно спокойно решается макросами. Но я говорил не про пороги, а про уровни. Они то решаются только дублированием, что сильно усложняет поддержку.
> ой, а если кроме гб надо ещё имя раздела сверитьТут бы я еще понял, хотя возможность сделать разные выражения одного триггера для разных хостов (с одним возможно динамическим названием триггера и описанием) было бы кстати.
Смысл в том, что заббикс всё это может, просто несколько уровней на один триггер допустим - это не гибко.
Разные выражения триггера тоже макросами решаются, хотя конечно не без изъянов, длина выражения триггера слишком ограничена.
У меня много хостов и много триггеров. Я не хочу плодить еще один точно такой же темплейт, потому что заббикс почему-то не умеет менять уровни триггеров.
Это довольно частая проблема, какие-то сервера для меня критичны на них надо сразу среагировать, какие-то нет, их можно и утром починить, мониторю одно и то же, триггеры одни и те же, описания одни и те же. Я то могу сделать два шаблона, но во-первых о них всегда нужно помнить, если что то меняешь, надо не забыть и во втором\третьем поправить, о них всегда должны помнить другие пользователи (уже +статья для новоприбывших коллег), если они участвуют в иерархии, то это либо +еще лишние шаблоны, либо это разруливать (вручную или костыли для автоматизации, нормальной автоматизации у заббикса нет). Если эта система именно для мониторинга, то почему на пустом месте мне уже надо городить костыли?
> У меня много хостов и много триггеров. Я не хочу плодить еще
> один точно такой же темплейт, потому что заббикс почему-то не умеет
> менять уровни триггеров.Пфф. Как не умеет? Макросами пользуетесь?
Раз нужно платить за очевидные вещи то не проще ли купить толковую систему мониторинга а не использовать этот велосипед с квадратными колесами (сабж).
Ну тебя же мамка родила с квадратной головой? А ведь проще было пойти взять нормального.
> Адепты iaas все страдают...Не только. Вообще все те несчастные, кто пытается использовать Zabbix для мониторинга, а не для ИБД.
> Напишите уже feature-request, и заплатите за нужную фичу.
Последним двум конторам, которым я работал, проще было платить полторы-две сотки в месяц за человека, который заменит Zabbix на Prometheus. Потому что после завершения этой операции человек займется еще чем-нибудь полезным, а вот инженер по поддержке Zabbix стоит, может, и чуть дешевле, но всегда будет заниматься только поддержкой Zabbix. Да ещё и по мере роста числа серваков, нужно увеличивать число заббиксменов, один уже не вывозит.
Все так.
Дай угадаю.
В пределах сотни хостов и десятки тысяч элементов данных?
:D
В противном случае "полторы-две сотки" придётся платить лет 25, и всё равно не заменит.
многое что можно сделать через шаблоны и всякие там автодискавери.
если интересует миграция шаблонов между экземплярами то существует экспорт-импорт шаблонов в xml.
для автоматизации этих операций существует API configuration.export/configuration.import
Но все это на уровне костылей.
Шаблоны при ручном рефакторинге превращаются в адъ. Автоматический рефакторинг возможен только через апи, нормальных инструментов для этого нет, придется писать самому. Потом придет пользователь через веб интерфейс и навесит айтем на хост мимо шаблона, о чем вы скорее всего не узнаете, если не дергается по 100500 раз в день апи аудита, запросы к которому тоже придется написать самому.
Экспорт\импорт в xml занятие довольно весело, учитывая что в любой момент может прийти пользователь и поменять шаблон через веб-интерфейс. Можно по 100500 раз дергать апи и выгружать все шаблоны, проверять изменения и при необходимости их перезагружать, таким образом из буханки заббикса получится IaC трамвай но вряд ли это тянет на архитектуру века, даже если вы напишите для этого инструменты (удачи с редактированием триггеров в xml файлах). Имхо незачем сову на глобус натягивать, если можно просто взять глобус.
Переход на Yaml это как раз шаг в направлении значительного упрощения работы с текстом шаблона. Можно хоть в текстовом редакторе их создавать.
Получать шаблоны в ямле можно было давно, никак это не спасало.
Как их редактировать без веб интерфейса и удобного чекера(а его и в интерфейсе нет) все равно не понятно. Разве что иметь отдельный экземпляр заббикса для редактирования этого и через апи сначала выгружать в гит, а оттуда в настоящий заббикс. При этом в темплейте могут быть например связи с другими темплейтами. В теории наверное это все равно можно разрулить, но зачем бодаться и переписывать систему мониторинга, основная идея которой изкоробочность. Можно за то же время настроить (а то и переписать) другую систему мониторинга, которая решает задачи благодаря архитектуре, а не вопреки.
Не надо навешивать элементы без шаблонов. Да, такая возможность есть, но это скорее для инсталляций из полутора десятков хостов. Всё есть шаблон. Шаблон шаблона. Шаблон с шаблонами. API дёргается для заливки хостов и привязки к ним шаблонов. В т.ч. из CRM. Шаблоны на ХОСТ, а не на СЕРВИС. Если нужен СЕРВИС - агрегируется через API. В итоге рефакторить шаблоны обычно сильно не требуется.
Ну так расскажи как:
1)Запретить пользователям через вебинтерфейс навесить элемент без шаблона. Предвижу ответ в духе "костылить скрипт, дергать по 100500 раз аудит и отменять действие через апи", "не заводить пользователей без письменного согласия не добавлять айтем без шаблона". По понятным причинам оба варианта !@#$%.
2)Как рефакторить шаблоны шаблона:
темплейт1 с элементомА(условно место на файловой системе) и темплейт2 с элементомБ рефакторим в темплейт3 с элементомБ и темплейт4 с элементомА. Что можно сделать? Удалить часть темплейтов и потерять их айтемы и исторические данные (в тч критичные бизнес метрики) и навесить темплейты заново. Править базу данных заббикса ручками(!) и надеяться что ничего сломаешь и заббикс продолжит работать. По понятным причинам терять бизнес метрики и править БД не хочется.
3)Как гарантировать что шаблон созданный вон тем новеньким админом отвечает политике партии, ведь даже посмотреть аудит в заббиксе это мука. Можно скрипт написать который будет опосля лезть в аудит, но это совсем не по энтерпрайзному. В IaC я просто поставлю хук в гите.
4)Как же агрегировать через СЕРВИС? Например хочу видеть один триггер с перечислением лежащих серверов с распределенным сервисом (в идеале разворачиваемый список серверов, но пойдет и первые три), а не портянку из 20 проблем на каждом сервере. Навешивать триггер мониторящий сервис по нодами на хосты, потом (снова?) постоянно дергать апи и следить за появившимися событиями, удалять их(чтобы погасить портянку триггеров) и отправлять данные айтема с количеством лежащих серверов на фейковый хост? Ну это просто запредельный уровень костылестроения.
> Ну так расскажи как:
> 1)Запретить пользователям через вебинтерфейс навесить элемент без шаблона. Предвижу ответОчень просто. Есть CRM, который дёргает API. "Пользователи" с заббиксом в плане конфигурации вообще не работают.
В интерфейс ходят только power users, которые понимают, что делают - и то с выходом 5.2 я их обпилю очень существенно.
> 2)Как рефакторить шаблоны шаблона:
Заббикс - это не manager-oriented "бизнес-метрики", и он требует аккуратности. Это серьёзный _мониторинг_, а не рисовалка отчётов для директора. Если шаблоны требуют рефакторинга - значит они изначально созданы криво. Но даже в этом случае не надо ничего с ходу удалять. Заводите новые совместимые шаблоны-разбивку-или-слияние, отменяете старые без удаления item'ов, вешаете новые. Дальше правите новые шаблоны как душе угодно. И никакие метрики никуда не денутся.
> 3)Как гарантировать что шаблон созданный вон тем новеньким админом отвечает политике партии
Административно. Я не вижу причин технически это всё ограничивать, новенький админ, прежде чем чего-то куда-то писать, показывает сделанное.
> 4)Как же агрегировать через СЕРВИС? Например хочу видеть один триггер с перечислением
> лежащих серверов с распределенным сервисом (в идеале разворачиваемый список серверов,
> но пойдет и первые три), а не портянку из 20 проблемTags
> Очень просто. Есть CRM, который дёргает API. "Пользователи" с заббиксом в плане конфигурации вообще не работают. В интерфейс ходят только power users, которые понимают, что делают - и то с выходом 5.2 я их обпилю очень существенно.
> Заббикс - это не manager-oriented "бизнес-метрики", и он требует аккуратности. Это серьёзный _мониторинг_, а не рисовалка отчётов для директора.Если фронтендом не пользоваться, то от заббикса остается не слишком удобный агент и прожорливый, сложный в поддержке и с кривой отказоустойчивостью бекэнд. Возникает вопрос зачем вообще тогда нужен заббикс.
> а не рисовалка отчётов для директора
Сам заббикс так не думает и позиционирует себя именно как изкоробочное решение все в одном с графиками(потом правда переобулись, признались что не осилили и по графикам стали предлагать графану) и доступностью отчетов (если не для директора, то по-крайней мере для его прокладки). У них даже отдельные разделы для этого есть в интерфейсе, в том числе со всякими сгенерированными картами (уровня сайтов 1990х).
> Если шаблоны требуют рефакторинга - значит они изначально созданы криво.
Э, нет, это требования к мониторингу меняются. И это нормально, это даже сами заббиксовцы признают и даже выпускают лонгрид "как с наименьшей болью писать темплейты"(к сожалению то что боль приносит их архитектура там не обсуждается, зато обсуждается на конференциях, но ответ всегда в духе "думаем над этим, скоро выпустим M там станет немного лучше", но вот уже 5 лет прошло, а проблемы все те же).
> Но даже в этом случае не надо ничего с ходу удалять. Заводите новые совместимые шаблоны-разбивку-или-слияние, отменяете старые без удаления item'ов, вешаете новые. Дальше правите новые шаблоны как душе угодно. И никакие метрики никуда не денутся.
Тогда у меня остается куча мусорных метрик без темплейта, которые "не надо вешать на хост". Можно конечно их найти ручками и поудалять, но уровень костылестроения итак уже зашкаливает.
> Административно. Я не вижу причин технически это всё ограничивать, новенький админ, прежде чем чего-то куда-то писать, показывает сделанное.
В прометеусе он показывает мерж реквест, а в заббиксе он как показывать будет? Смотри, я сделал такой темплейт, давай прокликаем по всем 99 айтемам и 30 триггерам и проверим что я все правильно написал. Ну или скопируй все и в xml'ку потаращься. Ах да, проверить что я накуралесил мы сможем либо в отдельном экземпляре заббикса (и потом мучаться с экспортом, видимо еще дописывать "изкоробочное решение" впридачу с интеграцией с CRM), либо в бою(отдельный квест раскатить темплейт по хостам, а не скопом и наблюдать как весь дашборд становится красным от новых триггеров и закрывает действительно важные проблемы), ведь другого решения тестировать триггеры заббикс не предлагает.
> Tags
Я могу теги расставить и сделать триггер с зависимостью, чтобы он загорался когда проблем с тегами >2, но либо этот триггер будет на КАЖДОМ хосте и соответственно придем к тому от чего начинали. Либо он будет на отдельном фейковом хосте(что уже само по себе костыль, а до этого обновления еще и не очевидно где фейк, а где настоящий) и темплейт становится непереносимым (еще один камень к экспорту темплейтов), появляется неочевидная и неявная зависимость (оказывается темплейтА на хостах группыА и темплейт Б на фейковом хосте не могут друг без друга и логически представляют собой один темплейт, но в абстракциях заббикса два, и менять их(например название тега) надо оба, это кстати противоречит рекомендациям заббикса по разработке темплейтов). Ну и то что заббикс не умеет в иерархию тегов, считает tag:tag1, tag и tag:tag1:tag2 разными тегами, тоже не добавляет плюсов и заставляет в такой схеме городить фантастические перечисления тегов. Есть еще вариант дергать апишку и удалять проблемы с нужными тегами и вместо них создавать новые (опять же на фейковом хосте), но это опять же костылестроение, удар по производительности(постоянно дергаем апишку, а ведь системы мониторинга дерутся за nvps), опять дописываем "изкоробочное решение"
> Если фронтендом не пользоваться, то от заббикса остается не слишком удобный агент
> и прожорливый, сложный в поддержке и с кривой отказоустойчивостью бекэнд. ВозникаетВот как раз бэкенд - это то, что и есть в нём хорошего. Ну не вывозят ваши прометеусы с графанами тысячи разрозненных и не агрегируемых в сервисы хостов и сотни тысяч метрик без отдельной пары стоек под них, никак. Да и на паре стоек только с костылями.
> Сам заббикс так не думает и позиционирует себя именно как изкоробочное решение
Изкоробочное решение - оно для тех, у кого небольшие инсталляции - там по сути без разницы, что выбрать. Кому-то больше нравится Zabbix, кому-то Prometheus, кому-то ещё что.
>> Если шаблоны требуют рефакторинга - значит они изначально созданы криво.
> Э, нет, это требования к мониторингу меняются.Если шаблоны созданы по принципу KISS и нормально структурированы, то меняющиеся требования к мониторингу вообще никакой попaболи не вызывают, это я тебе по опыту говорю. Да, архитектура там не простая (точнее наоборот, она простая в доску, и этим вызывает сложности у любителей кнопки "сделаймнезашибись"), но именно она позволяет строить практически любые варианты мониторинга.
> Тогда у меня остается куча мусорных метрик без темплейта, которые "не надо
> вешать на хост". Можно конечно их найти ручками и поудалять, но
> уровень костылестроения итак уже зашкаливает.Зачем? Ещё раз: создаёте новые шаблоны, которые у вас крутятся в голове, из исходных. Далее отменяете-навешиваете - и вот здесь сразу видно, что с заббиксом работали постольку-поскольку - существующие item'ы сами привяжутся к новым шаблонам по совпадению ключей. Дальше уже в рамках новых шаблонов добавляете-меняете-удаляете всё, что душе угодно.
> В прометеусе он показывает мерж реквест, а в заббиксе он как показывать
> будет? Смотри, я сделал такой темплейт, давай прокликаем по всем 99
> айтемам и 30 триггерам и проверим что я все правильно написал.Хуже. Не просто прокликаем, а сделаем логический анализ написанного.
Тяп-ляп "позырить в код" по-диагонали - не наш метод. Половина из далее указанного после не нужна.> интеграцией с CRM), либо в бою(отдельный квест раскатить темплейт по хостам,
> а не скопом и наблюдать как весь дашборд становится красным от
> новых триггеров и закрывает действительно важные проблемы), ведь другого решения тестировать
> триггеры заббикс не предлагает.Мы для тестов используем "серенький" unclassified приоритет. Фаззинг триггеров тоже делается легко, благо создать тестовые элементы вида trapper и пополнять их sender'ом проблем нет, но это честно говоря даже в рамках наших масштабов оверкилл.
>> Tags
Мы для этого никаких фейковых хостов не используем, просто _опционально_ (опционально потому, что при непосредственно решении проблемы надо видеть всё) убираем при отображении эвенты, для которых имеются однозначные выстрелившие зависимости по тегам. Да, список забираем через API. На nvps это вообще не влияет.
Полновесный API в Zabbix существует фиг знает сколько лет, так-то.
Соответственно любая конфигурация через код благодаря API возможна.
Любой костыль теоритически возможен. А для любой конфигурации на практике как миниум нужны колбеки (вебхуки) и работа над оптимизацией апи, чтобы не приходилось делать 100 запросов на каждый чих (на базе эти 100 запросов превратятся в 500).
> Интерфейсы хостов стали необязательнымиДождались. Актуально для кастомных мониторингов основанных на самописных скриптах.
Changelog солидный. Молодцы, команда Zabbix, отрадно на него смотреть.
А экспорта dashboards до сих пор нет, ни в модный yaml, ни в немодный xml, да?
А зачем? Действительно интересно.
Действительно, ну зачем нам экспорт конфигурации, кому он нахрен нужен?
Давайте просто бэкапать пятитерабайтную базу вместе с ненужной историей (обратите внимание, что структура базы "прекрасно документирована исходным кодом"), а потом восстанавливать чохом, если что-то где-то ненароком повредили или переписали а оно-вот, вместо того чтобы достать из заначки нужный скрин как он был день назад, да еще и сравнить с текущим.Ни истории правок, ни возможности клонирования на другие системы - клик, клик, клик мышиком наше всьо.
Я одного не пойму - а зачем собственно экспорт-импорт всего остального был сделан, включая и скрины?
Собственно, прекращение публикации (последние года четыре?) ОТДЕЛЬНО изменившихся в новых версиях темплейтов, для тех кто поапгрейдил старые, оставшись с древними шаблонами, из той же серии. Ну зачем вам новые шаблоны, вы ж уже старые кастомизировали и переделали двадцать раз.
А, ну у нас вообще legacy шаблонов нет например.
Они нам не годятся, все шаблоны сделаны под задачу.
Не для всех вариант, да, но он незаменим.
Мой вопрос был конкретно про дашборды.
Что так глобально отличает дэшборд от любого другого элемента конфигурации?Почему шаблон бэкапаем, обычный хост бэкапаем, а дэшборд, собирающий данные сразу о группе хостов - внезапно, не бэкапаем?
При том что это наиболее мутная, недопиленная и неудобная часть забикса, и бэкап вообще-то очень даже может пригодиться (как и просто возможность сравнить было-стало)
Так ты можешь бекапить и без ненужной истории.
Исключаешь семь таблиц истории (тренды и обычная история) и твой бекап становиться очень небольшим.
После разворачивания бекапа без истории на другую (или ту же) БД и создания семи недостающих таблиц - всё работает без проблем (проверял на Zabbix 4.0)
> Так ты можешь бекапить и без ненужной истории.Не могу.
Поскольку совершенно неясно, что потом с этим бэкапом делать и зачем он такой мне ненужен.От какой беды стра$уемся-то(запрещенное на впопеннете слово) - попадания ядреной бонбы прямо в сервер мониторинга? А тебе еще точно этот бэкап потом пригодится?
Гораздо более вероятная беда - кто-то (да хоть ты сам) полез переделывать и сделал хуже чем было. Вернуть все назад при наличии экспортированного шаблона - дело нескольких секунд (а то и сравнить два файла и аккуратно смержить нужное, выбросив вредное). Но с дэшбордом этот фокус не прокатит, любые твои изменения неоткатываемы и неконтролируемы.
Восстановить бэкап за вчера целиком, потеряв вообще всю информацию за сегодня (а в твоем экономичном варианте еще и все данные вообще)? Ну оооок...
При этом структура базы недокументированная (и в ней чорт ногу сломит) - как сами разработчики умудряются при этом в ней разобраться, неведомо. Поэтому и вручную sql'ем ты свой дэш отдельно не добудешь.
я может чего не так понял, но
если ты забэкапишь таблички кроме тех, что про ненужные тренды и историю, потом все непоправимо улучшишь, что мешает влить тот самый бэкап?
наличие drop table(database) if exists? это и есть не решаемая проблема или есть более другие какие-то?
Ну тоже как-то так себе вариант - снести нахрен ВСЮ конфигурацию ради одного поломанного графика.Возможно еще и получив пачку мертвых item'ов в хистори, если со времени создания бэкапа понасоздавались какие-то из них, или еще каких интересных проблем целостности бд (я вот не помню, что там за constraints на хистори стоят, но вполне могут быть).
Знаешь, ну его нафиг, я лучше уж снесу неудачный дашборд и новый себе сделаю. (Ну или, на самом деле - продолжу рисовать их графаной. Та тоже умеет их необратимо портить, но у нее есть экспорт и он, в отличие от некоторых, работает, а не спрашивает "ну зачем вам")
На хистори там нет констрейнтов вообще, хистори и тренды можно смело бахать, ничего, кроме вычислений за длинный период, не сломается - да и те восстановятся, как наберутся данные.
Ну мы так и бэкапим. Потеря истории совершенно не страшна.
Я кажется понял, в чём вообще у двух местных мониторинговых лагерей коллизия.
Мы здесь смешиваем технический мониторинг (который для опознавания, решения, предупреждения возникающих проблем) и "бизнес"-мониторинг (который всегда с красивыми угловатыми идущими вверх графиками).
Заббикс - это технический мониторинг. В котором сами по себе метрики особо важного значения не имеют, важное значение имеют значение вычисляемые от них триггеры.
> Мы здесь смешиваем технический мониторинг (который для опознавания, решения, предупреждения возникающих
> проблем) и "бизнес"-мониторингнет.
Просто не любую проблему можно свести к конкретному значению конкретного параметра в сию секунду, и повесить на нее триггер. Иначе бы меня давным-давно заменили обезьянкой, умеющей отличать красное от зеленого и в нужном случае дернуть сгоревшую деталь, заменив на новую. Кстати, забикс и его дэшборды для этого не нужны, справился бы примитивный nagios.
Иногда (на самом деле - в нормальной среде почти всегда, потому что на то и нормальная, что не разваливается на ходу сама по себе) нужно видеть состояние системы - как комплекса разных метрик, и чаще всего - графических, чтобы побыстрее понять, где оно сегодня отвалилось или еще только собирается.
И очень часто нормальное состояние нельзя отличить от аномального, если нет возможности посмотреть, как это самое нормальное выглядело вчера, час назад, год назад.
В нашем случае из графических метрик только трафик. Нет, есть прочие, но на них по-хорошему никто почти не смотрит в графике, проще на список выстреливших (в т.ч. превентивных) триггеров глянуть. Потому что ну сотни ж тысяч метрик с кучей связок по триггерам, это всё графически рисовать и отсматривать просто бессмысленно.
По изменениям больше похоже на major release. Круто!
Да он и есть мажорный, только не lts.
У них достаточно классическая система версионирования, без version number inflation.
5.2 это не минор, 5.2 - это полноценный новый релиз.
бесполезная вещь.
Мде отображние графиков не починили (ZBX-17748)
Так же не починили ZBX-18071,ZBX-18265
Все колом встает
Самый эталонный "ненужен" в вакууме. Более бесполезной и усложнённой системы мониторинга не видел. Написано через одно место, хуже разве что только OpenNMS.
а как Вы относитесь к netxms?
Не пробовал. Вы знаете я упоротый ярый фанатик Prometheus и считаю что им можно сделать всё что относится к мониторингу, даже орехи колоть :)
Зачем же тогда придумали Victoria Metrics?
> Самый эталонный "ненужен" в вакууме. Более бесполезной и усложнённой системы мониторинга не видел. Написано через одно место, хуже разве что только OpenNMS.Не отчаивайтесь. Говорят, начиная с версии 7.0, собираются начать добавление функций собственно мониторинга.
ZBXNEXT-46 до сих пор не завезли. А обещали в 5.0. 11 лет, рукожопы.
Обещали и сделали зависимость от доступности прокси. Зависимости между хостами (а не сервисами или проблемами) в Zabbix не имеют смысла. Ненужное усложнение.
Вы это с серьезным выражением лица пишите, да ?
Эти тонны писем когда грядка оборудования сломалась/ починилась, типа нормально...
Насколько я понимаю, разработчики первоначального жабикса были э...как бы это помягче. Серверные админы мелкой лавки (мелкой, потому что крупная плясала бы от сервисов, а не от хостов). В нем и snmp-то появился к концу второй версии, и только к четвертой - такой что им стало можно пользоваться на самом деле. Говорит кое о чем, не так ли? Поэтому им вообще невдомек, что у, скажем, сетевого оборудования зависимости именно от "хостов", а не айтимов, от которых часто нужна хистори, но не триггеры (мне совсем неинтересно знать что порт 5/0/42 в дауне - это юзер выключил комп и домой пошел).Они реально не понимают.
Приспосабливать жабикс к мониторингу именно сетей - очень печальное занятие, поверьте моему опыту.
Как жаль, что whatsup сдох, а замены так и не появилось.
5/0/42 в дауне - это плохо. Все неиспользуемый порты потушены, пользовательские порты промаркированы USER_CAN_BE_DOWN в дескрипшнах.
Соответственно заббих читает дескрипшны и знает, какие порт имеет особенности. Каким-то портам например не разрешено работать не в 1G, каким-то разрешено только в 100M (иначе что-то переключили), и т.д, и т.п. Это если о портах.
> 5/0/42 в дауне - это плохоэто нормально, в петропавловске-камчатском - полноч! Спать домой он пошел, и ноут с собой уволок.
Или вырубил десктоп. А может у него вообще отпуск.Мне _вообще_ неинтересно получать информацию об изменении этого статуса. Вот падение аплинка - это повод накостылить обезьянку на местах. А это соседний 5/0/48, и на нем будет триггер.
При этом мне _может_ потребоваться иногда взглянуть на состояние ("пользователь жалуется, что интернет всьо - порт-то в апе?"), картинку в целом - "у нас что-то канал перегружен, это все равномерно взялись за работу, где-то аномалия, или какая-то часть машин что-то резко стала качать?" или "а вообще-то нормально что он _сейчас_ выключен - какой у этого порта в принципе use-pattern...а, ага, постоянно вкл-выкл, значит, проблема вряд ли в нем". То есть собирать какие-то метрики мы будем, но никаких автоматических выводов про них делать не будем, и "все красное" показывать тоже не будем.
Ну мы так и делаем - на состояние порта можно взглянуть, даже если он в игноре. Просто триггер для него взлетать не будет.
Мне чаще было нужно не состояние, а внезапную флуктуацию загрузки сразу пачки портов, например, увидеть.И это хорошо видно именно на общих скринах. Причем проблема скорее всего не имеет отношения к непосредственно сетевому железу - но она хорошо на нем видна (когда знаешь его нормальное состояние, причем именно в это день недели и в это время - вот для чего нам нужна история), а дальше уже можно по получившейся картинке сделать выводы, куда копать дальше. Иногда мне удавалось поймать проблему ДО того как срабатывал мониторинг сделанный на уровне бизнес-логики.
Или мы его и придумывали после разбора, новый.
То же самое, к примеру, с внезапной флуктуацией места на диске - она еще и близко не подошла к тревожным порогам, но видно что вот эти группы ВДРУГ начали активно место поджирать - "а не логи ли они пишут, и нет ли чего нехорошего в тех логах".
Или cpu load. Машинки нынче мощные - до критического состояния вообще никогда не дойдет. Но вот этот конкретный демон - явно сходит с ума. Один или все? Или как распределено? Опять же часто в логи потом можно уже и не смотреть, и так всепонятна.
> И это хорошо видно именно на общих скринах.Флуктуации загрузки портов без флуктуации загрузки аплинка обычно не бывает, последнюю и мониторим min/max.
> То же самое, к примеру, с внезапной флуктуацией места на диске
Угу, мониторим дельты для изменения. Диски, почтовые очереди. Если растёт быстро, алертим.
> Или cpu load. Машинки нынче мощные - до критического состояния вообще никогда
CPU load мониторим не только в %, но и по числу активных процессов. + количество зомбей.
В общем да, всё похоже делается. Только мы алерты пишем по новым ситуациям сразу, на графический мониторинг зоопарка ни у кого времени не хватит.
> Флуктуации загрузки портов без флуктуации загрузки аплинка обычно не бывает, последнюю и
> мониторим min/max.Ну вот она растет, письмо прислала - самое время пойти и посмотреть, откуда дровишки - и проще всего это увидеть просто в общем скрине по юзерпортам.
То ли случайность, то ли разгоняемся, "и, кстати, не на эту ли стойку 15 минут назад апдейты накатили?" Оно бы еще минут через пять, конечно, и так сработало и откатилось - но иногда эти пять минут решают.
> В общем да, всё похоже делается. Только мы алерты пишем по новым ситуациям сразу
ее ж для этого зафиксировать надо, ситуацию-то. А дальше уже думать - есть вероятность повторения, или хрен бы с ним, завтра в другом конце спагеттины что-то пошевелится.
[это не спагеттина, это солитёр :D]
А что там такого с snmp в 4 версии поменялось? Я от 3 особых отличий не вижу.
где-то между 3 и 4 стало можно по настоящему пользоваться snmp3 - до того он был недоделанный, то не авторизуешься, доступным железу способом, то не прочитаешь.Впрочем, на фоне первых версий где его вообще не было, и агент запускал ручные скрипты, читающие счетчик из файла, это были еще цветочки.
> Вы это с серьезным выражением лица пишите, да ?
> Эти тонны писем когда грядка оборудования сломалась/ починилась, типа нормально...Не надо тонны писем. Расставьте теги и сделайте action+HTTP, далее API и уже ситуативное письмо, и то если необходимо. У нас допустим сделан визуальный мониторинг с оповещением, письма вторичны и нужны только при разборе ситуаций.
> У нас допустим сделан визуальный мониторинг с оповещениемэто хорошо для вас, с прикованной к этому мониторингу обезьянкой 24/7 отличающей красное от зеленого (и которую порют, если уснула и проспала). Хотя глядя на пример ниже - у вас там "все красное", как вы вообще живете с этой херней?
А у нас вот нынче нету прикованных обезьянок, и в визюальный мониторинг пыриться совершенно некому и некогда. Он служит для поиска системных проблем, которые не сводятся или пока не получилось свести к контролю единственного айтима. И то в общем в графане, ибо родные жабиксные средства плохие, а когда я это настраивал их вообще не было.
А когда просто где-то место вотщаскончится, где раньше такого не было - нужно письмо владельцу, чтоб просто быстро бежал разбиратьтся.
> глядя на пример ниже - у вас там "все красное", как вы вообще живете с этой херней?Так в таких масштабах это нормально. Всегда где-нибудь что-нибудь лежит.
Проблемы, которые не требуют нашего решения, получают тикеты, acknowledge, и уходят до момента решения.
Текущие проблемы решаются. Есть проблемы, которые требуют решения, но оно долгосрочное - это висит.
Всё это разбито по группам, каждую группу отсматривают и отвечают за решение "по сектору" отдельные команды.> А у нас вот нынче нету прикованных обезьянок, и в визюальный мониторинг
> пыриться совершенно некому и некогда. Он служит для поиска системных проблем,Не обязательно туда постоянно пыриться. Отметил новые проблемы, создал при надобности тикеты, дальше список проблем позволяет в т.ч. разобраться в причине падения. Не просто "вот нашему сервису 3.14-да-да", а что и где отломалось или скоро отломается видно.
Зачем мне эти заморочки теги, экшены, апи вот эти все грабли? Мне нужен простой инструмент, простая зависимость хоста от хоста.
Я понимаю в чём коллизия. У вас все хосты друг на друга завязаны, и сервис один (ну или два с половиной).
У нас сервис не монолитен, и все хосты относительно независимы, плюс есть сложного типа резервирования, когда прямая зависимость хоста от хоста исчезает.
Ну то есть вот в этом примере ниже - у нас Barracuda недоступна. Балансеры ругаются.
Но нам похер, потому что есть другое уведомление, что лёг свитч в одном из DC.
И нам тоже похер, потому что есть ещё одно уведомление (его не видно), что лёг power feed A в этом самом DC.
А похер потому, что по факту недоступность всей этой пачки на сервис не влияет, там резервирование и балансировка. Но мы знаем, что проблема есть. И когда фид поднимется, если что-то на место само не встанет, уведомления будут висеть. Если бы была проблема с сервисом - были бы уведомления других категорий. В добавку к.
Как только DC mgmt закроет тикет по power, мы пойдём чекать, сгинули ли наши уведомления :D
Ну вот все, что мне хотелось бы знать в данной ситуации - что в писятом DC сдох один из питальников.
Что попутно сдохла половина установленного там железа, не имеющего резервного питания - уже знать незачем и неинтересно - и нефиг засорять мне мусором почту, электричество от этого не появится. Починят электричество - вот тут пора будет осторожненько проверить, все ли поднялось.Причем в идеале бы уведомления по этой проверке еще отложить на пол-часика, потому что что-то может подниматься долго, и мне об этом тоже неинтересно знать. Но это не про жабикс, увы, абсолютно.
Заманаешься в нем такие цепочки настраивать. В prtg чуть лучше, но тоже слишком много ручной ненужной возни (и главный сервис по мнению их разработчиков - "ping". Который, вместе со своими метриками, мне вообще нах не сдался в большинстве случаев. Зачем пинговать то, к чему все равно ходим по tcp, мать вашу?!)
Почты вообще нет. Точнее она есть - свалкой в архив для разбора полётов, если вдруг.
SMS только на критические события, когда действительно сервис валится.
Иначе очешуеешь получать 100500 писем в сутки, даже если все цепочки обрезать до 1 элемента.
Самих цепочек очень много.
// сервис валится = сервис валится целиком или настолько критично, что страдают все клиенты или здоровые сегменты
Ну так мы чинить-то что-то собираемся, или как? Если собираемся - мне нужно письмо об этом (а не в вебню пыриться). Вот сколько нужно чинить - столько и писем. А если чинить ненужно, мне об этом и знать незачем.
Зачем нам письмо, если сразу же видишь, что надо чинить, и насколько это критично?
В любой момент времени. Не шарясь в 100500 письмах за текущие сутки.
> Зачем нам письмо, если сразу же видишьГде вижу? Нигде не вижу - я не обезьянка, я не смотрю 24x7 в дэшборд. Я туда смотрю когда уже что-то пошло не так.
Вот почту я прочитаю, рано или поздно. Потому что это вообще основной инструмент коммуникаций. (Для тех у кого они другие - в жабиксе есть другие media)
Если у тебя 100500 ненужных писем в сутки, которые ты все равно не собираешься читать - настрой уже себе аутлук, времена mailx давно прошли.
Мы ещё даже несколько дальше шагнули, до проактивности: мы видим, когда превышены или занижены определённые показатели (самое простое - те же диски в примере, на деле всего больше - ёмкости каналов, трафик по voip-транкам, etc.) в т.ч. от медианы за период. И поэтому заранее видим, чего ещё дышит, но может сломаться.
Как пример - мониторим версии ядер. Если кто-то вкрутит куда-то ядро не из разрешённых - мы это увидим, хоть оно и работает.
Версии прошивок на свитчах, роутерах, версии FPD. И т.п.
Если мы допустим находим бажную версию - впихиваем её в список, и сетевая бригада получает горку оповещений о "замените этот глюкодром".
Потом сетевая команда может сама в дескрипшны интерфейсов вписать свои MIN/MAX/PCTL, на BGP и т.п. в дескрипшны пиров. Zabbix это сам обработает, и даст им такие алерты, которые именно они хотят на каждом конкретном участке.
Ну и это всё частные примеры, оно повсеместно. Какие темплейты на сервер вешать - пишется в параметре агента на самой ноде, например.
Какие темплейты вешать на клиентское устройство, в т.ч. от партнёра - решает детектор. Сначала заббикс выгребает банальные device name и т.п. из SNMP и прочих типовых мест, всё что смог. Потом это через API смотрит скрипт-детектор, и делает enable-disable всяких темплейтов и элементов через API, согласно тому, что увидел в прописанных параметрах устройства.
У нас например клиенты имеют возможность смотреть графики своих VPN и выделенных линий. CRM смотрит в заббикс, берёт с него список нужного к отображению, и дальше клиент это всё видит. Появилось устройство - оно везде появилось. Короче у нас специфичная тема, оно почти zabbix-centered всё :D
Вы это с серьезным выражением лица пишите, да ?
Эти тонны писем когда грядка оборудования сломалась/ починилась, типа нормально.
Для вас может и не имеет смысла, а для меня как для сетевика это крайне важная необходимость. Ибо без этого для меня это бесполезная поделка. Эту фичу люди просят с 1.6. На текущий момент по количеству проголосовавших за эту фичу на первом месте. Но разрабы упорно игнорируют. В 5.4 судя по всему тоже не будет её.
> Возможность использования пользовательских макросов в коде скриптов препроцессингаВ 5.0 это уже было
Не понял, без объявления отменили поддержку CentOS 7?
И так каждый релиз - преодолевание созданных собой же трудностей. Придумали идиотские абстракции сначала, потом немножко убрали ограничений, теперь вот отказались от некоторых из них.Умные люди давно уже снесли этот ПТУшный курсач и поставили что-то типа Прометея
> Умные люди давно уже снесли этот ПТУшный курсач и поставили что-то типа Прометеяи теперь получают зарплату за "поддержку мониторинга", отдельную от остальной работы?
Потому что оно будет именно так.
Нет, прометей просто работет. Сотня хостов, тысяча — ему пофиг.А вот при количестве хостов более сотни "инженер по поддержке Zabbix" — обязательная позиция в IT-отделе.
> Нет, прометей просто работет. Сотня хостов, тысяча — ему пофиг.ему-то пофиг, рабу не пофиг - который все это в нем старательно заводит и правильным образом в него складывает.
А потом _отдельно_ поверх бесполезной свалки метрик возводит с нуля и из ничего - мониторинг.> А вот при количестве хостов более сотни "инженер по поддержке Zabbix" — обязательная позиция в
> IT-отделе.мы как-то обходились, при количестве хостов чуть менее тысячи.
Обычными инженерами, обычно занятыми своей основной деятельностью.Если бы жабикс нам не помогал в этой деятельности, а мешал бы ей - его бы тут же выкинули на помойку. Но он вполне себе справлялся (как раз везде, кроме моего участка - потому что мне нужно было сетевые устройства, и с этим все было плохо совсем).
И так каждый релиз - преодолевание созданных собой же трудностей. Придумали идиотские абстракции сначала, потом немножко убрали ограничений, теперь вот отказались от некоторых из них.Умные люди давно уже снесли этот ПТУшный курсач и поставили что-то типа Прометея
Прометей хорош, когда у тебя полтора элемента на хост (докер жив или нет) и надо смотреть на сервис в целом. Как только самих хостов у тебя становится тысячи и монолитных сервисов они не образуют (ISP, например, со SLA клиентами) - ты начнёшь теряться в метриках ради метрик, в этих местах всерьёз нужны шаблоны, автообнаружение, возможность интегрироваться.
Так заббикс как раз в шаблонах, автообнаружении и возможности интегрироваться очень плох.
Шаблоны либо примитивные (на каждый тип сервера свой ультрашаблон, никакого наследования, что тоже своего рода адъ, но не организационный а требующий контроля и ручных действий), либо превращаются в адъ (описывал выше пример с рефакторингом).
Автообнаружение либо через навешивание шаблонов через метаданные что адъ, либо через добавление через апи (что тоже адъ, ведь нормальных модулей для интеграции я не встречал).
Все кастомное интегрирование в заббиксе сделано либо через заббикс трапперы (большая нагрузка, сложный траблшутинг), либо через витиеватый апи генерирующий тонны запросов (и еще больше неоптимальных запросов в базу) и частенько требующий постоянно его передергивать (коллбеков то нет)
Нет у manager-oriented систем модулей для интеграции с тем, с чем мы работаем.
У этих устройств либо голый SNMP, у каждого класса устройств свой, либо специфичная консоль, либо свой специфичный API, либо вообще вебня.
Короче в основной массе далеко не докеры и собственный код, куда можно что угодно закрутить.
Кастомное интегрирование конкретно у нас работает через API, external checks, sender, agent/agent2, web requests, action+HTTP.
Интересно, планируется ли отказ от возможностей zabbix_agent первой версии.
Не планируется пока, сам Владышев это говорил
Смысл?
В принципе перевезли половину наблюдаемых VM на игогошный agent2, но памяти он таки жрёт в 3 раза больше... На большом количестве малых виртуалок немножко заметно.
А в чем вообще смысл этого действия? Медленно готовитесь к самому худшему, да?
По агенту то?
Готовимся к тому, что agent1 канет в небытие, да :(
Ретрограды!
Лучший мониторинг для здоровенных сетей и сервисов, где менеджер-ориентированные сервисы встают сначала колом, потом раком, и превращаются в unmanageable. И никаких альтернатив ему нет, там, где Zabbix вывезет без проблем в рамках 1-2-3 серверов, коммерческие монстрики потребуют целой стойки.
Да он для сетей вообще не предназначен. Построить зависимость хост от хоста не возможно на нем. Это гребанная поделка.
В таких сетях, о которых я, зависимость хоста от хоста имеет немножко другой уровень. En masse.
Там не СЕРВИС, а целая фигова туча сервисов, которую ты задолбаешься в других системах описывать.
И есть уровни этого сервиса - пользователи там, пользователи сям, бэкбон там-сям, кора там-сям.
Хелпдеску надо несколько тысяч SLA хостов видеть.
Зависимости все строятся прекрасно снаружи, если правильно расставлять теги.
Триггеры выгребаются через API.
Кастомные проверки и интеграции подвязываются.
Шаблоны на каждый тип хоста, которых сотни. Которые могут прийти из CRM, а могут просто прийти, потому что вон тот партнёр, с которым вообще нет интеграции, подключил очередного пользователя.
etc.
> Зависимости все строятся прекрасно снаружи, если правильно расставлять теги.Это не ты тот тип которому было мало 9999 зависимостей у триггера?
Я так понял у вас мониторинг настраивается через апи, данные выгребаются тоже через апи, а заббикс выступает только ui интерфейсом для Хелпдеска и складированием метрик. Учитывая что в двух последних функциях он проигрывает графане и прометеусу, то не понятно зачем вам вообще заббикс.
> Это не ты тот тип которому было мало 9999 зависимостей у триггера?Угу, он самый :D
У нас голосовой софтсвитч с кучей клиентских транков. Выгрести нагрузку по транкам можно только полностью по всем, из специфичной консольной утилиты свитча, а дальше её надо препроцессить и делить на инфу по транкам. Транков давно больше 10000. Раньше делил скриптом, и запихивал через sender, когда появились dependent items - правильнее делить препроцессингом, соответственно пошли в эту сторону.
> Я так понял у вас мониторинг настраивается через апи, данные выгребаются тоже
> через апи, а заббикс выступает только ui интерфейсом для Хелпдеска и
> складированием метрик. Учитывая что в двух последних функциях он проигрывает графане
> и прометеусу, то не понятно зачем вам вообще заббикс.Manager-oriented мониторинги не осилят 400000 метрик без отдельной стойки, это мы уже поняли, когда.
Графану с инфлюксом когда попробовали - инфлюкс просто лёг на агрегации. Ладно, фиг с ним, прекратили поток - мб потом оптимизируем. Попробовали отрисовать скрин для хелпдеска с парой сотен графиков. Тут уже легла графана, потому что кеширования у неё никакого, попутно проложив инфлюкс.Нам по сути не интересны сами метрики для наблюдения, кроме нагрузочных. Нам больше интересны сложные триггеры от этих метрик, которые техподдержка способна оценить в реальном времени. Бывает что падает целый район города из-за пропадания питания в таковом. Бывает что падают BGP-сессии. Очень много чего бывает, монолитного определения целостности сервиса нет.
Как пример триггера для HD: есть клиент, у которого наземная линия и бэкап через 4G.
IP у наземки и мобилки одинаковый, простым пингом не отделаешься.
Есть две RADIUS-сессии на двух разных железках.
Надо выгрести состояние этих двух RADIUS-сессий и сопоставить с пингом для клиента.
В итоге выдать хелпдеску не только жив ли клиент, но и не сидит ли он на бэкапе.
Или клиент мёртв, а сессии живы, тоже не нормально.
Сложности особой нет, но вот таких вот вывертов очень много требуется.
По RADIUS сессиям своя отдельная тема, выгребать их надо оптом, а не per check, потому что чеков много :D
> Нам больше интересны сложные триггеры от этих метрик, которые техподдержка способна оценить в реальном времени. Бывает что падает целый район города из-за пропадания питания в таковом. Бывает что падают BGP-сессии. Очень много чего бывает, монолитного определения целостности сервиса нет.И как выкручиваетесь? Крутится скрипт и разруливает зависимости между всеми триггерами?
> И как выкручиваетесь? Крутится скрипт и разруливает зависимости между всеми триггерами?Группировка по тегам, тикетирование, визуальный мониторинг. Зависимости да, на основании тегов разруливаются в отображении, если есть тег с объемлющей причиной, дочки автоматически помечаются как отсмотренные.
Web морда кстати не для хелпдеска в основном, а для доступа к конфигурации.
Очень много (почти всё, связанное с клиентами) сделано через API, но инфраструктурные хосты в CRM добавляются в т.ч. вручную, шаблоны шаблонятся. Морда для хелпдеска и не только хелпдеска у нас своя специфичная: https://pasteboard.co/JxH9rNc.png
Интересно! В 5.2 можно получить очень похожий интерфейс: сохраняем фильтры для быстрого переключения и с помощью ролей оставляем доступ лишь к странице Monitoring->Problems.
Сколько у вас хостов и nvps?
> Сколько у вас хостов и nvps?Number of hosts 15715
Number of templates 126
Number of items 638258
Number of triggers 439417
Number of users 36
Required server performance, new values per second 1914.19
> Required server performance, new values per second 1914.19и кто это у вас обеспечивает, можно подробностей? А то я все жду, когда мой mysql лопнет.
Немножко можно. Если что конкретно интересно - спрашивайте.--- xl info (XenServer)
release : 4.19.0+1
machine : x86_64
nr_cpus : 12
threads_per_core : 1
cpu_mhz : 2095.137
total_memory : 47810
free_memory : 10811
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_commandline : watchdog ucode=scan crashkernel=256M,below=4G console=vga vga=mode-0x0311 dom0_max_vcpus=1-4 dom0_mem=3072M,max:3072M xpti=0 spec-ctrl=no pv-l1tf=0 smt=0 mds=0 md-clear=0--- Zabbix+MariaDB VM cpuinfo
Старичок из старой партии. В перспективе AMD EPYC Zen2/Zen3.
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz
stepping : 4
cpu MHz : 2095.070
cache size : 16896 KB
siblings : 12
cpu cores : 12--- Zabbix+MariaDB VM memory
MemTotal: 32843324 kB
MemFree: 921164 kB
MemAvailable: 13662648 kB
Buffers: 236856 kB
Cached: 13794504 kB
SwapCached: 53508 kB
Active: 24584872 kB
Inactive: 5396760 kB--- Zabbix VM s/w versions
Linux ... 5.4.17-2011.6.2.el8uek.x86_64 #2 SMP Thu Sep 3 13:38:27 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux
mysql Ver 15.1 Distrib 10.5.5-MariaDB, for Linux (x86_64) using readline 5.1
Таблички history%/trends% пока лежат в TokuDB, но поскольку TokuDB всё (и это блин полный Ц и беда), смотрим в стороны, пока ничего особо не глянулось, начали собирать TokuDB для 10.5 сами. MariaDB 10.4 в котором TokuDB ещё есть из коробки - работает не хуже.
zabbix_server (Zabbix) 5.0.4
Revision 69c0ad3686 28 September 2020, compilation time: Sep 28 2020 15:30:12--- Хранилка - локальные SSD, RAID 6 на 4 устройства. Samsung MZ7KM960HMJP0D3 (PM863)
Пробовали на iSCSI SAN (Dell/Compellent SCv, SSD-only), latency приличная, но хуже не становится. Оставили локальное потому что мониторинг не должен зависеть от состояния сетевого SAN.
<VD>
Virtual Drive: 1 (Target Id: 1)
RAID Level : Primary-6, Secondary-0, RAID Level Qualifier-3
Size : 1.745 TB
Sector Size : 512
Parity Size : 1.745 TB
Strip Size : 1.0 MB
Number Of Drives : 4
Span Depth : 1
Current Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU<SSD>
Raw Size: 894.252 GB [0x6fc81ab0 Sectors]
Sector Size: 512
Firmware state: Online, Spun Up
Device Firmware Level: GD57
Inquiry Data: S3BVNX0JA16095MZ7KM960HMJP0D3 GD57
Ясно, спасибо, нам есть еще куда расти экстенсивно.
Это же не очень много, у нас 3к nvps, иногда упираемся в постгрю, потюним базу - работаем дальше, но думаем уйти от заббикса.
мне с одной стороны столько не надо, а с другой - бюджет ограничен, nvme диски под базу мне не дадут. Поэтому важно представлять, сколько мы еще можем переварить до того как все развалится под собственным весом. Я пару раз наблюдал, было не очень смешно.
Ну у нас допустим nvps вообще роли не играет, конкретный сервер спокойно вытянет еще раз 5 по столько же.
У нас основная нагрузка на БД, как ни странно - обработка сложных триггеров, которым нужна хистори за прошлые сутки, например. Эти прорежаем. Где тротлингом, где интервалом.
Это один сервер.
У него на периметре три небольших прокси, одна из-за изоляции сети, две - для балансировки нагрузки от пинг и snmp-чекеров на ядро, их по 64 процесса на каждой проксе.
Впрочем, количество хостов писать - дело неблагодарное, уже сегодня их станет ещё на десятку больше.
Вот гранулярной настройки прав ждали очень давно. Теперь я наконец-то смогу подрезать права тем, кто имеет право на редактирование, сделаю их владельцами исключительно своих участков.
Ну ничетак система. Пару лет работаю с ней. 40 хвостов. Полет нормальный.
Работаю с ней около 5 лет, когда заводили других адекватных систем не было, но те проблемы какие были 4 года назад так и остались. Система адъ, если бы не время по переводу (1,5к хостов, 500к айтемов, 200к триггеров, а ведь еще и работать же надо) на другую систему давно бы выкинул.
> Работаю с ней около 5 лет, когда заводили других адекватных систем не было, но те проблемы какие
> были 4 года назад так и остались. Система адъпросто ты мало работаешь. С 2009го появились такие проблемы, о которых мы тогда и помыслить не могли. (Ну, надо признать, конечно, что в 2016м с появлением почти нормальной lld и похорон айтимов-которые-не-совсем-айтимы трех разных сортов, ЧАСТЬ старых проблем ушла, и многие квадратноколесатые велосипеды без седла перестали быть нужны. К сожалению, это так и осталось единственным светлым пятном в истории.)
А тормознутые value cache и config cache, сделанные на глобальных блокировках, которые давят параллелизм, так и не переделывают...
Много было экспериментов на заре выбора мониторинга структуры сети, от самописных скриптов, до различных "монстров". С десяток лет назад, а то и больше, остановились на zabbix и до сих пор живет и радует. А главное, радует что сам проект не умер, а развивается. А того что индивидуально нет, можно и самому дописать, ни одно приложение не удовлетворит на все 100% Ваших потребностей - факт!
Ненужно.Кстати, промитиус для классического мониторинга хостов не подходит.
А что подходит?
да лучше б старый интерфейс вернули, новым гумном пользоваться невозможно
> да лучше б старый интерфейс вернули, новым гумном пользоваться невозможноВ новом интерфейсе мне существенно не нравится невозможность быстро выбрать группу хостов для отсмотра / конфигурации.
Надо либо впечатывать кусок названия, либо тыкать на Select и дёргать чекбоксы.
Очень неудобно, когда хостов тысячи, и они строго разбиты по группам. Раньше можно было просто на селектбокс кликнуть и перейти в другую группу.
Вообще я бы наверное предложил помимо "Select..." добавить ещё "стрелочку вниз" для быстрого выбора одного варианта, который надо заполнить в поле выбора, и сразу обновить форму. Это удовлетворило бы оба лагеря :)