Log-based Metrics: мониторинг ошибок и latency в реальном времени

Почему 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 почти всегда сводятся к четырём вещам: не взорвёт ли разметка хранилище метрик, не утонет ли дежурный в алертах, что будет с событиями при обрыве связи и сколько всё это придётся хранить. Отвечаем по каждому пункту так, как решаем это на реальных контурах.

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

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

Что происходит с событиями при обрыве связи с коллектором?

Агент буферизует поток на диск и отдаёт его после восстановления, поэтому короткие сетевые провалы данные не теряют. Метрики из логов считаются устойчивыми к повторной доставке: дубликат события не удваивает счётчик. Для критичных путей добавляем контроль по расхождению между числом запросов в приложении и числом разобранных событий.

Логи придётся хранить вечно?

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

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

Обычно нет. Мы подключаемся к существующему сборщику логов и добавляем правила разбора поверх текущего формата, а дашборды и алерты переносим постепенно. Старые метрики продолжают работать, пока новые не подтвердят совпадение на исторических данных.

Обсудим задачу: что прислать для оценки и плана

Чтобы вернуться с оценкой работ и планом внедрения, а не с общими словами, нам нужен минимум вводных по вашей инфраструктуре. Чем конкретнее вход, тем меньше допущений придётся снимать на этапе настройки и приёмки.

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

В ответ присылаем оценку работ по этапам, план внедрения с порядком подключения источников и точками контроля, а также состав правил извлечения метрик и оповещений. Отдельным пунктом идёт передача документации: описания панелей, логика разбора сообщений, инструкции для дежурной смены и порядок изменения правил без нас. Опишите задачу в свободной форме — вернёмся с оценкой и планом.