> Очень просто. Есть 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), опять дописываем "изкоробочное решение"
