Как стать автором
Обновить
10
0
Михаил Макуров @makurov

Пользователь

Отправить сообщение

Следующая проблема, которую вам нужно будет решить - наполнение ValueCache.

ClickHouse очень латентен при выполнении запросов.

И будет проблема - старт будет еще хуже, чем у ванильного заббикса.

В разы хуже. Если айтемов хотя бы 1-2млн, то стагнация на час или больше.

Как только пойдут первые данные, начнут считаться триггеры, триггерам нужны еще данные, а их в кеше нет, и в итоге все процессы history_syncer будут ожидать медленных ответов клика, так как он их будет наполнять по одному айтему.

Поточностью тоже не решить - очень быстро, примерно на 40-70 спрашивающих потоках на ноду Клика, суммарная скорость ответов только деградирует

Дальше есть три варианта действий:

  1. Заранее наполнить весь ValueCache сделав на старте один массовый запрос. Недостаток - неизвестно заранее, сколько метрик с какой глубиной нужно в кеше, и вообще, нужна ли метрика в кеше. В заббиксе в ValueCache хранятся только те метрики, которые в триггерах и в calculated значениях использовались.

  2. Иногда сохранять ValueCache, чтобы обеспечить холодный запуск. Идея рабочая, нам здорово помогает

  3. Сделать watchdog в момент записи истории: в случае, если сервер тратит слишком много времени на ожидание чтения - не читать такие данные, возвращать ошибку. Это самый простой и действенный способ - требуется буквально 4ре строчки в реализации истории, получаете мнгновенный страт. С таким решением сервер в первые 20 минут работы при такой реализации пропускает через себя примерно на 2 порядка (в 100-200раз!) больше данных и считает триггеров, чем если бы он не пропускал операции чтения из кеша.

В документации прямо в настройке коннектора клика есть настройка буфферизации:

https://docs.glaber.io/ru/setup/history/clickhouse/#_2

HistoryModule=clickhouse;{"url": "http://127.0.0.1:8123?user=default&password=XXXX", "batch":100000, "flush":"30", "disable_reads":100, "timeout":5, "write_types":"dbl, str, uint, text", "max_calls":10000000 }

Опции batch и flush управляют размером буффера.

По опыту, даже при 400-500к Nvps существеноой нагрузки на клик не будет

Ну черт знает. По честному, там же все равно какой то личный профит в конце, даже если он в том, чтобы «сделать мир лучше».
Очень в тему, спасибо.

Да, я бы сказал так — тогда был выбран такой путь, сейчас решение расширения функциональности на Go мне кажется самым верным и так оно и делается для нового функционала. Но я этот путь чуть позже асинхронного SNMP осознал, поэтому там осталось на С.

На самом деле на Go я одновременно с реализацией 4 прорабатывал. Но там копились разные мелочи — то мибы не транслируются, то поддержки v3 нет, то что то еще. В общем, учитывая опыт в С и отсутсвие такового в Go, решил в какой то момент оставить реализацию на С.

А так то было бы очень интересно сравнить ресурсы на Go и на С (память и CPU) на одинаковой задаче. Учитывая скорость разработки и количество библиотек, выбор очевиден.

А сейчас расширение функционала (адаптеры к разным системам хранения, сервера, воркеры) именно так и делаются — все на Go
У меня нет цифр под рукой, но когда то посчитал, что «дорого» получится. И потоками и форками тем более. Там два очевидных ресурса — память, и ресурсы процессора на переключение контекста.
Читал что это «не по правилам», вот и не стал писать
А вообще https://gitlab.com/mikler/glaber

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность