[System info] [message] [context]
де:- system info. мітка часу, ід процесу, ід потоку і інша службова інформація
- message. Текст повідомлення
- context. будь-яка додаткова інформація, контекст може бути загальним для повідомлень в рамках якої то операції.
Для того, щоб зв'язати пари запит \ відповідь часто використовується http заголовок X-Request-ID. Такий заголовок може згенерувати клієнт, або він може бути згенерований на стороні сервера. Додавши його в контекст кожного рядка балки з'явиться можливість легким рухом руки знайти всі повідомлення виникли в рамках виконання конкретного запиту. А в разі розподілених систем, заголовок можна передавати далі по ланцюжку Інтернет-дзвінків.
Але з єдиним контекстом в рамках запиту виникає проблема з різними ORM, http клієнтами або іншими сервісами \ бібліотеками, які живуть своїм життям. І ще добре, якщо вони надають можливість перевизначити свій стандартний логер хоча б глобально, а ось виставити контекст для логера в рамках запиту часто не реально. Дана проблема в основному актуальна для багатопотокового обробки, коли один процес обслуговує безліч запитів. Але наприклад в фреймворке Rails є дуже тісна інтеграція між усіма компонентами і запити ActiveRecord можуть писатися в лог разом з глобальним контекстом для поточного мережевого запиту. А в мові Go деякі бібліотеки логування дозволяють динамічно створювати новий об'єкт логера з потрібним контекстом, виглядає це приблизно так:
reqLog: = log.WithField ( "requestID", requestID)
Після цього такий екземпляр логера можна передати як залежність в інші об'єкти. Але відсутність стандартизованого інтерфейсу логування (наприклад як psr-3 в php) провокує творців бібліотек хардкодіть малосумісні реалізації логери. Тому якщо ви пишете свою бібліотеку на Go і в ній є компонент логування, не забудьте передбачити інтерфейс для заміни логера на призначений для користувача.