Refactoring: Changed remaining check parameters starting with an 's' to the new rules...
[check_mk.git] / .werks / 1395
blob457468f2e7bd64d817ebea60c821e57e9e904f16
1 Title: Event Console can now create notifications via Check_MK RBN
2 Level: 2
3 Component: ec
4 Compatible: compat
5 Version: 1.2.5i6
6 Date: 1409752217
7 Class: feature
9 The Event Console has now the new builtin action <i>Send monitoring
10 notification</i> that can be used in all three situations where actions
11 are possible:
13 <ul>
14 <li>When an event is being opened</li>
15 <li>When an event is being cancelled</li>
16 <li>By a user executing an action on an open event</li>
17 </ul>
19 This new action creates a monitoring notification just as the ones that happen,
20 when in normal (non-EC) monitoring a service goes from OK to CRIT or vice
21 versa. This notification is being process by the rule based notifications
22 and is handled just like a monitoring notification.
24 Why whould you want to do that?
26 <ul>
27 <li>You can use the same notification plugins for alarms triggered by the
28 monitoring and by the Event Console. No need for an extra SMS script in
29 the Event Console.</li>
30 <li>You can use all of the flexiblity of existing notification plugins - including
31 configuring their parameters via WATO.</li>
32 <li>All notifications from your Check_MK environment are now controlled by a common set of notification
33 rule. For example if a user wants to disable all of his notifications then there is just
34 one place for doing that.</li>
35 </ul>
37 There is nothing you need to setup. Just check the action <i>Send monitoring
38 notification</i> in your event rules and that's it.
40 <b>Note</b>: Because events are not exactly the same as services and because
41 of the nature of distributed monitoring there are a few specialities in
42 notifications that come from the Event Console:
44 <ul>
45 <li>EC notifications have only limited information about the host. There is
46 <b>no information</b> about host tags or WATO folders. Do not use matching
47 criteria on those or otherwise that match will always fail.</li>
48 <li>EC notifications currently have no information about contacts or groups of
49 a host. This would need an online Livestatus query, but that would fail
50 if the host is being monitored by a remote system.</li>
51 <li>EC notifications do not have a <i>previous</i> host or service state,
52 since the Event Console is a stateless monitoring.
53 Do not set any matching criteria on the event type since none of these
54 can be fulfilled currently.</li>
55 <li>All EC notifications are sent as <i>service</i> notifications. The name
56 of the event's application is taken as service description.</li>
57 </ul>
59 The notification rules have got a new matching option especially for EC
60 notifications: <i>Event Console alerts</i>. Here you can make a notification
61 rule deal only with EC notifications or exclude just those.  You can also match
62 on EC specific fields like the event's rule id, syslog priority, syslog
63 facility and event comment.
65 Most of the event's special fields are available as notification
66 context variables - to be used in custom notification scripts or
67 template definitions.  Please use the standard debugging methods
68 for displaying all variables.  At least defined are <tt>EC_ID</tt>,
69 <tt>EC_RULE_ID</tt>, <tt>EC_PRIORITY</tt>, <tt>EC_FACILITY</tt>,
70 <tt>EC_PHASE</tt>, <tt>EC_COMMENT</tt>, <tt>EC_OWNER</tt>, <tt>EC_PID</tt>,
71 <tt>EC_MATCH_GROUPS</tt>, and <tt>EC_CONTACT_GROUPS</tt>.