Log-based Metrics: моніторинг помилок і затримок у реальному часі

Чому log-based metrics розходяться з реальністю

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

Метрики, побудовані на логах (log-based metrics), успадковують усі дефекти вхідного потоку: якщо подію не описано структурно або відсіяно на етапі збору, вона не потрапить ні до лічильника, ні до графіка, ні до алерту.

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

Поки в події немає обов’язкових полів — сервісу, рівня, коду помилки, ідентифікатора запиту — лічильник відмов рахується за підрядком, і пропуск помилок у проді закладено в саму конструкцію.

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

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

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

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

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

Моніторинг помилок у реальному часі спирається на потік, а не на знімок, тому й тримає інцидент у полі зору з першої секунди.

Log-based metrics: вимірюваний ефект для експлуатації

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

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

Правило описує шаблон повідомлення або рівень логування, групування за кодом відповіді, ендпоінтом і версією релізу, вікно агрегації в 15–60 секунд.

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

Час до виявлення та відновлення

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

Відновлення прискорює зв’язка метрики із записами: перехід від графіка до логів конкретного вікна та версії релізу — один крок. Причина — просадка залежності, помилка конфігурації, відмова диска — видна за групуванням, а не перебором рядків.

Шум в алертах і ціна хибних спрацювань

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

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

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

Порівнюємо підходи: потокові лічильники, пакет і гібрид

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

Коли потоковий режим надлишковий

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

Що втрачається за пакетної агрегації

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

Як ми впроваджуємо моніторинг помилок і затримок

Будуємо log-based metrics від джерел: без повної інвентаризації схема збору дає сліпі зони, а цифри розходяться з реальністю. Далі збираємо потік подій, задаємо правила агрегації та перевіряємо все на живому навантаженні — лише після цього передаємо схему в експлуатацію.

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

Перевірка на піковому навантаженні

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

Обмеження та точки відмови схеми

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

Артефакти впровадження: конфігурації, схеми, регламенти

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

Передаємо на руки:

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

Політики доступу та ролі

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

Регламент чергувань та ескалації

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

Кейс: як ми прибрали шум і прискорили виявлення відмов

Вихідна точка та обмеження

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

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

Друга проблема — сирі логи писалися цілком, без розбору на поля, тому за ними не можна було ні групувати помилки за кодом і методом, ні будувати розподіли тривалості.

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

Що вийшло за метриками

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

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

Чим потокова обробка логів відрізняється від пакетної?

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

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

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

Стійкість до втрати подій теж різниться.

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

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

Обсяг зберігання різниться на порядок. Потокова схема зберігає лише агрегати за мітками — наприклад, Prometheus з рядами лічильників — і зростання обмежене кардинальністю міток.

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

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

Кардинальність, шум і втрати подій: часті сумніви

Сумніви щодо log-based metrics майже завжди зводяться до чотирьох речей: чи не вибухне розмітка сховище метрик, чи не потоне черговий в алертах, що буде з подіями за обриву зв’язку і скільки всього цього доведеться зберігати. Відповідаємо за кожним пунктом так, як вирішуємо це на реальних контурах.

Як прибрати шум алертів, не пропустивши реальну деградацію?

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

Що відбувається з подіями за обриву зв’язку з колектором?

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

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

Логи доведеться зберігати вічно?

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

Ми вже розгорнули моніторинг — доведеться все переробляти?

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

Обговоримо задачу: що надіслати для оцінки та плану

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

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

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

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