1. У gunicorn-а побольше настроек запуска и побольше возможностей. Например, конфигурация через python файл как в этой статье. Все зависит от потребностей.
2. Не смотрел. Нужно понимать, что воркер гипотетически может упасть, и нужны гарантии того, что ресурс в виде worker_id будет освобожден. Lock-файл с этим отлично справляется. При любом варианте завершения процесса lock будет релизиться. Как добиться таких же гарантий UltraDict-ом мне лично сложно сказать.
3. Это достаточно спорная тема. Если разговаривать в контексте того, что приложение запущено в kubernetes, то нужно помнить про выделенные квоты на cpu. Условно говоря, если поду будет выделено 0.5 cpu, это приведет к троттлингу. Троттлинг приводит к повышению времени обработки запроса. Увеличиваешь cpu, чтобы уменьшить задержки, можешь столкнуться с меньшей утилизаций, чем хотелось бы. И именно в этот момент может появиться желание запускать несколько процессов на одном ядре. Также если следовать рекомендации после некоторого количества запросов перезапускать воркер, то в случае если в поде будет один такой хромой воркер, во время перезапуска воркера этот под будет отдавать 503. В общем, я перечислил лишь часть причин, по которым вам могут понадобиться несколько процессов в поде. А какое решение выберете вы, зависит от ваших потребностей, нагрузки, возможностей и тд. Строго индивидуально. Ну и наконец для запуска небольшого приложения может вообще не понадобиться вся эта история с подами и kubernetes-ами. Кому-то нужно просто запустить приложение на виртуалке с 16-ью ядрами. И тут уж точно без мультипроцессинга не обойтись, иначе зачем столько ядер нужно.
Концептуально проблемы те же самые остаются. Только теперь не количество файлов будет расти, а количество ключей в редисе. Также появилась дополнительная точка отказа и необходимость в разработке и поддержке этого решения.
Не могу однозначно ответить. Всех возможностей прометеуса не знаю, к сожалению. Могу только предположить, что прометеус агрегацией не занимается. На мой взгляд его задача хранить серии векторов с соответствующими lable-ами и обрабатывать пользовательские запросы.
В моем представлении если идти по пути экспортирования метрик на разных портах, необходимо, чтобы во всех отдаваемых метриках были соответствующие label-ы, по типу port="8001". И уже в той же графане учитывать факт их наличия и строить соответсвующие запросы к прометеусу.
Зависит от того, что понимать под стандартом. Конечно, существуют библиотеки, которые работают асинхронно с файлами. Из популярного на моей памяти aiofiles https://github.com/Tinche/aiofiles. Однако качественную оценку дать не могу, так как не доводилось применять в проектах.
Если смотреть в разрезе хранения метрик в файлах, я в любом случае следовал бы рекомендации смонтировать директорию как tmpfs. Это позволит убрать диск из цепочки обработки запроса. Это будет полезно как для синхронных, так и для асинхронных приложений.
Однако самому интересно посмотреть на цифрах эту пользу для асинхронного приложения. И есть ли она вообще. Хочется понять, стоит ли вмешиваться в работу prometheus_client, или приложению будет достаточно, чтобы файлы хранились в tmpfs.
1. У gunicorn-а побольше настроек запуска и побольше возможностей. Например, конфигурация через python файл как в этой статье. Все зависит от потребностей.
2. Не смотрел. Нужно понимать, что воркер гипотетически может упасть, и нужны гарантии того, что ресурс в виде worker_id будет освобожден. Lock-файл с этим отлично справляется. При любом варианте завершения процесса lock будет релизиться. Как добиться таких же гарантий UltraDict-ом мне лично сложно сказать.
3. Это достаточно спорная тема. Если разговаривать в контексте того, что приложение запущено в kubernetes, то нужно помнить про выделенные квоты на cpu. Условно говоря, если поду будет выделено 0.5 cpu, это приведет к троттлингу. Троттлинг приводит к повышению времени обработки запроса. Увеличиваешь cpu, чтобы уменьшить задержки, можешь столкнуться с меньшей утилизаций, чем хотелось бы. И именно в этот момент может появиться желание запускать несколько процессов на одном ядре. Также если следовать рекомендации после некоторого количества запросов перезапускать воркер, то в случае если в поде будет один такой хромой воркер, во время перезапуска воркера этот под будет отдавать 503. В общем, я перечислил лишь часть причин, по которым вам могут понадобиться несколько процессов в поде. А какое решение выберете вы, зависит от ваших потребностей, нагрузки, возможностей и тд. Строго индивидуально. Ну и наконец для запуска небольшого приложения может вообще не понадобиться вся эта история с подами и kubernetes-ами. Кому-то нужно просто запустить приложение на виртуалке с 16-ью ядрами. И тут уж точно без мультипроцессинга не обойтись, иначе зачем столько ядер нужно.
Концептуально проблемы те же самые остаются. Только теперь не количество файлов будет расти, а количество ключей в редисе. Также появилась дополнительная точка отказа и необходимость в разработке и поддержке этого решения.
Не могу однозначно ответить. Всех возможностей прометеуса не знаю, к сожалению. Могу только предположить, что прометеус агрегацией не занимается. На мой взгляд его задача хранить серии векторов с соответствующими lable-ами и обрабатывать пользовательские запросы.
В моем представлении если идти по пути экспортирования метрик на разных портах, необходимо, чтобы во всех отдаваемых метриках были соответствующие label-ы, по типу port="8001". И уже в той же графане учитывать факт их наличия и строить соответсвующие запросы к прометеусу.
Зависит от того, что понимать под стандартом. Конечно, существуют библиотеки, которые работают асинхронно с файлами. Из популярного на моей памяти aiofiles https://github.com/Tinche/aiofiles. Однако качественную оценку дать не могу, так как не доводилось применять в проектах.
Если смотреть в разрезе хранения метрик в файлах, я в любом случае следовал бы рекомендации смонтировать директорию как tmpfs. Это позволит убрать диск из цепочки обработки запроса. Это будет полезно как для синхронных, так и для асинхронных приложений.
Однако самому интересно посмотреть на цифрах эту пользу для асинхронного приложения. И есть ли она вообще. Хочется понять, стоит ли вмешиваться в работу prometheus_client, или приложению будет достаточно, чтобы файлы хранились в tmpfs.
Думаю, на эту тему будет вторая статья.
Все верно. О существовании этой проблемы коротко упомянуто в разделе "Влияние файлов метрик на общую производительность".
К слову, библиотека prometheus-async никак не решает эту проблему.