Checkmk: Unterschied zwischen den Versionen
| Zeile 73: | Zeile 73: | ||
==Registrierung eines Hostes== | ==Registrierung eines Hostes== | ||
1. Im Terminal des Servers den Befehl „cmk-agent-ctl register --hostname ''Name des Hosts'' --server ''Name/IP des Servers'' --site ''Name der Site'' --user ''Name des Users''“ | |||
2. Passwort des Nutzers eingeben und Host ist angelegt. | |||
3. Auf Checkmk selbst auf „Setup“ -> “Hosts“ -> “Hosts“ gehen. | |||
4. Neuen Host suchen und mit Stift-Symbol bearbeiten. | |||
5. Funktion „Save & run connection test“ ausführen und Verbindungen durchlaufen lassen. | |||
6. Abschließend „Save & go to host properties“ auswählen. | |||
==Einrichtung von Services== | ==Einrichtung von Services== | ||
Version vom 5. Dezember 2024, 10:54 Uhr
Was ist Checkmk?
Checkmk ist eine Software zum überwachen von Server, Netzwerke, Applikationen und ähnliches. Über „Agenten“ lassen sich die einzelnen „Hosts“ gebündelt auf einer Web-Oberfläche überwachen und kontrollieren. Es gibt dabei 5 verschiedene Editionen:
- - Raw: Ist eine kostenlose Edition, die 100% Open-Source ist und die einfachste Edition von Checkmk.
- - Enterprise: Ist die Edition, die für den Professionellen gebrauch gedacht ist. Sie hat die gleichen Funktionen wie die Raw Edition, und bietet noch weitere Funktionen an, wie zum Beispiel den Monitoring-Agent, der Informationen über die Zielsysteme beschafft, eine große Anzahl an Dashlets die dem Dashboard hinzugefügt werden können und vieles mehr.
- - Cloud: Ist eine erweiterte Edition von der Enterprise Edition, die in Cloud-Umgebungen nützlich ist, die mit speziellen Plugins, Dashboard und ähnlichem.
- - Free/Trial: Ist die gleiche Edition wie die Cloud Version, die allerdings für 30 Tage kostenlos ist, und ab dem Punkt dann entweder käuflich erworben werden kann, oder aber weiterhin kostenlos als Free Version genutzt werden kann, dann allerding nur mit einer Instanz und maximal 750 Services.
- - MSP (Managed Service Provider): Ist für die Nutzung mit mehreren Kunden gedacht. Dadurch kann man mehrere Server von Kunden auf einem Dashboard haben, und kann seinen Kunden dann genau Zugriff auf die Services haben lassen, für die sie zuständig sind/die zu ihnen gehören.
Je nachdem, für welchen Zweck man Checkmk nutzen möchte, ist eine Edition besser als die andere.
Begriffe die im Laufe des Eintrages auftreten
| Name | Beschreibung |
|---|---|
| Site | Damit ist die Instanz gemein, mit der wir uns Verbinden und über die alles angezeigt wird. |
| Host | Der Host ist der Server, den wir hauptsächlich beobachten, und über den wir Informationen wollen. |
| Agent | Der Agent ist die Verbindung zwischen unserem CheckMK Server und dem überwachten Server. |
| SNMP | Simple Network Management Protokol dient zum Überwachen von Netzwerkgeräten. |
Einrichtung eines Checkmk Servers
Installation von CheckMK
1. Checkmk öffnen und das richtige System auswählen.
2. Auswahl der Edition
3. Auswahl der Plattform
4. Checkmk downloaden und auf Server installierne.
Erstellen einer Site
1. Terminal auf Server aktivieren
2. Den Befehl „omd create Name der Site“ eingeben.
3. Admin und Passwort rauskopieren/aufschreiben
4. Den Befehl „omd start Name der Site“ eingeben und Start der Site auslösen.
5. Im Browser „IP des Servers/Name der Site“ eingeben.
6. Unter „Setup“ und dann „Users“ Password des Admin ändern.
Anlegen eines Agenten/Host
1. Checkmk WATO auf „Setup“ -> "Agents" -> „Windows, Linux, Solaris, AIX“
2. Agent für richtiges Betriebssystem aussuchen und Herunterladen.
3. Datei auf Ziel-Computer laden und installieren.
4. In Checkmk auf "Setups" -> "Hosts" -> "Hosts"
5. "Add host" auswählen, dem Host ein Namen geben und IP-Adresse des Computer eintrage
6. Alle angaben mit „Save & view folder“ speichern
Registrierung eines Hostes
1. Im Terminal des Servers den Befehl „cmk-agent-ctl register --hostname Name des Hosts --server Name/IP des Servers --site Name der Site --user Name des Users“
2. Passwort des Nutzers eingeben und Host ist angelegt.
3. Auf Checkmk selbst auf „Setup“ -> “Hosts“ -> “Hosts“ gehen.
4. Neuen Host suchen und mit Stift-Symbol bearbeiten.
5. Funktion „Save & run connection test“ ausführen und Verbindungen durchlaufen lassen.
6. Abschließend „Save & go to host properties“ auswählen.
Einrichtung von Services
Nachdem der Host aufgenommen wurde, geht es jetzt darum, die Services einzurichten. Dafür geht man bei den Einstellungen des Host auf „Save & run service discovery“, wodurch sich die Seite „Services of host“ öffnet. Dort können wir einstellen, welche Services wir gerne beim Host überwachen möchten. Wenn der Agent richtig läuft, dann schlägt Checkmk an dieser Stelle bereits einige Services vor, die sich überwachen lassen. An dieser Stelle könne Services verschiedene Status haben.
- Undecided: Es wurde nicht entschieden, ob der Service überwacht werden soll.
- Monitored: Der Service wird überwacht.
- Disabled: Es wurde entschieden, den Service nicht zu überwachen.
- Vanished: Der Service wurde überwacht, ist aber verschwunden.
Genau in dieser Reihenfolge werden die Server auch angezeigt. Über den Punkt „Monitor undecided services“ werden alle Services, die aktuell auf „Undecided“ stehen zu „Monitored“ geändert. Sollte ein Service mal verschwinden, weil z.B. das Dateisystem entfernt wurde, dann würde dieser Service als „UNKNOWN“ angezeigt werden, oder in diesem Server als „Vanished“. Mit der Funktion „Remove vanished services“ werden alle „Vanished“ Services aus dem Monitoring entfernt. Für den Anfang ist es am einfachsten, wenn man die Funktion „Accept all“ nutzt, dadurch wird alles einmal bestätigt – Services werden monitored, verschwundene Services entfernt, Host Labels aktualisiert. Sollte sich am Host etwas geändert haben, dass ein neues Service hervorrufen würde, so kann man später immer wieder zu diesen Optionen wechseln, und nachträglich Services hinzufügen (oder auch entfernen).
Änderungen aktivieren
Immer, wenn eine Änderung in Checkmk vorgenommen wird, dann wir diese nicht sofort ausgeführt, sondern wird in einer „Konfigurationsumgebung“ zwischengespeichert. Diese Änderungen müssen jedes Mal akzeptiert werden, bevor sie dann auch in echt durchgeführt werden. Ob und wieviel Änderungen gerade akzeptiert werden müssen, sieht man oben rechts auf jeder Seite. Wenn man auf diese „Warnung“ klickt, kommt man auf die Seite „Activate pending changes“. Dort stehen unter „Pending changes“ alle Änderungen, die aktuell vorgenommen wurden. Diese kann man sich nochmal anschauen und unter Umständen nochmal entfernen, falls man etwas falsch erstellt hat oder etwas anders einstellen möchte. Wenn man mit den Änderungen zufrieden ist, dann kann man mit der Funktion „Activate on selected sites“ einmal alle Änderungen vornehmen und dieser werden dann auch durchgeführt.
Eine Webseite monitoren:
Um eine Webseite zu überwachen, muss man zuerst einen Host haben, den man ihm zuordnen kann. Danach kann man über "Setup" nach „HTTP, TCP, Email, ...“ suchen. Dann wählt man „Check HTTP“ aus. Hier kann man jetzt eine „Regel“ erstellen. Es beginnt mit den Rule Properties, aber die werden nicht benötigt. Als nächstes muss man einen „Service Name“ eingeben, das wird der Name der Webseite, die wir im Monitoring haben wollen. Dann wird der Hostname geändert. Da wir hier eine Webseite haben, wird aus dem Hostname die IP-Adresse unter der die Seite erreichbar ist (optional würde auch die DNS funktionieren). Wichtig ist hier, dass wir im Speziellen eine Webseite und kein Webserver monitoren wollen, daher brauchen wir hier nochmal einen „Virtual host“. Zudem müssen wir noch angeben, dass es sich hierbei um eine Verschlüsselte Seite handelt, daher wird noch „Use SSL/HTTPS“ ausgewählt. Unter „Conditions“ kann man dem Server/der Seite dann einen Host zuweisen. Als nächstes müssen wir darauf achten, dass wir auch die richtige Seite monitoren. Dazu gehen wir einmal auf die Seite, die wir bewachen wollen und schauen uns den Quellcode an. Hier suchen wir nach einem String, die zu der Seite gehört, die Überprüft werden soll. Diesen können wir dann unter „Fixed string to expect in the content“ eintragen. Um jetzt zu überprüfen ob das Zertifikat der Seite noch aktuell ist, können wir diese Regel einmal kopieren. Wenn wir die Kopierte Regel jetzt bearbeiten, dann können wir von „Kontrolle der URL“ auf „SSL Zertifikat Alter“ wechseln. Hier kann man dann einstellen, ab wie viel Tagen Rest-Gültigkeit der Check in „warning“ oder in „critical“ fällt. Um jetzt etwas Leistung einzusparen, kann man das Kontrollintervall für das Zertifikat einstellen. Normalerweise kontrolliert CheckMK alle 60 Sekunden, was für ein Zertifikat viel zu häufig ist. Unter „Setup“ und „Service monitoring rules“ suchen wir nach „normal check interval for service checks“. Hier erstellt man sich dann eine Regel, welche besagt in welchen Abständen nach dem Zertifikat geschaut werden muss. Das läuft wie bei jeder anderen Regel ab. Die Besonderheit kommt durch die Bearbeitung von „Services“. Hier lässt sich eintragen, welche Checks von der Regel betroffen sind. Wenn man jetzt jeder Zertifikats Kontroller am Anfang den Namen „Zertifikat“ gibt, kann man in der Regel einfügen, dass jeder Service mit dem Namen „Zertifikat“ am Anfang in diese Regel fällt.
Monitoring von Checkmk
Analyze configuration
Die Analyze configuration erlaubt dir, Fehler in der Einstellung von Checkmk zu finden. Du erreichst ihn unter „Setup“ -> „Maintenance“ und dort dann „Analyze configuration“. Das LAden der Seite dauert etwas, da bereits jetzt Tests durchgeführt werden. Hier findest du nun die Tests und die passenden Ergebnise, die durchgeführt wurden. Zu jedem Test gibt es Informationen, die man sich mit dem blauen Icon am Anfang des Testes anzeigen lassen kann. In diesen Informationen sieht man, was genau dieser Test tut. Sollte es hier eine Warnung geben, so hat man hier die Möglichkeit, die Werte des Testes abzuändern. Wenn man hier Änderungen vornimmt, muss man diese auch wieder über das Gelbe Icon am oberen Rand akzeptieren. Selbst nachdem man die Einstellungen angepasst hat, wird einem eine Warnung hier angezeigt. Das liegt daran, dass Checkmk nicht weiß, wie die passenden Werte sind, die wir brauchen. Daher kann man mit dem Werkzeug Symbol auf der rechten Seite diese Warnung akzeptieren und dann wird dieser Test als „OK“ angezeigt.
Problem erkennen
Probleme in Checkmk sind alle Zustände in denen ein Server oder ein Host nicht auf OK steht. Dies kann unterschiedliche Gründe haben. Wenn man auf den Host/Service klickt, bekommt man Details zu dem jeweiligen Punkt und sieht dort dann auch, was der Grund für den Fehler ist. Um jetzt ein Problem zu bestätigen, geht man auf den problematischen Host/Service. Dort kann man entweder direkt auf „Acknowledge problems“ gehen, oder das Feld im Reiter „Commands“ nutzen. Wenn man die Checkboxen aktiviert hat, dann kann man auch mehrere Probleme bestätigen. Wenn man auf „Acknowledge problems“ geht, dann wird man dazu aufgefordert ein Kommentar einzugeben. Da biete es sich dann einfach an, die Lösung hinzuschreiben. Nach dem bestätigen wird dann das Problem nicht mehr bei den „unhandeld Problems“ angezeigt. Sollte man nun wieder auf die Probleme gehen, hat man die Möglichkeit, die Probleme wieder als „unhandeld“ anzuzeigen. Dazu wählt man einfach den Punkt „Remove acknowledgement“ aus. Man wird gefragt, ob man dies wirklich tun möchte und danach wird der Fehler wieder normale angezeigt. Zusätzlich zu den normalen Kommentaren, kann man noch Sonderbedingungen hinzufügen. Einmal „sticky“, dabei wird ein Problem als „Handeld“ markiert, selbst wenn sich der Status von z.B. Warn auf Crit ändert. Dies hat den Vorteil, dass Probleme keine neuen Benachrichtigungen senden, obwohl sie bereits bearbeitet werden. Und das andere ist „persistent comment“. Dabei wird das Kommentar zu dem Problem quasi angepinnt und verschwindet nicht, wenn das Problem behoben ist. Dies hat den Vorteil, dass man auch später noch nachvollziehen kann, was genau gemacht wurde.
Wartungszeiten
Wartungszeiten werden genutzt um gezielte Downtimes von Services und Hosts einzurichten, damit man dafür keine Fehlermeldungen bekommt. Wenn zum Beispiel ein Rechner, der über Checkmk kontrolliert wird, über Nacht abgestellt wird, würde eine Benachrichtigung generiert werden, da dieser ja nicht mehr erreichbar ist. Um dies zu umgehen kann man Wartungszeiten für diesen Host einrichten. Um die Wartungszeit einzurichten geht man zuerst auf den Host, den man einrichten möchte. Jetzt könnte man zwar direkt auf „schedule downtime“ gehen, dann würden aber nur die Services des Hostes mit einer Wartungszeit gepflegt werden. Da wir aber auch den Host selbst mit einer Wartungszeit versehen wollen, klicken wir einmal auf den Hostnamen. Hier können wir nur direkt auf „schedule downtime“ gehen oder wir öffnen diese über das „Commands“ Menü. Als erstes müssen wir ein Kommentar/Grund für die Downtime angeben. Danach kann man einstellen, wann und wie lange die Downtime sein soll. Ob sie von jetzt an für eine Stunde geht, oder man kann einstellen, dass sie jeden Tag um 18 Uhr anfängt und um 8 Uhr am nächsten Tag wieder aufhört. Man gibt einfach an, wie man es braucht. Wenn ein Host dann in die Downtime wechselt, gibt es einmal ein Symbol, dass dies darstellt. Sollte in der Downtime jetzt Probleme auftreten, so wird dies keine Benachrichtigung/Problem verursachen. Wenn ein Host sich gerade in der Downtime befindet, dann kann man über das Symbol die Wartungszeiten aufrufen. Hier sieht man dann die aktuellen und zukünftigen Wartungszeiten des Hostes. Über die Auswahl der Downtime hat man auch die Möglichkeit, die einzelnen Downtimes zu bearbeiten. Sollte man zum Beispiel die aktuelle Downtime länger benötigen, kann man ganz einfach die Zeit verlängern, entweder mit fest vorgelegten Werten oder man gibt eine eigene Zeit an. Wenn du jetzt mehrere Hosts hast, die zum gleichen Zeitpunkt die Downtime haben, dann könnte man dies bei jedem Host einzeln eintragen. Das würde aber zu viel Zeit brauchen, weshalb man dafür auch eine Regel schreiben kann. Das geht man links auf „Setup“ und sucht nach "Downtime". Dort findet man nun die Optionen für "Recurring downtimes for services" und "Recurring downtimes for services". Hier kann man dann die Downtime Regeln erstellen, wie man es gewöhnt ist. Zuerst geben wir der Regel wie gehabt ein Kommentar, welches bei jeder Downtime sagt, warum es diesen gibt. Dann stellt man ein, ab wann die Downtime das erste Mal Greifen soll. Man kann auch einstellen, wann die Regel das letzte Mal greifen soll, wenn man z.B. möchte, dass diese Regel nur ein Jahr gilt. Danach gibt man das Intervall ein, wann immer eine Downtime veranlasst werden soll. Die Dauer kann man hier auch manuell einstellen, da nicht jeder Host gleichschnell ist. Unter den Conditions kann man dann noch einstellen, welche Hosts von der Regel betroffen sind.
Bulk action - Bearbeitung mehrere Hosts/Services gleichzeitig
Mit Bulk actions können Änderungen an mehreren Hosts gleichzeitig vorgenommen werden. Dies ist hilfreich, wenn man nur vereinzelte Hosts bearbeiten möchte und nicht alle. Dazu wählt man in Setup den Punkt „Hosts“ aus. Hier sieht man nun die Hosts, unterteilt in den Ordnern. Wenn man hier jetzt über die Checkbox mehrere Hosts auswählt, kann man über "Hosts" und dem Punkt „on selected Hosts“ verschiedene Dinge einstellen. Der wichtigste wird sein „Edit attribute“. Hiermit kann man die Punkte der Hosts anpassen, wie z.B. die IP-Adresse oder unter welche Site die Hosts gecheckt werden. Wichtig ist zu beachten, dass man hier in dem Menü nur angibt was man ändern möchte. Nur weil man ein Punkt weglässt, heißt es nicht, dass dieser Wert wieder auf seinen Ursprünglichen zurückfällt. Dafür braucht man die Funktion „remove explicit attribute settings“. In diesem Menü findet man nur die Punkte, die ein Wert eingetragen haben. Und hier kann man einstellen, dass bei den von uns markierten Hosts der eingetragene Wert entfernt werden soll, wodurch sie wieder auf ihren Standartwert wechseln.
Netzwerk Topologie
Bei einem Netzwerk in Checkmk kann man sich anzeigen lassen, inwiefern die Hosts mit der Site verknüpft sind. Zum Beispiel sind 4 der Hosts über einen Switch mit der Site verbunden. Wenn jetzt der Switch ausfallen würde, dann würden auch die 4 Hosts ausfallen und wir würden für alles eine Benachrichtigung bekommen. Da es mehr Sinn macht, in diesem Fall nur über den Switch bescheid zu wissen, kann man ein „Parent“ für die Hosts festlegen. Dazu muss man bei "Setup" auf „Host“ gehen. Dort kann man bei den Einstellungen für den Einzelnen Host ein Parent eintragen. Checkmk weiß dann, dass, um Zugriff auf den Host zu bekommen, er zuerst auf den Parent zugreifen muss. Und sollte der Parent dann nicht mehr erreichbar sein, wird der Host nicht als „Down“ angezeigt, sondern als „Unreachable“. Wenn ein Host über mehrere Switches erreichbar sein kann, dann kann man einem Host auch mehrere Parents zu weißen. Dadurch wird der Host selbst dann noch als „Up“ angezeigt, selbst wenn einer der Parents abgeschaltet ist.
Benachrichtigungen
Um Benachrichtigungen für Hosts und Services zu erhalten, muss auf einem Konto erst eine Kontaktmöglichkeit hinterlegt werden, sei es eine E-Mail-Adresse oder eine Handynummer (für SMS). Jeder, der die Benachrichtigung erhalten soll, muss mit einem Kontakt hinterlegt werden. Dies funktioniert ganz normal über den Punkt „Setup“ und dann „User“. Dort sind einmal alle User hinterlegt und hier kann man den Einzelnen Nutzern weitere Kontaktdaten hinzufügen. Unter „Contact groups“ kann man Nutzer in Gruppen unterteilen, denen dann Spezielle Hosts/Services zugeordnet werden. So kann man dafür sorgen, dass nicht jeder alle Benachrichtigungen bekommt, sondern, dass diese auch an die richtigen Personen gesendet werden. In den Einstellungen jedes Users befindet sich die Option „Contact groups“, hier kann man einstellen, zu welcher Kontaktgruppe ein Nutzer nun gehört. Unter dem Punkt „Setup“ gibt es dann jetzt noch den Punkt „Assignment of services to contact groups“. Hier kann man, auf Regeln basiert, die Services den Einzelnen Kontaktgruppen zuordnen. Unter „Assignment of services to contact groups“ wählt man zuerst die Gruppe aus, die Benachrichtigt werden soll. Und bei „Conditions“ wählt man aus, was genau für Services kontrolliert werden, also in welchem Ordner befinden die sich, wie heißen diese. Man kann hier auch auswählen, dass es bestimmte Host sein sollen, die Kontrolliert werden sollen. Die Benachrichtigung selbst, wird unter „Setup“->“Notifications“ eingestellt. Hier kann man anhand von Regeln festlegen, welche Informationen übermittelt werden, wann sie Übermittelt werden und so weiter. Mit Erweiterungen lassen sich auch weitere Benachrichtigungen einfügen. Eine wichtige Option ist die „Notification Bulking“. Diese Option lässt dich mehrere Benachrichtigungen die kurz hintereinander und an die Gleiche Person gerichtet sind, als eine Nachricht zusammenfassen. Allerdings muss man hier auch bedenken: Wenn man hier größere Zahlen eingibt, dann muss man auch dementsprechend warten, bis die Zeit jeweils vorbei ist. Wenn man zum Beispiel eingibt, dass alle Nachrichten innerhalb von 5 Minuten, zusammengefasst werden sollen, dann muss man auch warten bis 5 Minuten vorbei sind, bis man überhaupt eine Benachrichtigung von einem Fehler bekommt. Zum Schluss gibt es dann noch die "Contact Selection". Hier wird eingetragen, welche Kontaktgruppen kontaktiert werden bzw. welche User genau kontaktiert werden. Unter den „Conditions“ wird dann angegeben welche Hosts und Services angesprochen werden. Zum Beispiel kann man einstellen, dass nur die Hosts die eine bestimmte IP-Adresse haben, eine Benachrichtigung schicken, oder dass bestimmte Hosts gar nicht es eine Benachrichtigung abschicken können. Man kann auch mehrere Regeln erstellen und diese dann jeweils für andere Gruppen einrichten. Mit der Funktion „Show analysis“ kann man sich die letzten 10 Benachrichtigungen anzeigen lassen. Das hat den Vorteil, dass man neue Regeln die man erstellt hat, direkt überprüfen kann um zu schauen, ob die Regeln auf die aktuellsten Benachrichtigungen zutreffen würde. Ansonsten hat man auch die Möglichkeit einen „Fake Zustand“ auszulösen und so Benachrichtigungen, die jetzt nicht neu sind, zur Verfügung zu haben.
Logfiles in Checkmk
Um sich über Checkmk die Logfiles anzuschauen, braucht man den Log Watch auf dem System. Log Watch ist quasi wie ein Agent, den man auf dem Server installiert, daher wird er auch wie jeder andere Agent auch, über „Setup“ -> „Agents“ aufgerufen. Dann gehen wir auf "Agent rules" und suchen nach log. Ab hier ist es dann wie bei den normalen Regeln. Hier stellen wir ein, dass die Agenten die Log Files bewachen sollen. Das kann man auch für mehrere Einstellen. Dazu geben wir noch ein, welche Logs genau beachtet werden soll. Sobald alles passend eingestellt wurde, gehen wir auf „Bake agents“ und laden den Agenten herunter. Diesen Agenten müssen wir dann wie andere Agenten dem Server hinzufügen. Dazu schalten wir uns auf den Server und installieren diesen. Danach muss der neue Agent auch gefunden werden. Dazu geht man auf die Hosts und macht eine neue „discovery“. Diese Änderungen werden akzeptiert und damit sind die Log Dateien auch schon einsehbar. Wenn Checkmk nun ein Fehler in einem Log gefunden hat, dann kann man den Host auswählen und im Menü des Log Checks auf „Open Log“ gehen. Hier findet man nun eine Detaillierte Ansicht des Log Eintrages. Was hierbei zu beachten ist: Selbst, wenn der Fehler, der im Log angezeigt wird, bereits gelöst ist, wird hier dennoch ein „Warning/Critical“ angezeigt. Das liegt daran, dass im Log immer noch der Fehler steht. Um dies wieder auf „OK“ zu stellen, muss man in „Open Log“ auf „clear log“ gehen. Dies sorgt dafür, dass das Log gesäubert wird und jeder Fehler, der dort drin stand entfernt wird. Und dadurch wird der Log Service wieder auf „OK“ gestellt. Eine wichtiger Hinweis bei Log Dateien über Windows: In Checkmk bekommen wir alle Log Events von Windows angezeigt. Und um dies etwas einzugrenzen, muss man die Log patterns bearbeiten. Dazu gehen wir auf „Setup“ und suchen dort „Logfile patterns“. Hier können wir einstellen, dass alle Logfile Services immer ein bestimmten zustand bekommen. Z.B. wenn in dem Log das Wort „Test“ vorkommt, wird das Log immer als „OK“ angezeigt. Über den "pattern analyzer" kann man dann die erstellten Regeln überprüfen. Man kann Zeilen seines Logs hier einfügen, um herauszufinden, ob eine Regel dazu passt.
Erweiterungen für Checkmk
MKP - Checkmk Packages
MKP sind Erweiterungen für Checkmk, die es Standartmäßig nicht in Checkmk gibt. Man kann sich eigene Erweiterungen erstellen, oder man sucht sich Online (exchange.checkmk.com) die Erweiterung, die man braucht, vielleicht hat ja jemand schon eine erstellt. Bei der Auswahl der richtigen Erweiterung muss man darauf achten, dass die Erweiterung auch für die Checkmk Version gedacht ist, die man selbst verwendet oder dass sie zumindest die Erweiterung verwenden kann. Um eine Erweiterung zu installieren gehen wir auf Checkmk auf den Reiter "Setup" und suchen „extension packages“. Hier sieht man normalerweise alle Erweiterungen, die man installiert hat. Um jetzt eine Erweiterung zu installieren, muss man auf „upload package“ gehen. Hier kann man dann unter „file to search“ die Datei suchen, die man gerade heruntergeladen hat und mit "upload" einfach installieren. Sobald das Package installiert ist, muss man die Änderung akzeptieren. (Wichtig zu beachten: Sollte man eine Check-Erweiterung heruntergeladen haben, dann müsste man jetzt eine Neue Service Discovery ausführen, damit der Check auch auf die Computer angewendet wird.) Wir haben auch die Möglichkeit Erweiterungen direkt über das Terminal zu bearbeiten. Dazu schalten wir uns über SSH auf den Server drauf, auf dem sich Checkmk befindet. Mit dem Befehl „mpk“ kann man sich ne Liste an MPK Befehlen anzeigen lassen, z.B. „mpk list“ was uns anzeigt, welche Erweiterungen aktuell installiert sind. Und damit kann man dann die Erweiterungen von dem Terminal aus verwalten.
Agent bakery
Mit der "Agent bakery" können wir Einstellungen der Agents direkt als Paket zusammengefasst auf die Host aufspielen. Dazu kann man "Tags" benutzen, um zu bestimmen, welche Hosts nun welche Einstellungen bekommen. Dazu gehen wir auf "Windows, Linux, Solaris, AIX", dort haben wir unter "Agents" den Punkt "Automatic updates". Hier sieht man einmal, was alles gemacht werden muss, damit die Agenten automatisch geupdatet werden können. Über den "signatur key" sorgt man dafür, dass die Automatischen Updates geschützt sind. Und jeder Agent fragt diese ab, bevor er ein Update des Agenten durchzieht.