Мониторинг событий

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

Основные понятия

Мониторинг событий использует логическую шину для транспортировки событий от источников к подписчикам , при этом источники событий сообщают о событиях всем подписчикам событий, а подписчики событий получают события. Шина событий может быть распределена по набору физических узлов, таких как автономные компьютерные системы. Типичные примеры шин событий можно найти в графических системах, таких как X Window System , Microsoft Windows , а также в инструментах разработки, таких как SDT.

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

То, что отслеживается, обозначается как отслеживаемый объект ; например, объектами мониторинга могут быть приложение, операционная система, база данных, оборудование и т. д. Контролируемый объект должен быть надлежащим образом оснащен датчиками событий , чтобы обеспечить возможность мониторинга событий, то есть объект должен быть оснащен датчиками событий, чтобы быть контролируемым объектом. Датчики событий — это датчики, которые сигнализируют о возникновении событий всякий раз, когда событие происходит. Всякий раз, когда что-то отслеживается, эффект зонда необходимо контролировать .

Объекты мониторинга и зондирующий эффект

Как обсуждал Гейт, ^[1] когда объект контролируется, его поведение изменяется. В частности, в любой параллельной системе , в которой процессы могут выполняться параллельно , это создает особую проблему. Причина в том, что всякий раз, когда в систему вводятся датчики, процессы могут выполняться в другом порядке. Это может вызвать проблему, если, например, мы пытаемся локализовать неисправность и, наблюдая за системой, меняем ее поведение таким образом, чтобы неисправность не могла привести к сбою; по сути, неисправность можно замаскировать путем мониторинга системы. Эффект зонда — это разница в поведении наблюдаемого объекта и его неинструментального аналога.

По мнению Шютца, ^[2] мы можем избежать, компенсировать или игнорировать эффект зондирования. В критической системе реального времени, в которой своевременность (т. е. способность системы соблюдать временные ограничения, такие как сроки) имеет большое значение, избегание является единственным вариантом. Если мы, например, проверяем систему, а затем удаляем ее перед поставкой, это делает недействительными результаты большинства испытаний всей системы. В менее критичных системах реального времени (например, мультимедийных системах) компенсация может быть приемлемой, например, за тестирование производительности . В неконкурентных системах незнание допустимо, поскольку поведение в отношении порядка выполнения остается неизменным.

Анализ журнала событий

Анализ журнала событий известен как композиция событий в активных базах данных , распознавание хроники в искусственном интеллекте и логическая оценка в реальном времени в системах реального времени. По сути, анализ журнала событий используется для сопоставления с шаблонами , фильтрации вхождений событий и агрегирования вхождений событий в составные вхождения событий. Обычно динамического программирования стратегии из алгоритмов используются для сохранения результатов предыдущего анализа для будущего использования, поскольку, например, один и тот же шаблон может сопоставляться с одними и теми же событиями в нескольких последовательных обработках анализа. В отличие от общей обработки правил (используемой для выявления новых фактов из других фактов, см. механизм вывода ), которая обычно основана на методах обратного отслеживания , алгоритмы анализа журнала событий обычно являются жадными ; например, когда сообщается, что произошло объединение, этот факт никогда не отменяется, как это может быть сделано в алгоритме, основанном на обратном отслеживании.

Для анализа журнала событий было предложено несколько механизмов: конечные автоматы , сети Петри , процедурные (основанные либо на императивном языке программирования, либо на объектно-ориентированных языках программирования), модификация алгоритма поиска строк Бойера-Мура и простые темпоральные сети. .

См. также

Ссылки

^ Дж. Гейт (1985). Отладчик для параллельных программ. Программное обеспечение: практика и опыт , 15(6)
^ В. Шютц (1994). Фундаментальные вопросы тестирования распределенных систем реального времени. Системы реального времени , 7(2):129–157.

[1] Дж. Гейт (1985). Отладчик для параллельных программ. Программное обеспечение: практика и опыт , 15(6)

[2] В. Шютц (1994). Фундаментальные вопросы тестирования распределенных систем реального времени. Системы реального времени , 7(2):129–157.

[1]

[2]