Module: check_mk
Branch: master
Commit: 02b1930d7e142459b804126b4847f57921dec466
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=02b1930d7e1424…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Mon Nov 26 16:33:56 2012 +0100
Fixed ChangeLog
---
ChangeLog | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 27958a2..7d0c849 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,5 @@
1.2.1i4:
+ * FIX: postgres_sessions: handle case of no active/no idle sessions
Core:
* Better exception handling when executing "Check_MK"-Check. Printing python
exception to status output and traceback to long output now.
@@ -11,6 +12,7 @@
* Linux Agent, mk_postgres: Fixed database stats query to be compatible
with more versions of postgres
* apache_status: Modified to be usable on python < 2.6 (eg RHEL 5.x)
+ * FIX: postgres_sessions: handle case of no active/no idle sessions
Multisite:
* Implemented LDAP integration of Multisite. You can now authenticate your
@@ -169,9 +171,6 @@
* FIX: fixed detection of existing groups when creating new groups
* FIX: allow email addresses like test(a)test.test-test.com
- Checks & Agents:
- * FIX: postgres_sessions: handle case of no active/no idle sessions
-
1.2.0p3:
Mulitisite
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?
+