Аномалии и поиск причины

Не для всего можно заранее придумать порог. Сколько миллисекунд — это «медленно» для вашего API? Сколько заказов в час — «мало»? Наблюдатель отвечает на это сам. Для сервисов он выводит из истории цель — время ответа и долю ошибок — и уведомляет, когда сервис быстро выходит за неё. Для сервисов, потоков событий и метрик он замечает аномалии: заметные отклонения от обычного уровня.

Когда сервис начинает тормозить или ошибаться, Наблюдатель сразу ищет причину. Он проходит по зависимостям сервиса и пишет в уведомление вероятную причину сбоя, например «база db — проверка здоровья не проходит с 12:46», и цепочку от симптома к ней.

#Цель сервиса: главное уведомление о сервисах

Правило «Цель сервиса нарушена» включено в каждом проекте. Оно работает по трассам, поэтому нужна подключённая трассировка.

У каждого сервиса есть цель из двух частей:

• время ответа — p95 за минуту не выше заданного числа миллисекунд;
• ошибки — доля ошибок не выше заданного процента.

Минута, когда сервис вышел за цель, считается плохой. Запас — 1 % плохих минут за 30 дней.

Откуда берётся цель. Наблюдатель выводит её из истории сервиса сам и пересчитывает раз в сутки. Для времени ответа берётся обычный худший уровень p95 с запасом в полтора раза, но не меньше 250 мс. Для ошибок — втрое выше обычной доли, но не меньше 0,5 %. Цель появляется, когда у сервиса наберутся сутки истории запросов.

Когда приходит уведомление. Не на каждый всплеск, а только когда запас сгорает быстро — по методу Google SRE:

Короткий всплеск не проходит длинное окно и не будит. Долгое тихое ухудшение ловится медленным окном. Когда сервис возвращается в цель и в длинном окне, приходит «Сервис снова в цели».

#Как посмотреть и поменять цель

Цель видна на странице сервиса, в карточке «Цель сервиса»: «p95 минуты ≤ … · ошибок ≤ …» и откуда она взялась — «выведена из истории» или «своя». Там же по строкам «Сутки» и «Неделя» видно, сколько минут сервис был в цели и сколько осталось запаса. Если запас сейчас сгорает, карточка это покажет, иначе — «Сейчас в цели.»

Чтобы задать свою цель, нажмите «Изменить» (или «Задать», если цели ещё нет), заполните «p95 минуты, мс» и «ошибок не больше, %» и нажмите «Сохранить». Вернуться к цели из истории — «Вернуть автоматическую».

Совет. Если о каком-то сервисе приходят лишние уведомления, поднимите его цель, а не выключайте правило: иначе вы не узнаете и о настоящей деградации.

Правило находится в разделе «Управление» → «Правила», в группе «Сервисы (по трассам)», с условием «Цель сервиса (SLO)». Его можно сузить до одного сервиса или выключить.

#Аномалии сервисов

Правило «Аномалия сервиса» тоже включено в каждом проекте, но работает для ленты событий и поиска причины, а не для уведомлений. У него уровень «Инфо», поэтому в Telegram и на почту аномалии сервисов по умолчанию не приходят. Они видны в ленте событий стека и на странице сервиса и служат уликами при расследовании.

Каждые 10 минут Наблюдатель берёт последние 10 минут работы каждого сервиса и сравнивает их с тем, как сервис работал последние 6 часов. Проверяются три сигнала:

Рост p95 с 25 до 59 мс — обычный разброс, пользователь его не заметит. Поэтому нужен и рост в полтора раза, и прибавка не меньше 100 мс. Тихие сервисы с парой запросов не оцениваются. Кроме того, порог для каждого сервиса раз в сутки подбирается сам: самый строгий, при котором на прошлых сутках было не больше двух эпизодов аномалии. Нужно около 2 часов истории: пока её нет, сервис не оценивается.

Примеры событий:

• «Сервис api отвечает медленнее обычного: p95 1,2 с, обычно ~180 мс»;
• «Сервис payments: ошибок больше обычного — …, обычно ~…»;
• «Сервис api: запросов заметно меньше обычного — … за 10 минут, обычно ~…».

Когда сервис приходит в норму, пишется событие «Сервис вернулся к норме».

#Как настроить аномалии сервиса

Правило «Аномалия сервиса» находится в разделе «Управление» → «Правила», в группе «Сервисы (по трассам)». В нём можно:

• выбрать «Чувствительность»: «Низкая — меньше алертов», «Обычная» или «Высокая — реагировать раньше»;
• указать один сервис из трасс — пусто значит все сервисы;
• поменять «Уровень в ленте» — например, на «Предупреждение», если аномалии всё-таки нужны в канале;
• выключить правило.

Во всех проектах, включая созданные раньше, правило «Цель сервиса нарушена» добавлено само, а у правила «Аномалия сервиса» уровень «Предупреждение» сменился на «Инфо».

#Аномалии потоков событий и метрик

Потоки событий и логов. Когда приложение впервые присылает новый поток, например журнал запросов или платежей, для него само создаётся правило аномалии. Оно ловит, что записей стало заметно больше или меньше обычного. Сравнивается последний завершённый 10-минутный интервал с 6 часами истории. В правиле можно выбрать числовое поле потока, например длительность запроса, — тогда отслеживается его значение, а не количество записей. Подробнее — в статье события и логи приложения.

Метрики приложения. Для метрики можно создать правило с условием «Аномалия (авто)». Наблюдатель сравнивает последние 10 минут с обычным уровнем за 6 часов: для обычной метрики — среднее значение, для счётчика — прирост. Порог не нужен. Правило начинает работать, когда накопится около 2 часов истории. Для метрик, которые обычно стоят на нуле, аномалия не подходит — используйте порог. Подробнее — в статье метрики приложения.

Чувствительность у этих правил та же: низкая, обычная или высокая.

#Правило «5 раз за сутки — это норма»

Некоторые аномалии повторяются по расписанию: ночная выгрузка, пик в обед, кэш, который прогревается каждые пару часов. Чтобы такие события не превращались в шум, действует общее правило для аномалий сервисов, потоков и метрик:

• если одна и та же аномалия за сутки началась в пятый раз, уведомление об этом предупредит: «Повторяется 5-й раз за сутки — дальше считаем это обычным поведением и не уведомляем, пока аномалия не станет реже»;
• следующие уведомления по ней не приходят;
• когда аномалия станет реже, уведомления вернутся сами.

#Причина сбоя прямо в уведомлении

Когда нарушается цель сервиса, начинается аномалия сервиса или падает проверка сайта, Наблюдатель сразу запускает расследование. Для проверки сайта это работает, если известно, какой сервис принимает её запросы. Порядок такой:

1. Берёт сервис-симптом и идёт вниз по его зависимостям: сервисы, которые он вызывает, базы данных, внешние адреса, их контейнеры, диски под данными и серверы. Учитываются и сервисы без трассировки, которые видны только по сетевым соединениям, — например, база, к которой сервисы ходят напрямую.
2. Собирает улики за последний час: замедления и ошибки сервисов, в том числе запросов к базе со стороны сервиса, выкатки, падения, OOM, проблемы со здоровьем и перезапуски контейнеров, диск, заполненный на 90 % и больше, OOM и перезагрузки серверов, ответы с ошибкой 5xx из журналов запросов сервиса — если записи потока содержат trace_id.
3. Выбирает самую вероятную цепочку от симптома к причине.

В уведомлении появляется блок «🔎 Причина». Упрощённый пример:

🔎 Причина
Вероятная причина: база db — проверка здоровья не проходит с 12:46
Цепочка: api ← orders ← db
Заденет: gateway, web

• «Вероятная причина» — улика ниже симптома, которая объясняет его лучше всего.
• «Цепочка» — путь от симптома к причине.
• «Заденет» — сервисы, которые вызывают пострадавший и пострадают следом.

Если причина не нашлась, так и будет написано: «Причину по имеющимся данным не нашли: зависимости сервиса, их контейнеры и серверы в норме». Рядом — чего Наблюдатель не видит, например что у базы нет метрик и неизвестно, что происходит у неё внутри. Закрыть такие пробелы помогает карта проекта и слепые зоны.

Иногда причина проявляется позже симптома: база начинает отдавать ошибки через минуту после того, как сервис стал медленным. Тогда Наблюдатель допишет её в то же событие в ленте, без повторного уведомления.

Важно. Причина — это гипотеза по данным, а не приговор. Чем больше системы видит Наблюдатель — трассы всех сервисов, метрики баз, серверы под стеками, — тем точнее расследование.

#Причина в ленте событий

В ленте событий стека аномалия сервиса показывается эпизодом: начало, восстановление, длительность. Под ним — строка «Причина: …» и, если есть, «Цепочка: …». Ссылка «Улики и путь на карте →» открывает страницу сервиса с расследованием на момент начала аномалии. Подробнее о ленте — в статье события и инциденты.

#Кнопка «Проверить сейчас» на странице сервиса

На странице сервиса видно время ответа и операции сервиса, кто его вызывает и кого вызывает он, его контейнеры и серверы и события за сутки. Открыть её можно так: вкладка «Трассировка» стека → выберите сервис → «Страница сервиса →».

Если у сервиса идёт аномалия или вы пришли по ссылке из события, расследование запускается само. Если уведомления не было, а вам кажется, что сервис ведёт себя странно, нажмите «Проверить сейчас».

Блок «Расследование» показывает:

• период, за который собраны улики, и их число;
• цепочку от «симптом» до «вероятная причина» с уликой на каждом звене: аномалия, выкатка, падение, OOM, перезапуски, диск, ошибки;
• «Другие версии» — менее вероятные цепочки;
• «Все улики» — полный список со ссылками «открыть»;
• «Заденет тех, кто вызывает …» — кого затронет сбой;
• чего не видно: например, у базы нет метрик или стек не связан с сервером.

Путь причины подсвечивается на карте сервисов на этой же странице, остальное приглушается. Подробнее о карте — в статье карта сервисов.

#Разбор сбоя с ИИ-ассистентом

ИИ-ассистент видит причину в событии и может перепроверить её сам: пройти по зависимостям сервиса, посмотреть операции, выкатки и трассы. Спросите: «Почему api тормозил в 12:50?» Подробнее — в статье примеры запросов к ИИ-ассистенту.

#Что дальше

• Правила уведомлений — пороги и типовые правила проекта.
• Трассировка — без неё аномалии сервисов и поиск причины не работают.
• Карта проекта и слепые зоны — что ещё подключить, чтобы причина находилась точнее.
• Уведомления в Telegram, MAX и на почту — куда приходят уведомления о сервисах.