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 