О господи, .... у него еще и докера нет

Да такие задачи постоянно, просто из решение сильно от инфраструктуры зависит, сам думаю понимаешь

ну скорее для себя. и есть идея податься потом в разработку из админов. или нет, если не получится с учением. тогда в монастырь уйтт. ;)

кто знает, можно ли для модуля logging навесить дополнительное поведение на определённый level?
например, для error добавить отправку данных в sentry

@alex_aa
https://docs.python.org/3/library/logging.handlers.html
Напишите свой handler.

спасибо

я бы начал с монастыря

чистить надо как можно чаще, но так, чтобы это не было в пустую.
чем чаще ты чистишь, тем лучше, потому что ты делаешь это маленькими кусочками. в итоге, риски всяких переполнений минимальные, ресурсы потребляются ровно и предсказуемо. объем данных в системе не прыгает, а всегда относительно постоянный.
но слишком часто чистить тоже нельзя, потому что просто будет нечего чистить и ресурсы будут тратиться в пустую.
я обычно начинаю с чистки раз в час для данных, которые устаревают за дни и раз в несколько минут для данных, которые устаревают за часы. ну, т.е. чтобы не было "слишком старых" данных в системе, чтобы ещё не удаленные, но уже устаревшие данные занимали логорифмически малую часть от полезных данных и не было сильных скачков общего объема данных.
т.е. если у вас данные устаревают за два дня или даже за неделю, то чистить такие данные раз в день — весьма неудачная идея

1. поменьше грубости и неуважения к коллегам, пожалуйста!

2. запускать разные задачи с разной частотой — это вполне нормально:) потому что это разные задачи и у них разные условия работы, внезапно;)
более того, весьма полезно еще и разносить задачи "по фазе", т.е. чтобы не запускались все задачи ровно в 0 минут, одна раз в час, другая раз в два часа. это опять про неровное потребление ресурсов.

да не парься. делай лок-файл. это вполне норм решение.
я бы сделал шеловский или питоновский (лучше) скрипт, который бы принимал в аргументы что надо запустить и позволял бы запускаться этому, только если нет лок файла.
тогда любой скрипт в кроне можно записать вместо my-script.sh args, как my-bouncer.py my-script.sh args и не думать
к тому же, если потом понадобится делать это на распределенной системе, можно будет просто заменить реализацию my-bouncer.py redis и больше ничего не менять

да, кто сталкивался, скорее всего, использовал лок через файл, типа меня:)

Нет, так делать не хочется, т.к. нужно сделать максимально просто. Я выснял у девопса, билд выкатывается шефом, поэтому с лок файлом идея подходит. Шеф будет автоматом создавать этот файл перед началом работы и удалять по итогу. Человеческий фактор практически исключается

а как не хочется? я не понял:)

Заворачивать всё в отдельный шелл скрипт

Пусть крон запускает отдельные скрипты сам

дык а как ты будешь проверять в задаче, что лок установлен?

да, и эти срипты заворачивать в bouncer в конфиге крона

Будет проверка на наличие лока в системе

и где будет эта проверка? внутри скриптов?