Observability vs Monitoring: що реально потрібно бізнесу, а що - зайва складність

Моніторинг відповідає на запитання «Чи здорова система?», перевіряючи відомі несправності за допомогою агрегованих метрик. Observability дозволяє відповісти на запитання «Чому система поводиться дивно?», досліджуючи невідомі стани через дані високої кардинальності. Бізнес потребує Observability не заради красивих графіків, а заради радикального зменшення MTTR у розподілених системах, де неможливо передбачити всі сценарії збоїв. Ця стаття розбирає різницю між двома парадигмами на рівні теорії, архітектури та економіки.

Від теорії управління до розподілених систем: генезис Observability

Багато хто помилково вважає Observability просто «моніторингом на стероїдах» або маркетинговим ребрендингом, створеним вендорами для продажу дорожчих ліцензій. Така інтерпретація веде до побудови неправильної архітектури, адже за терміном стоїть чітка інженерна концепція, а не рекламний слоган.

Коріння поняття лежить у Теорії управління (Control Theory), сформульованій Рудольфом Калманом у 1960 році. Калман визначив спостережуваність як міру того, наскільки добре внутрішні стани системи можуть бути виведені (inferred) на основі знання її зовнішніх виходів. Інакше кажучи, система є спостережуваною тоді, коли за її вихідними сигналами можна однозначно реконструювати те, що відбувається всередині.

Моніторинг проти Спостережуваності

Моніторинг - це дія перевірки системи на відповідність заздалегідь визначеним критеріям відмови. Ви моніторите те, про що вже знаєте, що воно може зламатися - тобто працюєте з «Відомими Невідомими» (Known Unknowns). Observability, навпаки, є властивістю системи, яка дозволяє зрозуміти «Невідомі Невідомі» (Unknown Unknowns) - проблеми, яких ви ніколи раніше не бачили і для яких не могли створити сповіщення наперед.

Якщо ви можете зрозуміти причину збою, не додаючи нових логів і не перезапускаючи код - ваша система має Observability. Якщо вам потрібно додати console.log і зробити деплой, щоб зрозуміти, що сталося, - у вас налаштовано лише моніторинг.

Прокляття розмірності: кардинальність як фундаментальне обмеження метрик

Розуміння теоретичної різниці між моніторингом і спостережуваністю - необхідний перший крок, але саме по собі воно не пояснює, чому інструменти, які чудово працювали десять років тому для монолітів, стають «сліпими» у світі мікросервісів та Kubernetes. Відповідь криється в понятті кардинальності (Cardinality) - кількості унікальних значень у наборі даних.

У контексті Time Series Database (TSDB) на кшталт Prometheus або VictoriaMetrics кардинальність визначається комбінацією всіх можливих лейблів. Низька кардинальність - це status_code з його кількома десятками значень (200, 404, 500) або method з класичним набором GET, POST, PUT. Висока кардинальність - це user_id з мільйонами значень, transaction_id з мільярдами, container_id з тисячами значень, що постійно змінюються, або ip_address.

Проблема «Cardinality Explosion»: якщо ви спробуєте додати user_id як лейбл у метрику Prometheus, кількість часових рядів (time series) зросте експоненційно. Це призведе до надмірного використання оперативної пам'яті та падіння TSDB. Традиційний моніторинг змушений агрегувати дані, стираючи деталі - і саме тут починається проблема.

Агрегація як приховування правди

Моніторинг каже вам: «Середній час відповіді - 200 мс». На перший погляд, все добре. Але у розподіленій системі середнє значення приховує «довгі хвости» (tail latency): 99% користувачів отримують відповідь за 50 мс, а 1% - найважливіші VIP-клієнти з великими кошиками - чекають по 10 секунд. Середнє значення «розмиває» цю критичну проблему до невидимості.

Системи Observability (побудовані, наприклад, на базі ClickHouse, Honeycomb або Grafana Loki) працюють інакше: вони зберігають «сирі» події (raw events) і дозволяють виконувати запити по них у реальному часі. Це відкриває можливість запитів типу «Показати всі запити від user_id=12345 за останні 10 хвилин, де latency > 5s» - те, що принципово неможливо в системі, яка оперує лише агрегатами.

Руйнування міфу про «Три стовпи»: від Data Silos до єдиної події

Усвідомлення обмежень агрегованих метрик логічно підводить до наступного питання: якщо нам потрібні сирі дані, то як їх організувати? Індустрія роками просувала концепцію «Трьох стовпів Observability» (Three Pillars) - метрики, логи, трейси. Це призвело до створення Data Silos, ізольованих сховищ даних, які не взаємодіють між собою, і перетворило діагностику на виснажливий квест.

У типовій компанії процес виглядає так: інженер бачить сплеск CPU на дашборді метрик, копіює час інциденту і переходить у систему логування, щоб знайти помилки, потім знаходить помилку, копіює ID запиту і переходить у систему трейсингу, щоб побачити водоспад викликів. Кожен крок - це ручне перемикання контексту, яке з'їдає критичний час під час інциденту. Але суть у тому, що метрики, логи і трейси - це не три різні типи даних, а три різні проєкції однієї Події (Event).

«Canonical Log Line» - концепція широкої події

Сучасний підхід, реалізований в OpenTelemetry, пропонує об'єднувати контекст. Замість розрізнених даних створюється одна «широка подія» (Structured Event) на кожен запит:

Приклад Structured Event: одна JSON-структура, що є одночасно метрикою, логом і частиною трейсу

Ця єдина JSON-структура є одночасно і метрикою (можна порахувати кількість подій або обчислити перцентилі по duration_ms), і логом (має текст помилки в error.message), і частиною трейсу (має trace_id). Замість трьох ізольованих систем - одне сховище з повним контекстом кожного запиту.

OpenTelemetry як безальтернативний архітектурний стандарт

Ідея єдиної події на кожен запит залишається теоретичним ідеалом, доки немає стандартного способу генерувати, збирати та експортувати ці дані. Раніше, щоб змінити систему моніторингу (наприклад, перейти з Prometheus на Datadog), доводилося переписувати код у всіх мікросервісах. Це класичний Vendor Lock-in, який перетворює будь-яку міграцію на багатомісячний проєкт. OpenTelemetry (OTel) - проєкт CNCF, що став галузевим стандартом, - вирішує цю проблему, розділивши процес на дві незалежні фази: генерація даних та їх експорт.

Архітектура OTel Collector

Серцем стандарту є OTel Collector - окремий процес, який виконує три функції. Receivers приймають дані у будь-якому вхідному форматі: Jaeger, Prometheus, OTLP, Zipkin. Processors обробляють потік - фільтрують, анонімізують PII-дані, додають хмарні теги Kubernetes, групують події в батчі. Exporters відправляють результат у довільний бекенд: Elasticsearch, AWS X-Ray, Prometheus, Splunk або будь-яку іншу систему.

Використовуючи OTel, ви володієте своїми даними. Якщо постачальник послуг підніме ціни, ви змінюєте конфігурацію OTel Collector і перенаправляєте потік даних в іншу систему - не змінюючи жодного рядка коду продукту.

eBPF і Zero-Instrumentation: Observability без зміни коду

OpenTelemetry вирішує проблему стандартизації, але вимагає інструментації - додавання SDK та бібліотек у код. Виникає природне запитання: чи можна отримати Observability взагалі без зміни додатку? Відповідь дає eBPF (Extended Berkeley Packet Filter) - технологія ядра Linux, яка дозволяє запускати безпечні, ізольовані програми в просторі ядра без необхідності його перекомпіляції.

Інструменти на кшталт Cilium або Pixie використовують eBPF для перехоплення мережевих пакетів та системних викликів, що дає дві ключові можливості. По-перше, автоматичний RED (Rate, Errors, Duration): eBPF бачить весь TCP/HTTP трафік і може побудувати карту сервісів та показати затримки без жодної бібліотеки в коді додатка. По-друге, безперервне профілювання (Continuous Profiling): інструменти на базі eBPF показують, яка саме функція в коді споживає CPU, з мінімальним навантаженням на систему (менше 1%).

Проте eBPF має принципове обмеження: ця технологія бачить інфраструктуру, але не завжди знає бізнес-контекст. Вона не відрізнить VIP-клієнта від анонімного відвідувача, не знає, що конкретний запит - це частина критичного checkout-процесу. Тому ідеальна стратегія поєднує обидва підходи: OTel для бізнес-логіки та eBPF для інфраструктури.

FinOps-реальність: як не збанкрутувати на телеметрії

Технічні можливості OTel та eBPF можуть вселяти оптимізм, але перше, що відчує на собі реальна команда після впровадження повноцінної Observability, - це рахунок за зберігання. Зберігати гігабайти логів та трейсів «про всяк випадок» - прямий шлях до фінансових втрат, і витрати на Observability часто сягають 20–30% від загального рахунку за хмару. Розумне управління цими витратами - не менш важлива компетенція, ніж налаштування самих інструментів.

Розумний семплінг (Smart Sampling)

Ключовий інсайт FinOps-підходу: вам не потрібні 100% трейсів успішних запитів (HTTP 200 OK), які пройшли швидко. Вам потрібні 100% помилок і повільних запитів. Існують два підходи до семплінгу. Head-Based Sampling приймає рішення «зберігати чи ні» на початку запиту - це дешево, але є ризик пропустити рідкісну помилку, яка виникне в кінці обробки. Tail-Based Sampling працює інакше: система буферизує весь трейс, чекає його завершення, аналізує (чи була помилка? чи перевищено поріг затримки?) і тільки тоді приймає рішення про збереження. Це гарантує збереження лише дійсно цінних даних.

Різні рівні зберігання (Tiered Storage)

Другий важливий інструмент - об'єктні сховища (S3/GCS) для довгострокового зберігання логів. Сучасні інструменти дозволяють робити запити безпосередньо з S3, що значно дешевше за використання швидких SSD-дисків. Гарячі дані залишаються на швидкому сховищі для оперативної діагностики, а холодні - мігрують в об'єктне сховище, зберігаючи доступність, але радикально знижуючи вартість.

Від Uptime до User Happiness: SLO як мова бізнесу

Навіть оптимізована за витратами Observability-платформа не принесе бізнесу користі, якщо команда продовжить вимірювати не ті речі. Класичний Uptime сервера мало що каже про реальний досвід користувача - сервер може бути «живим», але при цьому віддавати помилки або відповідати неприйнятно повільно. Observability дозволяє перейти до іншої системи координат - моніторингу на основі SLI (Service Level Indicator).

Різницю найлегше побачити на прикладі алертингу. Класичний алерт на кшталт «CPU usage > 90%» є cause-based - він спрацьовує за причиною, яка може бути і безневинною (сервер обробляє піковий, але нормальний трафік). Правильний алерт працює за симптомами: «Error Budget Burn Rate > 2% за годину» означає, що ліміт на помилки вичерпується надто швидко і є ризик порушити домовленості з клієнтами (SLA). Такий підхід радикально зменшує втому від сповіщень (Alert Fatigue) - інженери реагують лише тоді, коли реально страждають користувачі, а не коли чергова метрика перетнула довільний поріг.

План дій

1. Прийняти OTel як стандарт. Увесь код має інструментуватися через OpenTelemetry, щоб уникнути прив'язки до конкретного вендора. Це інвестиція, яка окупається при першій же міграції.
2. Інвестувати в Structured Logging. Логи мають бути машиночитабельними (JSON) з обов'язковим полем trace_id для кореляції з трейсами та метриками.
3. Почати із «Golden Signals». Latency, Traffic, Errors, Saturation - чотири метрики, з яких варто стартувати. Налаштуйте SLO для критичних шляхів користувача.
4. Впровадити Tail-Based Sampling. Це дозволить бачити всі помилки без необхідності платити за зберігання зайвої інформації.
5. Розвивати культуру «Debugging in Production». Навчіть розробників використовувати трейси для діагностики, а не покладатися виключно на локальне відтворення багів.

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