unter 2.0.0p3 gab es noch einen Bug wo selbst verteilte Plugins (bei uns bspw. Exchange .ps1) nicht asynchron ausgeführt werden bzw. diese Einstellung ignoriert wurde.
Das Skript sollte nur einmal die Stunde ausgeführt werden wurde aber durch den Bug stetig ausgeführt und schlug somit fehl und setze den Server unter Last.
Ich konnte in den Changelog von 2.0.0p4 nicht erkennen ob der Bug nun wirklich behoben wurde.
Update:
In meinen Test scheint der Bug noch existent zu sein und erzeugt durch sein stetiges Abfragen eine immens hohe Last auf den Exchange Server alleine nur durch die PowerShell.
Dann habe ich auf unserem DHCP Servern das DHCP Plugin über die Agent Bakery verteilt um dort die Auslastung der DHCP Pools abzufragen aber diese sind total veraltet und ich glaube, das dort auch die stetige Abfrage der Pools eine hohe Systemlast erzeugt und die Abfrage nicht fertig wird bevor die nächste beginnt. Selbst der CheckMK Agent schafft es nicht seine Infos immer aktuell zu halten.
Wie kann ich prüfen ob der Befehlssatz vom CheckMK Server an den CheckMK Agent richtig übertragen wurde? Wie gesagt auch mit der 2.0.0p4 werden die Skripte minütlich ausgeführt statt wie gewünscht nur alle 30 min etc. Auch die Hauseigenen Skripte (Beispiel DHCP Pools) wie oben laufen wohl durchgängig und ich finde leider nicht den Punkt dort eine asynchrone Abarbeitung festzulegen.
Die hauseigenen Skripte landen in diesem Ordner. c:\Program Files (x86)\checkmk\service\plugins
Nein - dieser Ordner beinhaltet erstmal nur alle Plugins hier wird ohne extra Konfiguration nix ausgeführt.
Wenn die dort liegen wie der Screenshot diese anzeigt dann wird hier auch nix ausgeführt.
Es wird generell nur ausgeführt was in den Ordnern c:\ProgramData\checkmk\agent\plugins\ sowie c:\ProgramData\checkmk\agent\local\ liegt.
Aber selbst dies könnte man noch weg/umkonfigurieren.
Die Ordnerstruktur für Custom Files ist leider auch nicht ganz richtig.
Diese müsste eigentlich so aussehen.
custom → msexchange -->lib → local (wenn es ein local Check ist) oder plugins (wenn es ein richtiges CMK Plugin Script ist)
Hier die Verwendung von “bin” als Ordnername ergibt wie bei dir zu sehen eine die Ablage im “Arbeitsverzeichnis” des Agenten. Die Verwendung von nur “lib” führt zu gleichem Ergebnis.
Um diese Scripte dann noch mit einem Checkintervall zu versehen sind noch die folgenden Regeln zu bauen. → Set cache age for plugins and local checks
Dort muss halt für alle relevanten Plugins eine Regel vorhanden sein.
Kleine Ergänzung am Ende - bitte unter Windows kein MRPE verwenden das ist meist mit argen Schmerzen verbunden. Wenn es keine Binärdateien sind sondern wie hier Powershell Scripte dann einfach einen Local Check draus machen und fertig. Ist über 50% weniger Code und funktioniert zuverlässig. Und selbst Local Checks hab ich mit Config Dateien wie normale Plugins im Einsatz und brauchen damit auf der CMK Seite null Programmieraufwand. Sind aber mit der Dynamischen Status Auswertung extrem mächtig.
bei dem DHCP Server (mit CMK Plugin) laufen die Checks (DHCP Pool) augenscheinlich nachdem ich unter “Normales Intervall für Service-Checks” das Intervall auf 15min gesetzt habe.
Das mit dem verteilen über die Ordnerstruktur wurde uns so von einem Systemhaus so bei der Einrichtung gezeigt. Habe es jetzt nach deiner Methode umgebaut und die PS1 Skripte landen nun auch im Ordner C:\ProgramData\checkmk\agent\local und die aktivierten Skripte (über MRPE) werden und wurden auch als Service ausgeführt.
Die MRPE Checks (Regeln) für Exchange habe ich derzeit auch deaktiviert, die Umsetzung wurde uns aber auch so gezeigt damit die PowerShell Skripte lokal auf den Servern (teilweise mit Parametern) ausgeführt werden.
Wie kann ich das mit der Aussage “Wenn es keine Binärdateien sind sondern wie hier PowerShell Skripte dann einfach einen Local Check draus machen und fertig” verstehen, umsetzen und testen?
Was mir immens Kopfschmerzen verursacht sind die Exchange Server.
Hier habe ich mittels Agentrules das CMK Plugin für Exchange ausgerollt. Jetzt werden immens viele Services Checks erstellt und bei der hohen Anzahl von DB`s auf den Servern sind das nicht gerade weniges Checks.
Wenn ich bei den Exchange Servern auch das Service Check Intervall anpasse steigt die Last auf den Exchange Servern ebenfalls an und die CheckMK Services werde Rot.
Bei den Exchange Servern sind ca. 250 Checks und die Agent Abfrage läuft in ein Timeout. Auch auf einem Server der kein Exchange installiert hat aber -EX im Namen hält weil er das FileShareWitness System ist, erfolgt dieser Timeout. Eine Neuinstallation vom CheckMK Agent brachte keine Besserung.
Hast Du eine generelle Empfehlung wie Exchange Server am besten überwacht werden?
Selbst wenn ich das ausrollen des CMK Plugins für Exchange deaktiviere (“MS Exchange Datenbank Latenzzeit (Windows)” & “Database Availability Group (DAG) (Windows)”) und mittels Agent Bakery neu packen lassen sowie die Exchange Server aktualisiere, bleiben diverse Exchange Checks (bspw. Exchange IS Client) vorhanden.
Sorry wenn das zu viel Infos sind aber irgendwie bin ich hier auf Grund von diversen Umständen im Regen stehen gelassen worden
Das ist unerheblich für die Agenten Abfragen. Alle passiven Checks erben das Check Interval vom Check_MK Service. Gilt auch für die Exchange Sachen weiter unten
Wird also dein Server einmal pro Minute abgefragt was der default Wert ist so wird auch einmal pro Minute das DHCP Script ausgeführt falls es nicht für Caching konfiguriert wurde.
Sind die Scripte auch wirklich Local Checks? Oder was sind das für Scripte?
Das lässt sich am besten an einem kleinen Beispiel zeigen.
Ganz einfaches Powershell Script welches O365 Daten ausliest und ausgibt.
Wenn man nun schaut ist in diesem Script keinerlei Logik drin welche die Daten auswertet es wird einfach nur am Ende eine Zeile ausgeben und das wars. Die “Magic” passiert hier durch das “P” am Anfang der Ausgabe. CheckMK geht nun hin und schaut sich die Performance Daten an ein rechnet anhand der angegebenen Schwellwerte das Resultat aus.
In dem Fall hier würde ab 5 Lizenzen frei der Check Warning und bei 0 Critical weil 5 und 0 die unteren Schwellwerte sind.
Hier sieht man ein Local Check eignet sich besonders gut wenn was an Messwerten zurück gegeben wird.
Zu dem Exchange Server welcher 180 Sekunden braucht würde ich sagen hier läuft ganz arg was falsch.
Wie schaut den auf diesem Server die Agent Config aus wenn man sich die per “check_mk_agent showconfig” anzeigen lässt?
Ich vermute hier mal ins Blaue das keines der Plugins Asynchron ausgeführt wird und irgend eines dabei hängen bleibt. Aber das ist nur ne Vermutung - ohne Agent Config lässt sich nix sagen.
Die Daten kommen auch vom Agent direkt sind alles Performance Counter.
Die können aber keinen Einfluss auf den Agent weiter haben. Hab genug große Exchange Umgebungen im Monitoring (8 Node Cluster zum Beispiel) und keinerlei solche Probleme.
Ich vermute ganz stark das hier ein Grundlegendes Problem bei der Agent Config besteht.
Wenn ich jetzt fies wäre würde ich schreiben - der Dienstleister der das eingerichtet hat möge doch seiner Gewährleistung nachkommen
Hier die Ausgabe von “check_mk_agent showconfig”
Das ist kein direkter Exchange Server sondern nur ein System was als FileShareWitness dient ab der Agent trotzdem gegenüber den anderen normalen System eine “execution time 97.4 sec” hat.
Dieses Script dürftest dir komplett einsparen können. Die Exchange Queue Counter kann der Agent schon selbst abholen und für den Database Status sollte das DAG Plugin die richtigen Ausgaben liefern.
Und das is eindeutig zu lange
Hier meine Anregungen zur Config Anpassung.
Es sind alle Sektionen aktiv - abschalten was nicht generell gebraucht wird
Dies wären bei mir zum Beispiel - mrpe , skype, openhardwaremonitor, msexch
In der Global Section fehlt die Option → async_script_execution: parallel
Damit werden alle Plugins parallel ausgeführt und warten nicht brav auf einander
Nimm mal bei dem Host für den Test aus der Config die Zeilen für “msexch_*.ps1” raus.
mit so Platzhaltern immer vorsichtig sein bei den Plugins lieber ordentlich ausschreiben
Der Rest schaut im Endeffekt wie bei mir aus.
Ich tippe hier wirklich auf die Script Einbindung als Problem.
Ich schau mir mal das Exchange Script an und schreib das als Local Check nur zum Vergleich was man da an Code alles einsparen kann.
ich versuche mal ob ich davon etwas umsetzen kann aber wie gesagt ich hatte bisher nur 3 Tage Remotesitzung und sonst nicht mehr tiefgreifendes Wissen.
Dachte auch immer wenn ich in der Agent Bakery etwas konfiguriere dann wird das auch automatisch in die lokale Konfiguration vom Agent geschrieben (Deshalb die Ent. Version bei uns).
Die .yml Dateien ändern sich aber nicht.
Das ist die manuelle Config Datei welche nur geändert werden sollte wenn keine Agent Bakery verwendet wird.
Das ist die von der Bakery erstellte Datei welche sich auch ändern sollte wenn ein neuer Agent ausgerollt wird.
Deshalb meine Aussage um mit dem Agenten erstmal vertraut zu werden sollte man das auf einem Testsystem erstmal bisl manuell rumprobieren.
Also auf einem System wo es keine bakery.yml gibt und man alles in der user.yml per Hand konfigurieren kann. Die Optionen sind schon recht komplex und brauchen etwas Zeit um verstanden zu werden. Das ist halt wichtig für die Fehlersuche wie bei dir.
Hier nochmal kurz was du in deiner Bakery anpassen solltest für diesen Host.
Wenn Logfiles gar nicht übertragen werden sollen auch bitte die Sektion deaktivieren (spart Zeit)
Die Regel welche “msexch_*.ps1” auf diesem Host konfiguriert deaktivieren wenn hier nix abgefragt wird. Nix ist schlimmer wie Scripte welche versuchen zu laufen und nicht können.
Regel erstellen “Asynchronous execution of plugins” auf parallel stellen
nicht gebraucht Sektionen deaktivieren per Regel wie in meinem anderen Post angegeben
Im Local Ordner sollten nur Scripte sich befinden welche wirklich Local Checks sind und auch auf dem System wirklich abgefragt werden sollen.
Aktuell habe ich mittels Bakery folgendes umsetzen können.
# Created by Check_MK Agent Bakery.
# This file is managed via WATO, do not edit manually or you
# lose your changes next time when you update the agent.
global:
async_script_execution: sequential
disabled_sections:
- openhardwaremonitor
- skype
enabled: true
encrypted: 'yes'
install: true
only_from:
- 127.0.0.1
- 172.31.2.20
passphrase: xxxxxx
port: 6556
realtime:
encrypted: 'yes'
passphrase: xxxxxx
logwatch:
enabled: true
logfile:
- '*': off nocontext
send_all: false
plugins:
enabled: true
execution:
- async: true
cache_age: 14400
pattern: $CUSTOM_PLUGINS_PATH$\windows_updates.vbs
timeout: 600
- cache_age: 3600
pattern: $CUSTOM_PLUGINS_PATH$\cmk_update_agent.checkmk.py
- cache_age: 600
pattern: $CUSTOM_PLUGINS_PATH$\msexch_dag.ps1
run: true
- cache_age: 600
pattern: $CUSTOM_PLUGINS_PATH$\msexch_database.ps1
run: true
- async: true
pattern: $CUSTOM_PLUGINS_PATH$\msexch_*.ps1
run: true
Die Sektionen “openhardwaremonitor” und “skype” sind global jetzt deaktiviert.
Welche von denen hier meintest Du noch sollten global deaktiviert werden und kann ich mit einer neuen Regel die an erster Stelle steht Sektionen wieder für bestimmte Systeme aktivieren?
Wir planen nur auf ausgewählten Systeme die Eventlogs auszuwerten und anfänglich wurde über die Agentregel “Windows Eventlog-Überwachung justieren” es global vom Dienstleister abgeschaltet.
Bezüglich ausführen von Skripten die auf den Systemen vorliegen haben wir noch diverse eigene und aus dem Nagios Bereich im Einsatz (in op5) und kommen vorerst nicht davon weg diese zu nutzen
Das Thema Windows Logs dürfte nicht so viel ausmachen. Also kannst es so auch lassen.
Normal hab ich bei mir immer “System” und “Application” in der Übertragung drin sonst nix.
Ich schalte bei mir halt auch immer “Legacy Monitoring Plugins ausführen” ab (MRPE) weil ich halt der Meinung bin das man sowas nicht braucht und es nur viel zu fehleranfällig ist.
Bitte erstmal alle andern eigenen Scripte raus nehmen und nur die drin lassen welche jetzt konfiguriert sind.
Ihr kommt auf keinen grünen Zweig wenn diese seltsamen Scripte Probleme machen.
Ich glaube nicht, dass eines dieser Scripte wirklich notwendig ist. Jedenfalls nicht in Ihrer jetzigen Form.
Wie und wo kann ich das Eventlog dann nur für System und Application aktivieren? Wenn ich es generell wieder einschalte tauchen diese Services auf (Beispiel von einem anderen Server kein Exchange ist).
Ich kenne das deaktivieren von Services aber geht das auch anders damit nur bestimmte Logs erst vom Agent übertragen werden?
Sorry ich bin eher jemand der mit der Oberfläche arbeitet.
Bei dem asynchronen ausführen von Plugins habe ich das schon so eingestellt und hoffe nicht das es ein Bug ist.
Des Weiteren habe ich nun die Verteilung der eigenen PS1 Dateien deaktiviert und der Agent ist wieder schnell mit fast 4sec.
Wenn ich es richtig verstanden habe werden alle Skripte unterhalb von “C:\ProgramData\checkmk\agent” immer ausgeführt egal ob ich MRPE aktivier oder nicht?
Ich habe auf einigen Systemen wo ich ebenfalls ein PS1 zu laufen habe (bspw. Check vom IIS Webpool) das Skript unter “C:\ProgramData\checkmk\agent” zu liegen (aufgrund der neuen Verteilung) und MRPE konfiguriert. Hier sieht es wie folgt aus.
Bei Application und System setz ich das auf Warn und “without context”.
Hier noch als dritten Eintrag den mit * und deaktiviert einfügen. Dann kommt wirklich nur Application und System.
Nein - hier wird nur ausgeführt was im Verzeichnis “Local” und “Plugins” liegt wenn nicht anderweitig konfiguriert.
Wie kann ich jetzt vorerst dennoch die eigenen Skripte ausführen lassen bis ich da eingearbeitet bin oder es eine andere Lösung für uns gibt?
Wohin (Ordner) müssen die Skripte denn dann verteilt damit nicht wie bis heute Morgen die Last bzw. Ausführungszeit vom Agent in die höhe schießt was wohl an der Ablage im Ordner “\local” lag?
Als sie direkt unter “C:\ProgramData\checkmk\agent” lagen gab es das Lastproblem nicht.
Wie kann ich denn eigentlich die gemeldeten Logs filtern damit nur bestimmte Events aufschlagen und alle anderen ignoriert werden?
Bspw. das die Event ID 1028 von System angezeigt wird. Wird das über Logfile Patterns umgesetzt?
Wäre das als Beispiel so richtig und wie setzte ich das für Events um die noch nicht aufgetreten sind und ich nicht weis wie sie von CheckMK ausgelesen werden?
Ich finde es etwas ungünstig das hier das Log gefiltert wird und die Anwender dann nur eine E-Mail erhalten das etwas gefunden wurde. Bei op5 konnte man einen Check nur für diesen Event erstellen der im Namen schon sagt was gefunden wurde. Jetzt müssen ja die Admins wissen was diese Event ID nochmal aussagt.
Normal wenn es MRPE Scripte sind in den Ordner mrpe unterhalb von agent.
Ich sehe das aber sehr skeptisch - was bringen den diese Scripte an Informationen welche mit den Exchange Countern und den beiden Exchange Powershell Scripten noch fehlen? Kann mir da nix vorstellen.
Das ist etwas komplexer. CMK hat zwei Varianten wie es Log Files bearbeiten kann.
Entweder mit der Logdatei Muster Regel - hier bestimme ich eigentlich nur was ich nicht haben will also was ignoriert wird. Es bleiben alle anderen Events übrig welche nicht gefiltert wurden.
Der zweite Weg ist dann eine Weiterleitung an die EventConsole und dort erfolgt die Filterung genau anders herum - man gibt an was man sehen will alles andere wird ignoriert.
zwischendurch einmal vielen Dank für deine Geduld und Unterstützung
Das mit den Logs schaue ich mir dann doch nochmal in Ruhe an.
Wie bekomme ich jetzt die PS1 über die Agent Bakery in den Ordner mrpe?
Welche Ordnerstruktur müsste ich da lokal auf dem CheckMK Server bauen denn dazu hatte ich nichts gefunden?
Die Scripte welche ich im Screenshot sehe werden alle nicht gebraucht wenn du die beiden vorhandenen Plugins im CMK + der Perfcounter des Agents benutzt. Da sind die Informationen aus den Scripten alle schon enthalten. Wenn du dir wirklich die Probleme mit MRPE geben willst dann pack die Dateien einfach in den Unterordner mrpe anstatt local.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
, skype, openhardwaremonitor, msexch
