Що таке observability: як logs, metrics і traces допомагають бачити систему

Опівночі у продакшні падає оформлення замовлень. Моніторинг показує: усі сервери живі, процесори не перевантажені, диски в порядку. Але клієнти не можуть платити, і ніхто не розуміє чому. Саме для таких ситуацій існує observability — спостережуваність системи, яка дозволяє відповісти не лише на питання «чи все працює», а й «чому саме воно не працює».

Що таке observability простими словами? Це властивість системи, за якої за її зовнішніми сигналами — логами, метриками й трейсами — можна зрозуміти внутрішній стан без залізання в код у розпалі інциденту. Термін запозичений з теорії керування: інженер Рудольф Калман ще в 1960-х описав спостережуваність як можливість відновити стан системи за її виходами. У світі технологій та інновацій поняття набуло практичного значення приблизно з середини 2010-х, коли мікросервіси й хмари зробили архітектури настільки розподіленими, що класичний моніторинг перестав справлятися.

Чим observability відрізняється від звичайного моніторингу

Моніторинг відповідає на заздалегідь сформульовані запитання. Ви знаєте, що диск може заповнитися, тому ставите поріг 85% і отримуєте алерт, коли він перевищений. Це працює для відомих режимів відмови — так званих known unknowns. Проблема в тому, що в складній системі більшість реальних інцидентів — це unknown unknowns: комбінації обставин, які ніхто не передбачав.

Observability працює інакше. Система постійно випромінює багату телеметрію, а інженер у момент інциденту ставить довільні запитання до цих даних: які запити повільні, на якому сервісі вони гальмують, що змінилося після останнього релізу, які користувачі постраждали. Відбувається перехід від «перевірки за чеклистом» до «розслідування за фактами».

На практиці моніторинг і observability не конкурують, а доповнюють одне одного. Алерти за метриками залишаються першим сигналом тривоги, але глибина розбору інциденту залежить саме від того, наскільки добре система дозволяє себе спостерігати. Команда, у якої є лише дашборди з CPU і пам’яттю, у складному інциденті опиняється сліпою.

Три стовпи: logs, metrics і traces

Розмовляючи про observability, фахівці зазвичай називають три основні типи телеметрії. Кожен дає свій ракурс, і жоден не замінює інші.

Logs — детальний журнал подій

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

Слабкість логів — обсяг і хаос. У системі з сотнями контейнерів щосекунди народжуються тисячі рядків, і шукати потрібний без централізованого збору та індексації марно. Тому практичним стандартом стали структуровані логи у форматі JSON: замість вільного тексту кожна подія — набір полів (час, сервіс, рівень, ідентифікатор запиту, повідомлення), які легко фільтрувати й агрегувати. Друге правило — осмислені рівні: DEBUG для розробки, INFO для нормальних подій, WARN і ERROR для відхилень. Логувати все підряд на рівні INFO — означає потім тонути в шумі.

Metrics — числовий пульс системи

Метрики — це числові вимірювання, агреговані в часі: кількість запитів на секунду, відсоток помилок, затримка на 95-му перцентилі, вільна пам’ять. На відміну від логів, вони компактні, дешеві у зберіганні й ідеально підходять для дашбордів і алертів. Саме метрики відповідають на питання «чи є проблема загалом і наскільки вона масштабна».

Класичний набір для будь-якого сервісу описує підхід RED: Rate (частота запитів), Errors (частка помилок), Duration (тривалість обробки). Для інфраструктурних ресурсів застосовують метод USE: Utilization, Saturation, Errors. Метрики майже не розкажуть про причину конкретного збою, але без них ви просто не дізнаєтесь, що збій стався, — це основа алертингу та відстеження SLO.

Traces — шлях запиту крізь систему

Трейси, або розподілене трасування, показують повний шлях одного запиту крізь усі сервіси, які він торкнувся. Запит користувача може пройти через балансувальник, API-шлюз, п’ять мікросервісів, базу даних і чергу повідомлень. Трейс зшиває всі ці кроки в єдине дерево, де видно, скільки часу зайняв кожен етап і де саме виникла затримка чи помилка.

Це наймолодший з трьох стовпів і водночас найцінніший для мікросервісних архітектур. Коли checkout гальмує, трейс за секунди показує: 800 мс із 900 пішло на виклик сервісу антифроду, який очікував відповіді зовнішнього API. Без трасування цю причину довелося б збирати вручну з логів кількох команд. Технічно трасування працює завдяки propagation — передаванню ідентифікатора трейсу в заголовках кожного наступного виклику, тому воно вимагає інструментування всіх ланок ланцюжка.

Як три сигнали працюють разом у реальному інциденті

Цінність observability розкривається саме в комбінації. Типовий сценарій розслідування виглядає так. Алерт за метрикою повідомляє: частка помилок 5xx на платіжному сервісі зросла з 0,1% до 4%. Це точка входу — ми знаємо, що проблема існує і де вона проявляється зовні.

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

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

Observability у хмарах, дата-центрах і Kubernetes

У власному дата-центрі з десятком однотипних серверів можна було обходитися простим моніторингом. Сучасна інфраструктура влаштована інакше: віртуальні машини створюються й знищуються автоматично, контейнери в Kubernetes мігрують між вузлами, serverless-функції живуть секунди. Статичний список хостів більше не описує систему, і телеметрія має збиратися з динамічних, короткоживучих об’єктів.

У Kubernetes-екосистемі фактичним стандартом збору метрик став Prometheus із його pull-моделлю та мовою запитів PromQL, а для візуалізації найчастіше використовують Grafana. Логи контейнерів збирають агенти на кшталт Fluent Bit або Promtail і складають у сховища типу Elasticsearch чи Loki. Для трасування поширені Jaeger і Tempo. Важливий технологічний зсув останніх років — OpenTelemetry: відкритий стандарт і набір SDK, що дозволяє інструментувати застосунок один раз і відправляти логи, метрики й трейси в будь-який сумісний бекенд, не прив’язуючись до одного постачальника.

Хмарні платформи пропонують власні рішення — CloudWatch, Azure Monitor, Google Cloud Operations, — які зручні для старту, бо телеметрія інфраструктури з’являється майже безкоштовно. Але в гібридних середовищах, де частина системи живе в хмарі, а частина у власному дата-центрі, командам зазвичай потрібен єдиний шар спостереження поверх усіх середовищ, інакше інциденти доводиться розбирати в двох консолях одночасно.

Від даних до рішень: SLO, алерти й дашборди

Зібрати телеметрію — лише половина справи. Друга половина — перетворити її на керований процес. Центральне поняття тут — SLO, цільовий рівень обслуговування: наприклад, 99,9% запитів до API мають завершуватися успішно й швидше за 300 мс. SLO визначається через SLI — вимірювані показники з метрик. Це зміщує фокус із «сервери працюють» на «користувачі отримують нормальний сервіс», а різниця між 100% і SLO утворює бюджет помилок, який можна свідомо витрачати на ризиковані релізи.

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

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

Типові помилки при впровадженні observability

• Купівля платформи замість практики. Інструмент сам по собі не робить систему спостережуваною: без інструментування застосунків, кореляції сигналів і звички розбирати інциденти навіть дорогий стек залишиться складним дашбордом.
• Логування без структури. Вільний текст, різні формати в різних сервісах і відсутність ідентифікаторів запитів перетворюють пошук причини збою на археологію.
• Надмірна кардинальність метрик. Додавання в мітки метрик унікальних значень — user_id, session_id, URL із параметрами — вибухає сховища часових рядів і рахунок за нього. Унікальні ідентифікатори належать логам і трейсам, а не метрикам.
• Трасування лише частини ланцюжка. Якщо хоч один сервіс у шляху запиту не передає контекст, трейс рветься, і найцікавіша ділянка лишається невидимою.
• Алерти на все. Сотні сповіщень на добу гарантують, що справді критичний алерт буде пропущено.
• Ігнорування вартості. Детальна телеметрія з високого трафіку коштує помітних грошей; семплювання трейсів і політики ретенції логів — нормальна інженерна практика, а не економія на безпеці.

З чого почати впровадження: практичний чекліст

Найбільша помилка команд — спроба побудувати все одразу. Розумніша послідовність виглядає так.

1. Визначте один критичний для бізнесу сценарій — наприклад, оформлення замовлення або авторизацію — і сформулюйте для нього SLO з вимірюваними SLI.
2. Налаштуйте збір базових метрик за методом RED для сервісів цього сценарію та побудуйте один дашборд верхнього рівня.
3. Приведіть логи до структурованого формату з кореляційними ідентифікаторами й централізуйте їхнє зберігання.
4. Додайте розподілене трасування через OpenTelemetry, починаючи з точки входу запитів, і поступово розширюйте покриття вглиб ланцюжка.
5. Перегляньте алерти: залиште тільки ті, що відображають симптоми для користувача й вимагають дій, решту — приберіть або переведіть у звіти.
6. Після кожного інциденту фіксуйте, якого сигналу не вистачило для швидкої діагностики, і закривайте цю прогалину — так observability зростає з реального досвіду, а не з абстрактного плану.

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