Module: check_mk
Branch: master
Commit: 48b7590c8958d66c16dac1e7e6717c8f412c4ca2
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=48b7590c8958d6…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Fri Dec 17 08:29:08 2010 +0100
Updated internal doku
---
LIESMICH.zutun | 79 +++++++++++++++++++++++++------------------------------
1 files changed, 36 insertions(+), 43 deletions(-)
diff --git a/LIESMICH.zutun b/LIESMICH.zutun
index 3dac633..ec2d693 100644
--- a/LIESMICH.zutun
+++ b/LIESMICH.zutun
@@ -338,16 +338,16 @@ Auf diese Art funktioniert erstmal alles weiter. Trotzdem wird die Variable
irgendwann planmäßig abgeschaltet.
View options für Painter: Ein Painter hat eine Liste von Painter-Viewoptions.
-Dazu gibt es ein dict: painter_view_options["pnpsource"] = {
-( "PNP Timerange", "1", [("0":"4 hours"), ("1", "24 hours"), ... ] )
-Vor dem Anzeigen des Layouts ermittle ich alle benötigten View-Options.
-Analog zu refersh mache ich Persisitierung und HTML-Variablen-Auswertung
-und komme zu einem Ergebnis. Das speichere ich dann in view_option["pnpsource"].
-Dies kann der Painter einfach abfragen. Einsatz: PNP-Zeitraum, Darstellung
-von Zeitstempeln (Delta/Absolute/Mixed).
+Dazu gibt es ein dict: painter_view_options["pnpsource"] = { ( "PNP Timerange",
+"1", [("0":"4 hours"), ("1", "24 hours"), ... ] ) Vor dem Anzeigen des
+Layouts ermittle ich alle benötigten View-Options. Analog zu refersh
+mache ich Persisitierung und HTML-Variablen-Auswertung und komme zu einem
+Ergebnis. Das speichere ich dann in view_option["pnpsource"]. Dies kann der
+Painter einfach abfragen. Einsatz: PNP-Zeitraum, Darstellung von Zeitstempeln
+(Delta/Absolute/Mixed).
-Multisite: Wenn man bei einer View einen Filter ausfüllt (user), dann
-soll irgendwo ein Icon anzeigen, dass das Resultat gefiltert ist.
+Multisite: Wenn man bei einer View einen Filter ausfüllt (user), dann soll
+irgendwo ein Icon anzeigen, dass das Resultat gefiltert ist.
Multisite: Hover: Wenn man über einen Painter geht, könnte man eine
Hover aufmachen, der einen weiteren Painter anzeigt. Das macht man
@@ -408,8 +408,8 @@ FreeBSD Agent:
Die Sektionen/Checks ps und postfix_mailq sind jetzt schon kompatibel.
Idee: Bei SNMP-Checks gibt es manchmal Daten, die sich dynamisch nicht ändern
-(z.B. Interfacenamen, etc.). Man könnte diese Daten cachen, so dass sie nicht
-jedes mal geholt werden, sondern z.B. nur alle 10 Minuten.
+(z.B. Interfacenamen, etc.). Man könnte diese Daten cachen, so dass sie
+nicht jedes mal geholt werden, sondern z.B. nur alle 10 Minuten.
IDEE: Prefetching agent: Der agent soll die Daten schon berechnen kurz bevor
sie abgefragt werden. Das ganze läuft so: Zunächst ermittelt der Agent,
@@ -433,12 +433,12 @@ Livestatus: Spalte bei Services und Hosts, die das ausgeführte Kommando
Multisite: Spalte, die das Kommando (die Befehlszeile) ausgibt.
-Multisite: Man soll über eine Variable die URL für die rechte
-Seite mitgeben können. So kann man direkt auf eine Unterseite
-verlinken. Evtl. das sogar abrufbar über ein Icon :-)
+Multisite: Man soll über eine Variable die URL für die rechte Seite mitgeben
+können. So kann man direkt auf eine Unterseite verlinken. Evtl. das sogar
+abrufbar über ein Icon :-)
-Livestatus: Informationen ueber Eskalationen ausgeben (eigene Tabelle
- oder Anreicherung von contacts, hosts, services)
+Livestatus: Informationen ueber Eskalationen ausgeben (eigene Tabelle oder
+Anreicherung von contacts, hosts, services)
IPv6-Support in Check_MK:
def lookup_ipaddress(hostname):
@@ -459,41 +459,31 @@ def lookup_ipaddress(hostname):
Ausserdem kommt check_icmp damit nicht klar. Hier muss dann auf
check_ping ausgewichen werden.
-Wenn eine IP-Adresse nicht aufgelöst werden kann, sollte stattdessen
-eine (konfigurierbare) Dummyadresse verwendet werden. Sonst
-scheitert check_mk -O, wenn ein DNS-Eintrag verschwindet.
+Wenn eine IP-Adresse nicht aufgelöst werden kann, sollte stattdessen eine
+(konfigurierbare) Dummyadresse verwendet werden. Sonst scheitert check_mk -O,
+wenn ein DNS-Eintrag verschwindet.
-Livestatus: neben custom_variable_names und custom_variable_values
-waere noch custom_variables huebsch, welches beides kombiniert.
+Livestatus: neben custom_variable_names und custom_variable_values waere
+noch custom_variables huebsch, welches beides kombiniert.
+
+Disk IO read/write: Zu einem Check zusammenfassen. Einen gemeinsamen Graphen
+mit dem Windows-Check erstellen (wo ein Graph eh fehlt).
-Disk IO read/write: Zu einem Check zusammenfassen. Einen gemeinsamen
-Graphen mit dem Windows-Check erstellen (wo ein Graph eh fehlt).
-
Multisite: Quicksearch evtl. case-insensitive machen?
Livestatus: StatsGroupBy: mehrere Spalten erlauben
-Multisite: Die TOP-25 Alerts: Welche Dinge hosts/services
-hatten in einem Zeitraum die meisten Alerts. Das geht
-mit log und StatsGroupBy: host_name service_description
-
-Multisite: Filter, der Hosts zeigt, die entweder selbst
-Summary hosts sind oder keinen haben.
+Multisite: Die TOP-25 Alerts: Welche Dinge hosts/services hatten in einem
+Zeitraum die meisten Alerts. Das geht mit log und StatsGroupBy: host_name
+service_description. Dazu muss ich allerdings zuerst eine Gruppierung nach
+mehr als einem Feld einbauen.
-Multisite: Könnte man nicht Aggregationen in Views einbauen.
-Man würde dann in der View Regeln definieren, nach denen
-Services und Hosts aggregiert werden können. Dazu müsste man
-in den View-Editor einen neuen Abschnitt einbauen. Ist das
-nicht ähnlich wie Gruppieren? Allerdings wäre es dann gut,
-wenn man die Aggregationen irgendwo separat editieren kann
-und in der View nur noch drauf verweisen. Sonst muss
-man soviel Copy&Paste zwischen den Views machen...
+Multisite: Filter, der Hosts zeigt, die entweder selbst Summary hosts sind
+oder keinen haben.
-Idee: Checks, die eigentlich keine Perfdaten liefern, könnten
-über eine Konfiguration künstlich perfdaten bekommen, ala
-status=0, status=1 etc. Das könnte man über eine Regel
-konfigurierbar machen:
-fake_perfdata = [ ... ]
+Idee: Checks, die eigentlich keine Perfdaten liefern, könnten über eine
+Konfiguration künstlich perfdaten bekommen, ala status=0, status=1 etc. Das
+könnte man über eine Regel konfigurierbar machen: fake_perfdata = [ ... ]
Idee: Inventurcheck könnte gleich die Checkergebnisse berechnen
@@ -513,6 +503,9 @@ Snapins: die letzten 10 Notifikationen, die letzten 10 Alerts
(evtl. umschaltbar per Tabs)
Acknowledgements: Ankreuzung, ob persistent oder nicht
+Hm. Komisch. Im Code sehe ich, dass ich für persistent eine 0
+setzen. Trotzdem bleibt das Acknowledgment über einen Nagios-
+Neustart erhalten.
Tactical Overview: Man könnte folgendes machen: Die Kästchen
enthalten ja Links zu Views, welche die entsprechenden Probleme
Module: check_mk
Branch: master
Commit: c5efa7111e366afec15bdec5403db6b041707369
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=c5efa7111e366a…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Thu Dec 16 14:07:41 2010 +0100
updated internal doku
---
LIESMICH.zutun | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/LIESMICH.zutun b/LIESMICH.zutun
index 0adf60e..8b21e5f 100644
--- a/LIESMICH.zutun
+++ b/LIESMICH.zutun
@@ -15,9 +15,6 @@ aber erst, wenn eine stabile Version das ALL_SERVICES erlaubt!
Livestatus: is_contact_member_of_contactgroup selbst programmieren,
da diese Funktion in Nagios rausfliegen wird.
-Multisite: Kontextknöpfe Services: OK, Services: Crit usw. unsichtbar
-machen. Dazu einen neue View-Option einbauen (hide context button).
-
Inventurcheck: retry_interval evt. anders (kuerzer) einstellbar machen.
Das geht aber auch mit extra_service_conf. Evtl. reicht hier die Doku.
Ein sinnvoller Default-Wert wäre aber schon gut.
Module: check_mk
Branch: master
Commit: 5dbfbc1be6d20a1b605ecfe2f5074f9f87f17ddb
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=5dbfbc1be6d20a…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Thu Dec 16 16:47:49 2010 +0100
Updated internal doku
---
LIESMICH.zutun | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/LIESMICH.zutun b/LIESMICH.zutun
index 8b21e5f..413c32d 100644
--- a/LIESMICH.zutun
+++ b/LIESMICH.zutun
@@ -439,15 +439,10 @@ Livestatus: Spalte bei Services und Hosts, die das ausgeführte Kommando
Multisite: Spalte, die das Kommando (die Befehlszeile) ausgibt.
-Multisite: Eine konfigurierbare URL für die Startseite (also
-alternativ zum rechten Startframe.
-
Multisite: Man soll über eine Variable die URL für die rechte
Seite mitgeben können. So kann man direkt auf eine Unterseite
verlinken. Evtl. das sogar abrufbar über ein Icon :-)
-Multisite: icon_image von Nagios sollte angezeigt werden
-
Livestatus: Informationen ueber Eskalationen ausgeben (eigene Tabelle
oder Anreicherung von contacts, hosts, services)
Module: check_mk
Branch: master
Commit: bbe36899b6fd3a612e9faa008f21cc0aab39dc4e
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=bbe36899b6fd3a…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Thu Dec 16 10:33:49 2010 +0100
updated internal doku
---
LIESMICH.zutun | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/LIESMICH.zutun b/LIESMICH.zutun
index 9e01a84..0adf60e 100644
--- a/LIESMICH.zutun
+++ b/LIESMICH.zutun
@@ -87,10 +87,6 @@ die ganze Implementierung der Tabs nochmal anders programmiere. Das ist viel
zu kompliziert gelöst. Ich mache die Tabs doch mit Tabellen und -moz-rounded-border.
IE hat einfach Pech gehabt und bekommt eckige Kanten.
-Logwatch: was macht man hier bei verteilten Umgebungen?? Muss man das wie
-PNP per Proxy anfahren? Was ist aber dann, wenn man dort rumklickt? Dann hat
-man rechts plötzlich ein anderes System. Lösung ist noch nicht in Sicht.
-
LARS: Bei Opera kann man kein Snapin nach ganz unten ziehen. Der Indikator
springt dann immer nach ganz oben.
@@ -118,9 +114,6 @@ SNMP Version pro Host erkennen und speichern. Man könnte als erstes mit v2
versuchen und wenn das nicht geht auf v1 umschalten. Falls das nicht geht, dann
kann man eben kein SNMP machen.
-PNP4Nagios-Popups automatisch einbauen, mit eigenen intelligenten
-Icons.
-
Aliasse einbauen (Wrappen in bin/):
cmk = check_mk
mkp = check_mk -P