Module: check_mk
Branch: master
Commit: 53f933bfe67936c202bfc9e8ad7919093ce05da0
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=53f933bfe67936…
Author: Andreas Boesl <ab(a)mathias-kettner.de>
Date: Wed Mar 5 17:48:22 2014 +0100
fixed typo
---
ChangeLog | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 3f6d7d3..9cca635 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -100,7 +100,7 @@
* 0674 brocade_fcport: Now supporting interface speed of 16 Gbit (just discovered in the wild)
* 0138 Removed caching function in Windows Update agent plugin...
NOTE: Please refer to the migration notes!
- * 0564 esx_vsphere_vm.datastores: displays the datastores of the vm...
+ * 0564 esx_vsphere_vm.datastores: displays the datastores of the VM...
* 0103 FIX: services: Fixed bug with service inventory defined in main.mk...
* 0299 FIX: borcade_mlx_fan: Prettified output, handling "other" state now
* 0300 FIX: cisco_fru_power: Trying not to inventorize not plugged in FRUs...
Module: check_mk
Branch: master
Commit: 2962fad36ab4f6d58975e12f28f2bcdbc254abbf
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=2962fad36ab4f6…
Author: Andreas Boesl <ab(a)mathias-kettner.de>
Date: Wed Mar 5 17:24:21 2014 +0100
fixed typo
---
.werks/564 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.werks/564 b/.werks/564
index a3ce3f4..ceae4b7 100644
--- a/.werks/564
+++ b/.werks/564
@@ -1,11 +1,11 @@
-Title: esx_vsphere_vm.datastores: displays the datastores of the vm
+Title: esx_vsphere_vm.datastores: displays the datastores of the VM
Level: 1
Component: checks
Version: 1.2.5i1
Date: 1394029082
Class: feature
-This check proviced information about any datastores the virtualmachine is running on.
+This check provices information about any datastores the virtualmachine is running on.
Reported fields are the name, the total capacity and the percentage of free space.
The check returns {OK}, unless the datastore information is missing.
Module: check_mk
Branch: master
Commit: e44705e7fd173e5577104dfddf94493cca1a7fa0
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=e44705e7fd173e…
Author: Andreas Boesl <ab(a)mathias-kettner.de>
Date: Wed Mar 5 15:20:00 2014 +0100
esx_vsphere_vm.datastores: displays the datastores of the vm
This check proviced information about any datastores the virtualmachine is running on.
Reported fields are the name, the total capacity and the percentage of free space.
The check returns {OK}, unless the datastore information is missing.
In this case it returns {UNKNOWN}.
---
.werks/564 | 12 +++++++
ChangeLog | 1 +
agents/special/agent_vsphere | 27 +++++++++++++--
agents/special/agent_vsphere.pysphere | 21 ++++++++++++
checkman/esx_vsphere_vm.datastores | 17 ++++++++++
checks/esx_vsphere_vm | 60 +++++++++++++++++++++++++++++++++
6 files changed, 135 insertions(+), 3 deletions(-)
Diff: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=e44705e7fd…
Module: check_mk
Branch: master
Commit: 1c50260a439cf7b2d3645c8ee8226aaf9396da47
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=1c50260a439cf7…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Mon Mar 3 17:18:36 2014 +0100
Removed obsolete white paper
---
doc/drafts/LIESMICH.rule_based_notifications | 182 --------------------------
1 file changed, 182 deletions(-)
diff --git a/doc/drafts/LIESMICH.rule_based_notifications b/doc/drafts/LIESMICH.rule_based_notifications
deleted file mode 100644
index ca2c751..0000000
--- a/doc/drafts/LIESMICH.rule_based_notifications
+++ /dev/null
@@ -1,182 +0,0 @@
-Ausgangspunkt: die "Flexible Notifications" von Check_MK sind einigermaßen
-flexibel und bieten schon mehr Möglichkeiten, als das Standard-Nagios.
-Allerdings gibt es etliche Situationen, in denen man noch mehr Flexibilität
-braucht. Ferner ist es so, dass bei einer größeren Zahl von Benutzern es
-sehr umständlich ist, für jeden Benutzer diese korrekt einzurichten.
-
-Das folgende Konzept soll diese Probleme lösen und für die Zukunft
-ausbaubar sein.
-
-REGELBASIERTE NOTIFIKATIONEN
-----------------------------
-Grundidee: Notifikationen werden - ganz ähnlich zur Event Console -
-von einem Regelwerk abgearbeitet, dass zunächst unabhängig von einem
-konkreten Benutzer ist. Der Ablauf ist dann wie folgt:
-
-1. In Nagios/CMC geschieht ein Host/Service-Alert.
-
-2. Ãœber einen Sammelbenutzer "checkmk-notify", der von allem Kontakt ist,
- wird eine Notifikation ausgelöst.
-
-3. Diese ruft wie gehabt "cmk --notify" auf. Dabei wird in einer Umgebungsvariable
- vom Core auch die Liste der (eigentlichen) Kontakte für diesen Service
- mitgeteilt. Bei diesen Kontakten selbst sind die Notifikationen ausgeschaltet,
- damit sie nicht doppelt versendet werden. Dafür sorgt WATO in der Benutzerverwaltung.
-
-4. Jetzt durchläuft das Ereignis eine Regelkette, die man mit WATO editieren kann.
- *Jede* Regel, die greift, wird ausgeführt. Dadurch wird festgelegt, welcher Benutzer
- über welches Plugin notifiziert wird.
-
-REGELN
-------
-Die Regeln sind ähnlich aufgebaut, wie bei der Event Console und werden ähnlich
-über ein eigenes WATO-Modul gepflegt. Jede Regel hat eine Bedingung und eine
-daraus resultierende Aktion.
-
-Die Bedingung kann formuliert werden über:
-
-Wie bei bestehenden "Flexible Notifications":
-* Ob eine bestimmte Timeperiod gerade aktiv ist
-* Eskalationsnummer
-* Service Level
-* Host/Service Event-Typ (down,up,unreach,OK,CRIT,etc.)
-* Host-Bedingung wie bei den WATO-Regeln, mit Tags und expliziten Ausnahmen
-* Service-Bedingungen wie bei den WATO-Regeln mit Regexen
-
-Neu kommt dazu:
-* Eventuell: Ausgangszustand bzw. kompletter Ãœbergang, also nicht
- nur "bei WARN", sondern bei "CRIT -> WARN".
-* Eventuell: Bedingung über den Typ des Checks (z.B. nur df)
-* Eventuell: enthalten in bestimmter Host oder Servicegruppe
-* Eventuell: enthalten in bestimmter Kontaktgruppe
-* Eventuell: bestimmter Kontakt ist zuständig
-* Eventuell: Wert von bestimmter Custom-Variable
-
-Wenn die Bedingung zutrifft, legt die Regel eine Aktion fest:
-
-* Wer soll Notifiziert werden?
- a) alle Kontakte des Hosts/Services
- b) explizite Liste von Kontakten
- c) Mitglieder einer bestimmten Kontaktgruppe
- d) Email/Pager-Adressen, die nicht Kontakt sind
- e) alle Kontakte
-
-* Mit welchem Plugin soll notifiziert werden?
-
-* Die Parameter dieses Plugins
-
-Die Aktion wird aber nicht sofort ausgeführt, sondern zunächst in
-einer Aktionsliste gespeichert. Diese ist eine Liste von Tupeln
-mit dem Aufbau
-
- Kontakt, Plugin, Parameter
-
-Und eine Checkbox: [ ] Kann vom Benutzer deaktiviert werden.
-(siehe Auschlussregeln)
-
-
-AUSSCHLUSS-REGELN
------------------
-Um besser Ausnahmen behandeln zu können, kann man Ausschluss-Regeln
-definieren. Hierzu wird die Regel wie gehabt aufgebaut, nur wird
-jetzt festgelegt, wer *nicht* notifiziert werden kann. Dabei ist die
-Reihenfolge der Regeln entscheidend. Beispiel:
-
-Regel 1 ...
-Regel 2 ...
-Regel 3 -> löst Notifikation an A und B mit Plugin P aus
-Regel 4 ...
-Regel 5 -> legt fest, dass B *nicht* über Plugin P notifiziert wird
-
---> Nur A wird mit P notifiziert.
-
-Achtung: Da - anders als z.B. bei der Event Console - immer *alle* Regeln
-ausgewertet werden, muss man hier die Ausnahmen *nach* den allgemeinen
-Regeln definieren. So können spätere Regeln frühere immer wieder revidieren.
-
-Auch bei Sperrregeln kann man ein Plugin auswählen. Dann werden nur die
-Notifikationen mit diesem Plugin gelöscht (um z.B. keine SMS zu bekommen).
-Wenn man kein Plugin auswählt, dann werden alle Notifikationen gelöscht.
-
-Positive Regeln und Ausschlussreglen können sich beliebig Abwechseln.
-Die Reihenfolge ist frei definierbar. Damit kann man z.B. erstmal alles
-zulassen, dann für eine Gruppe von Benutzern wieder abklemmen und
-dann für einen Benutzer doch wieder aktivieren.
-
-
-BENUTZER-REGELN
----------------
-Damit trotz allem Benutzer individuell etwas konfigurieren können, kann
-jeder Benutzer eigenen Regeln definieren. Diese sind analog aufgebaut.
-Allerdings ist bei der Frage *wer* notifiziert werden soll, nur der
-eigene Kontakt auswählbar. Ausschlussregeln sind aber möglich. Die Benutzer-Regeln
-werden immer *nach* den globalen Regeln ausgewertet.
-
-Der Benutzer kann somit:
-
-- Notifikationen hinzufügen
-- durch globale Regeln erzeugte Notifikationen abklemmen
-
-Merke: Der Benutzer kann so auch Notifikationen "abbonieren" für
-Hosts/Services, für die er im Nagios kein Kontakt ist!
-
-Notifikationen, die der Admin gesperrt hat (siehe oben), können vom
-Benutzer nicht abgeklemmt werden.
-
-
-
-FALLBACK
---------
-Wenn auf eine Notifikationsereignis keine einzige Regel greift, so wird
-stattdessen eine Email ein eine global einstellbare Default-Adresse
-versendet.
-
-
-UMSETZUNG IN WATO
------------------
-Im WATO sieht das ganze neue Konzept dann so aus:
-
-* Ãœber eine neue globale Option werden die regelbasierten
- Notifikationen eingeschaltet. Diese sind zunächst per Default aus,
- später (1.4.0) dann an.
-
-* Wenn sie an sind, dann ändert sich der Notifikations-Abschnitt
- bei den Benutzereinstellungen. Der aktuelle Block verschwindet
- komplett. Anstelle dessen kommt man über einen neuen Knopf auf
- eine eigene neue Seite, in der man die individuellen Regeln des
- Benutzers festlegen kann. Ein-/Ausschalten kann man die Notifikationen
- hier nicht. Das geht dann bei Bedarf über eine Regel.
-
-* Wenn bereits flexible Notifications konfiguriert waren, werden
- diese nicht automatisch in regelbasiert konvertiert. Die Einstellungen
- bleiben aber latent vorhanden für den Fall, dass man wieder zurückschaltet.
-
-* Ein neues WATO-Modul zeigt die globalen Notifikations-Regeln. Das
- gleiche Modul wird auch für die Benutzer-Individuellen Regeln leicht
- aberwandelt verwendet.
-
- In diesem Modul kann man Regeln anlegen, ändern, löschen und umsortieren -
- analog zur Event Console. Eventuell könnte man ein Simulationsfeld machen,
- mit dem man eine Notifikation ausprobieren kann. Das ist allerdings deutlich
- aufwendiger, als bei der EC, weil eine Notifikation deutlich mehr Datenfelder
- hat und die Logik dann in der GUI dupliziert werden muss.
-
-
-UMSETZUNG IN CHECK_MK
----------------------
-Das cmk --notify muss automatisch erkennen, dass es die regelbasierte
-Notifikation verwendet werden soll. Das kann z.B. am Kontaktnamen
-checkmk-notify festgemacht werden. Es führt dann das Regelwerk aus. Dieses
-ist zum einen in einer main.mk-Variable gespeichert, zum anderen in den
-individuellen contacts-Einstellungen. Es müssen bei jeder Notifikation
-alle Regeln aller Kontakte ausgeführt werden!
-
-im notify.log muss man bei entsprechendem Level wie bisher auch genau
-erklärt bekommen, warum jetzt welche Notifikation erzeugt oder verhindert
-wurde.
-
-Bei der Konfigerzeugung für Nagios/CMC muss man einen speziellen
-Benutzer anlegen, der für alles Kontakt ist.
-
-===> ACHTUNG: Es gibt jetzt ein englisches Dokument, das etwas aktueller
-ist und auch noch etwas zu den Bulk-Notifications schreibt.
Module: check_mk
Branch: master
Commit: cde60adac5a71eddea3f25a85eb883ba424fa01c
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=cde60adac5a71e…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Mon Mar 3 16:47:02 2014 +0100
FIX Fix multiple groups with same tag when grouping hosts after a tag
When you use the value of a specific host tag group for grouping in a view,
you got multiple times the same group. This has been fixed.
---
.werks/712 | 10 ++++++++++
ChangeLog | 1 +
web/htdocs/views.py | 8 +++++++-
web/plugins/views/painters.py | 9 ++++++++-
4 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/.werks/712 b/.werks/712
new file mode 100644
index 0000000..57b491f
--- /dev/null
+++ b/.werks/712
@@ -0,0 +1,10 @@
+Title: Fix multiple groups with same tag when grouping hosts after a tag
+Level: 1
+Component: multisite
+Class: fix
+State: unknown
+Version: 1.2.5i1
+Date: 1393861572
+
+When you use the value of a specific host tag group for grouping in a view,
+you got multiple times the same group. This has been fixed.
diff --git a/ChangeLog b/ChangeLog
index daea4b1..f1ae20a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -242,6 +242,7 @@
* 0670 FIX: LDAP: Fixed sync when non lower case attributes are configured...
* 0671 FIX: LDAP: Disable logging of password changes received from LDAP
* 0558 FIX: availability: fixed exception on specific filter settings...
+ * 0712 FIX: Fix multiple groups with same tag when grouping hosts after a tag...
WATO:
* 0308 Multisite can now set rotation view permissions for NagVis...
diff --git a/web/htdocs/views.py b/web/htdocs/views.py
index 934cbfa..1440bd1 100644
--- a/web/htdocs/views.py
+++ b/web/htdocs/views.py
@@ -2664,7 +2664,10 @@ def group_value(row, group_painters):
for p in group_painters:
groupvalfunc = p[0].get("groupby")
if groupvalfunc:
- group.append(groupvalfunc(row))
+ if "args" in p[0]:
+ group.append(groupvalfunc(row, *p[0]["args"]))
+ else:
+ group.append(groupvalfunc(row))
else:
for c in p[0]["columns"]:
group.append(row[c])
@@ -2677,6 +2680,9 @@ def get_painter_option(name):
return opt.get("value", opt['valuespec'].default_value())
def get_host_tags(row):
+ if "host_custom_variables" in row:
+ return row["host_custom_variables"].get("TAGS", "")
+
for name, val in zip(row["host_custom_variable_names"],
row["host_custom_variable_values"]):
if name == "TAGS":
diff --git a/web/plugins/views/painters.py b/web/plugins/views/painters.py
index 83d774b..69f6c45 100644
--- a/web/plugins/views/painters.py
+++ b/web/plugins/views/painters.py
@@ -1936,6 +1936,12 @@ def paint_host_tag(row, tgid):
return "", t[1]
return "", _("N/A")
+# Use title of the tag value for grouping, not the complete
+# dictionary of custom variables!
+def groupby_host_tag(row, tgid):
+ cssclass, title = paint_host_tag(row, tgid)
+ return title
+
for entry in config.wato_host_tags:
tgid = entry[0]
tit = entry[1]
@@ -1944,7 +1950,8 @@ for entry in config.wato_host_tags:
multisite_painters["host_tag_" + tgid] = {
"title" : _("Host tag:") + ' ' + tit,
"short" : tit,
- "columns" : [ "host_custom_variable_names", "host_custom_variable_values" ],
+ "columns" : [ "host_custom_variables" ],
"paint" : paint_host_tag,
+ "groupby" : groupby_host_tag,
"args" : [ tgid ],
}