Comments 7
Рассматривали ли вы вариант с opentelemety collector-ом, в который пушатся метрики из воркеров, и из которого prometheus выгребает сразу всё одим запросом?
Спасибо за комментарий!
Да, мы рассматривали возможность использования push-модель для сбора метрик. В некоторых случаях это может оказаться отличным, и даже единственным возможным решением - о таком кейсе рассказывал мой коллега в своем докладе: https://www.youtube.com/live/ZKUV1WzScDw?feature=shared&t=3216
Мы же решили придерживаться pull модели, т.к. именно в этой парадигме уже был настроен мониторинг в нашем продукте. Для этого и разработали представленное в статье решение, которое позволило без глобального пересмотра подхода к сбору метрик и запуска новых сервисов собирать показания. Все необходимые доработки выполнялись исключительно в исходном коде наших приложений.
Документация prometheus_client рекомендует использовать tmpfs
Спасибо за комментарий!
Я бы сказал, что файлы на диске используются в библиотеке как способ передать информацию между процессами операционной системы.
Касательно расхода места на диске - исторические данные в файлах не хранятся, только последние показания счетчиков.
Могут образовываться файлы от уже завершившихся процессов - библиотека их не чистит. У нас приложение развернуто в docker, и достаточно часто контейнер обновляется, поэтому от этих файлов не испытываем проблем. Для приложений, развернутых без контейнера, я бы использовал что-то наподобие logrotate или cron для чистки старых файлов.
Но если у вас все равно приложения в докере, не проще ли масштабироваться увеличивая количество контейнеров, в которых по одному процессу? Тогда ведь и делать бы ничего не пришлось.
В подобной статье я уже задавал этот вопрос. tl;dr зависит от нагрузки.
Мониторинг на Python: как сохранить метрики в мультипроцессном режиме