Следующая проблема, которую вам нужно будет решить - наполнение ValueCache.
ClickHouse очень латентен при выполнении запросов.
И будет проблема - старт будет еще хуже, чем у ванильного заббикса.
В разы хуже. Если айтемов хотя бы 1-2млн, то стагнация на час или больше.
Как только пойдут первые данные, начнут считаться триггеры, триггерам нужны еще данные, а их в кеше нет, и в итоге все процессы history_syncer будут ожидать медленных ответов клика, так как он их будет наполнять по одному айтему.
Поточностью тоже не решить - очень быстро, примерно на 40-70 спрашивающих потоках на ноду Клика, суммарная скорость ответов только деградирует
Дальше есть три варианта действий:
Заранее наполнить весь ValueCache сделав на старте один массовый запрос. Недостаток - неизвестно заранее, сколько метрик с какой глубиной нужно в кеше, и вообще, нужна ли метрика в кеше. В заббиксе в ValueCache хранятся только те метрики, которые в триггерах и в calculated значениях использовались.
Иногда сохранять ValueCache, чтобы обеспечить холодный запуск. Идея рабочая, нам здорово помогает
Сделать watchdog в момент записи истории: в случае, если сервер тратит слишком много времени на ожидание чтения - не читать такие данные, возвращать ошибку. Это самый простой и действенный способ - требуется буквально 4ре строчки в реализации истории, получаете мнгновенный страт. С таким решением сервер в первые 20 минут работы при такой реализации пропускает через себя примерно на 2 порядка (в 100-200раз!) больше данных и считает триггеров, чем если бы он не пропускал операции чтения из кеша.
Да, я бы сказал так — тогда был выбран такой путь, сейчас решение расширения функциональности на Go мне кажется самым верным и так оно и делается для нового функционала. Но я этот путь чуть позже асинхронного SNMP осознал, поэтому там осталось на С.
На самом деле на Go я одновременно с реализацией 4 прорабатывал. Но там копились разные мелочи — то мибы не транслируются, то поддержки v3 нет, то что то еще. В общем, учитывая опыт в С и отсутсвие такового в Go, решил в какой то момент оставить реализацию на С.
А так то было бы очень интересно сравнить ресурсы на Go и на С (память и CPU) на одинаковой задаче. Учитывая скорость разработки и количество библиотек, выбор очевиден.
А сейчас расширение функционала (адаптеры к разным системам хранения, сервера, воркеры) именно так и делаются — все на Go
У меня нет цифр под рукой, но когда то посчитал, что «дорого» получится. И потоками и форками тем более. Там два очевидных ресурса — память, и ресурсы процессора на переключение контекста.
Следующая проблема, которую вам нужно будет решить - наполнение ValueCache.
ClickHouse очень латентен при выполнении запросов.
И будет проблема - старт будет еще хуже, чем у ванильного заббикса.
В разы хуже. Если айтемов хотя бы 1-2млн, то стагнация на час или больше.
Как только пойдут первые данные, начнут считаться триггеры, триггерам нужны еще данные, а их в кеше нет, и в итоге все процессы history_syncer будут ожидать медленных ответов клика, так как он их будет наполнять по одному айтему.
Поточностью тоже не решить - очень быстро, примерно на 40-70 спрашивающих потоках на ноду Клика, суммарная скорость ответов только деградирует
Дальше есть три варианта действий:
Заранее наполнить весь ValueCache сделав на старте один массовый запрос. Недостаток - неизвестно заранее, сколько метрик с какой глубиной нужно в кеше, и вообще, нужна ли метрика в кеше. В заббиксе в ValueCache хранятся только те метрики, которые в триггерах и в calculated значениях использовались.
Иногда сохранять ValueCache, чтобы обеспечить холодный запуск. Идея рабочая, нам здорово помогает
Сделать watchdog в момент записи истории: в случае, если сервер тратит слишком много времени на ожидание чтения - не читать такие данные, возвращать ошибку. Это самый простой и действенный способ - требуется буквально 4ре строчки в реализации истории, получаете мнгновенный страт. С таким решением сервер в первые 20 минут работы при такой реализации пропускает через себя примерно на 2 порядка (в 100-200раз!) больше данных и считает триггеров, чем если бы он не пропускал операции чтения из кеша.
В документации прямо в настройке коннектора клика есть настройка буфферизации:
https://docs.glaber.io/ru/setup/history/clickhouse/#_2
Опции batch и flush управляют размером буффера.
По опыту, даже при 400-500к Nvps существеноой нагрузки на клик не будет
Да, я бы сказал так — тогда был выбран такой путь, сейчас решение расширения функциональности на Go мне кажется самым верным и так оно и делается для нового функционала. Но я этот путь чуть позже асинхронного SNMP осознал, поэтому там осталось на С.
На самом деле на Go я одновременно с реализацией 4 прорабатывал. Но там копились разные мелочи — то мибы не транслируются, то поддержки v3 нет, то что то еще. В общем, учитывая опыт в С и отсутсвие такового в Go, решил в какой то момент оставить реализацию на С.
А так то было бы очень интересно сравнить ресурсы на Go и на С (память и CPU) на одинаковой задаче. Учитывая скорость разработки и количество библиотек, выбор очевиден.
А сейчас расширение функционала (адаптеры к разным системам хранения, сервера, воркеры) именно так и делаются — все на Go
А вообще https://gitlab.com/mikler/glaber