Как и зачем мы разработали систему анализа аномальных логов. Кейс MWS

Меня зовут Андрей Басов, я руководитель команды технической поддержки стрима корпоративных продуктов и сервисов в MWS. Вместе со своими коллегами — Тимуром Хабибулиным (data scientist) и Рафисом Ганеевым (senior devops engineer) — занимаюсь технической поддержкой и сопровождением продуктов линейки Partner Experience Platform.

Чтобы улучшить качество наших сервисов, через которые МТС взаимодействует с партнерами, мы вынуждены постоянно внедрять новые решения, растить продукты и развивать их архитектуру, при этом нам важно обеспечивать надежность и стабильность работы ИТ-систем. Это не всегда дается легко, ведь объемы данных растут, и их нужно эффективно обрабатывать. Одной из основных проблем становится анализ логов — текстовых записей. В нашем случае они фиксируют события в работе систем, которые созданы за 25+ лет работы компании, а еще у них различные стеки и архитектурные подходы. 

Объемы данных настолько велики, что проанализировать вручную (например, в OpenSearch/Kibana) даже один продукт практически невозможно, иначе нам пришлось бы просматривать миллионы строк логов каждый день. Поэтому мы решили разработать систему, которая позволила бы автоматически выявлять в логах аномалии — события, не свойственные нормальному функционированию системы. Например, это могут быть следы багов, вызванных новыми релизами, или другие непредвиденные происшествия. Что из этого вышло — расскажу дальше. 

Содержание

• Масштаб проблемы ^[1]

• Традиционные решения — всё? ^[2]

• Автоматизация анализа логов с помощью методов машинного обучения ^[3]

• Архитектура ^[4]

• Выбор технологий ^[5]

• Ключ к стабильной работе системы: постепенное итеративное внедрение ^[6]

• Эффект от внедрения ^[7]

• Во всем виновата команда ^[8]

Масштаб проблемы

Современные ИТ-системы, особенно в крупных компаниях, таких как МТС, состоят из множества микросервисов, каждый из которых генерирует огромное количество логов. Это текстовые записи событий, происходящих внутри системы, — от запросов пользователей до внутренних операций программного обеспечения. Но из-за огромного объема их мониторинг становится настоящей головной болью ^[9] для команд поддержки и разработчиков.

Представьте ситуацию: вы выкатываете новый релиз или хотфикс. Все тесты проходят успешно, но через несколько часов или даже утром, после ночного деплоя, на вас обрушиваются жалобы от клиентов или других ИТ-систем компании, срабатывают точки и средства мониторинга. Регистрируют массовый инцидент и аварии. Что произошло? Возможно, в логах уже есть запись о критической ошибке ^[10], которая вызвала проблему? Если в компании развернуты основные инструменты наблюдаемости, такие как Jaeger, OpenSearch/Kibana, Grafana, есть шансы быстро понять, найти и устранить причину. Но если нет — придется искать эти иголки в стогах сена самостоятельно.

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

К тому же все логи содержат шум — повторяющиеся стандартные записи, которые не несут полезной информации, но занимают место и отвлекают внимание ^[11] инженера или разработчика, ведь таких записей большинство. Получается, любая новая аномалия — будь то след бага или просто результат добавления новой функциональности, обновления системы или проблемы на уровне сети — может остаться незамеченной среди моря обычных сообщений. Но чтобы обеспечить надежную работу, нужно уметь вовремя замечать, анализировать и различать нестандартное поведение ^[12] систем.

Традиционные решения — всё? 

Раньше для анализа логов использовались методы, основанные на статических правилах. Можно было настроить систему мониторинга, которая фиксирует только конкретные типы сообщений — например, ошибки с определенным кодом или по определенному процессу. Но такой подход плохо справляется с неожиданными проблемами. Такие ошибки заточены только на конкретные exceptions и уровни логирования error, которые заранее и при хорошей организации obs продукта отражены на дашбордах Grafana в виде различных плашек мониторинга критичных процессов. Но баги, вызванные уникальными комбинациями условий или взаимодействием разных компонентов системы, часто остаются за пределами заданных правил.

Кроме того, современные системы постоянно эволюционируют, появляются новые потребители как внутри компаний, так и извне. Новые функции, изменения в архитектуре или масштабирование могут привести к появлению новых типов логов, которые не были предусмотрены при создании правил. Это делает традиционные методы анализа недостаточно гибкими и эффективными.

Почему современные инструменты не гарантируют решения всех требуемых задач наблюдаемости

Мы занимаемся поддержкой продуктов линейки Partner Experience Platform — это платформа для цифрового взаимодействия с партнерами. Она представляет собой крупную и сложную ИТ-систему с десятками микросервисов. Мы используем средства наблюдаемости нашей внутренней платформы мониторинга ^[13] и смотрим предложения на рынке.  И все же мы до сих пор не нашли подходящего нам решения для анализа логов с акцентом на поиск аномалий. 

Без такого инструмента команды поддержки и разработки были вынуждены полагаться:

• на ручной анализ огромных объемов данных;

• специальные запросы к хранилищам логов (например, OpenSearch) для фильтрации ключевых событий;

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

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

Автоматизация анализа логов с помощью методов машинного обучения

Основная идея заключалась в том, чтобы:

• выделить среди «нормальных» логов аномальные, то есть те, которые могут указывать на наличие багов;

• иметь возможность находить похожие ошибки в прошлом;

• управлять процессом поиска аномалий в работе системы.

Тут важно отметить, что не все аномалии — это баги. Иногда новые функциональные возможности могут генерировать нетипичные записи, которые модель будет классифицировать как аномалию. Чтобы справиться с этим, мы дополнили систему фильтрами, порогами срабатывания мониторинга и визуализацией данных для ручного анализа.

Архитектура 

Наше решение для анализа логов представляет собой модульную архитектуру, которая базово состоит из четырех микросервисов: Detector (детектор), Retrain-clusterer (переобучение кластеризатора), DB-cleaner (очистка базы данных) и Stats-exporter (экспорт статистики). Каждый микросервис выполняет свою специализированную задачу, обеспечивая корректную работу системы в целом. Рассмотрим их подробнее.

Detector — ключевой микросервис, отвечающий за основной функциональность всей системы

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

1. Получение новых логов из OpenSearch.

2. Очистка текстового содержимого от шума (информации, не несущей полезной нагрузки и мешающей качественной кластеризации).

3. Векторизация логов с использованием bge-m3 — корпоративной модели генерации эмбеддингов.

4. Кластеризация полученных векторов актуальной версией HDBSCAN — модели иерархической кластеризации.

5. Выгрузка результатов в Qdrant.

Retrain-clusterer (переобучение кластеризатора) 

Этот микросервис поддерживает актуальность модели кластеризации. Он позволяет системе оперативно адаптироваться к изменениям в анализируемых сервисах. Для выполнения задачи реализован следующий алгоритм:

1. Получение всех векторов из Qdrant.

2. Обучение ^[14] модели HDBSCAN.

3. Выгрузка файла модели в S3.

4. Обновление меток кластеров в Qdrant.

DB-cleaner (очистка базы данных)

Этот микросервис, выполняя, казалось бы, простую задачу очистки, предотвращает переполнение векторной базы данных одинаковыми логами (что дает экономию ресурсов) и обеспечивает более быстрое и качественное обучение модели кластеризации (повышение точности детекции). 

Это достигается благодаря нетривиальному подходу: 

1. Получение всех логов кластера — очистка выполняется для каждого кластера отдельно.

2. Отбор наиболее разнообразных логов внутри кластера.

3. Удаление избыточных записей из Qdrant.

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

# Фрагмент кода микросервиса; Функция поиска разнообразных логов:
def get_useful_log_indexes(vectors: np.ndarray, max_logs_per_cluster: int) -> List[int]:
    # Считаем косинусное расстояние между векторами:
    distance_matrix = pairwise_distances(vectors, metric="cosine")
    # Добавляем в массив самый новый лог:
    indexes = [0]
    # Задаем начальный перцентиль допустимого расстояния:
    threshold_percentile = 95
    # Цикл, пока число выбранных меньше максимально допустимого:
    while len(indexes) < max_logs_per_cluster:
        # Получаем допустимое расстояние:
        threshold = np.percentile(distance_matrix, threshold_percentile)
        # Проход по всем векторам:
        for index in range(1, len(vectors)):
            # Если уже выбрали этот вектор, то пропускаем итерацию:
            if index in indexes:
                continue
            # Получаем расстояния до тех векторов, которые уже выбрали:
            distance_to_unique = distance_matrix[index][indexes]
            # Берем минимальное расстояние:
            min_distance = min(distance_to_unique)
            # Если минимальное больше порога:
            if min_distance >= threshold:
                # Добавляем в выбранные:
                indexes.append(index)
                # Если набрали максимально допустимое число выбранных:
                if len(indexes) >= max_logs_per_cluster:
                    # Выходим из цикла:
                    break
        # Уменьшаем перцентиль порога:
        threshold_percentile -= 5
    # Возвращаем выбранные:
    return indexes

Stats-exporter (экспорт статистики) — микросервис, который передает результаты детекции в системы мониторинга. Отдает Prometheus-метрику VictoriaMetricsAgent`у и выгружает аномальные логи в Logstash.

Выбор технологий

Дальше расскажу, на какие технологии мы опирались, чтобы реализовать наше решение. Нам было важно, чтобы система была эффективной и масштабируемой. 

HDBSCAN — кластеризация без предопределенных параметров

Этот алгоритм мы выбрали:

• за адаптивность: не требует заранее задавать количество кластеров;

• способность  эффективно выделять шум (аномальные логи) в данных;

• применимость «из коробки»: не требует поиска оптимальных гиперпараметров;

• гибкость: алгоритм может обрабатывать данные сложной формы.

HDBSCAN позволил нам разделить нормальные логи на кластеры и выделить записи, которые отличаются от нормального поведения ^[15] системы.

bge-m3 — эффективная векторизация текста

У МТС есть собственная платформа MWS GPT ^[16], через которую можно работать с множеством разных моделей. Для векторизации текстов мы выбрали модель bge-m3, которая демонстрирует оптимальное сочетание высокой точности и производительности при обработке больших объемов данных.

bge-m3 представляет собой современную модель эмбеддингов, значительно превосходящую классические подходы, такие как Bag-of-Words (BoW) и TF-IDF. Ее ключевое преимущество заключается в способности эффективно преобразовывать текстовые записи логов в семантически насыщенные числовые векторы, что упрощает последующий анализ с применением алгоритмов машинного обучения.

Docker — унифицированное окружение

Docker обеспечивает удобство развертывания и минимизацию проблем с совместимостью зависимостей:

• изолированные окружения,

• унификация сред,

• легкость деплоя.

GitLab CI/CD/ ArgoCD — автоматизация процессов

GitLab CI/CD в интеграции с ArgoCD позволяет нам быстро доставлять изменения в продуктивную среду и контролировать качество кода. Так мы сокращаем время релизов, отслеживаем изменения и видим метрики качества.

OpenSearch — источник логов

OpenSearch используется для первичного хранения логов и быстрого поиска по ним:

• предоставляет удобный интерфейс для фильтрации данных;

• хранит логи логов перед их обработкой системой анализа.

Для нашего сервиса извлекаются следующие поля:

• _id — на его основе создается UUID для Qdrant, также позволяет при необходимости обратиться к исходному логу в дашборде-источнике;

• message — текстовое содержимое лога, которое векторизуется в микросервисе Detector;

• logDate — временная метка записи лога для отслеживания хронологии событий.

OpenSearch — хранение аномальных логов

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

• serviceName — название анализируемого микросервиса;

• serviceID — идентификатор анализируемого сервиса;

• logDate — временная метка записи лога для отслеживания хронологии событий;

• qdrantID — идентификатор лога в Qdrant;

• srcOpenSearchID — идентификатор лога в OpenSearch-источнике;

• message — текстовое содержимое лога после очистки от шума регулярными выражениями.

Qdrant — векторная база данных

Qdrant предоставляет возможности для хранения и поиска векторизованных логов:

• быстро искать ближайших соседей,

• хранить большое количество данных.
   
  Qdrant позволяет нам эффективно хранить и анализировать числовые представления текстовых записей логов. Мы храним следующие поля:

• timestamp — logDate, преобразованный в timestamp-формат:

• log_id — идентификатор лога в OpenSearch-источнике:

• text — текстовое содержимое лога после очистки от шума регулярными выражениями:

• is_counted_for_stats — флаг, отображающий, был ли этот лог учтен микросервисом экспорта:

• cluster_id — метка кластера лога («–1», если лог распознан как аномальный.

S3 для хранения моделей

S3 обеспечивает надежное хранение моделей HDBSCAN для каждого микросервиса. У него высокая доступность и его относительно просто эксплуатировать.
 
Модели HDBSCAN в соответствии с конкретными стратегиями регулярно обновляются и сохраняется в S3 для дальнейшего использования.

Ключ к стабильной работе системы: постепенное итеративное внедрение 

Итак, мы разработали архитектуру и выбрали технологии. Следующим этапом стала реализация и внедрение нашего решения в инфраструктуру МТС. 

Мы написали код и затем 3–4 месяца внедряли, анализировали и оптимизировали различные компоненты системы, чтобы выстроить баланс между скоростью работы, точным определением аномалий и потребляемыми ресурсами.

Главными сложностями были:

1. Разрастание базы Qdrant по мере обучения и подключения новых анализируемых микросервисов.

2. Соответственно, рост моделей HDBSCAN.

3. Выделение из логов паттернов, которые мешают кластеризации и создают ненужный шум.

Внутри микросервисов мы настроили планировщик задач (Scheduler), который автоматически запускает каждый компонент системы с определенной периодичностью. Это позволяет системе регулярно анализировать новые данные и поддерживать актуальность модели кластеризации.

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

В итоге сервис полностью соответствует предъявляемым к нему требованиям: минимизирует шум, определяет аномальные логи и строит по ним дашборды в Grafana.

Эффект от внедрения

С нашей системой мы получили:

График в Grafana, по которому можно оперативно мониторить динамику аномалий

Он стал одним  из ключевых инструментов для работы с системой. По нему мы видим:

• визуализацию всплесков аномалий в виде графиков;

• исторический анализ количества аномалий;

• описания аномалий из OpenSearch.

Таким образом, можно реагировать ^[17] практически в режиме реального времени. Без этой информации мы не могли оперативно детектить новые и ранее не встречаемые ошибки. Как правило понимание о них приходило к нам в рамках анализа поступающих к нам инцидентов.

Удобный анализ аномалий 

Для просмотра самих аномальных логов мы создали специализированный OpenSearch Dashboard. В нем есть:

• фильтрация аномальных записей;

• поиск и группировка по различным параметрам;

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

Снижение нагрузки

Основным эффектом внедрения решения стало:

1. Сокращение объема данных для анализа и выявления проблем.

2. Возможность настраивать метрики по аномальным событиям.

3. Фокус только на значимые новые события.

4. Повышение отказоустойчивости систем и компонентов.

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

Во всем виновата команда

Разработка и внедрение нашего решения стало возможным благодаря слаженной работе междисциплинарной команды поддержки продукта:

1. Руководитель команды отвечал за архитектуру, постановку задачи, Python-разработку.

2. ML-/data-scientist-инженер отвечал за реализацию в с��здании микросервисов.

3. DevOps-инженер отвечал за cd/cd

   Так как данный инструмент создавался для технической поддержки и сопровождения поддерживаемых систем, то в процессе внедрения привлекались инженеры поддержки продукта, анализировались боли и сложности команд поддержки, оценивался их опыт ^[18] и пожелания. 

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

1. Data Science: выбор алгоритмов машинного обучения (HDBSCAN) и модели для векторизации текста (bge-m3).

2. DevOps: управление инфраструктурой (Docker), автоматизация процессов (GitLab CI/CD).

3. Python: написание кода микросервисов.

Каждый участник команды привнес свой уникальный опыт и навыки, что позволило нам создать эффективное решение для анализа логов.

В будущем планируем добавлять в нашу систему еще новых функций. Так, хотим внедрить генеративных llm для объяснения получаемых аномалий по информации из различных источников (Confluence, Jira, GitLab конкретных проектов).

 В следующих материала мы расскажем как отказаться от hdbscan, выстроить собственную систему кластеризации и внедрить Principal Component Analysis для понижения размерностей. 

Мы уверены, что такие инструменты могут и должны быть неотъемлемой частью современных ИТ-инфраструктур других компаний.