Comments 10
Это разве тянет на статью?
Звучит как «мы взяли все что можно сделали конфетку»
Где конкретный кейс?
Я ожидал как минимум увидеть elk, Prometheus на дашбордах Grafana.
Было бы интересно про использование clickhouse в работе с Prometheus.
Ну хотя бы озвучили используемый стек, и группы метрик. А не как обычно, мы купили Splunk, и теперь у нас все плохохорошо.
Кейс — выстраивание мониторинга с нуля. Я не решал задачу наставить модного софта и нарисовать кучу красивых графиков. У меня была конкретная проблема — прошлая система мониторинга не помогала в разборе инцидентов и не уведомляла о сбоях.
ELK, Prometheus и ClickHouse — всего лишь инструменты, и я написал почему остановил на них свой выбор и для чего использую.
ELK, Prometheus и ClickHouse — всего лишь инструменты, и я написал почему остановил на них свой выбор и для чего использую.
Ожидал прочитать как вы упростили стек «Prometheus, Clickhouse и ELK» до «Clickhouse», используя PromHouse и ElasticHouse, но мои ожидания — только мои ожидания :)
В моем случае хранение исторических данных в ClickHouse стало усложнением, а не упрощением. IMHO проще хранить предагрегированные исторические данные во втором инстансе Prometheus, в его встроенном хранилище, благо таких метрик очень мало. Или я что то неправильно понимаю?
В моем случае хранение исторических данных в ClickHouse стало усложнением, а не упрощением.Не первый раз слышу фразу «ClickHouse — это оверинжинеринг для моих задач».
Раньше я так же думал, хотя почти каждый день на протяжении трёх лет мой коллега рассказывал насколько он хорош :) Недавно я попробовал его для своей новой задачи, потому что если складывать в другую tsdb, то она будет занимать очень много места в памяти. Из-за характера данных количество тегов было бы бесконечным и они все хранились бы в памяти.
Благодаря несложной установке у меня получилось быстро начать с ним работу, а благодаря его интеграции в кучу продуктов (например, в IDEA или даже в adminer.php) работать с ним стало гораздо приятнее и комфортнее чем с тем же influx. Так же мне очень нравится его структура бд похожая на обычную rdbms.
Благодаря простым и удобным графическим интерфейсам у меня пропало «туннельное зрение». В инфлюксдб я раньше вообще не залезал, ограничиваясь графаной или редкими запросами из консоли, поэтому не замечал насколько он захламлялся всякими совершенно не нужными мне метриками.
Сейчас я не задаюсь вопросами: не много ли я пишу каких-то метрик, сколько это потом съест оперативной памяти, что место на ssd как-то не очень мног и не плохо бы это всё перенести на hdd, а надо ли мне будет потом сгруппировать по этому значению или может лучше его запихнуть в тег. Я пишу всё что хочу, очень удобно потом разруливаю с помощью materialized view и специализированных движков. И главное я всегда знаю, что на диске он будет хранить эти данные компактнее чем любое другое решение и мне в ближайшей перспективе даже думать не надо о миграции на другие продукты.
Насчет задач, в которых количество тегов получается огромным: я с вами полностью согласен. Натолкнулся на тоже ограничение, использовав изначально 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 действительно клевая база и я тоже планирую ее использовать и в дальнейшем.
Отлично получается хранить в нем метрики из 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 действительно клевая база и я тоже планирую ее использовать и в дальнейшем.
Мониторить метрики приложения/бизнеса/базы можно через github.com/chop-dbhi/prometheus-sql
«5 минут не уходили смс», «скопилось много необработанных заказов», «слишком много подключений к базе» и тп
«5 минут не уходили смс», «скопилось много необработанных заказов», «слишком много подключений к базе» и тп
Я использовал github.com/wrouesnel/postgres_exporter, тоже позволяет делать кастомные запросы в базу
А чем Icinga-то не подошла?
Sign up to leave a comment.
Как мы строили мониторинг на Prometheus, Clickhouse и ELK