Module: check_mk
Branch: master
Commit: b343df2c78fc9d8f20a75bb9bc5f6afb787cb5a8
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=b343df2c78fc9d…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Sun Nov 25 16:10:49 2012 +0100
Added draft for check interval tuning
---
doc/drafts/LIESMICH.interval | 119 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/doc/drafts/LIESMICH.interval b/doc/drafts/LIESMICH.interval
new file mode 100644
index 0000000..d3f74b8
--- /dev/null
+++ b/doc/drafts/LIESMICH.interval
@@ -0,0 +1,119 @@
+Idee zu neuem Verfahren mit Check-Intervallen
+---------------------------------------------
+
+Problemstellung: Manche der Plugins/Befehle im Agenten dauern zu lange,
+als dass man sie jedes mal ausführen möchte. Aktuell gibt es einen Trick,
+dass man mit einem Cache-File arbeitet - wie z.B. der ORACLE-Agent.
+Das ist etwas umständlich und funktioniert auch nicht bei Windows.
+
+Ich habe jetzt eine neue Idee, die das ganze vor allem für den Agenten
+vereinfacht und die Intelligenz ins zentrale Check_MK verlagert. Es
+funktioniert so:
+
+Es wird eine neue Sektions-Option eingeführt (die zweite nach sep(...)).
+Diese sagt dem Check_MK, dass eine Sektion bis zu einem bestimmten
+Zeitpunkt gültig ist und (maximal) solange vom Agenten nicht mehr neu gesendet
+werden wird.
+
+<<<foo:valid(1353854778)>>>
+foo1 bar test
+foo2 bar test2
+...
+
+Innerhalb der nächsten 300 Sekunden kann diese Sektion fehlen. In diesem
+Fall soll Check_MK einfach - aus der alten Datei von tmp/check_mk/cache -
+den Wert vom letzten Mal nehmen. Erst nach Ablauf der Zeit soll die übliche
+Warnung ausgegeben werden, dass Daten vom Agenten fehlen.
+
+Check_MK muss jetzt so vorgehen: Wenn es feststellt, dass eine Sektion fehlt
+(und nur dann!), lädt es die Cache-Datei. Wenn nicht vorhanden, gilt die
+Sektion als endgültig fehlend. Falls sie vorhanden ist, wird der Sektion
+aus der Cache-Datei geholt. Wenn der Zeitstempel noch nicht erreicht ist,
+wird die Sektion genommen und zur Ausgabe des Agenten hinzugefügt und auch
+an die dann neu erstellte Cache-Datei wieder angehängt.
+
+Gleichzeitig aber - und jetzt kommts(!) - wird Check_MK den Check dann
+nicht einfach mit den Cache-Daten nochmal ausführen, sondern einfach
+auslassen. Dadurch ist die Ausgabe in der GUI korrekt, wo man sieht,
+wie alt Check-Ergebnisse sind. Das Einzige, was jetzt noch doof ist, ist
+die neue Staleness-Funktion, die jetzt nicht weiß, wie oft die Daten
+eigentlich kommen sollen.
+
+Um die Implementierung mit dem Plugins zu vereinfachen (siehe unten),
+wird ferner die Möglichkeit eingeführt, Sektionsoptionen anonym für
+zukünftige Sektionen zu setzen:
+
+<<<:valid(1353854778)>>> --> Gilt für alle zukünftigen Sektionen
+<<<:valid(0)>>> --> Löscht die Option wieder
+
+Implementierung im Agenten (Linux):
+
+Hier muss sich der Agent irgendwie merken, wann er eine Sache das letzte
+Mal ausgeführt hat. Hier ist eine mögliche Lösung für das Verzeichnis
+plugins: Man führt darunter Unterverzeichnisse ein, die einer Anzahl von
+Minuten entsprechen (oder Sekunden)?
+
+/usr/lib/check_mk_agent/plugins/10/mk_oracle
+
+Das bedeutet, dass die Daten nur alle 10 Minuten berechnet werden sollen.
+Im Agenten ist das dann so implementiert (man verwendet die modification time
+des plugins selbst als Indikator, wann es das letzte mal aufgerufen wurde):
+
+# Execute timed plugins
+cd $PLUGINS_DIR
+for dir in $(find -type d) ; do
+ cd $dir
+ date '+<<<:valid(%s)>>>' -d "now + $dir min"
+ for plugin in $(find -cmin +$dir) ; do
+ touch $plugin
+ ./plugin
+ done
+done
+
+Frage ist noch, wie man das effizient bei eingebauten Plugins machen
+soll. Gut wäre es schon, wenn das geht.
+
+Implementierung im Agenten (Windows):
+
+Im Windows-Agenten merkt man sich die Ausführungszeit einfach im Speicher.
+Zusätzlich kann man in [global] auch die Gültigkeiten für die eingebauten
+Sektionen konfigurieren. Das sieht dann so aus:
+
+[global]
+ valid logwatch = 10
+ valid winperf_phydisk = 5
+
+
+SNMP:
+
+Hier kann man das Intervall einfach per Regel steuern:
+
+snmp_check_interval["filesystem"] = [
+ ( 3, ALL_HOSTS, ),
+]
+
+Hier geht man einfach nach der Checkgruppe. Das Item kann man natürlich
+nicht beeinflussen, da ein Check ja immer ganz oder garnich läuft.
+Zusätzlich könnte ein Check - analog zu dem was ja dann der Linux-Agent
+macht - selbst einen Default für seine Häufigkeit vorgeben. Das ist
+dann ein neuer Schlüssel in der check_info:
+
+check_info["hr_fs"] = {
+ ....
+ "interval" : 5,
+}
+
+Um das hinzubekommen, könnte man mit Zeitstempeln auf den Check_MK
+Cachefiles arbeiten. Diese sind ja pro Checktyp separat. Also könnte
+das gehen.
+
+Noch ein Problem gibt es: wenn ein manuelles reschedule ausgeführt wurde,
+wäre es natürlich schön, wenn das Intervall jetzt nicht berücksichtigt
+würde. Dazu müsste man bei SNMP Checks das Intervall ignorieren und bei den
+Agenten-Checks zumindest auf die Daten aus dem Cache-File zugreifen und doch
+zum Nagios senden, auch wenn diese ja nicht aktuell sind. Immerhin werden
+jetzt neue Check-Parameter aktiv, auch wenn der Agent wieder die gleichen
+Daten liefert. Um das hinzubekommen müsste man irgendwie rausbekommen,
+ob ein Check manuell angeworfen wurde oder nicht. Ist das möglich?
+Sendet Nagios hier etwas?
+
Module: check_mk
Branch: master
Commit: b0b9b5074dd9eb577b030e44a953b955441ba9f2
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=b0b9b5074dd9eb…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Fri Nov 23 15:01:27 2012 +0100
Updated bug entries #0872, #0819, #0811
---
.bugs/811 | 5 +++++
.bugs/819 | 7 +++++--
.bugs/872 | 2 ++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/.bugs/811 b/.bugs/811
index 64c419c..c52ad1d 100644
--- a/.bugs/811
+++ b/.bugs/811
@@ -9,3 +9,8 @@ If you install an MKP and it brings a check man page this man page is not
displayed from Multisite, instead it gives an error about not finding the
check man page in the default path. It would be good if multisite could
also check the local/ structure for existing man pages
+
+LM: This is already implemented, but with the nastyness, that the regular
+check manpages are placed in share/doc/check_mk/checks but the local
+check manpages are searched in local/share/check_mk/checkman. This should
+be cleaned up!
diff --git a/.bugs/819 b/.bugs/819
index 217a098..046d6c4 100644
--- a/.bugs/819
+++ b/.bugs/819
@@ -1,9 +1,9 @@
Title: Apache Status bug
Component: checks
-State: open
+Class: bug
+State: done
Date: 2012-10-24 11:08:13
Targetversion: 1.2.0
-Class: bug
osTicket id 258581
sorry to report a bug regarding the new apache_status in 1.2.0p3.
@@ -18,3 +18,6 @@ We tested the server-status url with lynx and it is working fine.
CentOS release 5.6 (Final) 32-Bit
httpd-2.2.3-65.el5.centos
+
+2012-11-23 14:38:23: changed state open -> done
+URL handling changed and fixed for python versions <2.6. Should work now.
diff --git a/.bugs/872 b/.bugs/872
index 2e5e4e3..dfc0f4e 100644
--- a/.bugs/872
+++ b/.bugs/872
@@ -8,3 +8,5 @@ Class: bug
When having e.g. the speedometer in the sidebar and removing it, the javascript worker code
remains fetching the speedometer webservice. The worker should detect that the snapin has
been removed and stop updating the data.
+
+Not a general problem: The speedometer uses its own scheduler. Must be fixed individually.