Для C++ на жаль бібліотек, які б мені реально подобалися, для цього нема.
А от на Python 💻 у мене є пара улюблених. Закладаюся, ви про них знаєте, але якщо ні, то прошу 🙂
Перша — це Dynaconf. Вона дуже фічаста. Читає конфіги й із файлів, і зі змінних оточення, і бозна-звідки ще. Підтримує купу різних вхідних форматів для налаштувань: TOML 💻, YAML 💻, JSON 💻 тощо. Я зазвичай користуюся YAML, бо руками його писати найприємніше. (І шо ви мені зробите, га‽). Також прикольна фішка з шарами — постійно нею користуюся. (Це як у VS Code 💻, де є сталі глобальні налаштування, є користувацькі і є проєктні. І кожні з них нашаровуються на попередні й перевизначають деякі поля. Знаєте ж?) Так от цим зручно користуватися, коли, наприклад, при розробці ви підʼєднуєтеся до якихось локальних серверів, вмикаєте додаткове логування, якісь ще фічі, API-токени читаєте з локального файлу, а в продакшні використовуєте віддалені сервери зі своїми ендпоїнтами, вимикаєте різні «дірки» для дебагу, токени берете десь з Vault тощо. Один раз налаштували профілі, а потім між ними перемикаєтеся — зручно.
Друга ліба — це structlog. Взагалі зазвичай коли кажуть про структуровані логи, то мають на увазі, що замість звичайного тексту в журнал записуються JSON-обʼєкти, причому часто не в локальний файлик, а в спеціалізований сервіс на кшталт Elastic. Але в мене таких юзкейсів нема.
Насправді ж ідея в тому, що ваш логер оперує не текстом, а обʼєктами. А це значить, що можна робити купу прикольних штук! Наприклад, можна додавати щось у контекст, і цей контекст прикріпиться до повідомлення. У мене ось є тестовий бот для тґ, в якому окремий middleware прикріплює в контекст повідомлення інформацію про команду, яка прийшла від користувача (якщо це саме запит з командою):
async def add_command(self, event, data) -> None:
match data:
case {'command': CommandObject(prefix=prefix, command=command)}:
structlog.contextvars.bind_contextvars(command=f'{prefix}{command}')
Ну й низка інших схожих штук. (Нижче є зняток екрану).
Якщо ви весь час оперуєте обʼєктами, то це значить, що можна побудувати ланцюжок додаткових обробників. Це приблизно як в нормальному (тобто 🆕) шелі, де ви через жолоб переливаєте з однієї команди в іншу не просто потік байтів, а структуровані дані. Завдяки цьому повідомлення, що логуються, легко додатково якось обробити: агрегувати в них щось, пофільтрувати, змінити структуру — будь-що. Наприклад, уявіть ситуацію, що при розробці ви хочете в терміналі бачити якомога більше даних в логах: різну зневаджувальну інформацію, параметри функцій, тіло запитів тощо. Але в продакшні цього робити не можна, бо логи у вас пишуться в якусь базу, і туди можуть випадково потрапити приватні користувацькі дані. Якщо логер у вас текстовий, то доведеться якісь милиці ставити, а якщо структурований, то ви легко можете написати окремий фільтр, який ті дані видалить або замаскує.
В якийсь момент ті обʼєкти все-таки доведеться перетворити в щось. Тому кожний ланцюжок обробників закінчується штукою, яка рендерить обʼєкт у конкретний формат. Оце, наприклад, стандартний для виводу в термінал:
processors = [
structlog.contextvars.merge_contextvars,
structlog.processors.add_log_level,
structlog.processors.StackInfoRenderer(),
structlog.dev.set_exc_info,
structlog.processors.TimeStamper(fmt="%Y-%m-%d %H:%M:%S", utc=False),
structlog.dev.ConsoleRenderer()
]
І нижче на знятку — те що отримуємо на виході (там кольорові штуки в кінці повідомлень — це контекстні змінні, які додаються моїм кодом автоматично! Дуже зручно).
Якщо знаєте якісь прикольніші ліби або аналогічні для інших мов, то напишіть мені в коментарі, будь ласка )