Posts by fx998

This forum was archived to /woltlab and is now in read-only mode.
    Quote

    cmk --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):


    Code
    1. # omd su YOURSITE
    2. OMD[YOURSITE]~$ echo -e "GET hostgroups\nColumns: name\n\n" | unixcat tmp/run/live 2>/dev/null

    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:


    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:


    • Es gibt wohl ältere Perlbasierte Checks, die sehr viel Resourcen brauchen(Information von MK-Webseite)
    • Es gibt wohl neuere VSphere-Checks die besser sein sollen(Information von MK-Webseite). Dort steht auch beschrieben, dass die generelle Situationen aufgrund von Restriktionen des /proc - Dateisystems bei VMWare wesentlich schwieriger geworden ist
    • Ein Bekannter sagt mir, dass er keine SMART/RAID-Informationen aus einem VMWare-Host auslesen kann. Er hat deswegen ein zusätzliches Monitoringtool für VMWare eingeführt(Das würde ich gerne möglichst vermeiden).

    Wie ist Eure Erfahrung dazu?

    • RAID/SMART-Checks sind für mich sehr wichtig. Kommt man an die Daten ran?
    • Kann man da individuelle local/agent-based Checks einrichten?
    • Gibt es sonst besondere Hürden beim Monitoring von ESXi - Hosts?
    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. :)

    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.

    Das kannst Du Dir einfach via Livestatus selbst basteln.


    Beispiel:


    Code
    1. echo -e "GET services\nColumns: host_name display_name \nFilter: state > 1 \n\n" \
    2. | unixcat tmp/run/live 2>/dev/null \
    3. | wc -l \
    4. | { read errors ; if [ $errors -eq 0 ]; then echo "(mailkommando): alles ist gut";fi ;}


    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."

    Quote

    Nur 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:

    Code
    1.     if_inventory_uses_alias = True


    Bei neueren Check_MK - Versionen sollte das wohl auch direkt über WATO gehen mit diesen globalen Einstellungen

    Code
    1. > Use description as service name for network interface checks
    2. > Use alias as service name for network interface checks

    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:

    Code
    1. omd su YOURSITE
    2. cmk -II
    3. cmk -R

    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


    [Blocked Image: http://i.imgur.com/3mMoxFL.png]

    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.

    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:


    • Text (Regex)
    • Host
    • source IP
    • syslog(TAG,PRIO,FACILITY,LEVEL)
    • service level
    • time period


    Bei den Shellscripten kann man diese Variablen auswählen.


    • $ID$
    • $APPLICATION$
    • $STATE$
    • $HOST$
    • $TEXT$
    • ...

    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?