Der UM-Agent fungiert als Vermittler. Er extrahiert und bereitet Messdaten aus verschiedenen Quellen auf und sendet diese an Überwachungs- oder Analysesysteme. Zu diesen Quellen gehören beispielsweise Logdateien, Systemparameter von Linux oder Windows-Leistungsindikatoren, das Windows-EventLog sowie Ausgaben beliebiger Befehle oder Programme, die Daten aus Datenbanken, APIs etc. liefern.
Download Version 4.0.0
Quelltext auf GitLab
Portierung der Java-Version auf die Programmiersprache Go. Die Konfigurationsdateien bleiben weitgehend kompatibel. Die wichtigsten Unterschiede:
Zeit|Level|EventID|Quelle|Text durchsucht (statt als XML-String).<source>STDERR</source> wertet die Fehlerausgabe aus.Der UM-Agent steht unter der MIT-Lizenz. Er enthält Code folgender Drittanbieter. Alle hier erwähnten Warenzeichen und eingetragenen Warenzeichen sind Eigentum der jeweiligen Inhaber.
Go Standardbibliothek
Copyright 2009 The Go Authors
Lizenz – BSD 3-Clause License https://go.dev/LICENSE
golang.org/x/sys
Copyright 2009 The Go Authors
Lizenz – BSD 3-Clause License https://cs.opensource.google/go/x/sys/+/master:LICENSE
-cfg sucht der UM-Agent die Konfigurationsdatei in folgender Reihenfolge: umagent.xml, cfg/umagent.xml, ../cfg/umagent.xml, /etc/umf/umagent.xml (nur Linux). Relative Pfade beziehen sich auf das Arbeitsverzeichnis.../log. Die Dateien werden täglich automatisch rotiert, z.B. mfdata.YYYY-MM-DD.log. Die archivierten Logdateien werden automatisch gelöscht, siehe Parameter keepdays.
Bei Installation per RPM liegen das Programm unter /opt/umf/bin, die Konfiguration unter /etc/umf und die Logdateien unter /opt/umf/log.
Das RPM-Paket umagent-4.0.0-1.x86_64.rpm kann auf RHEL, Rocky Linux, AlmaLinux, CentOS Stream und anderen RPM-basierten Distributionen mit systemd eingesetzt werden.
rpm -ivh umagent-4.0.0-1.x86_64.rpm
vi /etc/umf/umagent.xml
systemctl enable --now umagent
Auf beliebigen Distributionen genügt es, die Programmdatei zu kopieren.
mkdir -p /opt/umf/bin /opt/umf/log /etc/umf
cp linux/amd64/umagent /opt/umf/bin/umagent
chmod 755 /opt/umf/bin/umagent
cp umagent.xml /etc/umf/
cp umagent.service /usr/lib/systemd/system/
systemctl daemon-reload
systemctl enable --now umagent
Entpacke UM-Agent_[Version].zip
install.cmd
sc.exe start umagent
Der UM-Agent erkennt selbst, dass er als Dienst gestartet wurde. Arbeitsverzeichnis ist dann der Ordner der Programmdatei (bin), die Konfiguration wird daher unter ..\cfg\umagent.xml gefunden und die Logdateien landen in ..\log.
Nach der Installation müssen die Konfigurationsdateien angepasst werden. Als Basis kann man die mitgelieferten Beispiele im Ordner cfg verwenden. Mit umagent -list lässt sich die Konfiguration vorab prüfen.
Tabelle 1 zeigt die Startparameter des UM-Agent. Die Parameter dürfen mit - oder -- beginnen und abgekürzt werden (-c, -cf, --cfg).
Tabelle 1: Startparameter für UM-Agent
-cfg, -c – Pfad zur Konfigurationsdatei. Default umagent.xml, cfg/umagent.xml, ../cfg/umagent.xml oder /etc/umf/umagent.xml (nur Linux).-daemon, -d – Alle Meldungen in die Logdateien statt auf die Konsole ausgeben. Als Windows-Dienst immer aktiv.-list, -l – Konfiguration prüfen und alle Checks auflisten, die in der Konfigurationsdatei definiert sind.-version, -v – Version anzeigen.-help, -h – Hilfe anzeigen.Unter Linux wird der Dienst mit systemd gesteuert (Tabelle 2).
Tabelle 2: Steuerung des UM-Agent unter Linux
systemctl start umagent – Start des UM-Agent im Hintergrund.systemctl stop umagent – Stop des UM-Agent.systemctl restart umagent – Stop und dann Start des UM-Agent, z.B. nach Änderung der Konfiguration.systemctl status umagent – Status anzeigen. Wenn der UM-Agent läuft, wird die PID angezeigt./opt/umf/bin/umagent -c /etc/umf/umagent.xml – Start des UM-Agent auf der Konsole. Das ist für Testzwecke hilfreich. Zum Beenden: Strg-C./opt/umf/bin/umagent -c /etc/umf/umagent.xml -l – Auflisten aller Checks.Die Startparameter des Dienstes stehen in umagent.service (ExecStart). Änderungen nimmt man am besten mit systemctl edit umagent vor.
Der Agent protokolliert seine Arbeit im Daemon-Modus in zwei Logdateien. Wenn das Programm auf der Konsole gestartet wurde, werden keine Logdateien erzeugt, alle Meldungen erscheinen auf der Konsole. Die Logdateien werden beim Datumswechsel automatisch rotiert und veraltete Logdateien automatisch gelöscht.
In der Datei umagent.log werden die internen Ereignisse im folgenden Format protokolliert:
Datum Zeit Nachricht-Klasse Multi-Check-ID Nachricht
Die Nachricht-Klassen:
<server> oder doppelte parnum).Die Checks, die die gleiche Quelle haben, z.B. die gleiche Logdatei oder das gleiche Command, laufen als eine Einheit, genannt Multi-Check. Gleich nach dem Start wird in umagent.log protokolliert, aus welchen Checks ein Multi-Check besteht, z.B.
2026.10.03 18:59:09 INFO MultiCheck-1 Start multi-check with members=1,2,3
Fehler, die auftreten, bevor die Logdateien geöffnet sind (z.B. Konfigurationsdatei nicht gefunden oder kein gültiges XML), werden auf der Konsole ausgegeben. Unter Linux findet man sie mit journalctl -u umagent.
In der Datei mfdata.log werden die Messergebnisse in folgendem Format protokolliert:
Datum Zeit Parameter-Nummer Parameter-Name Wert Messeinheit
Beispiel mfdata.log:
2026.10.03 15:28:20 3 Mem_Usage 99.07 %
2026.10.03 15:28:20 4 Swap_Usage 26.26 %
2026.10.03 15:28:20 5 Mem_Real_Free 6.98 %
2026.10.03 15:28:20 16 App_NET_IN 0.02 MB/s
2026.10.03 15:28:20 14 Alive_Status_OK 4.00 Msg/Min
2026.10.03 15:29:19 1 CPU_Total 10.30 %
2026.10.03 15:29:19 2 CPU_IOWait - %
Ein „-“ als Wert bedeutet: kein Messwert (NODATA).
An den Recipient wird jeder Messwert je nach Sender (siehe globale Parameter) gesendet. Bei UDP als Paket im Format Objekt-Code:Parameter-Nummer:Wert, z.B. SRV000000000001:1:10.30. Bei HTTP-POST und HTTP-GET als HTTPS-Anfrage, siehe Sender.
Mit der Konfigurationsdatei legt man fest, welche Parameter der Agent erfasst. Die Konfigurationsdatei ist eine Textdatei im XML-Format, die Kodierung ist UTF-8 (ISO-8859-1 bzw. Windows-1252 nur mit entsprechender XML-Deklaration). Jeder Parameter eines Checks kann als Attribut <check parname="x"> oder als Element <parname>x</parname> angegeben werden. Unbekannte Attribute und Elemente werden ignoriert und als Warnung protokolliert. Im Folgenden werden die Pflichtparameter mit [P], die optionalen Parameter mit [O] markiert.
Die globalen Konfigurationsparameter regeln die Arbeit des Agenten insgesamt. Beispiel:
<umagent>
<common logdir="../log" keepdays="30" sender="UDP"/>
<server host="monitor.example.com" port="9888" objcode="SRV000000000001"/>
<include>
<cfgfile path="../cfg/syst.xml"/>
<cfgfile path="../cfg/appl.xml"/>
</include>
<check>
....
</check>
</umagent>
<common> – Allgemeine Parameter.logdir – Der Pfad zu dem Ordner für Logdateien. Default „../log“. Der Ordner wird bei Bedarf angelegt.keepdays – Aufbewahrungsdauer archivierter Logdateien. Von 1 bis 730 Tagen. Default 30 Tage.sender – Der Sender, der die Messdaten an den Recipient überträgt: UDP, HTTP-POST oder HTTP-GET. Default UDP. Es wird immer nur ein Sender verwendet, siehe Sender.<server> – Die Konfiguration der Verbindung zum Recipient.host – IP oder Hostname des Recipient. Default 127.0.0.1.port – Port für die Übertragung der Messdaten an den Recipient. 1–65535. Default 9888 bei Sender UDP, 443 bei HTTP-POST und HTTP-GET.authtype – Art der Authentifizierung für HTTP-POST und HTTP-GET. Zurzeit nur BASIC (HTTP Basic Authentication). Weitere Arten folgen später.authuser – Benutzername für die Authentifizierung. Default keine.authpwd – Passwort für die Authentifizierung. Default keine.
authtype, authuser und authpwd müssen zusammen angegeben werden. Sind alle drei nicht definiert, erfolgt keine Authentifizierung. Bei unvollständigen Angaben, unbekanntem authtype oder beim Sender UDP wird eine Warnung protokolliert und die Authentifizierung nicht verwendet.objcode – Objekt-Code des zugehörigen Objekts, 15 Zeichen. Jeder Check darf einen eigenen Objekt-Code haben. Wird benötigt, um einen Agenten einem System zuzuordnen.<include> – Einbeziehen von weiteren Konfigurationsdateien. Es wird empfohlen, die Konfiguration der Checks in separaten Dateien abzulegen und mittels <include> in die Hauptdatei einzubeziehen. Die eingebundenen Dateien haben ebenfalls das Wurzelelement <umagent> und enthalten nur <check>-Elemente.<cfgfile path="..."/> – Der Pfad zu der einbezogenen Konfigurationsdatei. Relative Pfade werden zuerst relativ zum Arbeitsverzeichnis, danach relativ zum Ordner der Hauptdatei gesucht.<check> – Die Definition der zu überwachenden Parameter. Maximal 1024 Checks sind erlaubt.Der Parameter sender in <common> legt fest, wie die Messwerte an den Recipient übertragen werden. Es wird immer nur ein Sender verwendet. Alle Parameter der Konfigurationsdatei (Namen und Werte wie sender, authtype) dürfen groß oder klein geschrieben werden, z.B. HTTP-POST oder http-post.
Die Checks übergeben ihre Messwerte an eine interne Warteschlange, der Sender liest sie von dort und überträgt sie. Ein langsamer Recipient bremst deshalb die Checks nicht. Ist die Warteschlange voll (4096 Messwerte), gehen neue Messwerte verloren, das wird im Logfile umagent.log protokolliert.
UDP – Default. Jeder Messwert wird als UDP-Paket im Format Objekt-Code:Parameter-Nummer:Wert gesendet. Default-Port 9888. Es gibt keine Rückmeldung, bei einem Fehler geht der Messwert verloren.
HTTP-POST – Jeder Messwert wird als HTTPS-POST-Anfrage an https://host:port/ gesendet. Der Inhalt (Content-Type: application/json) ist ein JSON-Objekt:
{"ObjectId":"SRV000000000001","ParNum":1,"Value":"10.30"}
ParNum ist eine Zahl, Value ein String ("-" bedeutet: kein Messwert). Default-Port 443.
HTTP-GET – Jeder Messwert wird als HTTPS-GET-Anfrage gesendet:
https://host:port/?ObjectId=SRV000000000001&ParNum=1&Value=10.30
Default-Port 443.
Hinweise zu HTTP-POST und HTTP-GET:
authtype="BASIC", authuser und authpwd in <server> wird HTTP Basic Authentication verwendet. Ohne diese Parameter erfolgt keine Authentifizierung.Beispiel:
<common logdir="../log" keepdays="30" sender="HTTP-POST"/>
<server host="monitor.example.com" objcode="SRV000000000001"
authtype="BASIC" authuser="agent" authpwd="secret"/>
Mit Check ist die Erfassung der Messwerte eines Parameters gemeint. Es gibt fünf Quellen für die Messdaten. Jede Quelle bezeichnet man als Gruppe.
Die Gruppen syslinux und syswindows liefern Messwerte direkt. Die drei anderen Gruppen benötigen zusätzliches Regelwerk, um aus den Zeichenketten die gewünschten Messwerte zu extrahieren. Es gibt zwei Typen von Regelwerk:
Alle Konfigurationsparameter eines Checks können in drei Bereiche unterteilt werden:
Beispiel der allgemeinen Parameter eines Checks:
<check parname="." uom="." step="." parnum="." active="." objcode=".">
<desc>...</desc>
<group>...</group>
<type>...</type>
<calc operation=".."/>
<default>N</default>
</check>
parname [P] – Logischer Name des Checks, 3 bis 50 Zeichen. Unter diesem Namen werden die Messergebnisse in mfdata.log protokolliert.uom [O] – Messeinheit, z.B. %, MB oder Msg/Min. Max. 15 Zeichen. Default „-“.group [P] – Die Gruppe des Checks: syslinux, logfile, command, syswindows oder eventlog.type [P] – Der Typ des Checks. Bei den Gruppen logfile, command und eventlog entweder finde_digit oder finde_string. Bei syslinux die Statistik (z.B. cpu_total), bei syswindows der Leistungsindikator.step [P] – Der Schritt des Checks in Sekunden. Minimalwert 10.parnum [P] – Die Parameter-Nummer 1, 2, ... Sie muss je Objekt-Code eindeutig sein.active [O] – Deaktiviert = 0, aktiviert = 1 (auch false/true). Default 1.objcode [O] – Objekt-Code des zugehörigen Objekts, 15 Zeichen. Falls nicht definiert, wird der globale Objekt-Code verwendet.<desc> [O] – Kurzbeschreibung des Checks. Max. 200 Zeichen.<calc operation="+ | - | * | / N"/> [O] – Umrechnung des Messergebnisses.<default>N</default> [O] – Der Default-Messwert wird verwendet, wenn kein Messergebnis vorliegt, aber keine Fehler bei Ausführung des Checks auftraten. Anwendbar bei den Gruppen logfile, command und eventlog. Erlaubt ist eine Zahl mit max. 9 Vor- und 2 Nachkommastellen oder „-“. Default bei finde_string „0“, sonst „-“; der Recipient interpretiert „-“ als NODATA.Die Umrechnung mit Hilfe von <calc> ist in einigen Fällen hilfreich, z.B. zur Umrechnung des Durchsatzes einer Netzwerkkarte von Byte/s in MB/s:
<calc operation="/ 1048576"/>
Oder wenn ein Check in Schritten von 5 Min. ausgeführt wird, um das Messergebnis auf einen Wert pro Minute umzurechnen:
<calc operation="/ 5"/>
Die Check Gruppe logfile verarbeitet Logdateien im Textformat in der Zeichenkodierung ASCII oder UTF-8. Es werden nur Zeilen ausgewertet, die nach dem Start des Agenten hinzukommen. Eine Zeile wird erst verarbeitet, wenn sie mit einem Zeilenumbruch abgeschlossen ist. Rotierende Logdateien werden automatisch erkannt, wenn der Schritt des Checks kleiner ist als der Schritt der Rotation. Unter Linux werden, wenn eine Logdatei während der Pause umbenannt oder verschoben wurde, auch die Zeilen berücksichtigt, die in dieser Pause in die alte Datei geschrieben wurden. Unter Windows ist das nicht der Fall: Hier wird die Datei nach jedem Schritt geschlossen, damit die schreibende Anwendung sie rotieren kann.
Der Typ des Checks spezifiziert, wie Messdaten extrahiert werden. Für die Suche werden Suchregeln in <rule>-Elementen definiert. Eine Suchregel ist entweder ein regulärer Ausdruck in RE2-Syntax (im Folgenden Regexp) oder ein Ausschnitt einer bestimmten Spalte (im Folgenden Split). Die Voraussetzung für den Split ist eine Logdatei im CSV-Format (Character Separated Values), das Trennzeichen kann ein beliebiges einzelnes Zeichen sein. In einem Check dürfen mehrere Split-Regeln und mehrere Regexp sein. Die Suchregeln kann man kaskadieren: Jede nachfolgende Regel durchsucht das Ergebnis der vorherigen Regel. Ein Regexp liefert als Ergebnis den Teil in der ersten runden Klammer. In 99,99% der Fälle reichen einfache Regexp aus.
Auch im letzten Regexp muss man das Suchergebnis in runde Klammern setzen. Der String in der runden Klammer wird als Endergebnis interpretiert (siehe Beispiele).
RE2 unterstützt keine Rückverweise (
\1) und keine Lookahead-/Lookbehind-Ausdrücke ((?=...),(?<!...)). Mit(?i)am Anfang wird Groß-/Kleinschreibung ignoriert.
Dieser Check extrahiert mit Hilfe der o.g. Suchregeln die Zahlen aus jeder neuen Zeile der Logdatei oder Ausgabe eines Programms und sendet, je nach Einstellung, Minimalwert, Maximalwert, ersten Wert, letzten Wert, Mittelwert oder die Summe der gefundenen Zahlen zurück. Als gültige Zahl werden Integer und Fließkommazahlen erkannt:
Z.B. „1.0020“, „-0,23456“, „+10000.12345686“. Mehrstellige Zahlen sind schwer zu lesen, deshalb kann man das Ergebnis mit dem Element <calc> umrechnen. Zum Beispiel Umrechnung von Byte in MB:
<calc operation="/ 1048576"/>
Wenn keine neue Zeile in der Logdatei erscheint oder keine Übereinstimmung mit einer Suchregel gefunden wurde, wird der Default-Wert gesendet. Ist kein Default-Wert konfiguriert, wird „-“ gesendet; hat der zugehörige Parameter auf dem Recipient eine Bewertungsregel, wird dies als NODATA interpretiert. Beispiel eines Checks vom Typ finde_digit:
<check parname="." uom="." step="." parnum="." active=".">
<group>logfile</group>
<type>finde_digit</type>
<path>/var/log/race.log</path>
<default>0</default>
<sendback>sum</sendback>
<rule>
<delimiter>,</delimiter>
<column>5</column>
</rule>
<rule>
<regexp>(^ \d{1,3}$)</regexp>
</rule>
</check>
Die allgemeinen Parameter parname, uom, group, type, step, parnum, active, <default>.
<path> [P] – Pfad zur Logdatei. Es kann ein fester sowie ein dynamischer Pfad eingesetzt werden.<sendback> [O] – Wenn die gesuchte Zahl in mehreren Zeilen vorkommt, kann man aus mehreren Zahlen auswählen oder das Endergebnis berechnen: avg, sum, min, max, last, first. Default last.<rule> [P] – Die Suchregel. Mindestens eine Regel wird benötigt. Das Element <rule> beinhaltet entweder die Kombination <delimiter>/<column>, um Daten aus einer bestimmten Spalte herauszufiltern, oder <regexp>, um Daten per Suchmuster herauszufiltern.<delimiter> – Das Trennzeichen des Splits. Genau ein Zeichen, auch ein Leerzeichen ist möglich. Das Zeichen wird wörtlich genommen (auch „|“ oder „.“).<column> – Spaltennummer des Splits. Beginnt bei 0.<regexp> – Regexp sucht nach einem Suchmuster und extrahiert daraus eine Zahl. Die Zahl muss zwingend in runden Klammern abgegrenzt werden.Der Check sucht ein bestimmtes Textmuster in jeder neuen Zeile der Logdatei und sendet die Anzahl der Zeilen zurück, in denen das Suchmuster vorkommt. Eine Zeile wird gezählt, wenn das Ergebnis der letzten Regel nicht leer ist. Suchregeln funktionieren genauso wie beim Typ finde_digit. Wenn keine neuen Zeilen in die Logdatei kommen oder keine Übereinstimmung mit dem Suchmuster gefunden wird, wird 0 gemeldet. Beispiel eines Checks vom Typ finde_string:
<check parname="." uom="." step="." parnum="." active=".">
<group>logfile</group>
<type>finde_string</type>
<path>../log/trace.log</path>
<rule>
<regexp>(\|ERROR\|)</regexp>
</rule>
<default>0</default>
</check>
Die allgemeinen Parameter parname, uom, group, type, step, parnum, active, <default>.
<path> [P] – Der Pfad zur Logdatei. Es kann ein fester sowie ein dynamischer Pfad eingesetzt werden, siehe nachfolgendes Kapitel.<rule> [P] – Die Suchregel. Mindestens eine wird benötigt.<regexp> – Der Regexp sucht nach Suchmustern.Einige Anwendungen erstellen Logdateien, deren Pfad oder Dateiname sich mit der Zeit ändert, z.B. /var/log/app-20160929-10.log. Der UM-Agent kann mit solchen Dateien umgehen, wenn der Pfad oder Dateiname Datum, Zeit oder Wochentag beinhaltet. Es wird automatisch erkannt, ob der Pfad dynamische Elemente beinhaltet. Folgende dynamische Elemente sind verfügbar:
%?YY% – Jahr: 2-stellig%?YYYY% – Jahr: 4-stellig%?M0% – Monat: 1-2-stellig, beginnt mit 0%?MM0% – Monat: 2-stellig, beginnt mit 0%?M1% – Monat: 1-2-stellig, beginnt mit 1%?MM1% – Monat: 2-stellig, beginnt mit 1%?D% – Der Monatstag: 1- oder 2-stellig%?DD% – Der Monatstag: immer 2-stellig%?WDN0% – Die Nummer des Wochentags, beginnt mit 0 (Montag) bis 6 (Sonntag)%?WDN1% – Die Nummer des Wochentags, beginnt mit 1 (Montag) bis 7 (Sonntag)%?H24% – Die Stunde im 24-Stunden-Format: 1- oder 2-stellig%?HH24% – Die Stunde im 24-Stunden-Format: immer 2-stelligAnstelle des Fragezeichens muss L oder S eingesetzt werden.
Der Beispielpfad am 29. September von 10:00 bis 10:59 Uhr:
/var/log/app-20160929-10.log
Entsprechende Pfadangabe im Element <path>:
<path>/var/log/app-%LYYYY%%LMM1%%LDD%-%LHH24%.log</path>
Der dynamische Pfad beinhaltet folgende Elemente:
Die Check Gruppe command führt in jedem Schritt einen Befehl aus und extrahiert den Messwert aus seiner Ausgabe. Standardmäßig wird die Standardausgabe (STDOUT) ausgewertet, mit <source>STDERR</source> die Fehlerausgabe. Der Befehl wird ohne Shell direkt gestartet; Argumente mit Leerzeichen setzt man in Anführungszeichen. Für Pipes, Umleitungen oder mehrere Befehle nacheinander ruft man die Shell selbst auf: unter Linux sh -c "...", unter Windows cmd /c "..." oder powershell -NoProfile -Command "...".
Liefert der Befehl keine Ausgabe, wird der Default-Wert gesendet. Ein Return-Code ungleich 0 wird als Fehler protokolliert, die Ausgabe wird trotzdem ausgewertet. Läuft der Befehl länger als <timeout>, wird er abgebrochen und die bis dahin erhaltene Ausgabe ausgewertet. Für das Extrahieren der Messdaten stehen die zwei Typen finde_string und finde_digit zur Verfügung. Checks mit gleichem Befehl und gleichem Schritt teilen sich eine Ausführung. Beispiel für einen Check der Gruppe command mit Typ finde_string:
<check parname="." uom="." step="." parnum="." active=".">
<group>command</group>
<type>finde_string</type>
<execute>sh -c "ps -ef | grep apache"</execute>
<timeout>2</timeout>
<rule>
<regexp>(Strang-1)</regexp>
</rule>
</check>
Die allgemeinen Parameter parname, uom, group, type, step, parnum, active, <default>.
<execute> [P] – Der Befehl, der ausgeführt werden soll.<timeout> [O] – Timeout in Sekunden. Min. 2, max. 86400 (1 Tag). Default 10.<source> [O] – STDOUT oder STDERR. Default STDOUT.<sendback>, <rule> – Wie bei der Gruppe logfile.Die Check Gruppe syslinux ist nur unter Linux verfügbar und erfasst Linux-spezifische Parameter aus /proc, /sys und dem Befehl df. Im Element <type> wird spezifiziert, welche Statistik benötigt wird. In den nachfolgenden Kapiteln wird aufgeführt, welche Typen zur Verfügung stehen. Checks derselben Untergruppe (cpu, mem, net, fs, bdev) mit gleichem Schritt werden gemeinsam erfasst. Bei CPU, Netzwerk und Block-Device werden die Werte als Differenz zum vorherigen Schritt berechnet; der erste Wert kommt daher nach einem Schritt. Ein Beispiel finden Sie in /etc/umf/example-syslinux.xml.
Die CPU-Checks erfassen die Statistiken über alle Kerne. Messeinheit %. Folgende Typen sind verfügbar:
Die Memory-Checks erfassen die Statistiken über RAM und Swap. Folgende Memory-Checks sind verfügbar:
Die Netzwerk-Checks erfassen die Statistiken über beliebige Netzwerkinterfaces. Für die Checks wird die Angabe eines logischen Netzwerkinterfaces im Element <if> benötigt, z.B. <if>eth0</if>. Existiert das Interface beim Start nicht, wird der Check deaktiviert. Folgende Netzwerk-Checks sind verfügbar (Werte pro Sekunde):
Die Dateisystem-Checks ermitteln die Belegung des lokalen Dateisystems unter einem Mountpoint. Messeinheit %. Für den Check wird der Pfad zum Mountpoint im Element <path> benötigt. Der Check benutzt den Linux-Befehl „df“, der in jeder Linux-Distribution enthalten ist. Folgende Dateisystem-Checks sind verfügbar:
Die Block-Device-Checks ermitteln statistische Daten eines Block-Devices. Als Block-Device kann eine Festplatte, Partition, RAID, LUN oder Multi-Path-Device dienen oder eine logische Partition davon. Dafür wird der Pfad zum Block-Device oder Mapper-Link im Element <path> benötigt. Ein wichtiger Parameter jedes Block-Devices ist die Sektorgröße. Sie wird für die Berechnung des Datendurchsatzes verwendet und aus folgender Datei gelesen:
/sys/block/[Block-Device]/queue/hw_sector_size
Das Dateisystem unter „/sys“ ist kein echtes Dateisystem, sondern ein virtuelles Dateisystem für den Zugriff auf Kernel-Parameter zur Laufzeit. Kann die Sektorgröße nicht gelesen werden, liefert der Check keine Werte und protokolliert einen Fehler. Folgende Block-Device-Checks sind verfügbar:
Eine genaue Beschreibung der Felder findet man in der Kernel-Dokumentation (procfs-diskstats).
Die Check Gruppe syswindows ist nur unter Windows verfügbar. Sie liefert Systemleistungsdaten aus den Windows-Leistungsindikatoren (Performance Counter). Der Agent liest sie direkt über die Windows-Schnittstelle PDH. Im Element <type> gibt man einen eindeutigen Leistungsindikator an.
Die Namen der Leistungsindikatoren werden immer in Englisch angegeben, unabhängig von der Sprache des Betriebssystems. Namen in der Sprache des Betriebssystems (z.B. „\Prozessor(_Total)\Prozessorzeit (%)“) werden nicht akzeptiert. Beispiele:
Wie finde ich die Namen der Leistungsindikatoren?
Am einfachsten mit dem PowerShell-Skript list-perfcounters.ps1, das zusammen mit UM-Agent ausgeliefert wird. Es listet die Leistungsindikatoren mit englischen Namen, wie sie der Agent im Element <type> erwartet, auf Windows in jeder Sprache:
powershell -ExecutionPolicy Bypass -File list-perfcounters.ps1
Anzeigen Instanzen in ein Object z.B. LogicalDisk
powershell -ExecutionPolicy Bypass -File list-perfcounters.ps1 -Object LogicalDisk -Instances
-Object <Text> – zeigt nur Objekte, deren englischer Name den Text enthält, z.B. Processor, LogicalDisk oder PhysicalDisk. Ohne diese Option werden alle Objekte ausgegeben (die Liste ist sehr lang und die Ausgabe dauert etwas).-Instances – zeigt die konkreten Instanzen, z.B. \LogicalDisk(C:)\% Free Space oder (_Total). Ohne diese Option steht „(*)“ in den Namen. Der Agent braucht die Form mit konkreter Instanz.powershell -ExecutionPolicy Bypass -File list-perfcounters.ps1 -Object LogicalDisk -Instances | findstr /C:"Free Space"
Die Leistungsindikatoren mit * in ihrem Namen dürfen nicht verwendet werden!
Hinweis zur Sprache: Bei einigen neueren Objekten (z.B. „TCP/IP-Leistungsdiagnose“, „SMB-Serverfreigaben“, „QUIC-Leistungsdiagnose“, „WMIPrvSE-Integritätsstatus“) gibt es auf einem nicht englischen Windows keine englischen Namen.
Alternativ mit typeperf.exe kann man die Leistungsindikatoren in der Sprache des Betriebssystems anzeigen. Auf einem englischen Windows sind die Namen daher direkt verwendbar:
typeperf.exe -qx – alle Leistungsindikatoren mit allen vorhandenen Instanzen, z.B. \Processor(0)\% Processor Time (die Liste ist sehr lang).typeperf.exe -q – alle Leistungsindikatoren, aber ohne konkrete Instanzen. Statt dessen steht *.Unbekannte Leistungsindikatoren werden beim Start des Agent erkannt und deaktiviert mit Fehlermeldung in Logfile. Mit umagent -list kann man die Namen prüfen, ohne den Agenten zu starten.
Die Werte werden in 5-Sekunden-Intervallen erfasst. Dadurch entstehen mehrere Messergebnisse pro Schritt. Deshalb kann das Element <sendback> benutzt werden. Default ist „avg“ (Mittelwert). In einigen Fällen ist eine andere Funktion sinnvoller, z.B. ist bei der Belegung einer Partition „last“ besser geeignet. Alle syswindows-Checks mit gleichem Schritt werden gemeinsam erfasst. Beispiel eines Checks der Gruppe syswindows mit Umrechnung von Bytes in MBytes:
<check parname="DiscWriteC" uom="MB/s" step="60" parnum="7" active="1">
<group>syswindows</group>
<type>\LogicalDisk(C:)\Disk Write Bytes/sec</type>
<calc operation="/ 1048576"/>
</check>
Weitere Beispiele in ..\cfg\example-syswindows.xml.
Die Check Gruppe eventlog ist nur unter Windows verfügbar. Der Agent liest die Events direkt über die Windows-Schnittstelle des Ereignisprotokolls. In jedem Schritt werden alle neuen Events gelesen, die seit dem letzten Schritt entstanden sind; beim ersten Schritt alle seit dem Start des Agenten. Events aus der Zeit, in der der Agent nicht lief, werden nicht gelesen. Das Lesen ist pro Schritt auf 10 Sekunden begrenzt.
Jedes Event wird in eine Zeile umgewandelt, die Felder sind durch „|“ getrennt:
Zeit|Level|EventID|Quelle|Text
2026-10-03T14:03:11.Auf diese Zeile werden die Suchregeln angewendet. Für das Extrahieren der Messdaten stehen die zwei Typen finde_string und finde_digit zur Verfügung. Im Element <path> steht der Name des Ereignisprotokolls (Kanal). Standardmäßig sind auf Windows folgende Ereignisprotokolle vorhanden: System, Application, Setup, Security – unabhängig von der Sprache des Betriebssystems. Möglich sind auch Kanäle wie „Microsoft-Windows-TaskScheduler/Operational“. Existiert der Kanal beim Start nicht, wird der Check deaktiviert.
Das Beispiel mit Typ finde_string zählt kritische Events im Ereignisprotokoll System:
<check parname="EventSysCritical" uom="Error/Min" step="300" parnum="9" active="1">
<desc>Check critical events in system eventlog.</desc>
<group>eventlog</group>
<type>finde_string</type>
<path>System</path>
<calc operation="/ 5"/>
<rule>
<regexp>^[^|]*\|(Critical)\|</regexp>
</rule>
</check>
Mit Split-Regeln kann man gezielt auf ein Feld zugreifen. Das Beispiel zählt Abstürze von Anwendungen (EventID 1000 im Ereignisprotokoll Application):
<rule>
<delimiter>|</delimiter>
<column>2</column>
</rule>
<rule>
<regexp>^(1000)$</regexp>
</rule>
Die allgemeinen Parameter parname, uom, group, type, step, parnum, active, <default>.
<path> [P] – Name des Ereignisprotokolls.<rule> [P] – Suchregel. Mindestens eine wird benötigt.<regexp> – Regexp. Sucht nach dem Suchmuster.Für Testzwecke können Sie ein Event selbst erzeugen:
eventcreate /T ERROR /ID 158 /L APPLICATION /D "This is a test-event"
Das Test-Event wird in folgende Zeile umgewandelt und anschließend durchsucht:
2026-10-03T21:45:24|Error|158|EventCreate|This is a test-event
Die Beispiele zeigen die unterschiedlichen Möglichkeiten, Parameter in Logdateien mithilfe der Typen finde_digit und finde_string zu überwachen.
Beispielsweise suchen wir in einer Logdatei nach einem bestimmten Muster, aus dem eine Zahl extrahiert werden soll. Weil das Suchmuster in mehreren Zeilen vorkommen kann, soll der Mittelwert an den Recipient gesendet werden. Hier eine Beispielzeile aus der Logdatei:
2012.05.20 20:23:23|INFO|Some-Modul...| ... Tried to connect XXX times|....||
Das erreicht man mit dem Typ finde_digit und einer Regexp-Regel. Die Regel sucht nach dem Text „Tried to connect“, gefolgt von einer Zahl. Der Teil in runden Klammern wird als die gesuchte Zahl interpretiert. Der Check analysiert alle 120 Sekunden alle neuen Zeilen. Der Mittelwert aller gefundenen Zahlen wird mit der Parameter-Nummer 1 an den Recipient gesendet.
<check parname="ConnectTries" uom="-" step="120" parnum="1" active="1">
<group>logfile</group>
<type>finde_digit</type>
<path>../log/random.log</path>
<rule>
<regexp>Tried to connect (\d+) times</regexp>
</rule>
<sendback>avg</sendback>
</check>
Wenn die gesuchte Zahl Nachkommastellen hat (z.B. „123,2334“), muss man den Regexp erweitern:
<regexp>Some result (\d+,\d+)</regexp>
Der Check liefert die Anzahl der Zeilen aus der Logdatei, in denen der gesuchte Regexp-Ausdruck gefunden wurde. Die Suchregeln funktionieren nach demselben Prinzip, deshalb hier nur eine Liste mit verschiedenen Beispielen für Regexp-Ausdrücke.
Tabelle 3: Beispiele für reguläre Ausdrücke
<regexp>(Abort|Error)</regexp> – Suche nach dem String „Abort“ oder „Error“.<regexp>(?i)(error)</regexp> – Suche nach „error“ ohne Beachtung der Groß-/Kleinschreibung.<regexp>(Tried to connect \d+ times)</regexp> – Suche nach dem Text „Tried to connect“ mit einer danach folgenden Zahl.<regexp>^[^|]*\|(Error|Critical)\|</regexp> – EventLog: Events mit Level Error oder Critical.Die Fehlermeldung „Failed process configuration file ... XML syntax error on line N“. Der Fehler passiert, wenn die Konfigurationsdatei nicht XML-konform ist. Beispiele:
<common logdir="../log/"> – hier fehlt das abschließende „/“.
<server host="mfserver/> – hier fehlt ein „"“.
<rule> … </rules> – das abschließende Element ist nicht identisch mit dem beginnenden Element.
<regexp>a&b</regexp> – die Zeichen „&“ und „<“ müssen als & bzw. < geschrieben werden.
Bei der Fehleranalyse ist das Linux-Bordmittel xmllint oder ein anderer XML-Parser hilfreich. Mit umagent -list wird die Konfiguration geprüft, ohne den Agenten zu starten.
Im Regexp fehlen die runden Klammern ().
Ungültiger Regexp-Ausdruck, z.B. mit Rückverweis oder Lookahead, die von RE2 nicht unterstützt werden.
Falscher Regexp-Ausdruck. Der gesuchte Text wird nicht erkannt.
syswindows: Name des Leistungsindikators in der Sprache des Betriebssystems statt in Englisch.
eventlog: Suchmuster aus Version 2 (z.B. <Level>1</Level>) passen nicht mehr zum neuen Zeilenformat.
Warnung „unknown element <...> ignored“ – Tippfehler im Namen eines Elements.
Copyright (C) 2012-2026 by Andrej Koslov. MIT-Lizenz. · UMAgent Dokumentation · Software Version 4.0.0