> Это не ты тот тип которому было мало 9999 зависимостей у триггера? Угу, он самый :D
У нас голосовой софтсвитч с кучей клиентских транков. Выгрести нагрузку по транкам можно только полностью по всем, из специфичной консольной утилиты свитча, а дальше её надо препроцессить и делить на инфу по транкам. Транков давно больше 10000. Раньше делил скриптом, и запихивал через sender, когда появились dependent items - правильнее делить препроцессингом, соответственно пошли в эту сторону.
> Я так понял у вас мониторинг настраивается через апи, данные выгребаются тоже
> через апи, а заббикс выступает только ui интерфейсом для Хелпдеска и
> складированием метрик. Учитывая что в двух последних функциях он проигрывает графане
> и прометеусу, то не понятно зачем вам вообще заббикс.
Manager-oriented мониторинги не осилят 400000 метрик без отдельной стойки, это мы уже поняли, когда.
Графану с инфлюксом когда попробовали - инфлюкс просто лёг на агрегации. Ладно, фиг с ним, прекратили поток - мб потом оптимизируем. Попробовали отрисовать скрин для хелпдеска с парой сотен графиков. Тут уже легла графана, потому что кеширования у неё никакого, попутно проложив инфлюкс.
Нам по сути не интересны сами метрики для наблюдения, кроме нагрузочных. Нам больше интересны сложные триггеры от этих метрик, которые техподдержка способна оценить в реальном времени. Бывает что падает целый район города из-за пропадания питания в таковом. Бывает что падают BGP-сессии. Очень много чего бывает, монолитного определения целостности сервиса нет.
