Observability: логи, метрики, трейси

Логи, метрики й трейси: три сигнали

Моніторинг відповідає на питання, які ми передбачили («CPU > 90%?»). Observability — це здатність пояснити стан системи за її зовнішніми сигналами, зокрема на питання, яких не передбачали («чому лише в користувачів із Safari у Франкфурті повільний checkout?»). Основні сигнали:

• Логи — окремі події з контекстом. Відповідають на «що саме сталося в цьому запиті». Дорогі за обсягом, найдетальніші.
• Метрики — числові ряди в часі (запитів/с, частка помилок, p95 затримки, використання пам’яті). Дешеві, добре агрегуються, показують що і наскільки, але не чому. Основа дашбордів і алертів.
• Трейси — шлях одного запиту через сервіси, розбитий на spans із тривалістю. Відповідають на «де саме загубився час або виникла помилка».

Типовий сценарій розслідування: алерт за метрикою (виросла частка 5xx) → трейс показує, що повільний/помилковий виклик у сервісі оплат → логи цього спана за trace id пояснюють причину (таймаут шлюзу).

Корисні набори метрик: RED для сервісів (Rate, Errors, Duration) і USE для ресурсів (Utilization, Saturation, Errors). Також є golden signals: latency, traffic, errors, saturation.

Для QA: окрім функціональної перевірки відповіді, тест чи ручна перевірка після релізу дивиться на помилки й затримки в метриках; синтетичні тести (synthetic monitoring) регулярно проходять ключові сценарії на проді.

Розподілені трейси, trace id і OpenTelemetry

У мікросервісах один клік користувача породжує ланцюжок викликів. Distributed tracing зв’язує їх в один trace: корінь — це весь запит, а span — окрема операція (HTTP-виклик, запит до БД) з початком, тривалістю, атрибутами й посиланням на батьківський span.

Щоб сервіси знали, що вони частина одного trace, контекст передається в заголовках. Стандарт — W3C Trace Context, заголовок traceparent:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             версія-trace id (32 hex)-parent span id (16 hex)-прапорці

Прапорець 01 означає «sampled» (трейс записується). Додатковий заголовок tracestate несе дані вендорів. Старіші системи використовують власні X-Request-Id, X-Correlation-Id чи B3; у логах цей ідентифікатор потрібен у кожному записі — тоді за одним id знаходяться і трейс, і всі пов’язані логи.

OpenTelemetry (OTel) — відкритий, нейтральний до вендорів стандарт і набір SDK для логів, метрик і трейсів:

• API/SDK для мов (інструментування вручну й автоматичне — бібліотеки HTTP, БД, фреймворки);
• OTLP — протокол передачі даних;
• Collector — проміжний сервіс, що приймає, обробляє (фільтр, маскування, семплінг) і розсилає дані в бекенд (Jaeger, Tempo, Datadog тощо).

Семплінг: писати кожен трейс дорого. Head sampling вирішує на початку (наприклад, 5% запитів), tail sampling — після завершення, і тому може лишати всі помилкові й повільні трейси.

Що це дає QA: тест чи ручна перевірка може взяти trace id з відповіді (або згенерувати traceparent сам), після падіння за ним відкрити повний шлях запиту й побачити, який сервіс зламався. Це особливо цінно для e2e, де UI показує лише «щось пішло не так».

Дашборди, алерти, SLI/SLO для QA

Дашборд показує стан системи на одному екрані: частка помилок, p95 затримки, трафік, черги. Хороший дашборд відповідає на «усе гаразд?» за кілька секунд і веде до деталей (drill-down). Алерт — автоматичне сповіщення, коли метрика порушує умову.

Принципи алертів:

• алертити на симптоми для користувача (частка помилок, затримка), а не на кожну внутрішню дрібницю;
• кожен алерт має бути діючим: хтось знає, що робити (runbook); шумні алерти ігнорують («alert fatigue»);
• усереднення ховає проблеми — дивляться на перцентилі (p95/p99), а не лише на середнє.

SLI / SLO / SLA коротко:

• SLI (indicator) — вимірюваний показник якості, наприклад частка успішних запитів або частка відповідей швидше 300 мс;
• SLO (objective) — ціль для SLI за період: «99,9% запитів успішні за 30 днів»;
• SLA — зовнішня договірна обіцянка з наслідками за порушення;
• Error budget — допустима частка невдач (100% − SLO; для 99,9% це 0,1%). Поки бюджет не вичерпано, команда може випускати зміни швидко; якщо вичерпано, пріоритет — надійність.

Де тут QA: перевіряє, що ключові сценарії покриті метриками й алертами (наприклад, алерт справді спрацьовує при інʼєкції помилки в тестовому оточенні); використовує SLO як критерій релізу (канарковий реліз, відкат за метриками); додає синтетичні тести; аналізує, чи інцидент було б упіймано тестом, і додає його.