Я бы сказал, что файлы на диске используются в библиотеке как способ передать информацию между процессами операционной системы.
Касательно расхода места на диске - исторические данные в файлах не хранятся, только последние показания счетчиков.
Могут образовываться файлы от уже завершившихся процессов - библиотека их не чистит. У нас приложение развернуто в docker, и достаточно часто контейнер обновляется, поэтому от этих файлов не испытываем проблем. Для приложений, развернутых без контейнера, я бы использовал что-то наподобие logrotate или cron для чистки старых файлов.
Да, мы рассматривали возможность использования push-модель для сбора метрик. В некоторых случаях это может оказаться отличным, и даже единственным возможным решением - о таком кейсе рассказывал мой коллега в своем докладе: https://www.youtube.com/live/ZKUV1WzScDw?feature=shared&t=3216
Мы же решили придерживаться pull модели, т.к. именно в этой парадигме уже был настроен мониторинг в нашем продукте. Для этого и разработали представленное в статье решение, которое позволило без глобального пересмотра подхода к сбору метрик и запуска новых сервисов собирать показания. Все необходимые доработки выполнялись исключительно в исходном коде наших приложений.
Спасибо за комментарий!
Я бы сказал, что файлы на диске используются в библиотеке как способ передать информацию между процессами операционной системы.
Касательно расхода места на диске - исторические данные в файлах не хранятся, только последние показания счетчиков.
Могут образовываться файлы от уже завершившихся процессов - библиотека их не чистит. У нас приложение развернуто в docker, и достаточно часто контейнер обновляется, поэтому от этих файлов не испытываем проблем. Для приложений, развернутых без контейнера, я бы использовал что-то наподобие logrotate или cron для чистки старых файлов.
Спасибо за комментарий!
Да, мы рассматривали возможность использования push-модель для сбора метрик. В некоторых случаях это может оказаться отличным, и даже единственным возможным решением - о таком кейсе рассказывал мой коллега в своем докладе: https://www.youtube.com/live/ZKUV1WzScDw?feature=shared&t=3216
Мы же решили придерживаться pull модели, т.к. именно в этой парадигме уже был настроен мониторинг в нашем продукте. Для этого и разработали представленное в статье решение, которое позволило без глобального пересмотра подхода к сбору метрик и запуска новых сервисов собирать показания. Все необходимые доработки выполнялись исключительно в исходном коде наших приложений.