Observability Stack: метрики, логи, трейси з кореляцією

Observability stack: чому метрики, логи й трейси розходяться

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

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

Типовий розрив кореляції метрик і логів починається з часу. Метрика зберігає момент вимірювання, запис у лозі — момент обробки на конкретному вузлі, трейс — початок і кінець операції.

За різниці часових поясів і затримки доставки події одного й того самого запиту розходяться за шкалою на хвилини. Ідентифікатор запиту в трасуванні й у лозі генерують різні бібліотеки, тому зіставлення йде за збігом сервісу та інтервалу — тобто приблизно.

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

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

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

Що дає єдиний observability stack: ефект у цифрах

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

Зводимо три сигнали в єдиний observability stack: інструментуємо сервіси через OpenTelemetry, щоб ідентифікатор запиту наскрізно проходив через метрику, лог і трейс.

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

Що змінюється вимірювано:

• Час локалізації причини збою — з 40–60 хвилин ручного зіставлення до 5–10 хвилин за готовою карткою інциденту.
• Частка збоїв, що розбираються без переходів між системами, — з 30 до 85%: контекст уже зібрано в одному місці.
• Повторні заходи в той самий інцидент скорочуються втричі — питання «покажи логи» відпадають.
• Простій на фазі «незрозуміло, де шукати» перестає бути основною його частиною, а діагностика стає коротким етапом розбору.

Варіанти розгортання: власні сервери, керований, гібрид

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

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

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

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

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

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

Етапи впровадження: аудит потоків, схема, налаштування, передача

Впровадження контуру спостережуваності йде від інвентаризації до передачі: кожен ступінь спирається на дані попередньої.

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

1. Аудит джерел телеметрії. Збираємо перелік сервісів, баз, брокерів і зовнішніх залежностей: хто вже віддає метрики, де логи лежать файлами, хто не інструментований взагалі. Тут же фіксуємо обсяг потоку — він визначає потужність сховища.
2. Схема збору та зберігання. Вирішуємо, де дані буферизуються під час піків, що йде в гаряче зберігання, а що в архів, які терміни зберігання закривають розбір інцидентів. Рахуємо зростання обсягу заздалегідь, щоб сховище не скінчилося на третій місяць.
3. Розмітка сервісів і запитів. Вводимо єдині мітки: сервіс, середовище, версія збірки, ідентифікатор запиту. Саме вони потім склеюють метрику, лог і трейс в одну картину інциденту.
4. Налаштування збору, панелей і оповіщень. Підключаємо агентів, проріджуємо високочастотні метрики, збираємо панелі за ключовими шляхами та правила оповіщень за значущими показниками, а не за кожним сплеском.
5. Перевірка на навчальній аварії. Ламаємо сервіс у погодженому вікні: чи надійшло оповіщення, чи знайшовся за ідентифікатором запиту весь ланцюжок, чи вклалося виявлення в цільовий час.
6. Передача контуру експлуатації. Черговій команді — регламенти, чек-лісти, розбір навчальної аварії та навчання; залишаємося на зв'язку, поки чергування не вийдуть на штатний режим.

Що залишається у вас: конфігурації, панелі, регламенти

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

Усе лежить у вашому репозиторії: конфігурації, панелі та регламенти версіонуються, проходять рев'ю і відкочуються як звичайний код.

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

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

Передача відбувається не текою файлів, а робочим контуром — розбираємо з вашими інженерами типові задачі: підключити сервіс, знизити шум, знайти причину за одним ідентифікатором запиту.

Кейс: скоротили час пошуку причини збою в рази

Платформа замовника утримувала потік замовлень, а спостереження було розподілено між трьома контурами: метрики жили в одному вікні, логи — у другому, трейси збирав окремий агент.

Ідентифікатор запиту ніде не збігався, тому черговий відновлював шлях запиту вручну — за часом і за збігом тексту помилки. На розбір однієї скарги витрачалося до сорока хвилин, і приблизно в половині випадків причину так і не підтверджували даними.

Звели три контури в єдиний шар спостереження на Grafana: одна точка входу для чергового, наскрізний ідентифікатор запиту в метриках, логах і трейсах, спільні ярлики сервісу та середовища.

Алерти перевели з окремих піків на правила за часткою помилок за вікно — зник клас хибних спрацьовувань на коротких сплесках, які будили чергового вночі.

Метрики до та після

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

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

Що робити, якщо частина сервісів уже пише в інше сховище

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

Проміжний шар стає між сервісами та сховищем: на хості або в середовищі контейнера змінюється адреса приймання, застосунок про це не знає.

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

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

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

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

Технічні сумніви: зберігання, навантаження, доступи

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

Чи не почне збір гальмувати робочі сервіси? Агент збору буферизує записи локально й надсилає їх пакетами, а не по одному. Споживання процесора та пам’яті обмежено зверху, у разі недоступності вузла збору дані лягають на диск і досилаються пізніше.

На критичних сервісах вмикаємо вибірковий збір — накладні витрати залишаються в межах кількох відсотків.

Як розмежувати доступ до логів? Доступ видаємо ролями за джерелами, сервісами й середовищами, а не «до всього сховища». Чутливі поля маскуються на вході, і їх не бачить навіть той, хто має доступ до самого логу. Звернення до даних фіксуються в журналі аудиту.

Що буде, якщо вузол збору впаде? Вузли збору запускаються в кількох копіях за балансувальником: вихід одного не перериває потік, трафік перерозподіляється.

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

Обговоримо ваше завдання: з чого почнемо і що уточнимо

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

Перелік вхідних даних, яких зазвичай достатньо для розрахунку:

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

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

Опишіть завдання своїми словами — відповість інженер, який поведе проєкт, і повернемося з оцінкою та планом.