Ich wollte mir mal die Expertise und den Erfahrungsaustausch zu dem Debuggen der Fetcher holen. Gibt es dort außer den üblichen Verdächtigen:
/omd/sites/[sitename]/var/log/*.log
oder
->Monitor->Service Check Duration
noch andere Möglichkeiten das Ganze sich anzuschauen. Ich habe unter der Version 2.0.0p6 auch schon den Vorversionen auf einer Site den Fetcher auf 99% bis 100% laufen. Was eher nicht optimal ist. Ich möchte nun wissen was den so zu müllt und warum.
Die Global Settings geben auch nur “Debugging of Checkmk helpers” raus oder das Debugging der Livestatus queries.
Na muss ja nix kaputt sein wenn die Fetcher zu 100% ausgelastet sind. Wie viele Hosts werden auf der Site wie gecheckt (Agent vs. SNMP) und wie viele Fetcher sind auf der Site konfiguriert?
Es sind ca. 750 Hosts und es ist fast 50:50 SNMP vs. Agent. Fetcher sind 13 konfiguriert. Die virtuelle Appliance hat 8 CPUs und 32 MB-RAM. Die CPU Load der Maschine ist so im Schnitt bei 1.3 und die Utilization bei 20%. Der RAM ist bei 20% und der User-Mem bei 20 GB. Für mich sehen die Werte auch okay aus und das zeigt, dass das System arbeitet und Peaks sehe ich auch keine.
Ich bin auch bei dir was die 100% angeht und dass dort nix kaputt ist. Ich möchte nur wissen, was und welcher Check gerade im Fetcher ist und wie lange es dauert bis er wieder raus ist. So ein Fetcher-Logging wäre cool, zu mindestens für Debuggings. Nur gucken nichts anfassen
Du kannst natürlich die Fetcher Zahl höher drehen, da die ja primär RAM brauchen. Bei Checkern sind aufgrund deiner CPU Kerne maximal 8 sinnvoll, Fetcher können aber je nach RAM Auslastung durchaus erhöht werden.
Zu Debugging kann ich leider nichts sagen, aber natürlich kann es sein, dass ein Fetcher blockiert wird, weil ein Gerät nicht antwortet, oder eine Firewall dazwischen steht.
Das wie lange kannst bei jedem Check_MK Service sehen. Dort ist jeweils der Wert “Time spent waiting for…” die Zeit welche der Fetcher gebraucht hat um die Daten für einen Host abzuholen.
Aktive Checks landen eh nicht in den Fetchern also ist mit dem Check_MK Service schon die einfachste Variante.
Was gerade der Fetcher tut in ein Logfile zu schreiben halte ich für recht sinnlos einfach aufgrund der Größe. Bei deinem Environment wenn du pro Fetcher Lauf 2 Zeilen Log (Start + Ende) schreibst sind das am Tag über 2 Mio Einträge.
Nein - das halte ich für sehr gefährlich vor allem bei begrenzten CPU Ressourcen. Ein hängender Fetcher wegen langsamer Antwort eines Gerätes kann auch gut CPU Ressourcen blockieren.
Für das Debugging ist einfach die Ausführungszeit des Check_MK Service das Ausschlaggebende Kriterium and danach schaue ich mir auch als erstes große Systeme an wenn ich die das erste mal in der Hand hab.
Dort werden alle Agent based Hosts rausgefischt welche länger wie 3-4 Sekunden brauchen weil da ist was an der Agent Config kaputt (kein Caching / nix async usw.).
Bei SNMP Geräten und der Check_MK Laufzeit muss man einfach jedes einzelne auffällige Geräte betrachten.
Gestern gerade nen System mit knapp 1k DSLAMs gehabt und dort hab ich im Endeffekt einfach die normalen Interface Checks deaktiviert da unbrauchbar langsam. Die für den Hersteller erstellten eigenen Checks holen sich nur Daten aus der Enterprise MIB des Herstellers und liefern damit auch Traffic Infos das geht im Millisekunden Bereich.
Da sieht man am aufwendigsten ist SNMP Debugging bei der Laufzeit, Agent based Hosts sind eigentlich straight forward
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
