Логування

Рядок логу — це подія, а не речення

Більшість коду логування пишеться для уявного читача: людини, що гортає термінал тієї миті, коли все ламається. Такого читача майже ніколи не існує. Справжній читач — це запит, надрукований за тижні кимось, кого там не було, з питанням, скількох користувачів це зачепило, чи почалося воно з останнього релізу і чи триває досі. Речення не відповідає на жодне з них. Запис із полями відповідає на всі три.

Практична зміна невелика: віддавайте обʼєкт замість відформатованого рядка й кладіть кожен факт, який ви вставили в повідомлення, ще й у власне поле. Не вдалося списати кошти з картки користувача 8213 після 3 спроб стає подією з назвою payment_failed і полями user_id, attempts та reason поруч. Лишіть і читабельне повідомлення, якщо хочете, — нічого не втрачається, — але саме поля роблять запис таким, що рахується. І вживайте одну назву поля в усіх сервісах, бо user_id в одному сервісі й userId в іншому — це дві колонки для рушія запитів і один дуже дратівливий день для людини.

Логи, метрики й трасування відповідають на різні питання

Команди, що логують усе, зазвичай роблять це тому, що логи — єдиний сигнал, який у них є; вони платять за це сховищем і при цьому досі не можуть відповісти на базові питання. Три сигнали — це не три формати однієї речі: у них різна форма, різна вартість і різні межі, і знати, яке питання кому належить, — це більша частина вміння.

Корисна дисципліна випливає з таблиці. Алертуйте за метриками: вони достатньо дешеві, щоб обчислювати їх постійно, і достатньо стійкі, щоб не спрацьовувати на одному поганому запиті. Діагностуйте трасуванням: воно показує, куди пішов час, без вгадування, у який сервіс дивитися. Підтверджуйте логами: саме там живуть деталі конкретного випадку, що впав. Команда, яка алертує за пошуком у логах, платить рушію запитів за роботу метрики — і це буде і повільніше, і дорожче рівно тієї миті, коли це важить.

Поля, що роблять інцидент відповідним на питання

Короткий і нудний список покриває більшість. Кожна подія з кожного сервісу має нести ці поля — не тому, що так каже стандарт, а тому, що кожне з них є питанням, яке хтось поставить, поки клієнт чекає.

• Ідентифікатор трасування

  Найцінніше поле на цій сторінці. Воно звʼязує кожен рядок логу з кожного сервісу з однією дією користувача. Створіть його на межі, передавайте всюди, логуйте завжди.

• Назва події

  Стала назва низької кардинальності із закритої множини. Саме її ви рахуєте, групуєте й берете в алерт, коли зрештою перетворюєте лог на метрику.

• Сервіс і реліз

  Який код це видав. Без релізу питання «чи спричинило це розгортання» не має відповіді, — а воно перше в більшості інцидентів.

• Актор і тенант

  З ким це сталося — ідентифікатором, а не імʼям чи поштою. Потрібно, щоб відповісти про масштаб: один клієнт, один регіон чи всі.

• Результат і причина

  Успіх чи провал і код причини із закритої множини. Саме лише «провал» змушує людину читати повідомлення; код причини можна згрупувати.

• Тривалість

  Скільки тривала операція, у мілісекундах, числом. Записати нічого не коштує, а на питання «чи було повільно до поломки» відповідає безкоштовно.

Двох речей у лозі бути не має. Персональних даних — імен, адрес, пошт, номерів карток, токенів, повних тіл запитів, — бо логи копіюються на пошукову платформу, лежать місяцями й читаються більшою кількістю людей, ніж ваша база, а це робить їх найімовірнішим місцем витоку, який ніхто не аудіював. І будь-чого, що ви не можете дозволити собі надрукувати, а на практиці це облікові дані: рядок логу — класичний шлях, яким секрет тікає із системи, обережної в усьому іншому. Логуйте ідентифікатор, а запис із бази дістаньте тоді, коли він справді знадобиться.

Арифметика, що стає рахунком

Вартість логування — це одне множення, і зробити його один раз означає уникнути несподіванки. Візьміть запити на секунду, помножте на рядки логу на запит, на байти в рядку і на секунди в добі. Сервіс на 500 запитів за секунду, що пише 8 рядків по 600 байтів, дає близько 200 ГБ на добу — з одного сервісу. Помножте на кількість сервісів, потім на строк зберігання, потім на те, що платформа бере за прийом і за індексацію, — а це зазвичай два окремі рахунки. Більшість команд знайомиться з цим числом уперше в інвойсі.

Керують цим чотири важелі, і тягнути їх варто в такому порядку:

• Перестаньте логувати те, що ніхто не запитує. Більшість обсягу — це кілька рядків на гарячому шляху, доданих під час налагодження роки тому й ніколи не прибраних.
• Робіть вибірку успішних і тримайте всі провали. Нікому не потрібен кожен з мільйона однакових успіхів, і всім потрібен кожен провал.
• Ешелонуйте зберігання: із пошуком — два тижні, дешевий архів — на строк відповідності. Майже кожен запит стосується останніх кількох днів.
• Перетворіть найоб’ємніші події на метрики й перестаньте зберігати їх поодинці: лічильник відповідає на «скільки» за похибку від тієї вартості.

Як зробити інцидент відповідним від краю до краю

У системі з одного сервісу логи — це файл. У системі з кількох це купа файлів, що описують ту саму дію користувача з пʼяти боків і не зʼєднуються — якщо тільки щось не було пронесено між ними. Це щось — ідентифікатор трасування, створений у першій точці входу запиту у вашу систему й переданий далі в заголовку, а потім причеплений до кожного рядка логу, який цей запит породжує будь-де. Це кілька годин сантехніки — і це різниця між реконструкцією інциденту й припущеннями про нього.

Ще дві звички відділяють сховище логів від придатного до вжитку. Віддавайте однакові назви полів усюди: домовтеся про них один раз, покладіть у спільну бібліотеку й не дозволяйте кожному сервісу вигадувати власні. І користуйтеся однією відкритою конвенцією, а не форматом вендора: OpenTelemetry дає ідентифікатор трасування, ідентифікатор відрізка й набір стандартних назв атрибутів, а отже, збір і платформу можна замінити, не чіпаючи коду застосунку. Друге з часом важить більше, ніж здається зараз, бо платформа логів — той компонент, який команди найчастіше хочуть змінити й найрідше можуть.

Антипатерни, які варто назвати

• Повідомлення, зібрані з шаблонів: кожен рядок — унікальний рядок, і без регулярного виразу нічого не порахувати.
• Залогувати виняток і кинути його далі: один збій зʼявляється чотири рази на чотирьох рівнях стека.
• Персональні дані в полях, що лежать девʼяносто днів на платформі зі ширшим списком доступу, ніж у базі, звідки вони взялися.
• DEBUG, лишений увімкненим у проді після розслідування, — його виявляє наступного місяця фінансовий відділ.
• Немає ідентифікатора трасування: інцидент між сервісами реконструюють, порівнюючи мітки часу й сподіваючись, що годинники згодні.
• Алерти за пошуком у логах: це робота метрики, яку виконує рушій запитів у найгіршу можливу мить.

Коли це застосовувати

Пов’язані сторінки

• ІнфраструктураАлертингАлертинг — це те, як стан системи перетворюється на рішення когось розбудити. Алерт — це прохання перервати людину, і саме так його варто читати щоразу, коли пишеш новий. Більшість систем алертингу провалюються не тому, що щось пропускають, а тому, що кричать «вовки», доки черговий інженер не перестане їм вірити, — і це збій проєктування, а не проблема дисципліни. На цій сторінці — які умови заслуговують переривання, чому алерт на симптом кращий за алерт на причину, як SLO й швидкість спалювання перетворюють «сайт наче гальмує» на число, заради якого варто прокинутися, і що має існувати ще до того, як виклик буде надіслано.
• ІнфраструктураKubernetesKubernetes — це цикл керування з API перед ним. Ви не наказуєте йому запустити контейнер: ви записуєте бажаний стан, а контролери постійно звіряють цей запис із тим, що працює насправді, і діють на різницю — завжди, а не один раз. Кожен обʼєкт, який він пропонує, і кожна його несподівана поведінка походять звідси. На цій сторінці — сам цикл, кілька обʼєктів, що справді важать, чому ліміти ресурсів і перевірки здоровʼя спричиняють більшість інцидентів у проді й коли все це вам справді потрібне.
• РозробкаМікросервісиМікросервіси — це архітектура, у якій систему будують як набір сервісів, кожен з яких можна деплоїти окремо. Визначальна властивість — незалежна деплойність, а не розмір: сервіс правильного розміру тоді, коли одна команда володіє ним від початку до кінця. Усе добре в цьому стилі випливає з тієї незалежності, а все складне — з того, що виклики між сервісами тепер ідуть через мережу.