Предисловие

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

• Тысячи алертов сыпятся в чаты, которые никто не читает;

• Постоянно создаются десятки разрозненных дашбордов, половина из которых устарела, а половина задезайнена так, что разобраться способен только их создатель;

• А если происходит сбой, то для выявления причины зачастую приходится собирать консилиум из DBA, сетивиков и инженеров всех смежных команд.

Ладно, возможно масштаб проблем немного преувеличен... Тем не менее многие согласятся, что это проблемы как минимум существуют. Эта статья повествует о попытке решить эти проблемы и попытаться выстроить новый подход к мониторингу на основе AI и ML.

Контекст

Для придания всей истории большего драматизма представим, что объектом повествования является небольшой стратап Pretix, который занимается продажей билетов на концерты и другие мероприятия. У стартапа есть небольшой сайт - про его развертывание, генерацию пользовательского трафика и симуляцию сбоев можно почитать в моей прошлой статье.

Итак, сайт был успешно разработан и развернут - всей поддержкой с этого момента занимается старший инженер Павел Глэр. Он хорошо знает систему, но сутками дежурить он не готов, поэтому в подмогу ему назначен стажер Федор.

Выстраиваем мониторинг

Как и любой современный сайт, Pretix состоит из множества инфраструктурных компонент: БД, виртуальные машины, кэширующий сервис. К счастью, Павел настроил экспорт метрик из всех этих компонент, подключил типовые дашборды из библиотеки Grafana и даже накидал кастомный дашборд для сайта с количеством ошибок, задержкой обработки запросов и визуализацией остальных метрик, которые ему предоставили разработчики
По итогу, на руках было несколько детальных дашбордов со всевозможными панелями, которые позволили бы обнаружить любую причину сбоя - от утечки соединений к БД до недостатка сетевой проходимости. Тем не менее, Федор на своем дежурстве, столкнувшись с полной недоступностью сайта в 4 утра, был вынужен будить своего наставника, так как даже оставленные ему ранбуки не позволили локализировать проблему и понять, что дело было в DDoS атаке местных студентов с факультета ИБ.

На следующий день волевым решением Павла было запустить "Проект Жар-птица", в рамках которого планировалось подключать искусственный интеллект, так как естественным Федор, по мнению Павла, не обладал. Задачи, которые должны были быть переложены на плечи машины, были:

• Анализ всех доступных метрик и поиск аномалий;

• Ранжирование аномалий во время сбоя;

• Генерация человекочитаемых гипотез возникновения сбоя.

Поиск аномалий в метриках

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

Уверенный в себе Федор сразу предложил определить пороги, в рамках которых метрики бы считались нормальными, а при нарушении этих порогов - аномальными. К сожалению, мир не так прост, объяснил ему Павел: "Такой подход хорошо работает, например, для определения допустимого процента ошибок, но большая часть наших метрик подверженна сезонности - у нас бывают праздники и распродажи, в течении которых нагрузка повышена, а регулярный дневной рост поьзовательской активности так легко спутать с DDoS атакой".

Вместо изначальной идеи было решено внедрить модель для предсказания временных рядов (т.е. метрик) - Prophet, которая на основе исторических данных о каждой метрике генерировала предсказание о поведении этой метрики в будущем. На картинке ниже можно увидеть как модель научилась предсказывать кол-во запросов к сайту (красная линия).

Если предсказание расходилось с реальными значениями метрики на данный момент, то метрика распазнавалась как аномальная, но, чтобы исключить выбросы, было решено считать метрику аномальной, только есть 9 из 10 последовательных значений не соответствовали предсказанию. Для примера можно посмотреть на график метрики занятых соединений к БД, который в какой-то момент начал сильно расти, из-за чего и был помечен как аномальный.

Ранжирование аномалий

После внедрения модели во время очередного сбоя обнаружилось, что список выявленных аномалий больше напоминал Великую Книгу Обид из вселенной Вархаммер - сотни аномалий и ноль полезной информации. Тем не менее было обнаружено, что большая часть найденных метрик просто напросто плохо поддается предсказанию. Чтобы не обращать внимания на такие метрики, список аномалий был отсортирован по частоте: аномальные метрики, которые были выявлены впервые отмечались как самые важные, а те, которые "стреляют" постоянно даже не входили в финальный отчет.

Таким образом, дежурному инженеру во время сбоя можно было предоставить список из первых 10-15 метрик, на которые нужно обратить внимание. Например, если приложение бы начало вдруг занимать все свободные соединения к БД, то модель бы сразу обнаружила, что метрика, отображающая, кол-во занятых соединений неожиданно превысила бы свои ожидаемые показатели.

Генерация гипотез

Во время еще одного сбоя Федор получил отчет о том, что pg_stat_activity_count принял аномально большие значения. Эта информация не дала ему ничего, поэтому ему сново пришлось будить Павла, чтобы тот посмотрел, что значит эта метрика и самостоятельно определил причину сбоя.

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

На тот момент у него на руках уже была модель, которая была способна выдавать аномальные метрики, на которые стоило бы обратить внимание. Оставалось лишь сгенерировать промпт. К счастью, формат метрик OpenMetrics, который повсеместно используется, содержит одну интересную фичу, на которую обычно никто не обращает внимание. Большинство метрик, которые экспортируются в этом формате, содержат описание, в котором очень кратко раскрывается их суть.
Используя эти описания, Павел настроил автоматическую генерацию промтов в LLM, которая выглядела примерно так:

I have an app that is used
to create events and
sell tickets to them. There is a frontend written in javascript and a backend written in python. 
The app runs on a virtual machine. 
There is also a Postgres database that is used by
the app.
I gathered metrics and analyzed them. 
We found anomalies with the following metrics: 
{metric-name}: {metric-description}
Considering the metrics described above give
me a list of 11 reasons what could go wrong 
with the system. This includes problems with 
the app, virtual machine, database, network 
or some other infrastructure component, VM 
admin's action or some outside factors that
  could influence the application's performance.

В ответ на промпт LLM генерировала возможные причины сбоя.

Завершение

В конце концов, автоматика для реагирования на сбои умела самостоятельно генреровать гипотезы о причинах сбоев и локализировать проблему, находя метрики, на которые нужно было посмотреть. Такой пайплайн позволял не тратить время на поиск аномалий глазами, пролистывая десятки дашбордов; больше не приходилось читать сотни алертов а каналах, а потребность в доменных знаниях о всех компонентах системы сильно снизилась.

P.S. Очевидно, что в реальном мире все не так просто и проблемы, описанные в статье нельзя решить банальным внедрением искуственного интелекта. Тем не менее, этот эксперимент по анализу метрик с помощью ML (в рамках дипломной работы) демонстрирует, что ML и AI действительно могут быть использованы для улучшения процессов работы SRE как в маленьких компаниях, так и в больших корпорациях. Выражаясь более техническим языком, подобные инструменты потенциально могут уменьшить MTTD (mean time to diagnose), ускоряя процесс локализации проблемы и генерации гипотез.