8 May
2013
8 May
'13
2:57 a.m.
Module: check_mk
Branch: master
Commit: d854ee487fff74722d9f7a99a3c0211344518da4
URL:
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=d854ee487fff74…
Author: Andreas Boesl <ab(a)mathias-kettner.de>
Date: Wed May 8 09:56:57 2013 +0200
Updated bug entries #0928, #0929, #0927
---
.bugs/927 | 12 ++++++++++++
.bugs/928 | 17 +++++++++++++++++
.bugs/929 | 20 ++++++++++++++++++++
3 files changed, 49 insertions(+)
diff --git a/.bugs/927 b/.bugs/927
new file mode 100644
index 0000000..2d64244
--- /dev/null
+++ b/.bugs/927
@@ -0,0 +1,12 @@
+Title: rising service check latency when using livecheck
+Component: livecheck
+State: open
+Date: 2013-05-08 09:40:42
+Targetversion: future
+Class: nastiness
+
+It seems that there are still some performance problems when using livecheck
+Scenario: 16000 services
+20 livecheck helpers, no livecheck overflows
+
+When running nagios the service check latency goes up (7 minutes and further)
diff --git a/.bugs/928 b/.bugs/928
new file mode 100644
index 0000000..68a18c7
--- /dev/null
+++ b/.bugs/928
@@ -0,0 +1,17 @@
+Title: livestatus table statehist speedup
+Component: livestatus
+State: open
+Date: 2013-05-08 09:47:22
+Targetversion: future
+Class: feature
+
+Querying large timeframes within the statehist table can eat up
+lots of time. This is because for every host/service an object is
+generated which stores the data.
+On global changes (timeperiod change) each of these objects need to be updated
+
+Sometimes the query just want to get info about a single host - using Filters
+statehist disregards this wish when collecting data, thus resulting in the slow
performance
+
+Possible solution:
+Take the queries filter into account when creating the objects for the host/services
diff --git a/.bugs/929 b/.bugs/929
new file mode 100644
index 0000000..82ab67e
--- /dev/null
+++ b/.bugs/929
@@ -0,0 +1,20 @@
+Title: Notification speedup
+Component: core
+State: open
+Date: 2013-05-08 09:51:56
+Targetversion: future
+Class: nastiness
+
+When using large monitoring environments ( thousands of hosts / hundreds of users )
+notifications from nagios take quite some time to process (~1 seconds)
+
+Problem:
+If there are multiple users within the contact group of a service, nagios will
+start a notification command for each single user, which adds up quite some time
+e.g. 10 users -> 10 seconds
+
+Even worse, nagios hangs while the notifications are processed!
+
+Solution:
+Each user gets a precompiled notification file.
+So its no longer neccessary to read the entire configuration from scratch when a
notication is raised