Чому “є логи” недостатньо
Коли щось ламається, вам потрібно відповісти на 3 питання: що зламалось, де, і чому. Без метрик/трейсів це перетворюється на здогадки.
1) Метрики: золоті сигнали
- Latency (p95/p99) для ключових ендпоїнтів.
- Traffic (RPS/запити/черги).
- Errors (4xx/5xx, timeouts, retries).
- Saturation (CPU/RAM/DB connections).
2) Логи: структура та кореляція
- JSON‑логи з полями: level, msg, requestId, userId (якщо можна), service, duration.
- Один requestId через gateway → бекенд → воркери.
- Санітизація: не логуй токени/паролі/карткові дані.
3) Трейси: де “втрачається” час
Distributed tracing показує, на якому кроці повільно: DB, зовнішній API, черга, кеш. Це найшвидший шлях до root cause у мікросервісах.
4) Алерти під SLO
- Алерт має означати “потрібна дія”, а не “десь щось сталося”.
- Використовуй error budget: алертимо при тренді, а не при одиничному сплеску.
- Розділяй severity: warning vs critical.
5) Runbooks
До кожного критичного алерта має бути коротка інструкція: що перевірити, як відкотити, де подивитись метрики. Це економить години.
Підсумок
Observability — це основа стабільних релізів: метрики + логи + трейси + алерти під SLO. Тоді інциденти стають керованими, а не “містикою”.