Насчет задач, в которых количество тегов получается огромным: я с вами полностью согласен. Натолкнулся на тоже ограничение, использовав изначально influx. Собственно, из за этого и перешел на ClickHouse. Тоже очень нравится, что он потребляет мало памяти и хорошо сжимает данные на диске.
Отлично получается хранить в нем метрики из pg_stat_statements и pg_stat_activity и логи nginx (они стали основным мотивом использования CH, исторические данные мониторинга — лишь довесок). Elasticsearch стал бы для этого очень дорогим, да и Prometheus не лучше (даже если брать хотя бы 5 самых ценных метрик, все равно для меня бы это вылилось в дополнительные 75к таймсериес с двумя репликами postgres, и это только изначально, со временем количество лейблов бы только росло).
Возможно стоит использовать CH как основное хранилище Prometheus, но возникнет другая проблема — экспортеры в большинстве своем используют гошную клиентскую библиотеку прометея. А она хранит все лейблы в памяти. В итоге приходим к тому, что экспортеры начинают пожирать память в нереальных количествах. Вот вам простой пример: метрики о активности процессов я снимаю с помощью github.com/ncabatoff/process-exporter. Поскольку у нас все написано на php, при сборе метрик с кронов и подписчиков одного cmdline уже недостаточно (/proc/$pid/cmdline), там будет только что то типа /usr/bin/php. Надо снимать и параметры, которые в этот php переданы: путь до скрипта, параметры, ему переданные. Так вот. Если сохранять это по всем процессам в системе (просто потому, что такой конфиг писать менее запарно) — количество лейблов растет бесконечно и этот экспортер ввиду особенности, указанной выше, начинает потреблять гигабайты памяти.
Да, можно накинуть лимит по памяти в systemd и рассчитывать на OOM с последующим рестартом. Но нет, процессу просто не выделяется память при поступлении запроса от прометея, горутину с хендлером создать не получается, сам же процесс не прибивается. Да, это достаточно паршивый пример, но аналогичная ситуация будет возникать со всеми экспортерами, количество метрик в которых растет (например github.com/percona/mongodb_exporter ведет себя аналогично, если бизнес логика вашего приложения активно использует временные коллекции).
В любом случае, спасибо за ваш комментарий. CH действительно клевая база и я тоже планирую ее использовать и в дальнейшем.
В моем случае хранение исторических данных в ClickHouse стало усложнением, а не упрощением. IMHO проще хранить предагрегированные исторические данные во втором инстансе Prometheus, в его встроенном хранилище, благо таких метрик очень мало. Или я что то неправильно понимаю?
Кейс — выстраивание мониторинга с нуля. Я не решал задачу наставить модного софта и нарисовать кучу красивых графиков. У меня была конкретная проблема — прошлая система мониторинга не помогала в разборе инцидентов и не уведомляла о сбоях.
ELK, Prometheus и ClickHouse — всего лишь инструменты, и я написал почему остановил на них свой выбор и для чего использую.
Отлично получается хранить в нем метрики из pg_stat_statements и pg_stat_activity и логи nginx (они стали основным мотивом использования CH, исторические данные мониторинга — лишь довесок). Elasticsearch стал бы для этого очень дорогим, да и Prometheus не лучше (даже если брать хотя бы 5 самых ценных метрик, все равно для меня бы это вылилось в дополнительные 75к таймсериес с двумя репликами postgres, и это только изначально, со временем количество лейблов бы только росло).
Возможно стоит использовать CH как основное хранилище Prometheus, но возникнет другая проблема — экспортеры в большинстве своем используют гошную клиентскую библиотеку прометея. А она хранит все лейблы в памяти. В итоге приходим к тому, что экспортеры начинают пожирать память в нереальных количествах. Вот вам простой пример: метрики о активности процессов я снимаю с помощью github.com/ncabatoff/process-exporter. Поскольку у нас все написано на php, при сборе метрик с кронов и подписчиков одного cmdline уже недостаточно (/proc/$pid/cmdline), там будет только что то типа /usr/bin/php. Надо снимать и параметры, которые в этот php переданы: путь до скрипта, параметры, ему переданные. Так вот. Если сохранять это по всем процессам в системе (просто потому, что такой конфиг писать менее запарно) — количество лейблов растет бесконечно и этот экспортер ввиду особенности, указанной выше, начинает потреблять гигабайты памяти.
Да, можно накинуть лимит по памяти в systemd и рассчитывать на OOM с последующим рестартом. Но нет, процессу просто не выделяется память при поступлении запроса от прометея, горутину с хендлером создать не получается, сам же процесс не прибивается. Да, это достаточно паршивый пример, но аналогичная ситуация будет возникать со всеми экспортерами, количество метрик в которых растет (например github.com/percona/mongodb_exporter ведет себя аналогично, если бизнес логика вашего приложения активно использует временные коллекции).
В любом случае, спасибо за ваш комментарий. CH действительно клевая база и я тоже планирую ее использовать и в дальнейшем.
ELK, Prometheus и ClickHouse — всего лишь инструменты, и я написал почему остановил на них свой выбор и для чего использую.