Module: check_mk
Branch: master
Commit: 43f8cd6b1072b54b9d6c9ab7d7f0ed4e85c9cff0
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=43f8cd6b1072b5…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Thu Mar 9 14:19:02 2017 +0100
Fixed wording in a few Werks
Change-Id: Iab996a1ea8c4bd8a35e191563e12c0dbad65dc2c
---
.werks/1306 | 2 +-
.werks/3262 | 2 +-
.werks/3539 | 2 +-
.werks/3720 | 24 +++++++++++----------
.werks/3861 | 72 ++++++++++++++++++++++++++++++++++---------------------------
.werks/3971 | 2 +-
.werks/4166 | 5 ++---
7 files changed, 59 insertions(+), 50 deletions(-)
diff --git a/.werks/1306 b/.werks/1306
index f04f93f..32b003f 100644
--- a/.werks/1306
+++ b/.werks/1306
@@ -1,4 +1,4 @@
-Title: mkeventd: The Recent event history can you be filtered by extended regexes
+Title: mkeventd: The recent event history can now be filtered by extended regular expressions
Level: 1
Component: ec
Compatible: compat
diff --git a/.werks/3262 b/.werks/3262
index a30f02f..b56d78f 100644
--- a/.werks/3262
+++ b/.werks/3262
@@ -1,4 +1,4 @@
-Title: Event Console: bulk delete button for custom MIBs now available
+Title: Bulk delete button for custom MIBs now available
Level: 1
Component: ec
Compatible: compat
diff --git a/.werks/3539 b/.werks/3539
index a1a2a5f..18e3bff 100644
--- a/.werks/3539
+++ b/.werks/3539
@@ -1,4 +1,4 @@
-Title: Event Console: The EC notifications are now also controlled through the master control snapin
+Title: Notifications are now also controlled through the master control snapin
Level: 1
Component: ec
Compatible: compat
diff --git a/.werks/3720 b/.werks/3720
index b6dae7a..fac8c13 100644
--- a/.werks/3720
+++ b/.werks/3720
@@ -1,19 +1,21 @@
-Title: The Event Console views are now supporting distributed setups
-Level: 2
+Title: The Event Console now supports real distributed setups
+Level: 3
Component: ec
Compatible: compat
Version: 1.4.0i1
Date: 1469428806
Class: feature
-The Event Console was not really supporting distributed setups in the past. In case you have
-a setup of multiple sites you always had to decide whether or not to setup a single, central,
-EC or one EC per site and how to handle and configure monitoring and notifications.
+The Event Console was not really supporting distributed setups in the past. In
+case you have a setup of multiple sites you always had to decide whether or
+not to setup a single, central, EC or one EC per site and how to handle and
+configure monitoring and notifications.
-The Event Console can now be integrated into distributed setups more easily. The standard
-setup should now be a single Event Console per site which receives the events of all
-hosts monitoringed with this site.
+The Event Console can now be integrated into distributed setups more
+easily. The standard setup is now a single Event Console per site,
+which receives the events of all hosts monitoringed with this site.
-In case you have a central view site, the Event Console views show up the events of all Event
-Console instances configured in the central site. You can manage all the events of the remote
-Event Console just like managing hosts and services of the remote site.
+In case you have a central view site, the Event Console views show up the
+events of all Event Console instances configured in the central site. You
+can manage all the events of the remote Event Console just like managing
+hosts and services of the remote site.
diff --git a/.werks/3861 b/.werks/3861
index 5b0ea44..80fa0b5 100644
--- a/.werks/3861
+++ b/.werks/3861
@@ -1,48 +1,56 @@
Title: Introduced open event limit mechanism for protecting against message storms
-Level: 3
+Level: 2
Component: ec
Compatible: compat
Version: 1.4.0i1
Date: 1474033893
Class: feature
-The Event Console has been extended to be able to protect agains message storms which can
-either result in too high load and also in out of memory situations.
+The Event Console has been extended to be able to protect agains message storms
+which can either result in too high load and also in out of memory situations.
-Because there can be multiple kind of message storms like one device which sends a lot of messages
-or many different devices sending equal messages, we introduced different limits to match them.
+Because there can be multiple kind of message storms like one device which
+sends a lot of messages or many different devices sending equal messages,
+we introduced different limits to match them.
There are the following limits:
<ul>
-<li>Limit by host: You can limit the number of open events created by a single host . This is meant to
-prevent you from message storms created by one device. Once the limit is reached, the Event Console
-will block all future incoming messages sent by this host until the number of open events has been
-reduced to be below this limit. In the moment the limit is reached, the Event Console will notify
-the configured contacts of the host.</li>
-
-<li>Limit by rule: You can limit the number of open events created by a single rule here. This is meant to
-prevent you from too generous rules creating a lot of events. Once the limit is reached, the Event Console will stop the rule
-creating new open events until the number of open events has been reduced to be below this limit. In the
-moment the limit is reached, the Event Console will notify the configured contacts of the rule or create a notification
-with empty contact information.</li>
-
-<li>Overall limit: To protect you against a continously growing list of open events created by
-different hosts or rules, you can configure this overall limit of open events. All currently open
-events are counted and once the limit is reached, no further events will be opened which means that
-new incoming messages will be dropped. In the moment the limit is reached, the Event Console will
-create a notification with empty contact information.
-</li>
+
+<li>Limit by host: You can limit the number of open events created by a
+single host . This is meant to prevent you from message storms created by
+one device. Once the limit is reached, the Event Console will block all
+future incoming messages sent by this host until the number of open events
+has been reduced to be below this limit. In the moment the limit is reached,
+the Event Console will notify the configured contacts of the host.</li>
+
+<li>Limit by rule: You can limit the number of open events created by
+a single rule here. This is meant to prevent you from too generous rules
+creating a lot of events. Once the limit is reached, the Event Console will
+stop the rule creating new open events until the number of open events has
+been reduced to be below this limit. In the moment the limit is reached,
+the Event Console will notify the configured contacts of the rule or create
+a notification with empty contact information.</li>
+
+<li>Overall limit: To protect you against a continously growing list of open
+events created by different hosts or rules, you can configure this overall
+limit of open events. All currently open events are counted and once the
+limit is reached, no further events will be opened which means that new
+incoming messages will be dropped. In the moment the limit is reached, the
+Event Console will create a notification with empty contact information. </li>
+
</ul>
-Each of those limits can be configured to different values. By default the limit is set to
-1000 for the host and rule based limit and 10000 for the overall limit. Please check carefully
-whether or not these defaults are OK for you. But they should be way enough for most environments
-since you really should never have so many open events in the Event Console open.
+Each of those limits can be configured to different values. By default the
+limit is set to 1000 for the host and rule based limit and 10000 for the
+overall limit. Please check carefully whether or not these defaults are
+OK for you. But they should be way enough for most environments since you
+really should never have so many open events in the Event Console open.
-But if you need to change those limits, you can change them in the global settings of the Event
-Console to fit your needs.
+But if you need to change those limits, you can change them in the global
+settings of the Event Console to fit your needs.
-Additionally, you can configure the actions the Event Console should perform once the limit is
-reached instead of the overflow event and notification creation as described above. Another action
-is for example delete the oldest event (of a host, rule or overall).
+Additionally, you can configure the actions the Event Console should perform
+once the limit is reached instead of the overflow event and notification
+creation as described above. Another action is for example delete the oldest
+event (of a host, rule or overall).
diff --git a/.werks/3971 b/.werks/3971
index 94e1c6b..35ecb18 100644
--- a/.werks/3971
+++ b/.werks/3971
@@ -1,4 +1,4 @@
-Title: Event Console: Event numbers are now also displayed in tactical overview snapin
+Title: Event numbers are now also displayed in tactical overview snapin
Level: 1
Component: ec
Compatible: compat
diff --git a/.werks/4166 b/.werks/4166
index 4489cfb..59c8e8e 100644
--- a/.werks/4166
+++ b/.werks/4166
@@ -6,6 +6,5 @@ Version: 1.4.0i3
Date: 1481808898
Class: feature
-In hosts or services views you can now archive all events
-at once by using the view command archive events below
-various commands.
+In hosts or services views you can now archive all events at once by using
+the view command {{Archive events}} in the section {{Various commands}}.
Module: check_mk
Branch: master
Commit: 7fafaff719d2bb8a550c13fdb50b5f26b930c398
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=7fafaff719d2bb…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Wed Mar 8 17:36:16 2017 +0100
mkbench: Terminate by high cmk latency after longer initialization time
Change-Id: Iff45d49dfbbc1f1ff98b4ad6af475e1e94188520
---
bin/mkbench | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/mkbench b/bin/mkbench
index 1d1ff10..4af2c3b 100755
--- a/bin/mkbench
+++ b/bin/mkbench
@@ -738,7 +738,7 @@ class TestRunner(threading.Thread):
# Initial scheduling of the CMC spreads the service checks for a maximum of
# 5 * check_interval. So we should terminate the test only after some initialization
# time.
- if self.test_case.duration() < 300:
+ if self.test_case.duration() < 450:
return
if m.site_stats and m.site_stats["average_latency_cmk"] > 30: