AIOps использует логи как источник фактов о сбое, чтобы связывать текущие события с уже известными инцидентами. Если описания алертов и инцидентов отличаются по словам, сходство по логам часто остается заметным и помогает быстрее найти связанный случай из истории.
Содержание статьи
Почему логи важны для поиска похожих инцидентов
Логи важны потому, что они фиксируют симптомы сбоя на уровне сервисов, приложений и инфраструктуры. По ним можно сопоставлять события даже тогда, когда текстовые описания написаны по-разному или слишком общо.
В управлении инцидентами есть старая проблема. Оповещение создается машиной. Карточка инцидента часто заполняется человеком. Один источник пишет про перегрузку базы данных, другой — про недоступную панель или задержку обработки. Слова разные, а причина может быть общей.
Есть и обратная ситуация. Два события имеют почти одинаковый текст, но вызываются разными сбоями. По одному описанию здесь легко ошибиться. Логи дают более предметный слой данных: какие сервисы участвовали, какие ошибки появились, в какой момент и в каком окружении.
Какие термины нужны для темы
Событие, алерт, инцидент и лог — это разные сущности, и путать их нельзя. От этого зависит, как строится корреляция в AIOps.
- Событие — факт заметного изменения в системе. Это может быть перенос контейнера на другой узел, выкладка новой версии приложения, изменение таблицы базы данных, нехватка памяти или процессорного времени.
- Алерт — запись о событии, которая указывает на проблемное состояние и требует внимания. Примеры: отказ диска, падение сетевого канала, исчерпание ресурсов.
- Инцидент — снижение качества работы сервиса или приложения, вызванное одним или несколькими алертами. Пример: недоступность приложения или хранилища.
- Лог — строка или набор строк, созданных компонентами системы. В логах обычно есть время, источник, тип операции, детали ошибки и данные о затронутом ресурсе.
Как логи помогают определить сходство событий
Ключевая идея проста: если у двух событий похожий набор ошибочных логов, эти события, скорее всего, связаны. Сходство текста здесь вторично.
Современное приложение обычно состоит из нескольких микросервисов. Они зависят друг от друга и образуют связанный граф. Сбой в одном сервисе часто вызывает ошибки в соседних участках цепочки: выше по потоку запросов, ниже по потоку или сразу в нескольких точках.
Из-за этого при анализе мало взять один лог-файл и найти в нем слово error. Нужно собрать все строки, которые относятся к моменту сбоя, а затем отделить действительно ошибочные записи от фонового шума. Без этого модель сравнения получает слишком много лишних данных.
Какой временной интервал обычно берут
Для события можно собрать логи из окна вокруг времени начала сбоя, например за 5 минут до и 5 минут после. Такой интервал дает контекст до инцидента и сразу после него.
Этот подход полезен по двум причинам. Во-первых, в логи попадают первые признаки проблемы. Во-вторых, видна реакция зависимых сервисов, которые начали фиксировать вторичные ошибки уже после первичного отказа.
Зачем нужен классификатор ошибок
Классификатор помогает разделить лог-строки на ошибочные и неошибочные. После этого в анализ сходства попадают только записи, которые действительно описывают сбойное поведение.
В базовой схеме каждая строка логов подается в предварительно обученную модель. На выходе модель относит строку к ошибке или к нормальному состоянию системы. Это нужно, чтобы не смешивать полезные сигналы со штатными техническими сообщениями.
Что такое сигнатура логов события
Сигнатура логов — это нормализованное представление события на основе шаблонов логов и идентификаторов приложений. Она нужна, чтобы сравнивать события не по сырым строкам, а по устойчивым признакам.
Сырые логи плохо подходят для прямого сопоставления. В них много переменных значений: время, идентификаторы запросов, адреса, номера сессий, имена узлов. Если сравнивать такие строки как есть, однотипные ошибки будут выглядеть разными.
Поэтому лог-строки сначала приводят к шаблонам. Условно говоря, из сообщения убирают изменяемые части и получают общий образец. Этот образец получает свой идентификатор шаблона. После этого для события можно хранить уже не сами строки, а набор пар: какой шаблон встретился и в каком приложении или сервисе он был зафиксирован.
Из чего состоит сигнатура
Сигнатура обычно включает два элемента: идентификатор приложения и идентификатор шаблона лога. Вместе они показывают, какая ошибка и в каком компоненте проявилась.
| Элемент | Что означает | Зачем нужен |
| Идентификатор приложения | Сервис, компонент или приложение, где найден лог | Помогает учитывать топологию системы и локализацию сбоя |
| Идентификатор шаблона | Нормализованный тип лог-сообщения | Позволяет сравнивать события без влияния переменных данных |
Если у события есть несколько шаблонов логов из двух приложений, его сигнатура будет содержать несколько таких пар. Это и есть компактный портрет сбоя.
Как считается сходство между двумя событиями
Сходство событий по логам считают по пересечению приложений и шаблонов логов внутри этих приложений. Чем больше пересечение, тем выше вероятность, что события связаны.
Сначала проверяют, есть ли у двух событий общие приложения или сервисы. Если пересечения нет, сходство обычно будет низким или нулевым. Если общие компоненты есть, внутри каждого такого компонента сравнивают наборы шаблонов логов.
Итоговый балл сходства строится на перекрытии этих наборов. Когда два события показывают схожие ошибочные шаблоны в одних и тех же приложениях, это сильный признак связности. Когда совпадают только общие слова в описании, но сигнатуры разные, доверия к такому совпадению меньше.
Упрощенная последовательность расчета
Практически процесс выглядит как цепочка из нескольких шагов. Каждый шаг убирает шум и оставляет признаки, пригодные для сопоставления.
- Определить время начала события.
- Собрать лог-строки из окна вокруг этого времени.
- Пропустить строки через классификатор ошибок.
- Нормализовать ошибочные строки в шаблоны.
- Связать каждый шаблон с приложением или сервисом.
- Построить сигнатуру события.
- Сравнить сигнатуру с историческими сигнатурами других событий.
Почему текстовые описания инцидентов часто дают слабый результат
Текстовые описания инцидентов полезны для чтения человеком, но ненадежны для точного поиска похожих случаев. Они зависят от формулировок, терминов и привычек автора.
Один инженер пишет коротко. Другой — через бизнес-эффект. Система мониторинга может сгенерировать сухой алерт, а оператор создаст карточку инцидента на естественном языке. В результате два связанных события получают разные наборы слов, хотя логи показывают одно и то же поведение сервисов.
Есть и еще одна причина. Описание инцидента часто отражает верхний уровень проблемы: недоступен экран, выросла задержка, не открывается отчет. Логи, напротив, фиксируют симптомы в глубине системы: тайм-ауты, ошибки соединения, отказ зависимого сервиса, сбои при доступе к базе данных.
В чем преимущество подхода на основе логов
Подход на основе логов лучше сохраняет связь между событиями, если их роднит общий технический симптом. Он опирается на наблюдаемые ошибки, а не на формулировки в тексте.
Это особенно полезно в среде с микросервисами. Один и тот же сбой может по-разному проявляться в интерфейсе, в очередях, в базе данных и в фоновых задачах. Текстовые описания будут фрагментированы. Сигнатура логов собирает эти проявления в один набор признаков.
Главный плюс такого метода в том, что он использует фактическое поведение системы в момент инцидента. За счет этого проще находить исторические случаи, у которых был похожий набор ошибок, даже если названия инцидентов и алертов почти не пересекаются по словам.
Где метод дает практическую пользу в AIOps
Поиск похожих инцидентов по логам нужен для корреляции событий, ускорения диагностики и повторного использования прошлых разборов. Это один из базовых сценариев AIOps.
Когда система находит похожий инцидент из истории, команда получает не просто совпадение по названию. Она получает связь с уже наблюдавшейся картиной сбоев. Это помогает быстрее локализовать источник проблемы и понять, какие сервисы стоит проверять первыми.
- Корреляция событий — связывание текущего события с уже известными цепочками отказов.
- Локализация сбоя — выделение сервиса или группы сервисов, где проявились ключевые ошибки.
- Снижение ручного разбора — меньше времени уходит на поиск похожих случаев по памяти или по ключевым словам.
- Работа с историей инцидентов — прошлые сигнатуры становятся базой для сравнения новых событий.
Какие ограничения у подхода есть
Метод зависит от качества логов, корректной нормализации и точной привязки записей ко времени события. Если эти части слабые, сходство будет считаться хуже.
Если логи неполные, в них мало ошибок или источники пишут сообщения в разном формате без единых шаблонов, построение сигнатур усложняется. Проблемой станет и избыточный шум, если классификатор плохо отделяет штатные записи от аварийных.
Еще один важный момент — границы временного окна. Слишком узкий интервал может не захватить начало деградации. Слишком широкий добавит лишние события, не связанные с данным инцидентом.
Что нужно запомнить об использовании логов в управлении инцидентами
Для поиска похожих инцидентов в AIOps логи часто надежнее текстовых описаний. Если два события имеют похожие сигнатуры логов, они с высокой вероятностью отражают связанную техническую проблему.
Рабочая схема состоит из четырех опорных частей: сбор логов вокруг момента сбоя, отбор ошибочных строк, нормализация в шаблоны и сравнение сигнатур между событиями. Такая модель помогает видеть связь там, где текст этого не показывает, и снижает зависимость от ручной интерпретации инцидентов.