анализ и обоснование цепочки событий - PullRequest
2 голосов
/ 20 июля 2011

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

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

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

Примеры:

  • Обнаружено короткое замыкание, в результате которого ограниченный режим работы, ограниченная операция не устраняет неисправность, поэтому аварийное состояние повышается, общая выходная мощность отключена.
  • линия безопасности обручилась. Ни один модуль не сообщил о его включении в течение 3 секунд с момента его включения, поэтому «неизвестный источник или помеха» объясняется как причина остановки системы.
  • большинство выходных модулей сообщают об отсутствии выходного напряжения. Примерно через 1 с модуль мониторинга источника питания сообщает о том, что питание отключено, что является первоначальной причиной.
  • модуль вывода сообщает об отсутствии выходного напряжения во всех своих выходных линиях. Нет отчета от модуля питания. Причина в том, что линия питания отключена от модуля.
  • модуль вывода сообщает об отсутствии выходного напряжения в одной из своих выходных линий. О других неисправностях не сообщалось. Причина - сгоревший предохранитель.
  • модуль вывода не сообщил о применении полученного состояния. Вскоре после этого модуль управления сообщает о недопустимом состоянии или выходных линиях (в результате модуль вывода действительно не обновляет состояние своевременно.) Причиной является модуль вывода (который вызвал ошибку), а не модуль управления (который остановил система из-за обнаруженной неисправности).
  • Неисправность входного модуля переводит устройство в резервно-отказоустойчивый режим. Модуль вывода, который до сих пор не использовался, который был неисправен, включается в этом режиме, и режим отказа переводится в критический. Первоначальной причиной является не ввод, который разрешает сообщать о ложных срабатываниях в отношении сбоев, а прерывание резервного копирования, прервавшего операцию.
  • Нет никаких действий от модуля вывода, в течение последних 2 секунд. Это означает, что он неисправен и необходимо войти в режим отказа.

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

Теперь о (слишком общем и расплывчатом) вопросе: как это решить? Существуют ли конкретные алгоритмы, методы или обобщенные решения для такого рода проблем? Как написать обобщенные наборы правил и сопоставить их? Как сделать софт-сопоставление? (скажем, модуль ввода сломался прямо в середине аварийной остановки, это совершенно не связанное событие, которое следует игнорировать.) Помогите, пожалуйста?

1 Ответ

1 голос
/ 20 июля 2011

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

Если вы настаиваете, я бы подошел к этому так, чтобы каждая ошибка сбрасывала какой-то символ / токен для каждого кода ошибки - вам будет намного сложнее, если вы попытаетесь сделать несколько совпадений слов / ключевых слов. Затем вы должны ввести выведенные токены в какой-то классификатор.

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

Вы также можете обучить байесовскую сеть или другой классификатор типов, но вам понадобится немало данных, которые вы пометили вручную (token1, token2, token3-> faultxyz), и, возможно, будет более точным сделать это сам.

...