CheckMK Server No Longer Processes Data from Windows Agents

Global Community Deutsch
1

Checkmk Raw Edition 2.3.0p10
Debian 12

Hello,

I wanted to ask you about an issue I’m having with CheckMK. A week ago, I installed the RAW version on a Debian 12 machine, configured everything, and installed the agents on the Windows boxes. Everything was working fine, including email notifications.

However, for the past few days, I’m not receiving any data from all the agents. The agents are running and the services are active. Port 6556 is reachable; when tested with Telnet from the Debian box, I can see the data.

CheckMK, however, has lost connection to the Windows machines. Ping works fine as well. The Windows Firewall has been optimized as described, allowing traffic on the necessary ports. Have you ever encountered something like this? It’s strange that it was working perfectly and then suddenly stopped.

API Error:Error running automation call diag-host: Your request timed out after 110 seconds. This issue may be related to a local configuration problem or a request which works with a too large number of objects. But if you think this issue is a bug, please send a crash report.

2

First test is on your monitoring machine as site user.

cmk --debug -vvn WINDOWSHOST

WINDOWSHOST = name of your monitored Windows machine inside CMK

3

-bash: cmk: Kommando nicht gefunden. But CheckMK ist installed

4

Habs hin bekommen mit User-Umeldung auf der Linux Büchse. Da kommt dann folgendes:
value store: synchronizing
Trying to acquire lock on /omd/sites/mysite/tmp/check_mk/counters/192.168.178.5
Got lock on /omd/sites/mysite/tmp/check_mk/counters/192.168.178.5
value store: loading from disk
Releasing lock on /omd/sites/mysite/tmp/check_mk/counters/192.168.178.5
Released lock on /omd/sites/mysite/tmp/check_mk/counters/192.168.178.5
Checkmk version 2.3.0p10

  • FETCHING DATA
    Source: SourceInfo(hostname=‘192.168.178.5’, ipaddress=‘192.168.178.5’, ident=‘piggyback’, fetcher_type=<FetcherType.PIGGYBACK: 4>, source_type=<SourceType.HOST: 1>)
    [cpu_tracking] Start [7f116fb1dac0]
    Read from cache: NoCache(192.168.178.5, path_template=/dev/null, max_age=MaxAge(checking=0.0, discovery=0.0, inventory=0.0), simulation=False, use_only_cache=False, file_cache_mode=1)
    No piggyback files for ‘192.168.178.5’. Skip processing.
    No piggyback files for ‘192.168.178.5’. Skip processing.
    Get piggybacked data
    [cpu_tracking] Stop [7f116fb1dac0 - Snapshot(process=posix.times_result(user=0.0, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.0))]
    [cpu_tracking] Start [7f11706bbda0]
  • PARSE FETCHER RESULTS
    HostKey(hostname=‘192.168.178.5’, source_type=<SourceType.HOST: 1>) → Add sections:
    Received no piggyback data
    No piggyback files for ‘192.168.178.5’. Skip processing.
    No piggyback files for ‘192.168.178.5’. Skip processing.
    [cpu_tracking] Stop [7f11706bbda0 - Snapshot(process=posix.times_result(user=0.0, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.010000001639127731))]
    [piggyback] Success (but no data found for this host), execution time 0.0 sec | execution_time=0.010 user_time=0.000 system_time=0.000 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=0.000

Dann hab ich probiert: telnet 192.168.178.5 6556 und da spuckt er Daten aus.
Aber der Agent wird nicht erkannt im CheckMK

5

Ist der Host mit seiner IP in checkmk angelegt als Name?
Wenn ja dann siehst so aus wie wenn er ohne Agent konfiguriert ist. Bitte mal mit
cmk -D HOSTNAME
prüfen

6

Wenn ich den Befehl mit Hostname eingebe, gibt er die iP-Adresse des Hosts und andere Infos aus. Ich habe auch in CheckMK IP only angehakt, weil diese Systeme statische IP-Adressen haben. Und wie gesagt es lief auch schon einwandfrei und dann plötzlich nicht mehr. Vielleicht wegen einem Debian Update aber ich weiß es nicht. Auch wenn ich den Haken entferne geht es nicht

7

Die Ausgabe des Befehls wäre interessant.
Da sieht man gut wie der Host eingerichtet ist.

8

Aber ändert das was? Mein Problem ist, dass im CheckMK also auch wenn man auf Verbindungs-Tests geht er den Agent nicht findet. Das Feld verfärbt sich dann rot. Was könnte man da tun?

Windows01.mx.net
Addresses: 192.168.168.5
Tags: [address_family:ip-v4-only], [agent:cmk-agent], [checkmk-agent:checkmk-agent], [criticality:prod], [ip-v4:ip-v4], [networking:lan], [piggyback:auto-piggyback], [site:monitoring], [snmp_ds:no-snmp], [tcp:tcp]
Labels: [cmk/site:monitoring]
Host groups: check_mk
Contact groups: all, check-mk-notify, email_benachrichtigungen
Agent mode: Normal Checkmk agent, or special agent if configured
Type of agent:
Program: /omd/sites/monitoring/share/check_mk/agents/special/agent_vsphere -u Xdseee ‘-s=test’ -i hostsystem,virtualmachine,datastore,counters --direct --hostname Windows01.mx.net -P --spaces underscore --vm_piggyname alias --snapshots-on-host --no-cert-check 192.168.168.5
Process piggyback data from /omd/sites/monitoring/tmp/check_mk/piggyback/Windows01.mx.net
Services:
checktype item params description groups

9

Für diesen Host ist der vSphere Special Agent konfiguriert - das stimmt so bestimmt nicht oder?

10

aber was soll man da groß machen? Man installiert ja den Agent den man direkt aus dem CheckMK herunter ladet und der hat funktioniert. ich habe nichts verändert und nach einigen Tagen war das plötzlich so. Was kann man jetzt machen? Auch wenn ich den Agent einfach neu installiere, ändert das nichts und auch für die anderen Windows Maschinen klappt es nicht mehr

11

Ich denke mal innerhalb vom CheckMK hat “irgend jemand” eine Regel hier
image
definiert.
Diese Regel scheint aber keine oder falsche Conditions zu haben. Sollte halt nur auf den vCenter oder ESX Server wirken und nicht auf den normalen Windows Host.

12

Ja Du bist ein Profi! Das wars! Habe diesen Test-Esx explizit ausgewählt und schon geht es wieder. Verrückt :slight_smile: Danke vielmals!