Checkmk Enterprise Edition 2.4.0p20
Hallo,
ich wollte mir eben einmal anzeigen lassen, bei welchen Hosts ich eingestellt habe, dass sie nicht gemonitort werden. Also schwubs eine View gebastelt, die den Hostnamen und den Host Tag Criticality anzeigt (Bild 1).
Es werden auch viele Hosts angezeigt. Aber nicht einer bei dem Criticality auf “Do not monitor this host” steht. Obwohl es mindestens einen Host gibt (Bild 2).
Ist das ein Bug im System oder sitzt der Bug vor der Tastatur?
Danke
Stephan
Hi,
das ist “works-as-designed”. “Do not monitor” heißt genau das: Den Host nicht überwachen. Daher taucht er dann auch nicht mit ping oder anderen Checks im Monitoring auf. Das wird gesteuert über die Regel “Hosts to be monitored”, die auf dieses Host-Tag greift.
Viele Grüße, Dirk.
Wenngleich die Antwort natürlich stimmt und das genau so soll, wirft die Originalfrage ein Licht auf eine Schwachstelle, den ich persönlich auch wirklich wirklich bedauere: keinerlei Filter- bzw. erweiterten Suchmöglichkeiten im WATO-Teil vom Interface. Im Monitoring-Interface kann man diese komplexen Filter bauen und sich damit auf die gerade relevanten Hosts anzeigen lassen, aber dann kann man auf diese Hostmenge keine Config-Massenänderungen durchführen. Oder für sie keine neue Regel anlegen.
Gerade gestern hatte ich den Fall, dass mich ein Kollege gebeten hat, ungefähr 25 Hosts einer veralteten Umgebung zu löschen. Er hatte für all diese eine Downtime gesetzt. Im Monitoring-Teil trivial herausgefiltert — aber die Hosts befanden sich in Summe in sieben verschiedenen Ordnern in der WATO. Und in den Ordnern waren auch noch Hosts, die beibehalten werden sollten.
Die »beste« Lösung war, im Monitoring-Teil jeden Host einzeln in einem neuen Tab zu öffnen, dort ins »Host«-Menü → »Host configuration«, dort »Host«-Menü → »Delete host«.
Es wäre so cool, im Monitoring-Teil eine Menge von Hosts herausfiltern und an die WATO übergeben zu können, um dort dann die üblichen Massenänderungen machen zu können (mit Checkboxen Teile davon auswählen, Hosts löschen/verschieben/umkonfigurieren etc. etc.). Oder eine neue Regel für sie anzulegen, und die vorher ausgewählten Hosts werden automatisch als »Regel gilt für diese Hosts…« eingetragen.
Alternativ: in der WATO dieselben Filtermöglichkeiten wie im Monitoring-Teil zu haben. Idealerweise: beides.
Hallo Dirk,
das ist ja schön und gut. Aber wenn ich eine Liste aller Host anzeigen lasse sollten wirklich alle darin sein.
Oder es muss ein Übersicht geben das alle “nicht Monitoren” anzeigt. Die Alternative wäre ja eine Liste zu pflegen wo ich die Hosts erfasse.
Ich muss jetzt also jeden Ordner durchgehen und schauen ob irgendwo ein Host steht der nicht überwacht wird.
Hallo Stephan.
Die Konfiguration und die Livestatus-Daten sind zweierlei Dinge. Views bedienen sich der Daten aus dem Livestatus und zeigen auch nur Systeme, die in den Livestatus liefern. Wenn ein Host auf “Do not monitor” gesetzt ist, hat der Core keine Konfiguration für diesen Host und fragt ihn natürlich auch nicht ab. Möchtest du eine Liste der Hosts haben, die auch die “Do not monitor” (offline) Hosts beinhaltet, dann lese die Host mittels RestAPI aus.
Viele Grüße,
Christian
In unserer Umgebung haben wir einen Top-Level-Ordner, an dem das Attribut “Do not monitor this host” klebt und immer, wenn wir einen Host aus der Überwachung nehmen wollen, schieben wir ihn in diesen Ordner. (Tatsächlich haben wir unsere gesamte Ordnerstruktur verdoppelt: einmal mit und einmal ohne dieses Attribut. Wir schieben dann die Hosts jeweils vom Ordner "Aktiv/X/Y/Z" nach "Stillgelegt/X/Y/Z".)
Aber abgesehen davon kann man sich die nicht überwachten Hosts doch auch mit Setup → Hosts → Display → Search hosts in einer Liste anzeigen lassen. Und diese Suche kann man sich ja sogar bookmarken.
Hallo Dirk,
Du bist mein Held. An Setup → Hosts → Display → Search hosts habe ich überhaupt nicht gedacht.
Auch die Idee, einen eigenen Ordner dafür anzulegen, finde ich nicht schlecht.
Danke für die guten Vorschläge.
Stephan
Hallo Stephan,
gerne doch. Bei Search hosts muss man leider immer ein bisschen aufpassen, weil das nicht immer zuverlässig funktioniert. Aber in diesem Fall tut es das.
Wenn wir damit z.B. nach Hosts mit einem bestimmten Hostlabel suchen, werden uns random irgendwelche Hosts angezeigt, und manche haben sogar das gesuchte Label, aber es sind auch etliche falsche dabei.
Das scheint mir ein Bug in checkmk zu sein. Ich bin auf der 2.3.0p40.cee, aber ich glaube, das ging noch nie richtig.
Gruß Dirk
Hallo Dirk,
ich werde das mit “Search hosts” einmal prüfen.
Schlimm finde ich, dass sogenannten “Checkmk Partner” wieder einmal nicht helfen konnten.
Immer nur die „Standardantworten“.
Als Enterprise-Kunde finde ich es extrem traurig, dass solche Firmen „Partner“ von checkmk sind.
Gruß
Stephan
Hallo Christian.
Auch wenn Dein Posting keine Antwort auf meine Frage ist.
Mache ich doch gerne. Sicher kannst Du mir sagen, was ich machen muss?
Als Nicht-Partner ebenfalls zahlender Kunde finde ich deine Aussage ziemlich arrogant. Für mich ist es bizarr zu denken, irgend jemand wüsste auf jede Frage die perfekte Antwort. Es ist generell anmaßend zu erwarten, dass in einem Forum, das auf freiwilliger Arbeit basiert, dir irgend jemand eine Antwort schuldet. Wenn du Antworten erwartest, dann mach ein Ticket bei Checkmk-der-Firma auf; als Enterprise-Kunde hast du ja auch Support dabei, für den du bezahlst.
Antworten dieser Art verleiten mich nur dazu, mich von Threads des Fragestellers in Zukunft fernzuhalten.
Hallo Stephan.
Über die API hast du die Möglichkeit dir alle Hosts mit ihren Eigenschaften abzufragen. Ich nutze diese Abfrage um z.B, mir eine CSV-Datei zu erzeugen, um diese ggf. zum Verwalten oder umziehen von Hosts zu verwenden. Hier das Beispiel für die Abfrage aus der Doku:
#!/usr/bin/env python3
import pprint
import requests
HOST_NAME = "localhost"
SITE_NAME = "mysite"
PROTO = "http" #[http|https]
API_URL = f"{PROTO}://{HOST_NAME}/{SITE_NAME}/check_mk/api/1.0"
USERNAME = "automation"
PASSWORD = "test123"
session = requests.session()
session.headers['Authorization'] = f"Bearer {USERNAME} {PASSWORD}"
session.headers['Accept'] = 'application/json'
resp = session.get(
f"{API_URL}/domain-types/host_config/collections/all",
params={ # goes into query string
"effective_attributes": True, # Show all effective attributes on hosts, not just the attributes which were set on this host specifically.
"include_links": False, # Flag which toggles whether the links field of the individual hosts should be populated.
"fields": '!(links)', # The fields to include/exclude.
"hostnames": ['host1', 'host2'], # Filter the result by a list of host names.
"site": 'site1', # Filter the result by a specific site.
},
)
if resp.status_code == 200:
pprint.pprint(resp.json())
else:
raise RuntimeError(pprint.pformat(resp.json()))
Ich habe effective_attributes auf True gesetzt um alle Felder zu bekommen. Die wichtigen Daten stehen dann unter dem Key “extensions”.
VG, Christian
Hallo Christian,
vielen lieben Dank für das Beispiel. Ich denke, damit kann ich mich reinarbeiten.
Viele Grüße
Stephan
Ergänzend hier noch der Tipp in die Runde, dass man bei Hosts → Display → Search hosts auch dort eine Tilde ~ voranstellen kann, um nach regex-Ausdrücken zu suchen, falls die normale Suche mit teilqualifiziertem Match nicht genügt.
Passt nicht direkt zur Ursprungsfrage, fand ich zur Host-Suche in Setup aber super hilfreich, als mir jemand den Tipp mal genannt hat.
Danach ist dann wie üblich Bulk-Edit oder Bulk-Delete auf die Ergebnisse möglich. Löschauftrag mit Hostnamen z.B. von Excel oder einer Komma-Liste konvertieren in regex ^(host1|hostabc|hostblah)$ und man hat das passende Ergebnis für Bulk-Delete
Wer Notpad++ verwendet: CTRL + j (für “join”) konvertiert mehrere Zeilen in eine einzelne Leerzeichen-getrennte Zeile. Dann Suchen/Ersetzen Leerzeichen zu Pipe |
Regex-Ausdruck über CTRL + j erstellen und in Hosts → Display → Search mit Tilde nach regex suchen war schon oft eine fantastische Zeitersparnis für mich. 
Viele Grüße, Dirk