Для прикладу в ./utils.py створити «враппер» для logger.log (як вказано в пункт 2) та у разі використання імпортувати та викликати utils.log(...).

Можливо процесу вибір того, що логується, а що ні — теж мав би бути описаний.

Цікаве питання. Насправді як і всюди існує дуже тонка межа, що варто логувати, а що ні(залежить від багатьох факторів як бюджет, період ротації, дотримання певних сертифікацій та тп).

На рахунок json.dumps люто плюсую. Можливо це потрібно прямо першим пунктом :)
Дякую за згадування цієї важливої особливості

PS Використовую завжди ujson

Так, декорування логування, наприклад, для запитів до сторонніх сервісів (14 пункт), є чудовою практикою.

PS Я починав писати статтю з «python logging, monitoring, alerting та налаштування і які продукти краще використовувати» та після розуміння який обєм вийде — скоротив до logging

На мою субєктивну думку, уникаю використання «string format» логів, оскільки потім їх важко знаходити, незалежно від того, як вони зберігаються (ELK, log file, Cloud watch)

Дякую за коментар :)

Дякую, виправив!
Рекомендую використовувати data(dict) та зберігати всю додаткову інформацію там. Це допоможе уникнути безладу в «структурі» лога.

Для прикладу, що ми отримуємо на фіналі

{
  "msg": "Subscription was deactivated",
  ...
  "data": {
    "previous_subscription_id": 11,
  }
}