View source for Event monitoring

{{Short description|Computing process}}
In [[Computer science|computer science]], '''event monitoring''' is the process of collecting, analyzing, and signaling event occurrences to subscribers such as [[Operating system|operating system]] [[Process (computing)|processes]], active [[Database|database]] rules as well as human operators. These event occurrences may stem from arbitrary sources in both [[Software|software]] or [[Computer hardware|hardware]] such as operating systems, database management systems, application software and [[Engineering:Microprocessor|processor]]s. Event monitoring may use a [[Software:Time series database|time series database]].

== Basic concepts ==
Event monitoring makes use of a logical bus to transport event occurrences from [[Communication source|source]]s to [[Observation|subscriber]]s, where ''event sources'' signal event occurrences to all event subscribers and ''event subscribers'' receive event occurrences. An event bus can be distributed over a set of physical [[Node (networking)|node]]s such as standalone computer systems. Typical examples of event buses are found in [[Graphical user interface|graphical systems]] such as [[Software:X Window System|X Window System]], [[Software:Microsoft Windows|Microsoft Windows]] as well as development tools such as SDT.

''Event collection'' is the process of collecting event occurrences in a filtered event log for analysis. A ''filtered event log'' is logged event occurrences that can be of meaningful use in the future; this implies that event occurrences can be removed from the filtered event log if they are useless in the future. ''Event log analysis'' is the process of analyzing the filtered event log to aggregate event occurrences or to decide whether or not an event occurrence should be signalled. ''Event signalling'' is the process of signalling event occurrences over the event bus.

Something that is monitored is denoted the ''monitored object''; for example, an application, an operating system, a database, hardware etc. can be monitored objects. A monitored object must be properly conditioned with event [[Engineering:Sensor|sensor]]s to enable event monitoring, that is, an object must be instrumented with event sensors to be a monitored object. ''Event sensors'' are sensors that signal event occurrences whenever an event occurs. Whenever something is monitored, the [[Probe effect|probe effect]] must be managed.

==Monitored objects and the probe effect==
As discussed by Gait,<ref>J. Gait (1985). A debugger for concurrent programs. ''Software-Practice And Experience'', 15(6)</ref> when an object is monitored, its behavior is changed. In particular, in any concurrent system in which processes can run in [[Parallel computing|parallel]], this poses a particular problem. The reason is that whenever sensors are introduced in the system, processes may execute in a different order. This can cause a problem if, for example, we are trying to localize a [[Engineering:Fault (technology)|fault]], and by monitoring the system we change its behavior in such a way that the fault may not result in a failure; in essence, the fault can be masked by monitoring the system. The ''[[Probe effect|probe effect]]'' is the difference in behavior between a monitored object and its un-instrumented counterpart.

According to Schütz,<ref>W. Schütz (1994). Fundamental issues in testing distributed real-time systems. ''Real-Time Systems'', 7(2):129–157</ref> we can avoid, compensate for, or ignore the probe effect. In critical real-time system, in which timeliness (i.e., the ability of a system to meet time constraints such as deadlines) is significant, avoidance is the only option. If we, for example, instrument a system for testing and then remove the instrumentation before delivery, this invalidates the results of most testing based on the complete system. In less critical real-time system (e.g., media-based systems), compensation can be acceptable for, for example, performance testing. In non-concurrent systems, ignorance is acceptable, since the behavior with respect to the order of execution is left unchanged.

==Event log analysis==
Event log analysis is known as event composition in [[Active database|active database]]s, chronicle recognition in [[Artificial intelligence|artificial intelligence]] and as real-time logic evaluation in real-time systems. Essentially, event log analysis is used for [[Pattern matching|pattern matching]], filtering of event occurrences, and aggregation of event occurrences into composite event occurrences. Commonly, [[Dynamic programming|dynamic programming]] strategies from [[Algorithm|algorithm]]s are employed to save results of previous analyses for future use, since, for example, the same pattern may be match with the same event occurrences in several consecutive analysis processing. In contrast to general rule processing (employed to assert new facts from other facts, cf. [[Philosophy:Inference engine|inference engine]]) that is usually based on [[Backtracking|backtracking]] techniques, event log analysis algorithms are commonly [[Greedy algorithm|greedy]]; for example, when a composite is said to have occurred, this fact is never revoked as may be done in a backtracking based algorithm.

Several mechanisms have been proposed for event log analysis: finite state automata, Petri nets, [[Procedural programming|procedural]] (either based on an imperative programming language or an object-oriented programming languages), a modification of Boyer–Moore string-search algorithm, and simple [[Temporal network|temporal network]]s.

==See also==
* [[Event stream processing]] (ESP)
* [[Complex event processing]] (CEP)
* [[Network monitoring]]
* [[Runtime verification]] (RV)

==References==
<references />

[[Category:Operating system technology]]
[[Category:Network management]]
[[Category:Management systems| ]]
[[Category:Systems management]]

{{Sourceattribution|Event monitoring}}