tyler.durden
/
icinga2
mirror of https://github.com/Icinga/icinga2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Documentation: Fix event command execution conditions 

fixes #6685
This commit is contained in:
Michael Friedrich 2014-07-10 11:27:37 +02:00
parent 7e83247508
commit 2358d70c96
1 changed files with 10 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
doc/3-monitoring-basics.md
View File

@ -901,11 +901,17 @@ NotificationCommand object refer to that.
### <a id="event-commands"></a> Event Commands
Unlike notifications event commands are called on every service execution
if defined. Therefore the `EventCommand` object should define a command line
Unlike notifications event commands are called on every host/service execution
if one of these conditions match:
* The host/service is in a [soft state](#hard-soft-states)
* The host/service state changes into a [hard state](#hard-soft-states)
* The host/service state recovers from a [soft or hard state](#hard-soft-states) to [OK](#service-states)/[Up](#host-states)
Therefore the `EventCommand` object should define a command line
evaluating the current service state and other service runtime attributes
available through runtime vars. Runtime macros such as `$SERVICESTATETYPE$`
and `$SERVICESTATE$` will be processed by Icinga 2 helping on fine-granular
available through runtime vars. Runtime macros such as `$service.state_type$`
and `$service.state$` will be processed by Icinga 2 helping on fine-granular
events being triggered.
Common use case scenarios are a failing HTTP check requiring an immediate
@ -1604,22 +1610,6 @@ Detailed information on the commands and their required parameters can be found
on the [Icinga 1.x documentation](http://docs.icinga.org/latest/en/extcommands2.html).
## <a id="event-handlers"></a> Event Handlers
Event handlers are defined as `EventCommand` objects in Icinga 2.
Unlike notifications event commands are called on every host/service execution
if defined. Therefore the `EventCommand` object should define a command line
evaluating the current service state and other service runtime attributes
available through runtime macros. Runtime macros such as `$service.state_type$`
and `$service.state$` will be processed by Icinga 2 helping on fine-granular
events being triggered.
Common use case scenarios are a failing HTTP check requiring an immediate
restart via event command, or if an application is locked and requires
a restart upon detection.
## <a id="logging"></a> Logging
Icinga 2 supports three different types of logging: