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

Для проверки этой статьи нужны дополнительные цитаты . Помогите улучшить эту статью , добавив ссылки на надежные источники . Неподтвержденные материалы могут быть оспорены и удалены. Найти источники:  «Мониторинг событий» – новости  · газеты  · книги  · ученый  · JSTOR ( август 2017 г. ) ( Узнайте, как и когда удалять это сообщение )

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

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

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

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

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

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

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

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

• Обработка потока событий (ESP)
• Комплексная обработка событий (CEP)
• Мониторинг сети
• Проверка во время выполнения (RV)