6 Mar
2014
6 Mar
'14
10:56 a.m.
Module: check_mk
Branch: master
Commit: 67fcafe8529d4aa461d152101dacad9ed75b9e20
URL:
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=67fcafe8529d4a…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Thu Mar 6 16:56:34 2014 +0100
Removed obsolete draft (because now it is implemented)
---
doc/drafts/README.bulk_notifications | 102 ----------------------------------
1 file changed, 102 deletions(-)
diff --git a/doc/drafts/README.bulk_notifications b/doc/drafts/README.bulk_notifications
deleted file mode 100644
index ac4b76a..0000000
--- a/doc/drafts/README.bulk_notifications
+++ /dev/null
@@ -1,102 +0,0 @@
-BULK NOTIFICATIONS
-------------------
-The idea of "bulk notifications" or "notification aggregation" is to
cut
-down the number of notifications in cases where some general problem causes
-hundreds or thousands of similar alerts at the same time. In some cases this
-problem can be tackled with Nagios "service dependencies". The problem is
-that this is very tedious to configure and includes the risk of blocking
-critical notification per mistake.
-
-The bulk notification feature would collect all notifications of the same
-channel and target user for a certain time into a pool and then send *one*
-notification email/sms/whatever that contains all those notifications. A
-typical time frame of such a pooling could be 1 minute. Assuming that your
-check period is one minute, that would mean that all alerts that origin from
-the same problem would be packed into one single notification.
-
-In order to make you not blind to *other* problems that happen during such a
-burst of alerts the pooling could be done on a per-checktype or per-hostgroup
-or per-whatever base. It also could take the service level of objects into
-account so that e.g. all alerts of the level "Tier 3" is bulked by 5 minutes,
-the alerts of "Tier 1" would not be bulked by sent independently.
-
-The configuration of the notification aggregation could be done as a parameter
-to the notification rules. Example:
-
-Condition:
-- Service Level <= 10 (Tier 3)
-
-Notification:
-- Send to all configured monitoring contacts
-- Send via Email
-
-Aggregation:
- - time range (e.g. collect notifications up to 2 minutes)
- - force separate notification bulks for different
- [ ] hosts
- [ ] check types
- [ ] states (WARN, CRIT, etc.)
- [ ] service descriptions
- [ ] service levels
-
-
-OVERRIDING
-----------
-If there is a global rule that configures a notification without aggregation,
-then a later rule can override that and add an aggregation. That way a user
-can enable bulk notifications for otherwise un-bulked ones.
-
-Vice versa: if in a rule notifications are aggregated and a later rule
-(e.g. one of a user) has aggregation disabled, that setting has precedence.
-
-
-IMPLEMENTATION
---------------
-We implement the bulk notifications as an addition to the "rule
-based notifications."
-
-A) WATO
-
-[1] Each positive notification rule has some new options for bulking
- [x] Enable bulk notifications
- - Bulk up to [__0] days [_0] hours [10] minutes [_0] seconds
- - Bulk up to [__100] notifications
- - Force separate notifications for different
- [X] Hosts
- [ ] Check types
- [ ] Service Levels
-
-[2] Complain if the selected plugin does not support bulking.
-
-[3] Extend the API of the notification plugins so that bulking
- ability can be detected by WATO.
-
-B) NOTIFICATION
-
-[11] The bulk options are stored as an additional parameter in the notification
- table. Later rules that trigger the same check plugin override these options.
- That way a user can enable bulking if its globally turned off or vice versa.
-
-[12] If a plugin is being called with bulk notifications on, then
- a) compute a unique name for the bulk. This takes into account
- the separation options.
- b) compute the path of a directory below var/check_mk/notify/bulk/$USER and
- create it if its missing
- c) add a file into that directory that contains the notification context
- d) If the directory was new then also add some general information needed later
-
-C) NOTIFICATION SPOOLER
-The bulk notifications require the notification spooler, since asynchronous
-actions need to be done (i.e. sending the actual notification after the timeout)
-
-[21] Create a regular scan of the bulk directories
-
-[22] Detect wheter a bulk is "ripe".
-
-[23] In that case call the notification plugin matching the bulk and send the
notification
- context via stdin
-
-D) NOTIFICATION PLUGINS
-
-[31] Implement bulking for the HTML emails
-