Einrichtung der Infrastruktur Installation Agent für Betriebsysteme mit apt Packetmanager Nun agents für die Hosts installieren Auf dem zu überwachenen des Host wo der Agent installiert werden soll, ein Verzeichnis checkmk_setup im root verzeichnis erstellen mkdir -p /root/checkmk_setup Nun mit dem Webbrowser auf dem Checkmk Server einloggen und dann Dazu auf Setup -> Agents -> Windows, Linux, Solaris , AIX anklicken Nun auf DEB mit dem Ubuntu Symbol anklicken und downloaden Nun per scp die datei auf den server ins Home Verzeichnis von root/checkmk_stup  übertragen check_mk übertragen scp Downloads/check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb root@192.168.0.30:/root/checkmk_setup Nun auf dem Server einloggen und in das Verzeichnis /root/checkmk_setup gehen und die rpm Datei installieren cd /root/checkmk_setup apt install ./check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb Ausgabe: Paketlisten werden gelesen… Fertig Abhängigkeitsbaum wird aufgebaut… Fertig Statusinformationen werden eingelesen… Fertig Hinweis: »check-mk-agent« wird an Stelle von »./check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb« gewählt. Vorgeschlagene Pakete: time Die folgenden NEUEN Pakete werden installiert: check-mk-agent 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen noch 0 B von 4.517 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 4.555 kB Plattenplatz zusätzlich benutzt. Holen:1 /root/checkmk_setup/check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb check-mk-agent all 2.1.0p16-1.d88c216c6ad53a29 [4.517 kB] Vormals nicht ausgewähltes Paket check-mk-agent wird gewählt. (Lese Datenbank ... 35073 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../check-mk-agent_2.1.0p16-d88c216c6ad53a29_all. deb ... Entpacken von check-mk-agent (2.1.0p16-1.d88c216c6ad53a29) ... check-mk-agent (2.1.0p16-1.d88c216c6ad53a29) wird eingerichtet ... Deploying systemd units: check-mk-agent.socket cmk-agent-ctl-daemon.service chec k-mk-agent-async.service check-mk-agent@.service Deployed systemd Creating/updating cmk-agent user account ... WARNING: The agent controller is operating in an insecure mode! To secure the co nnection run `cmk-agent-ctl register`. Activating systemd unit 'check-mk-agent.socket'... Created symlink /etc/systemd/system/sockets.target.wants/check-mk-agent.socket → /lib/systemd/system/check-mk-agent.socket. Activating systemd unit 'cmk-agent-ctl-daemon.service'... Created symlink /etc/systemd/system/multi-user.target.wants/cmk-agent-ctl-daemon .service → /lib/systemd/system/cmk-agent-ctl-daemon.service. Activating systemd unit 'check-mk-agent-async.service'... Created symlink /etc/systemd/system/multi-user.target.wants/check-mk-agent-async .service → /lib/systemd/system/check-mk-agent-async.service. N: Der Download wird als root und nicht Sandbox-geschützt durchgeführt, da auf die Datei »/root/checkmk_setup/check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb« durch den Benutzer »_apt« nicht zugegriffen werden kann. - pkgAcquire::Run (13: Keine Berechtigung) !!!NUR durchführen wenn die Agents später NICHT regestriert werden sollen, was im Kaptitel Grundkonfiguration beschrieben wird!!! Siehe hier !!! Um Agents auch auf ipv4 lauschen zu lassen in der config file folgendes ändern. Aber erstmal die Dienste stoppen und terminieren systemctl stop check-mk-agent.socket killall cmk-agent-ctl killall check_mk_agent Nun die Datei /lib/systemd/system/check-mk-agent.socket bearbeiten nano /lib/systemd/system/check-mk-agent.socket Und folgendes auskommentieren #ListenStream=/run/check-mk-agent.socket Und genau unter der Auskommentierten Zeile diese einfügen ListenStream=0.0.0.0:6556 Speichern, systemctl reloaden und dienst n eustarten systemctl daemon-reload systemctl restart check-mk-agent.socket Installation Agent für Betriebsysteme mit rpm Packetmanager Nun agents für die Hosts installieren Auf dem zu überwachenen des Host wo der Agent installiert werden soll, ein Verzeichnis checkmk_setup im root verzeichnis erstellen mkdir -p /root/checkmk_setup Nun mit dem Webbrowser auf dem Checkmk Server einloggen und dann Dazu auf Setup -> Agents -> Windows, Linux, Solaris , AIX anklicken Nun auf RPM mit dem Redhat Symbol anklicken und downloaden Nun per scp die datei auf den server ins Home Verzeichnis von root/checkmk_stup  übertragen check_mk übertragen scp Downloads/check-mk-agent-2.1.0p16-d88c216c6ad53a29.noarch.rpm root@192.168.0.30:/root/checkmk_setup Nun auf dem Server einloggen und in das Verzeichnis /root/checkmk_setup gehen und die rpm Datei installieren cd /root/checkmk_setup rpm -i check-mk-agent-2.1.0p16-d88c216c6ad53a29.noarch.rpm Ausgabe: Removing deployed systemd units: check-mk-agent-async.service, check-mk-agent.socket, cmk-agent-ctl-daemon.service, check-mk-agent@.service Deploying systemd units: check-mk-agent-async.service check-mk-agent.socket cmk-agent-ctl-daemon.service check-mk-agent@.service Deployed systemd Creating/updating cmk-agent user account ... WARNING: The agent controller is operating in an insecure mode! To secure the connection run `cmk-agent-ctl register`. Activating systemd unit 'check-mk-agent-async.service'... Created symlink /etc/systemd/system/multi-user.target.wants/check-mk-agent-async.service → /lib/systemd/system/check-mk-agent-async.service. Activating systemd unit 'check-mk-agent.socket'... Created symlink /etc/systemd/system/sockets.target.wants/check-mk-agent.socket → /lib/systemd/system/check-mk-agent.socket. Activating systemd unit 'cmk-agent-ctl-daemon.service'... Created symlink /etc/systemd/system/multi-user.target.wants/cmk-agent-ctl-daemon.service → /lib/systemd/system/cmk-agent-ctl-daemon.service. 2022-11-20 16:34:32,252 - ha-helper[28335] - INFO - Synchronizing to node 192.168.177.2 2022-11-20 16:34:32,253 - ha-helper[28335] - INFO - Synchronizing... / -> root@192.168.177.2:/ 2022-11-20 16:34:32,510 - ha-helper[28335] - INFO - Synchronization / -> root@192.168.177.2:/ done 280 run_parts async call !!!NUR durchführen wenn die Agents später NICHT regestriert werden sollen, was im Kaptitel Grundkonfiguration beschrieben wird!!! Um Agents auch auf ipv4 lauschen zu lassen in der config file folgendes ändern. Aber erstmal die Dienste stoppen und terminieren systemctl stop check-mk-agent.socket killall cmk-agent-ctl killall check_mk_agent Nun die Datei /lib/systemd/system/check-mk-agent.socket bearbeiten nano /lib/systemd/system/check-mk-agent.socket Und folgendes auskommentieren #ListenStream=/run/check-mk-agent.socket Und genau unter der Auskommentierten Zeile diese einfügen ListenStream=0.0.0.0:6556 Speichern, systemctl reloaden und dienst n eustarten systemctl daemon-reload systemctl restart check-mk-agent.socket Installation Agent für andere Betriebsysteme ohne systemd / xinetd (Anbindung per ssh) tar.gz Beschreibung Es gibt Systeme auf denen gibt es kein Systemd und xinetd. Der Checkmk Service lauscht normalerweise auf einen TCP Port. Da es aber keine Services ohne xinetd und systemd gibt, gibt es eine weitere Methode. und zwar das abrufen des Agents über ssh. Allerdings funktioniert für diese Methode die Agnet Bakery natürlich nicht. Agents für die Hosts installieren / entpacken Auf dem zu überwachenden des Host wo der Agent installiert werden soll, ein Verzeichnis checkmk_setup im root verzeichnis erstellen mkdir -p /root/checkmk_setup Nun mit dem Webbrowser auf dem Checkmk Server einloggen und dann Dazu auf Setup -> Agents -> Windows, Linux, Solaris , AIX anklicken Nun auf tar gz bei Linux mit dem gelben Symbol anklicken und downloaden Nun per scp die Datei auf den zu überwachenden Server ins Home Verzeichnis von root/checkmk_stup  übertragen check_mk übertragen ​scp Downloads/check-mk-agent_2.1.0p16-d88c216c6ad53a29.tar.gz root@192.168.0.30:/root/checkmk_setup Nun  die  check-mk-agent_2.1.0p16-d88c216c6ad53a29.tar.gz tar auf dem zu überwachendem Host entpacken tar -xf check-mk-agent_2.1.0p16-d88c216c6ad53a29.tar.gz -C / SSH Schlüssel falls nicht schon vorhanden auf der Checkmkinstanz erstellen Auf dem Checkmk server inloggen. Dann in die instanz einloggen omd su Beispiel omd su monitoring Nun den Schlüssel erstellen ohne passphrase ssh-keygen -t ed25519 Ausgabe OMD[monitoring]:~$ ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (/omd/sites/monitoring/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /omd/sites/monitoring/.ssh/id_ed25519. Your public key has been saved in /omd/sites/monitoring/.ssh/id_ed25519.pub. The key fingerprint is: cc:87:34:d2:ed:87:ed:f7:1b:ec:58:1f:7c:23:00:e2 monitoring@mycmkserver The key's randomart image is: +--[ED25519 256--+ | | | . . | | ..+.. | | .=.+.o | | ES +.o | | . o. o | | ...B.| | .=.*| | . o+| +-----------------+ Die Schlüssel liegen dann im .ssh Verzeichnis des Monitoring Verzeichnisses. Dateien anzeigen ll .ssh Ausgabe OMD[monitoring]:~$ ll .ssh total 8 -rw------- 1 monitoring monitoring 1679 Feb 20 14:18 id_ed25519 -rw-r--r-- 1 monitoring monitoring 398 Feb 20 14:18 id_ed25519.pub Der private Schlüssel heißt id_ed25519 und ist nur für den Instanzbenutzer lesbar ( -rw------- ) — und das ist auch gut so! Der öffentliche Schlüssel id_ed25519.pub sieht etwa so aus: Ausgabe: OMD[monitoring]:~$ cat .ssh/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 monitoring@mycmkserver Nun auf dem zu überwachendem Host in einer zweiten SSH-Sitzung einloggen. und die authorized_keys Datei bearbeiten nano /root/.ssh/authorized_keys Dort am ende den öffentlichen Schlüssel eintragen. Davor aber noch ein command, der dient dazu, das nur der Agent aufgerufen werden kann und auch gleichzeitig beim einloggen aufgerufen wird. Die ganze zeile in der  authorized_keys Datei sähe dann so aus command="/usr/bin/check_mk_agent" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 monitoring@mycmkserver Nun ausloggen. Testen der Verbindung Nun auf dem Checkmkserver wieder in die instanz einloggen, wenn nicht noch von der vorherigen Sitzung eingeloggt omd su Beispiel omd su monitoring Nun einfach ssh root@ und den Fingerprint des Schlüssels mit der Eingabe von yes bestätigen. Der Fingerprint wird nur beim ersten mal abgefragt. ssh root@ Ausgabe OMD[monitoring]:~$ ssh root@myhost23 The authenticity of host 'myhost23 (10.11.12.13)' can't be established. ECDSA key fingerprint is SHA256:lWgVK+LtsMgjHUbdsA1FK12PdmVQGqaEY4TE8TEps3w. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes <<>> Version: 2.1.0b6 AgentOS: linux Hostname: myhost123 AgentDirectory: /etc/check_mk DataDirectory: /var/lib/check_mk_agent SpoolDirectory: /var/lib/check_mk_agent/spool PluginsDirectory: /usr/lib/check_mk_agent/plugins LocalDirectory: /usr/lib/check_mk_agent/local <<>> fertig, Verbindung steht. Einbinden des Hosts in Checkmk Nun da die SSH Verbindung hergestellt ist, muss jetzt die SSH verbindung im Host in Checkmk eingetragen werden. Dazu in der Weboberfläche von check mk gehen, den Host anlegen wenn noch nicht geschehen. Sollte der Host schon bestehen. Kann das anlegen natürlich übersprungen werden. Wichtig ist nur das in den Host Einstellungen folgendes gemacht ist Hostanpassen Dazu wieder auf Setup -> Hosts Nun auf edit Host für den Host den man editieren will gehen (Stift) Nun unter Monitoring Agents / API intergation: API integrations if configured, else Checkmk agent auswählen Wenn die Einstellungen beim Host getätigt sind Geht es  weiter auf : Setup -> Agents -> Other integrations -> Custom integrations -> Individual program call instead of agent access klicken Nun auf Add rule klicken Hier nun folgende Sachen ausfüllen: Description : Agent connection through SSH Command to Execute : ssh -T root@$HOSTADDRESS$ Explicit Hosts: unser(e) Server die, die Verbindung über SSH aufbauen sollen. Hinweis: Wir nutzen hier als Variable die $HOSTADDRESS$ dies bedeutet, dazu zum verbinden die IP vom Host genommen wird. nun auf save klicken.  Nun wieder oben rechts auf change klicken Nun auf activate on selected sites Nun wieder auf Setup -> Hosts Nun auf edit Services für den Host gehen (gelber Würfel) Nun wenn gewünscht über das X Services deaktivieren, die NICHT überwacht werden sollen. Soll alles übernommen werden einfach auf Accept all Fertig Installation Agent für Windows Beschreibung: Installation Agent für Windows. Dieser wird dann ähnlich wie bei Linux über die Kommandozeile installiert. Installation Agent Auf der Check MK Seite anmelden und dann auf Setup -> Agents -> Windows, Linux, Solaris, AIX Dort auf das Windows MSI Paket klicken. Nun erscheint der Download Dialog eures Webbrowsers kann bei jedem anders aussehen, auf jeden Fall die Datei speichern. Nun liegt diese Datei im Download Ordner. Dort ein Doppelklick drauf Nun startet das Setup, auf Next klicken Lizenbedinnungen akzeptieren und auf Next klicken Clean install auswählen, alles andere abwählen und auf next klicken Nun auf Install klicken Nun auf Finish klicken Registrieren Anlegen von Hostgruppen und deren Verzeichnisse Nach dem Einloggen sehen wir die Hauptseite Im Menü links auf Setup -> Hosts ->Host Groups. Nun auf den Button dd group klicken und einen Gruppennamen vergeben. bei uns RVS-SERVERS Dann auf Save Nun eine weitere Gruppe anlegen namens PROXMOX-SERVERS Auf save klicken. Nun haben wir zwei gruppen. Nun oben rechts auf den Button changes klicken. Denn unsere Änderungen die wir gemacht haben sind noch nicht aktiv. Die Zahl zeigt an wie viele Änderungen wir gemacht haben. Nun auf Activate on selected sites klicken Nun gehen wir wieder auf Setup -> Hosts -> Hosts Dort erstellen wir Verzeichnisse mit den gleichen Namen wie die Gruppen. Dazu klicken wir auf Add folder Nun den Verzeichnisnamen  eingeben. RVS-SERVERS (im Screenshot steht server hab das s vergessen) Das gleiche auch für PROXMOX-SERVERS Dann sieht das ganze so aus. Wieder Änderungen übernehmen Nun auf Activate on selected sites klicken Fertig. Anlegen von Hosts Nun die Hosts anlegen. Falls noch nicht getan die Agents auf die Hosts die überwacht werden sollen installieren Siehe abschnitt Einrichtung Nun Auf -> Setup -> Hosts klicken Nun haben wir eine Übersicht unserer Verzeichnisse In das Verzeichnis reinklicken wo wir gerne den / die Host(s) erstellen möchten und auf Add Host to the monitoring klicken. Nun auszufüllen Hostname : name des hostes rein. IPv4 Adresse Haken rein und die ip Adresse eintargen Checkmk  agent / API integration :  haken rein Label : sinnvolle label vergeben, können auch mehrer sein. Wir definieren hier ein neues Label mit einem wert servertyp : rvs Nun auf Save & go to services configuration Nun bekommen wir eine Liste mit allen Diensten. Es werden auch zwei neue Labels erstellt: devicetyp und os_family Wenn wir Dienste nicht überwacht ahben wollen klicken wir auf das rote x bei dem jeweiligen Dienst Hier gibt es eine Checkmk Warnung weil wir den Agent noch nicht registriert haben, kommt später. Wir sehen hier einen Fehler beim Dienst Postfix und beim systemd clam av. Den Postfix fehler bekommen wir auch nicht weg, da auf diesem System Postfix unkonfiguriert ist. Entweder postfix konfigurieren wenn benötigt oder den Dienst von der Überwachung ausschließen. Wir klicken hier auf das rote X bei Postfix, weil wir den Dienst hier nicht brauchen. Um die in der Vergagngenheit liegenden Fehler von Systemd zu löschen einfach im Terminal mit dem Befehl. systemctl reset-failed Das nur so nebenbei. Nun ist der Postfix Dienst ausgeschlossen, weil wir diesen ja mit dem roten X entfernet haben. Dieser steht unter Diabled Service, durch klick auf das grüne plus können wir diesen jederzeit wieder hinzufügen. Auch später, falls wir uns entscheiden doch postfix auf dem System zu nutzen Wenn alle Dienste aussortiert, die nicht gerbaucht werden. Hier nur postfix dann auf Accept all klicken. Nun die Änderungen wieder bestätigen Wieder active on selected sites Nun Auf Monitor und dann Main Dashboard. Ein Dienst Critical,  und eine Warnung. Die Warnung kommt noch vom nicht registriertem Client. Das kommt im nächsten Abschnitt, denn damit ein Client registriert werden kann muss er erst im System angelegt sein, was wir in diesem Abschnitt gemacht haben Agents am CheckMK Server registrieren Beschreibung: Wenn im Service AGENT diese Warnung steh, ist der Host mit seinem agent beim Checkmk Server noch nicht registriert. Der host wird erst im Checkmk angelegt und dann übers Terminal registriert. Ansosten steht diese Meldung hier. Denn der Host kann den Agent ja erreichen, aber unverschlüsselt und fur jeden. Warum das ganze? Wenn der Agent unverschlüsselt läuft, kann jeder über den Port Daten vom Hostabgreifen Befehl: telnet 192.168.0.34 6556 Die Ausgabe <<>> Version: 2.1.0p16 AgentOS: linux Hostname: rvs6-tecmata AgentDirectory: /etc/check_mk DataDirectory: /var/lib/check_mk_agent SpoolDirectory: /var/lib/check_mk_agent/spool PluginsDirectory: /usr/lib/check_mk_agent/plugins LocalDirectory: /usr/lib/check_mk_agent/local FailedPythonReason: SSHClient: <<>> {"version":"2.1.0p16","agent_socket_operational":true,"ip_allowlist":[],"allow_legacy_pull":true,"connections":[]} <<>> pluginsdir /usr/lib/check_mk_agent/plugins localdir /usr/lib/check_mk_agent/local <<>> <<>> tmpfs tmpfs 1616236 1568 1614668 1% /run /dev/mapper/rvs6test--vg-root ext4 243008916 169841472 60750420 74% / tmpfs tmpfs 8081168 46800 8034368 1% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock /dev/nvme0n1p2 ext2 481642 124858 331799 28% /boot /dev/nvme0n1p1 vfat 523248 3512 519736 1% /boot/efi /dev/fuse fuse 131072 52 131020 1% /etc/pve tmpfs tmpfs 1616232 0 1616232 0% /run/user/0 <<>> [df_inodes_start] tmpfs tmpfs 2020292 1131 2019161 1% /run /dev/mapper/rvs6test--vg-root ext4 15507456 61994 15445462 1% / tmpfs tmpfs 2020292 106 2020186 1% /dev/shm tmpfs tmpfs 2020292 21 2020271 1% /run/lock /dev/nvme0n1p2 ext2 124928 352 124576 1% /boot /dev/nvme0n1p1 vfat 0 0 0 - /boot/efi /dev/fuse fuse 262144 38 262106 1% /etc/pve tmpfs tmpfs 404058 20 404038 1% /run/user/0 [df_inodes_end] [df_lsblk_start] { "blockdevices": [ {"name":"/dev/sda", "uuid":null}, {"name":"/dev/sda1", "uuid":"77085686-971d-498a-8692-0fd8048da3a0"}, {"name":"/dev/sr0", "uuid":null}, {"name":"/dev/mapper/nvme0n1p3_crypt", "uuid":"ZZLFwZ-JMTb-Qdcu-akhk-5gEc-d2kd-6idwqE"}, {"name":"/dev/mapper/rvs6test--vg-root", "uuid":"da0060ca-629b-4f24-96e4-2bc3dd1dde9a"}, {"name":"/dev/mapper/rvs6test--vg-swap_1", "uuid":"08efe098-7e3a-4ab0-b961-5154eb194d89"}, {"name":"/dev/nvme0n1", "uuid":null}, {"name":"/dev/nvme0n1p1", "uuid":"04B7-49AB"}, {"name":"/dev/nvme0n1p2", "uuid":"0c954140-e9ed-457d-8833-f4564326cdd5"}, {"name":"/dev/nvme0n1p3", "uuid":"663f7527-3144-4b54-9768-454e65aad4b4"} ] } [df_lsblk_end] <<>> [list-unit-files] ... <<>> Server: 129.70.132.34 (2.debian.pool.ntp.org) Poll interval: 34min 8s (min: 32s; max 34min 8s) Leap: normal Version: 4 Stratum: 2 Reference: 81468952 Precision: 1us (-24) Root distance: 3.287ms (max: 5s) Offset: +2.726ms Delay: 15.787ms Jitter: 5.769ms Packet count: 2634 Frequency: -9.423ppm [[[1674394719]]] <<>> NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-24, RootDelay=381us, RootDispersion=3.097ms, Reference=81468952, OriginateTimestamp=Sun 2023-01-22 14:38:39 CET, ReceiveTimestamp=Sun 2023-01-22 14:38:39 CET, TransmitTimestamp=Sun 2023-01-22 14:38:39 CET, DestinationTimestamp=Sun 2023-01-22 14:38:39 CET, Ignored=no PacketCount=2634, Jitter=5.769ms } Timezone=Europe/Berlin <<>> Connection closed by foreign host. Nachdem der Server registriert wurde, sieht die Ausgabe nun so aus. Nun kann nur noch der Checkmk Server mit dem Zertifkat die Daten abrufen und keine dritten mehr. Denn das wäre ja noch so ohne Probleme gegangen, wie die obere Ausgabe ja zeigt. oot@checkmk:~# telnet 192.168.0.34 6556 Trying 192.168.0.34... Connected to 192.168.0.34. Escape character is '^]'. 16 Is still waiting here... No Output anymore Wie registrieren wir den Server nun? Unter Linux: Dazu auf Sem Server einloggen wo der Agent läuft und mit cmk-agent-ctl hinzufügen Hier einmal die Hilfe die wir mit Paramter -h bekommen. Keine Panik, weiter unten zeige ich ein Beispiel. Der Befehl cmk-agent-ctl -h Ausgabe: cmk-agent-ctl 2.1.0p16 Checkmk agent controller. USAGE: cmk-agent-ctl FLAGS: -h, --help Prints help information -V, --version Prints version information SUBCOMMANDS: daemon Run as daemon and handle all pull and push connections delete Delete a connection to a Checkmk instance delete-all Delete all connections to Checkmk sites dump Collect monitoring data and write it to standard output help Prints this message or the help of the given subcommand(s) import Import a pull connection from file or standard input proxy-register Register with a Checkmk site on behalf of another host pull Handle incoming connections from Checkmk sites collecting monitoring data push Push monitoring data to all Checkmk sites configured for 'push' register Register with a Checkmk site status Query the registration status of this host Hier die Parameter für den Befehl register aus der Hilfe cmk-agent-ctl register -h Ausgabe: cmk-agent-ctl-register 1.0.0 Register with a Checkmk site Register with a Checkmk instance for monitoring. The required information can be read from a config file or must be passed via command line. USAGE: cmk-agent-ctl register [FLAGS] [OPTIONS] FLAGS: -d, --detect-proxy Detect and use proxy settings configured on this system for outgoing HTTPS connections. The default is to ignore configured proxies and to connect directly -h, --help Prints help information --trust-cert Blindly trust the server certificate of the Checkmk site --validate-api-cert Enable TLS certificate validation for querying the agent receiver port from the Checkmk REST API. By default, certificate validation is disabled because it is not security- relevant at this stage, see werk #14715 -V, --version Prints version information -v, --verbose Enable verbose output. Use once (-v) for logging level INFO and twice (-vv) for logging level DEBUG OPTIONS: -H, --hostname Name of this host in the monitoring site -P, --password Password for API user. Can also be entered interactively -s, --server Address of the Checkmk site in the format "" or ":" -i, --site Name of the Checkmk site -U, --user API user to use for registration Welche Parameter brauchen wir? Da wir ein selbstsigniertes Zertifikat haben brauchen wir folgende Parameter --trust-cert --password --server --site --user Also würde unser Befehl so aussehen: cmk-agent-ctl register --trust-cert --password *****unsersischerspass**** --hostname rvs6-tecmata --server 192.168.0.33 --site monitoring --user automation Erläuterung der Paramter: --password das automation user api password --hostname der Hostname des Servers den wir registrieren wollen, dieser name muss identisch mit dem im checkmk sein, im Feld hostname hier rvs6-tecmata --server : unser checkmkserver an dem wir den client registrieren wollen --site unsere site / intanz auf dem checkmk  server hier monitoring --user der api user hier automation Unter Windows Eine Eingabeaufforderung mit Admin rechten Öffnen Nun den Client mit -h öffnen um die Parameter zu bekommen. C:\WINDOWS\system32>"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" -h cmk-agent-ctl 2.1.0p16 Checkmk agent controller. USAGE: cmk-agent-ctl.exe FLAGS: -h, --help Prints help information -V, --version Prints version information SUBCOMMANDS: daemon Run as daemon and handle all pull and push connections delete Delete a connection to a Checkmk instance delete-all Delete all connections to Checkmk sites dump Collect monitoring data and write it to standard output help Prints this message or the help of the given subcommand(s) import Import a pull connection from file or standard input proxy-register Register with a Checkmk site on behalf of another host pull Handle incoming connections from Checkmk sites collecting monitoring data push Push monitoring data to all Checkmk sites configured for 'push' register Register with a Checkmk site status Query the registration status of this host C:\WINDOWS\system32> Dann lassen wir uns die Hilfe für den Parameter register anzeigen C:\WINDOWS\system32>"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" register -h cmk-agent-ctl.exe-register 1.0.0 Register with a Checkmk site Register with a Checkmk instance for monitoring. The required information can be read from a config file or must be passed via command line. USAGE: cmk-agent-ctl.exe register [FLAGS] [OPTIONS] FLAGS: -d, --detect-proxy Detect and use proxy settings configured on this system for outgoing HTTPS connections. The default is to ignore configured proxies and to connect directly -h, --help Prints help information --trust-cert Blindly trust the server certificate of the Checkmk site --validate-api-cert Enable TLS certificate validation for querying the agent receiver port from the Checkmk REST API. By default, certificate validation is disabled because it is not security- relevant at this stage, see werk #14715 -V, --version Prints version information -v, --verbose Enable verbose output. Use once (-v) for logging level INFO and twice (-vv) for logging level DEBUG OPTIONS: -H, --hostname Name of this host in the monitoring site -P, --password Password for API user. Can also be entered interactively -s, --server Address of the Checkmk site in the format "" or ":" -i, --site Name of the Checkmk site -U, --user API user to use for registration Welche Parameter brauchen wir? Da wir ein selbstsigniertes Zertifikat haben brauchen wir folgende Parameter --trust-cert --password --server --site --user Also würde unser Befehl so aussehen: "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" register --trust-cert --password *****unsersischerspass**** --hostname rvs6-tecmata --server 192.168.0.33 --site monitoring --user automation Wenn alles geklappt hat wird nichts als Ausgabe zurück gegeben. Nun können wir den Status überpüfen: "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" status Version: 2.1.0p16 Agent socket: operational IP allowlist: any Connection: ip:8000/monitoring UUID: 00bf5de9-7d67-4c76-a9c5-886310581f19 Local: Connection type: pull-agent Certificate issuer: Site 'monitoring' local CA Certificate validity: Wed, 08 Mar 2023 12:14:56 +0000 - Mon, 09 Jul 3021 12:14:56 +0000 Remote: Connection type: pull-agent Registration state: operational Host name: jtl-wawiclient C:\WINDOWS\system32> Nun ist die  Warnung weg. Ob dieser abschnitt noch beötigt wird weiß ich nicht, ich lasse es erstmal stehen Bleibt der Fehler bestehen und es ist noch eine CRIT Warnung dazu gekommen die lautet [agent] Host is registered for TLS but not using it CRIT , Got no information from host CRIT , execution time 0.1 sec  Checks Schwellenwerte / Limits anpassen Beschreibung: Es gibt situationen da passen die Standard Schwellenwerte / Limits einfach nicht. Zum Beispiel weil ein Server zu wenig Festplattenspeicher für eine Temporäre Zeit hat oder der RAM übern Limit ist. Aber es eigentlich noch okay ist. Da kein weiterer RAM dazu gekauft wird. Auszug aus den Emails. Von OK auf Warning Danach wieder von Warning auf OK Einstellen der Limits Auf dem Dashboard hat man unten rechts eine Schnellübersicht der Alarme der letzten 7 Tage. Klickt man auf den Hosteintrag bekommt, man alle service Alerts. Klickt man auf den Service bekommt man die Alerts nur vom Service für den Host. Wir klicken auf Memory und bekommen dann folgende Ansicht. Hier sehen wir Limits von 79,95% - 80% bei RAM und  Commit change 70- 72% gerundet Nun klicken wir oben im Menü auf Service Nun auf Das Burgermenu beiService Icons und dann auf Parameters for this service klicken Nun haben wir eine Neue Übersicht. Im Blauen Rahmen Rechts sieht man das dieser Check schon Standardwerte hat, nämlich Warnung bei 80% und Critical bei 90%. Im roten Rahmen steht der Name des Checks. Diesen klicken wir an, um eine neue Regel zu erstellen. Nun klicken wir auf Add Rule Nun geben wir eine Beschreibung für die Rule ein. unter Value können wir ankreuzen, welche Werte wir definieren wollen. Wir wollen in diesem Beispiel den Memory und die Commit Change anpassen. Unsere Werte waren gerundet, 79,95% - 80% bei RAM und  Commit change 70- 72% Also legen wir RAM auf 88% Warn und 95% Crit um ein bisschen Puffer zu haben. Und commit belieben auf standard auf 80% Warn und 90% Crit. Wir stellen fest, das Commit mit den Standardwerten ausreicht. Also Kreuz wieder raus. unten bei Explicit Hosts ein Kreuz rein und den Host auswählen. Will man das ganze für eine Gruppe Wählt man die Gruppe aus. Anstatt Main, irgendine andere. Dazu muss der Haken dann bei explicit Host natürlich wieder raus. Nun auf Save klicken Nun auf Change klicken Nun auf Activate on selected sites Fertig. Benachrichtungen für bestimmte Checks deaktivieren Beschreibung: Wer kennt sie nicht die Windows Ereignisanzeige. Da werden Fehler und Warnungen geloggt, die eigentlich nicht von belang sind. Sind aber im Log als Critical und Checkmk schickt auch sofort ein Alert raus. Man möchte die Alters natürlich im Checkmk System behalten. Aber eben keine Emailbenachrichtung. Wie also rausnehemn? Emailbenachrichtung für einen Service rausnemen: In der Checkmk Oberfläche anmelden. Dann unter  Setup -> Hosts den Host raussuchen Dort dann auf Services klicken Bei den Service den man ändern möchte auf die Balken klicken (man kann in diesem Atemzug auch mehrere Services in eine Rule packen. Dann einfach die Anderen Servicenamen wie hier  Log Application, dann noch hinzufügen.) Sehen wir später im Rule Editor Nun auf Enable Disable notification for services klicken Nun Auf add Rule Nun eine Beschreibung ausfüllen Enable Diable notification for Services auf disabled stellen, denn das wollen wir ja Bei Condition wieder angeben für wen das gelten soll, Gruppe oder Host etc. In unserem beispiel ein Host. Hätten wir mehr Windows Server hätten wir das anhand eines Labels wie zum Beispiel Windows machen können. nun die Services, wir können mehre definieren. Einfach den Service Namen eintragen. Nun aus Save oben links klicken. Nun auf change oben rechts klicken Nun auf Activate on selected sites Fertig nun werden für die Dienste keine Notifcations mehr rausgesendet. Wenn man jetzt die Services wieder aufruft. Dazu einfach in der Suche den host eingeben und drauf klicken Dann sieht man alle Services und bei denen wo wir die deaktiviert ahben, sieht man ein duchgestrichendes Lautsprechersymbol. Geht man mit der Maus drücber, steht da Notiifications are disabled for this service Fertig. Wartungszeiten - geplante Downtimes festlegen Beschreibung: Es kommt immer mal wieder vor das ein Dienst offline genommen wird. Oder sogar jeden Tag ein Gerät nicht mehr erreichbar ist, zum Beispiel über ein Backup  was nachts läuft, oder eine Zwangstrennung den internet Providers. Hier kommen Wartungszeiten ins Spiel, die sogenannten "Scheduled Downtimes" Hier gibt es zwei Kategorien. Einmal Host und Service. Es muss ja nur bei einem Update der SQL Datenbank zum Beispiel ja nicht der ganze Host weg sein. Dann würde man da für einen oder mehrere Services eine Downtime einrichten. Einrichtung: Downtime eines Host definieren Dazu loggen wir uns in der Checkmk Oberfläche ein. Dann auf Setup ->Host monitoring rules Dann ganz rechts auf Recurring downtimes for Hosts Dann auf Add rule klicken Hier definieren wir ein beispiel das jeden tag um 23:50 - 00:05 eine Downtime stattfindet, wegen Backups und so die Maschine nicht verfügbar ist. Nun eine beschreibung vergeben für de Rule vergeben Nun eine beschreibung vergeben, die die Downtime beschreibt Wann die Downtime zum ersten mal stattfindet, hier 2023.05.04 um 23:50:00 UHR Will man das die Downtime nur einmal ist, würde man den Haken downtime will not start anymore after einhaken. Was wir aber nicht wollen denn sie soll ja täglich ablaufen. Dazu dann in repaet this downtime im dropdown menu  das intervall auswählen, in diesem Fall day für täglich. Nun angeben, wie lang die Downtime sein soll. Hier 0 Stunden und 15 min. Damit beginnt unsere Downtime 23:50 - 0:05 UHR Jetzt wieder wie bei allen Regeln auswählen ob es Pro Host oder Gruppe oder sonst irgendwelchen Kretierien gelten soll. Nun auf Save klicken Nun auf change klicken Und auf activate klicken Downtime eines Service definieren Den Namen des Service herausbekommen. Damit wir die Regel anhand des Servicenamens definieren können brauchen wir zuerst den Namen der Regel. In Unserem Beispiel geht es um einen HTTP Check. Nun Auf Setup -> HTTP, TCP Email Checks klicken Nun auf Check HTTP Service klicken Nun sehen wir eine Liste mit den Checks und rechts die Service namen stehen. Manchmal packt Checkmk noch was vor den den namen. Bei hTTP Check ist es das Wort HTTP oder HTTPS. Je nachdem ob der Check HTTP oder HTTPS checkt. Darum setzten wir ein .* davor und am ende ein $ Denn dann ist egal ob der check später mal in HTTP oder HTTPS geändert wird. Weil der Name bleibt ja gleich. Jetzt haben wir den Namen und können die Downtime regel angelegen Downtime anlegen Auf Setup-> Services -> Service monitoring rules klicken Dann runterscrollen bis Notifcations und dann Recurring downtimes for Services anklicken Dann auf Add rule klicken Hier definieren wir ein beispiel das jeden tag um 23:50 - 00:05 eine Downtime stattfindet, wegen Backups und so die Maschine nicht verfügbar ist. Nun eine beschreibung vergeben für de Rule vergeben Nun eine beschreibung vergeben, die die Downtime beschreibt Wann die Downtime zum ersten mal stattfindet, hier 2023.05.04 um 23:50:00 UHR Will man das die Downtime nur einmal ist, würde man den Haken downtime will not start anymore after einhaken. Was wir aber nicht wollen denn sie soll ja täglich ablaufen. Dazu dann in repeat this downtime im dropdown menu  das intervall auswählen, in diesem Fall day für täglich. Nun angeben, wie lang die Downtime sein soll. Hier 0 Stunden und 15 min. Damit beginnt unsere Downtime 23:50 - 0:05 UHR Jetzt wieder wie bei allen Regeln auswählen ob es Pro Host oder Gruppe oder sonst irgendwelchen Kretierien gelten soll. hier wählen wir service aus und geben den Service Namen an. Beim Service wird immer der Anfang genommen und am Ende muss ein $ Zeichen sein, damit das System weiß hier ist Ende. In unserem Beispiel : .*check-rvs-prod-https-available$ Nun die Condition einstellen. Dann auf Save klicken Dann auf change klicken. Nun activate on selected site anklicken. Fertig Discovery anpassen -> Netzwerkkarten ausschliessen Beschreibung: Manchmal möchte man Geräte nicht erfassen, so wie die tap Adapter von VPNs oder Virtuellen machinen. Dazu gibt es eine Möglichkeit Discovery Rules anzulegen. In dem gleichen Menü kann man noch andere Discovery eigenschaften festlegen. Hier werden wir die Netzwerkkarten festlegen. Neue Rule erstellen Dazu auf Setup -> Discovery Rules gehen. Dort in unserem Fall auf Network interface and switch port discovery klicken Add Rule anklicken Nun folgendes ausfüllen: Description: was die rule machen soll Appearance of network interface : Use alias Conditions for this rule to apply : specify matching condition Match interface alias (regex) : anhaken und dort alle interfaces rein die gefunden werden sollen. Im regex format ist .* ein asterisk Diese dann speichern und übernehmen. Diese Rule wird dann in Zukunft angewandt. Sollten die Devices schon erkannt worden sein, die man nicht haben möchte müssen diese trotzdem noch manuell entfernt werden. Diese Rule gillt für Zukünftige Devices. Fertig