The cause of the error message is a missing library.
Check the following:
This should give you at least one error message.
Figure out to which Debian Package the files belong to(with dpkg -S or apt-file) and install(if installed --> reinstall with apt-get install --reinstall ) the package.
Quotecmk --list-hosts [Gruppe]
Grundsätzlich sollte das gehen. Ich würde mal von einem Tippfehler beim Gruppennamen ausgehen.
Vielleicht nochmal genau den Namen prüfen, auch mit dieser Livestatusabfrage(Geht natürlich nur, wenn Livestatus aktiv ist):
Ansonsten wäre für alle Abfragen an das Check_MK Monitoring LiveStatus genau das richtige. Dort kannst Du Dir alle Informationen im Detail holen.
Siehe auch:
https://mathias-kettner.de/checkmk_livestatus.html
Im Übrigen ist Livestatus auch viel performanter als der cmk Befehl:
Beispiel:
War das bei Windows nicht, so, dass man im Task-Manager eine Applikation fest einem Core zuordnen kann? (Wäre vielleicht brauchbar, für Tests).
Hallo zusammen,
ich möchte gerne in die Virtualisierung mit VMWare einsteigen. Eine Aufgabe dabei ist, zu prüfen, wie die Monitoringsituation mit Check_MK da ist und mir diesbezüglich einen Überblick zu verschaffen. Folgende Erkenntnisse habe ich bis jetzt:
Wie ist Eure Erfahrung dazu?
Du kannst Dir selbst einen local Check schreiben. Vorausgesetzt, du hast irgendein Programm, dass Dir die gewünschte Information liefert, sollte das nicht all zu schwer sein.
Von Windows-Checks habe ich allerdings überhaupt keine Ahnung. Kann aber auch nicht so schwer sein.
Quote...xinetd...
...user=nobody...
Schön zu lesen. Dann braucht man sich also ggf. nur noch um Plugins zu kümmern, sofern man beim Setup da nicht drauf geachtet hat.
Auch wenn es Deep 911 zuerst erwähnt hat: Schlage vor Lucky den Titel "Monitoring-Portal-Check_MK-Gott" zu verleihen. 
Ich kann mir nicht vorstellen, dass der Agent ohne root-rechte auch nur ansatzweise an seine Daten kommt.
Ich hab's gerade mal getestet. Da kommen doch schon recht viele Informationen raus.
Der Agent prüft sehr vieles, was mit Hardware zu tun hat. Dort werden meist umfangreiche Rechte benötigt.
Für eine Umstellung auf einen Benutzeraccount müsste man das check_mk_agent Script Zeile für Zeile durcharbeiten, prüfen wo erhöhte Zusatzberechtigungen erforderlich sind und sich Alternativen überlegen, nur die Rechte zu geben, die wirklich erforderlich sind oder manche Checks weglassen. Das wird bestimmt sehr viel sein. Das gleiche für alle Plugins und local checks.
Huch. Tippfehler. Sollte heissen "state > 0".
Das kannst Du Dir einfach via Livestatus selbst basteln.
Beispiel:
Ansonsten - IMHO:
Ich wünsche mir von einem Monitoring eher, dass es ruhig ist, wenn alles gut ist und wenn etwas ist, dass es sich dann aber auch wirklich meldet. Dazu gehört dann natürlich auch das Monitoring für das Monitoring. Denn wenn das Monitoring kaputt ist, dann kann es natürlich auch keine Mails schicken
zu "hosted by netways :)"
Das ist für mich absolut problemlos und heisst für mich "Ich habe deine Signatur gelesen, dass Du dort arbeitest als icinga-Entwickler, bei der Firma die Icinga entwickelt und wundere mich deswegen nicht, dass Du von icinga begeistert bist."
QuoteNur damit man ungefähr ein Gefühl dafür bekommt, wo du letztendlich hinwillst, solltest du eine Migration in Betracht ziehen.
Also migrieren möchte ich meine Umgebung erst einmal gar nicht. Hier gibt's noch ausreichend Luft durch mehr Hardwarepower. Mir geht's eher um ein Kundenprojekt, das derzeit mit plain Nagios aufgesetzt ist und ca. 25000 Geräte umfasst und im Laufe der nächsten Jahre angegangen werden soll. Es braucht ca. 1 Stunde für einen Restart und wird mit diversen Scripten krude irgendwie generiert. Die Performance kann mit Check_MK auch nicht besser werden, ist ja schliesslich auch nur Nagios als Kern drunter.
Quote
Mich würde an der Stelle interessieren, welche Server das sind, und ob du ungefähr einen Überblick geben kannst, welche Services und Plugins das sind.
Mein eigenes Check_MK ist eher hystischerisch gewachsen - aber bei weitem nicht so schlimm, wie die Phrase meinen könnte. Am Anfang hatte ich da noch nicht so den ganz den Blick auf die Performance als später, deswegen sind da auch perl, python, lua und bash checks mit drin, und wahrscheinlich alle nicht so hochoptimiert, wie Sie sein könnten. Auch werden eine steigende Anzahl an - hauptsächlich clientbasierten - Einzelchecks durchgeführt. Refaktoring lässt grüssen. Ansonsten bin mit ich damit, was die Flexibilität, den Nutzungskomfort, das effiziente Interface und die Stabilität betrifft hochzufrieden. Was das andere Projekt betrifft, da bin ich selbst auch noch nicht umfassend informiert.
Quote
Dass ich dir Icinga 2 ans Herz lege, ist dir ohnehin klar.
monitoring-portal: hosted by netways
---
Bei der Grössenordnung darf man sich vorher einiges an Gedanken machen. CMDB ist wohl vorhanden/im Aufbau. Deployment ist im Einsatz(Chef). Und gerade mit moderner Log-Verarbeitung(Graylog/ELK/....) sehe ich einen grossen Gewinn. Es gibt auch eine ganze Reihe von Personen, die das Monitoring nutzen werden: Zentrale Admins, Anwendungsbetreuer der verschiedenen Kunden.
Hi,
sorry für das ausgraben des alten Threads. Aber für mich ist das nach wie vor aktuell.
Ich schätze und benutze Check_MK sehr gerne und für kleine bis mittlere Instanzen finde ich das ganze absolute klasse(siehe oben).
Doch wenn es gross wird, dann wird es da schwieriger. In der Open Source Variante ist der Nagios-Kern drunter unter der ist nun mal um einiges langsamer als Icinga2 ( Das ist jetzt meine Vermutung von einigem an Recherche zum Thema. ) Man kann die Hardware noch bis zum Anschlag hochdrehen und muss auch bei den implementierten Checks auf die Performance achten(sollte man sowieso immer).
Mein Hauptmonitoringsystem umfasst derzeit ca. 200 Server mit ca. 8000 Checks. Unten drunter ist ein etwas älterer Core i7 als virtuelles(8 Vcores) System der auf Dauer-CPU-Last von 50% liegt mit einer Dauer-Load zwischen 7-11. Und 200 Server ist jetzt mal gar nicht mal so viel.
Man kann zwar auch noch auf die Enterprise Edition gehen. Doch da wird's dann halt teuer.
Was sagen die Icinga2- und Check_MK-Kenner dazu?
Ich habe bei mir in /omd/sites/MYSITE/etc/check_mk/main.mk diese Variable gesetzt:
Bei neueren Check_MK - Versionen sollte das wohl auch direkt über WATO gehen mit diesen globalen Einstellungen
Danach vermutlich alle Hosts neu inventarisieren. Dabei würde ich vorsichtig sein. Wenn Du vieles manuell eingestellt hast, kann es sein, dass Du hier diese Einstellungen verlierst. Deswegen vielleicht erst mal 1-3 Hosts manuell neu inventarisieren, schauen, ob da irgendwas komisch ist und anschliessend alle per Konsole:
Ich bin mir nicht sicher, ob man da nicht was umstellen musste, dass die Interface checks nicht mehr "Interface 0, Interface 1,..." heissen sondern "Interface eth0, Interface br0,...". Das ist in jedem Fall die Voraussetzung für das ausblenden von Interface-Checks basierend auf deren Namen.
Bei mir sieht das dann so aus(check_mk 1.2.8p11):
[Blocked Image: http://i.imgur.com/KIEVSP7.png]
Regel: Monitoring Configuration -> Disabled Services
xinetd ist auch installiert.
So sieht meine /etc/sysconfig/iptables aus:
Zeile 6 ist die relevante Zeile und 1.2.3.4/32,1.2.4.0/24 sind ein paar Beispieladressen die zugreifen dürfen.
XenServer hat Firewallregeln in der Grundinstallation aktiv. Port 6556 muss in jedem Fall vor Nutzung von Check_MK zugelassen werden.
Die Konfiguration erfolgt bei mir bei beiden Versionen(6.5+7.x) über die Datei /etc/sysconfig/iptables. Die 7.x wurde allerdings aktualisiert. Kann sein dass das bei nativen Installation jetzt anders ist. Beim neuen Unterbau CentOS 7 wird ja jetzt grundsätzlich "firewall-cmd" verwendet.
Ok. Ich habe jetzt gesehen, dass es eine Einstellung "Enable Syslog Style log" gibt. Damit sehe ich in der mkeventd.log das Syslog-format.
Was mich sehr irritiert, ist das in der EventConsole bei der Regelerstellung(Eventconsole -> Rule Packs -> New Rule) andere Variablen für die Mustererkennung auswählbar sind, als die Parameter, die man den Shellscripten bei den Actions dann weiter gibt.
Bei der Regel kann man folgende Kriterien auswählen:
Bei den Shellscripten kann man diese Variablen auswählen.
Letzteres sieht so nach Nagios-Macros aus.
Was mich irritiert ist, was hat das mit den syslog-Geschichten da auf sich? Ja. Ich weiss was diese Syslog-Begriffe bedeuten, aber auf welche Logdateien beziehen sich diese Regeln? nagios.log? mkeventd.log? In den beiden Dateien sehe ich kein Syslog-Style-Format. Und die Variable "Text" im Rule-Match ist wohl nicht identisch mit dem Macro $TEXT$ des Scriptargumentes - oder aber es ist identisch wobei der Text alleine dann darin reicht nicht aus um die Regel sicher zu identifizieren.
Was helfen würde, wäre auch, wenn man die Syslog-Variablen, die für das Matching verwendet werden, auch dem Script übergeben kann. Dann könnte ich mir das ausgeben lassen und sehe wenigstens Mal was dort drin steht.
Was mir im Moment als sinnvolle Option nur bleibt, ist einen Wildcard-Match zu verwenden und alles weitere in einem Script zu regeln, dass dann Zugriff auf alle wichtigen Variablen und somit die wichtigen Daten haben kann.
Ich hänge mich hier mal dran, weil ich ein zugehöriges Problem hatte bzw. habe, dass noch nicht zufriedenstellend gelöst ist.
Ich möchte bei mir auch erst nach einer gewissen Zeit die Benachrichtigungen haben. Und dann möchte ich auch die Wiedererreichbarkeitsmail haben.
Das Problem was ich nun hatte, ist, dass die Störungsmeldungen brav verzögert kamen. Aber die Wiedererreichbarkeitsemails kamen auch für alle Störungen, die den Schwellwert bzgl. der Dauer der Verzögerung nicht erreicht haben. D. h. ich bin mit Wiedererreichbarkeitsemails zugeballert worden. Was ich eigentlich möchte sind nur die Wiedererreichbarkeitsmails für die auch eine Störungsmail(Crit,Unknown,Warn) versendet wurde.
Kennt Ihr das Problem auch oder gar eine Lösung dafür?
