[Check_mk (deutsch)] Häufige Check_MK inventory PROBLEM > Recovery Probleme

Global Community Deutsch
1

Hallo,

wir haben ständige Email Benachrichtigungen und Probleme mit dem CheckMK Inventory Check/Tool.

Inhalt der Mail:

Service: Check_MK inventory
State: OK -> UNKNOWN (PROBLEM)
Command: check-mk-inventory
Output: UNKN - check failed - please submit a crash report!
Perfdata:
Crash dump:\nH4sIADQLLF8C/+19W3PbSJZmvxZ/BdYRu2PPkjLuF0d1R0jU1RYlWZRE2+UKBQiAJC…

Diese Crashdump/Meldung sagt uns nichts und kann auch keiner von uns nachvollziehen.

Direkt nach der Problem Meldung kommt Sekunden später ein Recovery Meldung mit folgenden Inhalt:

Service: Check_MK inventory
State: UNKNOWN -> OK (RECOVERY)
Command: check-mk-inventory
Output: OK - 10 unmonitored services (wmi_cpuload:1, systemtime:1, logwatch:6, services.summary:1, winperf_if:1), no vanished services found

Perfdata:
unmonitored: logwatch: Log Symantec Endpoint Protection Client
unmonitored: systemtime: System Time
unmonitored: winperf_if: Interface 1
unmonitored: wmi_cpuload: Processor Queue
unmonitored: logwatch: Log Windows PowerShell
unmonitored: logwatch: Log Key Management Service
unmonitored: logwatch: Log Internet Explorer
unmonitored: services.summary: Services Summary
unmonitored: logwatch: Log Lenovo-Customer Feedback
unmonitored: logwatch: Log HardwareEvents
ignored: logwatch: Log Application
ignored: logwatch: Log Security
ignored: logwatch: Log System
ignored: dotnet_clrmemory: DotNet Memory Management Global

oder nur so:
Service: Check_MK inventory
State: UNKNOWN -> OK (RECOVERY)
Command: check-mk-inventory
Output: OK - no unmonitored services found, no vanished services found
Perfdata:

Die Probleme tauchen täglich auf und müllen unser Admin Postfach zu.

Kann uns jemand helfen?

Gruß

2

Der Fehler deutet auf einen Fehlerhaften Agenten oder auf ein Script mit fehlerhaftem Output hin.
Beim Crashdump muss dann einfach schnell mal auf das Bombenicon geklickt werden dann sollte bisl mehr Text raus fallen mit einigen Infos.

Was mich bisl stutzig macht ist der Teil hier

Output: OK - 10 unmonitored services (wmi_cpuload:1, systemtime:1, logwatch:6, services.summary:1, winperf_if:1), no vanished services found

Dies würde bedeuten, dass vorher erstmal alle Services entfernt wurden und nun neu gefunden werden.
Wenn ich mir die Ausgabe weiter unten anschaue würde ich aber auch meine Agent Config mal genauer prüfen die sieht etwas “verwahrlost” aus - jedenfalls Anhand der gefundenen Log Files :smiley:

Das tägliche ist klar da der Discovery Check meist einen Interval von 4-12 Stunden hat.

Ich würde aber den Discovery Check generell von der Benachrichtigung ausnehmen der ist nicht Kriegs-entscheidend für das Monitoring.

3

Vielen Dank für ihre schnell Anwort und das sie sich Zeit genommen haben.

Wir haben den Crashdump mal entschlüsseln können und sind auf eine Fehlermeldung gestoßen:

wmi query timed out

und haben folgenden Beitrag bei CheckMK gefunden: https://checkmk.de/check_mk-werks.php?werk_id=5411

Nun ist die Frage, ob da ein Zusammenhang besteht? Bekommen wir deshalb so viele Meldungen?

In einem Forum habe ich dazu gelesen, dass es wohl nur bei Windows Server 2012R2 Maschinen das Problem sei, wir aber trotzdem die Probleme ebenfalls auf 3 Windows 10 Maschinen haben.

4

WMI Timeouts auf aktuellen Systemen deuten eher darauf hin, dass diese Systeme lieber mal neu aufgesetzt werden sollten oder das verwendete Software nicht ok ist und das System “korrumpiert” :wink:

Vor allem wenn die WMI Fehler öfters kommen.

Zu dem verlinkten Werk - der verwendete Agent ist doch nicht so alt oder? Ich würde zur Zeit sehr dringend dazu raten wenn es Probleme mit dem Agent gibt im Windows auf den aktuellen 1.6er zu wechseln und ganz wichtig diesen richtig zu konfigurieren. Die Default Config ist aber hier schon besser, als beim 1.5er oder 1.4er.

5

Aktuell haben wir überwiegend Windows Server 2012 R2 im Einsatz und CheckMK läuft zur Zeit auf der Version 1.5

6

1.5er Agent ist etwas problematisch wenn es um WMI geht und genau so ist 2012R2 nicht die beste Grundlage für WMI Abfragen. Würde hier mal den 1.6er Agenten probieren auf einem “Problemhost” der Windows Output ist wenn mich nicht alles täuscht soweit identisch zwischen 1.5 und 1.6 nur die ganze Aufbau des Agenten ist halt neu.

7

Ok, muss man dafür das checkmk updaten oder bekommt man den 1.6er Agenten auch so und kann das erstmal temporär testen

8

Am einfachsten ist eine leere CMK Site mit 1.6 erstellen und dort das MSI Paket herunter laden. Dann noch eine ordentliche config Datei erstellen und auf dem Problemhost installieren.

9

  1. was meinen Sie genau mit einer richtigen ordentlichen Konfiguration des Agentens (könnten sie mir vielleicht hier zu einen Link dazu schicken, wie man diesen richtig und ordentlich konfiguriert).

  2. wissen Sie in etwa wie viel Zeit es in Anspruch nehmen würde für einen Release Wechsel von 1.5 zu 1.6?

  3. habe ich den Agenten mal auf einer Maschinen über die CMD testen können, dabei hat sich herausgestellt, das bei use_wmi der Wert 0 war und nicht yes oder 1…

10

Das ist nicht ganz einfach zu erklären. Was ich meine ist die kommentierte Beispielkonfiguration genau zu lesen und den eigenen Bedürfnissen gerecht anzupassen.
Die Beispiel Konfiguration beim 1.6er Agent hat den Namen “check_mk.user.yml” mit dem Namen an der gleichen Stelle muss danach die eigen angepasste Konfiguration liegen.

Wenn ich nix vergessen hab ist das folgende ein Beispielkonfiguration wie ich diese bei den meisten Windows Maschinen benutzte. Die Erklärung für die ganzen Optionen findet sich halt in der kommentierten YAML Datei.

global:
    only_from: MEINE_MONITORING_SERVER_IP
    encrypted: yes
    passphrase: geheim
    sections: 
        - check_mk 
        - spool 
        - plugins
        - local
        - winperf 
        - uptime 
        - systemtime 
        - df 
        - mem 
        - services 
        - msexch
        - dotnet_clrmemory
        - wmi_webservices
        - wmi_cpuload
        - ps 
        - fileinfo 
        - logwatch 
ps:
    enabled: yes
    use_wmi: yes
    full_path: yes
winperf:
    enabled: yes
    counters:
        - 638: tcp_conn
        - Terminal Services: ts_sessions
fileinfo:
    path:
        # - 'c:\a\a' # generates missing| string
        # - 'c:\Users\Public\*.log' # real string to process
        # if needed
logwatch:
    enabled: yes
    logfile:
        - 'Application': warn nocontext
        - 'System': warn nocontext
        - '*': off
plugins:
    enabled: yes
    async_start: yes
    execution:
        - pattern     : '$BUILTIN_PLUGINS_PATH$\windows_if.ps1'
          timeout     : 30
          run         : yes
        - pattern     : '$BUILTIN_PLUGINS_PATH$\mk_inventory.vbs'
          timeout     : 30
          run         : yes
        - pattern     : '$BUILTIN_PLUGINS_PATH$\windows_tasks.ps1'
          timeout     : 30
          run         : yes
        - pattern     : '$BUILTIN_PLUGINS_PATH$\windows_updates.vbs'
          cache_age   : 90000
          timeout     : 3600
          run         : yes
        - pattern     : '$CUSTOM_PLUGINS_PATH$\*.*'
          timeout     : 30
          run         : yes
        - pattern     : '$BUILTIN_PLUGINS_PATH$\*.*'
          timeout     : 30
          run         : no
        - pattern     : '*'
          run         : no
local:
    enabled: yes
    async_start: true
    execution:
        - pattern     : '*.*'
          run         : yes
mrpe:
    enabled: no

Das kommt auf die Größe des Systems an und auch wie viele Erweiterungen selbst erstellt wurden oder mkp’s installiert sind. Zwischen 10 Minuten und nem halben Tag :slight_smile:

Dieses “use_wmi” bezieht sich nur auf die Abfrage der Prozesse der Agent selbst nutzt in verschiedenen Teilen trotzdem WMI.

1 Like
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.