0800 71 20000
Kontakt
...
Monitoring & Betrieb

Zentrales Logging unter Linux: Logs sammeln, auswerten und im Ernstfall nachweisen

Lokale Logs helfen dir im Ernstfall nicht: Wer angreift, räumt sie auf. Erst eine zentrale Sammlung mit eigenem Zugriffsschutz macht Korrelation möglich und erfüllt nebenbei die Nachweispflichten aus NIS2.

6 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Betriebsingenieur beobachtet mehrere Monitoring-Bildschirme im Leitstand
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum lokale Logs im Ernstfall nicht ausreichen

Auf einem einzelnen Server ist die Lage übersichtlich: journalctl, ein paar Dateien unter /var/log, logrotate räumt regelmäßig auf. Sobald aber dreißig oder dreihundert Systeme im Spiel sind, kippt dieses Modell. Ein Vorfall zieht sich über Loadbalancer, Applikationsserver, Datenbank und Firewall, und du sitzt vor vier SSH-Sessions und versuchst, Zeitstempel im Kopf zu synchronisieren. Wenn ein System kompromittiert wurde, ist ausgerechnet dessen lokales Log die unzuverlässigste Quelle, weil jemand mit Rootrechten Einträge löschen oder verändern kann.

Dazu kommt der regulatorische Druck. NIS2 verlangt von betroffenen Einrichtungen eine Frühwarnung innerhalb von 24 Stunden und einen Bericht nach 72 Stunden. Diese Fristen hältst du nur ein, wenn die Daten schon vor dem Vorfall an einer Stelle liegen, mit definierter Aufbewahrung und durchsuchbar. Wer erst nach dem Alarm anfängt, Logs einzusammeln, verliert genau die Zeit, die er für die Analyse bräuchte.

Typische Fehler wiederholen sich dabei in fast immer derselben Reihenfolge. Es wird alles auf höchstem Loglevel eingesammelt, der Storage läuft nach wenigen Wochen voll, danach dreht jemand die Aufbewahrung auf sieben Tage herunter und die Nachweisfähigkeit ist wieder weg. Oder die Zeitquelle stimmt nicht, weil chrony auf einem Teil der Systeme nie sauber konfiguriert wurde, und die Korrelation über mehrere Hosts wird zur Ratearbeit. Und sehr oft fehlt die Zugriffskontrolle: Wenn dieselben Konten, die Systeme administrieren, auch die zentrale Logablage schreiben und löschen dürfen, ist die Beweiskraft der Daten praktisch dahin.

Miniatur-Szene: Leitstand mit drei Dashboard-Bildschirmen, Alarmglocke und rotierender Radarschüssel
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Die Ebenen einer zentralen Logpipeline

  1. 01 Quellen: journald, auditd, Dienste
  2. 02 Collector auf dem Host
  3. 03 Transport mit TLS und Puffer
  4. 04 Speicher: Index oder Objektstorage
  5. 05 Retention und Unveränderbarkeit
  6. 06 Auswertung, Alarme, Nachweis
Was du mitnimmst

So baust du eine belastbare Logpipeline auf

Zentrales Logging ist weniger ein Produkt als eine Kette aus Entscheidungen. Wenn du sie in dieser Reihenfolge triffst, bekommst du eine Umgebung, die im Betrieb bezahlbar bleibt und im Vorfall trotzdem trägt.

Quellen und Loglevel festlegen

Bevor du eine Zeile Konfiguration schreibst, entscheidest du, welche Quellen wirklich zentral gebraucht werden: journald mit systemd-Unit-Kontext, auditd für Kernel- und Zugriffsereignisse, sshd, sudo, nftables-Logs, Webserver-Access-Logs, Datenbank-Logs und Applikationsausgaben. Dabei legst du je Quelle das Loglevel fest, statt pauschal alles auf debug zu stellen.

Sammlung und Transport sauber trennen

Auf den Systemen läuft ein Collector, etwa rsyslog, systemd-journal-upload, Fluent Bit, Vector oder Promtail beziehungsweise der Grafana Alloy Nachfolger. Wichtig sind gepufferter Versand, damit ein Netzwerkausfall keine Lücke reißt, sowie TLS und eine Authentifizierung, damit niemand fremde Einträge in deine Pipeline schreiben kann.

Struktur und Zeit vereinheitlichen

Logs werden erst dann auswertbar, wenn Felder benannt sind. Setze auf strukturierte Formate wie JSON oder ein gemeinsames Label-Schema mit host, unit, environment und severity, und sorge mit chrony und einheitlicher Zeitzone dafür, dass Zeitstempel über alle Systeme hinweg vergleichbar bleiben.

Speicher, Index und Kosten planen

Hier entscheidet sich der Betrieb. Ein Volltextindex wie in OpenSearch oder Elasticsearch macht beliebige Suchen schnell, kostet aber deutlich mehr Speicher und RAM. Grafana Loki indexiert nur Labels und legt den Rest komprimiert in Objektstorage ab, was günstiger ist, dafür aber ein durchdachtes Labelkonzept verlangt. Rechne den erwarteten Tagesdurchsatz in GB hoch und leite daraus Retention und Hardware ab, nicht umgekehrt.

Aufbewahrung und Unveränderbarkeit umsetzen

Definiere Aufbewahrungsfristen pro Datenklasse, etwa kurze Fristen für Debug-Ausgaben und lange für sicherheitsrelevante Ereignisse. Ergänze WORM-Storage oder Objektstorage mit Object Lock, getrennte Konten für Schreiben und Löschen sowie eine dokumentierte Löschroutine, damit Datenschutz und Nachweispflicht nicht gegeneinander laufen.

Auswertung, Alarme und Übung

Zum Schluss baust du Dashboards und Alarmregeln für die Fälle, die dich wirklich wecken sollen, etwa fehlgeschlagene Anmeldungen in Serie, sudo-Nutzung außerhalb der Wartungsfenster oder plötzlich abreißende Logströme. Ein stiller Collector ist selbst ein Alarm. Spiele einen Vorfall einmal komplett durch, damit im Ernstfall klar ist, wer welche Abfrage stellt und wie der Export für eine Meldung aussieht.

Tutorial

Vom lokalen Journal zum abgesicherten Logserver

Der Aufbau folgt dem Weg der Daten: erst das lokale Journal so einstellen, dass nichts stillschweigend verschwindet, dann ein Transport, der Netzausfälle übersteht, dann die Ablage auf dem Sammler, zum Schluss Unveränderbarkeit und Auswertung. Die Beispiele nutzen rsyslog mit RELP, weil das in gemischten Landschaften aus RHEL-Derivaten und Debian der kleinste gemeinsame Nenner ist.

01

Schritt 1: Das lokale Journal soll keine Zeilen mehr verwerfen

Bevor du irgendetwas versendest, muss die Quelle stimmen. Standardmäßig liegt das Journal im RAM und wirft bei Lastspitzen Meldungen weg.

/etc/systemd/journald.conf
[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G
SystemMaxFileSize=128M
MaxRetentionSec=2week
RateLimitIntervalSec=30s
RateLimitBurst=20000
ForwardToSyslog=yes

Storage=persistent braucht das Verzeichnis /var/log/journal, sonst bleibt alles flüchtig. ForwardToSyslog=yes ist die Brücke zu rsyslog, ohne sie sieht der Weiterleiter nichts vom Journal.

Übernehmen und prüfen
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

journalctl --disk-usage
journalctl --verify
journalctl -b -p err                       # Fehler seit dem letzten Boot

journalctl --verify prüft die Journaldateien auf Beschädigungen. Wenn es dort schon Lücken meldet, brauchst du über zentrale Auswertung noch nicht nachzudenken.

02

Schritt 2: Transport, der Ausfälle übersteht

Syslog über UDP verliert Nachrichten still und kennt keine Authentifizierung. RELP bestätigt jede Nachricht auf Anwendungsebene, das ist der Unterschied zwischen Vermutung und Nachweis.

Vier Transportwege im Vergleich

TransportWas bei Störung passiertWofür brauchbar
UDP 514Nachrichten fallen kommentarlos weg, niemand merkt esAltgeräte, die nichts anderes können, und nur mit Zusatzüberwachung
TCP 514Verbindung bricht, gepufferte Nachrichten gehen verlorenBesser als UDP, ohne Queue aber kein Nachweis über Lücken
TCP mit TLSWie TCP, zusätzlich verschlüsselt und beidseitig authentifiziertMindeststandard, sobald der Weg ein Netzsegment verlässt
RELP mit TLSJede Nachricht wird quittiert, unquittierte werden erneut gesendetDer Weg, den du nimmst, wenn die Logs Beweiswert haben sollen
/etc/rsyslog.d/10-forward.conf auf jedem Client
module(load="omrelp")

action(type="omrelp"
       target="log01.intern.example"
       port="2514"
       tls="on"
       tls.caCert="/etc/pki/tls/certs/logging-ca.pem"
       tls.myCert="/etc/pki/tls/certs/client.pem"
       tls.myPrivKey="/etc/pki/tls/private/client.key"
       tls.authMode="name"
       tls.permittedPeer=["log01.intern.example"]
       action.resumeRetryCount="-1"
       queue.type="LinkedList"
       queue.filename="fwd_log01"
       queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on")

Die letzten fünf Zeilen sind der Unterschied zwischen Logs sind bei der Netzstörung weg und Logs kommen nach. action.resumeRetryCount=„-1“ versucht es unbegrenzt weiter, queue.filename schaltet die plattengestützte Warteschlange ein, queue.saveOnShutdown rettet sie über einen Reboot.

Pakete und Pfade je Distribution
# RHEL / Rocky / Alma
sudo dnf install -y rsyslog-relp rsyslog-gnutls
# Zertifikate unter /etc/pki/tls/{certs,private}

# Debian / Ubuntu
sudo apt install -y rsyslog-relp rsyslog-gnutls
# Zertifikate unter /etc/ssl/{certs,private}

sudo rsyslogd -N1                          # Syntaxpruefung, immer zuerst
sudo systemctl restart rsyslog
logger -p local3.info "logtest $(hostname) $(date +%s)"
ss -tnp | grep 2514

rsyslogd -N1 ist das Gegenstück zu sshd -t: Es fängt genau die Tippfehler ab, die dir sonst den Logversand abschalten, ohne dass es jemandem auffällt. Der logger-Aufruf mit Zeitstempel ist dein Testsatz, den du auf dem Sammler wiederfindest.

03

Schritt 3: Der Sammler nimmt an und legt sortiert ab

Auf dem Logserver läuft dieselbe Software, nur mit dem Eingangsmodul. Wichtig ist die Ablagestruktur: pro Host und Tag eine Datei, sonst kommst du im Ernstfall nicht durch die Menge.

/etc/rsyslog.d/10-collector.conf auf dem Logserver
module(load="imrelp" ruleset="remote")

input(type="imrelp" port="2514" tls="on"
      tls.caCert="/etc/pki/tls/certs/logging-ca.pem"
      tls.myCert="/etc/pki/tls/certs/log01.pem"
      tls.myPrivKey="/etc/pki/tls/private/log01.key"
      tls.authMode="name"
      tls.permittedPeer=["*.intern.example"])

template(name="proHost" type="string"
         string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")

ruleset(name="remote") {
    action(type="omfile" dynaFile="proHost"
           dirCreateMode="0750" fileCreateMode="0640")
}

tls.authMode=„name“ prüft den Namen im Clientzertifikat gegen permittedPeer. Ohne diese beiden Zeilen ist TLS nur Verschlüsselung, aber keine Authentifizierung, und jeder im Netz kann dir Logzeilen unterschieben.

Zugang begrenzen und Ablage aufräumen
# RHEL / Rocky / Alma
sudo firewall-cmd --permanent --zone=internal --add-source=10.10.0.0/16
sudo firewall-cmd --permanent --zone=internal --add-port=2514/tcp
sudo firewall-cmd --reload

# Debian / Ubuntu mit nftables
sudo nft add rule inet filter input ip saddr 10.10.0.0/16 tcp dport 2514 accept

# Alte Tagesdateien wegraeumen, Aufbewahrungsfrist einsetzen
sudo find /var/log/remote -type f -name '*.log' -mtime +365 -print -delete

Der Logserver nimmt ausschließlich aus dem Verwaltungsnetz an. Genauso wichtig ist die Gegenrichtung: Von den überwachten Hosts darf es keinen administrativen Zugang auf den Sammler geben, sonst ist die Trennung wertlos.

04

Schritt 4: auditd getrennt wegstreamen

auditd schreibt nicht ins Journal, sondern nach /var/log/audit/audit.log. Genau diese Spur brauchst du im Ernstfall, also gehört sie ebenfalls vom Host weg.

Audit-Weiterleitung einschalten
sudo dnf install -y audispd-plugins          # Debian/Ubuntu: sudo apt install audispd-plugins
sudoedit /etc/audit/plugins.d/au-remote.conf # active = yes
sudoedit /etc/audit/audisp-remote.conf
#   remote_server = log01.intern.example
#   port = 60
#   transport = tcp
#   network_failure_action = syslog

sudo service auditd restart
sudo auditctl -s
sudo ausearch -m USER_LOGIN -ts today | tail

network_failure_action = syslog sorgt dafür, dass ein Ausfall der Strecke wenigstens im Syslog auftaucht, statt lautlos zu passieren.

05

Schritt 5: Aufbewahrung, die vor Gericht trägt

Ein Logarchiv, das der Angreifer mit denselben Rechten löschen kann wie das Original, ist kein Archiv. Diese Punkte trennen Sammlung von Beweissicherung.

Unveränderbarkeit und Nachweis

  • Archivkopie auf einem Speicher, den der Sammler nur beschreiben darfObjektspeicher mit Object Lock oder ein Ziel, das nur Anlegen erlaubt, verhindert nachträgliches Verändern. Wer löschen kann, kann Spuren verwischen.
  • Abgeschlossene Tagesdateien auf append-only setzenchattr +a lässt Anhängen zu, aber kein Überschreiben und kein Löschen, selbst für root nicht ohne vorheriges Entfernen des Attributs. Das kostet nichts und macht stilles Manipulieren auffällig.
  • Zeit auf allen Hosts synchron und der Sammler auf UTCOhne gemeinsame Zeitbasis kannst du Ereignisse nicht korrelieren. Sommerzeitwechsel in lokalen Zeitstempeln sind der Klassiker für unbrauchbare Beweisketten.
  • Zugriffe auf das Archiv selbst protokollierenWer das Archiv liest oder exportiert, gehört ebenfalls in die Spur. Sonst ist der einzige unprotokollierte Vorgang der interessanteste.
  • Löschfristen schriftlich festgelegtDie DSGVO verlangt eine Begründung für die Speicherdauer personenbezogener Daten, und Logs enthalten regelmäßig welche. Eine Frist ohne Dokument ist keine Frist.
  • Betriebsrat vor der Einführung beteiligtZentrale Protokollierung ist eine technische Einrichtung im Sinne von Paragraf 87 Absatz 1 Nummer 6 BetrVG. Ohne Beteiligung kippt dir das Projekt spät und teuer.
  • Wiederherstellung aus dem Archiv einmal geübtErst der Rückweg zeigt, ob Format, Schlüssel und Werkzeuge zusammenpassen. Ein Archiv, das nie jemand gelesen hat, ist eine Annahme.
Härtung und Zeitbasis
sudo timedatectl set-timezone UTC
chronyc tracking | grep -E 'Reference ID|System time|Stratum'

# Abgeschlossene Tagesdatei versiegeln
sudo chattr +a /var/log/remote/web01/2026-07-24.log
lsattr /var/log/remote/web01/2026-07-24.log

# Journal zusaetzlich lokal signieren (erkennt Manipulation, verhindert sie nicht)
sudo journalctl --setup-keys
journalctl --verify

Forward Secure Sealing über journalctl --setup-keys ersetzt keine zentrale Sammlung, es macht aber nachträgliche Änderungen am lokalen Journal erkennbar. Für die Einordnung: Das BSI beschreibt die Anforderungen an Protokollierung im Baustein OPS.1.1.5, die Auswertung im Baustein DER.1.

06

Schritt 6: Auswerten, alarmieren, üben

Erst mit Abfragen und Alarmen zahlt sich der Aufbau aus. Wer nur sammelt, hat ein teures Archiv und keine Erkennung.

Grafana Alloy als Journal-Quelle
loki.source.journal "system" {
  max_age    = "12h"
  labels     = { job = "systemd-journal", host = env("HOSTNAME") }
  forward_to = [loki.write.zentral.receiver]
}

loki.write "zentral" {
  endpoint {
    url = "https://loki.intern.example/loki/api/v1/push"
  }
}

Alloy hat Promtail als Agent abgelöst und liest das Journal direkt. Der Weg über rsyslog bleibt trotzdem sinnvoll, weil er auch Geräte einsammelt, auf denen kein Agent läuft, etwa Switches und Firewalls.

Vier Abfragen, mit denen du anfängst

  • sum by (host) (count_over_time({job=„systemd-journal“} |= „Failed password“ [5m])) > 20 findet Bruteforce gegen SSH.
  • absent_over_time({job=„systemd-journal“, host=„web01“}[15m]) alarmiert, wenn ein Host aufhört zu liefern. Das ist der wichtigste Alarm überhaupt, denn Stille ist der erste Effekt eines erfolgreichen Angriffs.
  • Ein Alarm auf gestoppte Auditd-Dienste und auf Änderungen an /etc/sudoers.d/ deckt die typischen Rechteausweitungen ab.
  • Ein Alarm auf den freien Platz des Sammlers, ausgeliefert über einen zweiten Weg, etwa direkt aus dem Monitoring.

Plane einmal im Quartal eine halbe Stunde ein, in der jemand aus dem Team eine konkrete Frage nur mit den zentralen Logs beantwortet, zum Beispiel: Wer hat sich am vorletzten Dienstag zwischen 20 und 22 Uhr auf welchem Host als root angemeldet? Wenn das länger als zehn Minuten dauert, fehlt es nicht an Daten, sondern an Struktur, Feldern oder Rechten.

Passende Kurse

Kurse zu zentralem Logging unter Linux bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Grafana Loki Schulung für Log-Management 3 Tage Präsenz nächster Termin 14.10.2026 Zum Kurs Monitoring mit Prometheus und Grafana - Grundkurs 3 Tage Präsenz oder Live-Online nächster Termin 09.11.2026 Zum Kurs Linux Troubleshooting Training: Kritische Probleme beheben 3 Tage Präsenz nächster Termin 09.12.2026 Zum Kurs Linux Security Intensivkurs 3 Tage Präsenz nächster Termin 16.11.2026 Garantietermin Zum Kurs
Unverbindlich beraten lassen Alle DevOps-Kurse ansehen
Gut zu wissen

Häufige Fragen zu zentralem Logging unter Linux

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Reicht rsyslog als zentraler Logserver aus?
Für kleinere Umgebungen reicht ein rsyslog-Server mit TLS, sauberer Ablagestruktur und logrotate durchaus, und er ist auf jedem Linux-System ohnehin vorhanden. Sobald du aber über viele Systeme hinweg suchen, filtern und visualisieren willst, stößt die reine Dateiablage an ihre Grenzen, weil grep über Terabyte an Textdateien keine Analyse ersetzt. Dann lohnt sich ein System mit Index oder Labelsuche darüber.
Loki oder OpenSearch, was passt besser?
Grafana Loki indexiert ausschließlich Labels und speichert den Loginhalt komprimiert in Objektstorage, was den Betrieb günstig und die Skalierung einfach macht, solange deine Abfragen sich an Labels wie Host, Umgebung und Dienst entlanghangeln. OpenSearch oder Elasticsearch bauen einen Volltextindex auf und erlauben dadurch beliebige Freitextsuchen und komplexe Aggregationen, brauchen dafür aber deutlich mehr RAM und Storage sowie mehr Pflege. Wenn Logs vor allem dem Betrieb und dem Troubleshooting dienen, ist Loki oft die wirtschaftlichere Wahl, bei forensischer Freitextsuche über lange Zeiträume spielt der Volltextindex seine Stärke aus.
Wie lange muss ich Logs unter NIS2 aufbewahren?
Die NIS2-Richtlinie und das deutsche Umsetzungsgesetz nennen keine feste Zahl an Monaten, sondern verlangen Verfahren zur Behandlung von Sicherheitsvorfällen und die Fähigkeit, innerhalb von 24 Stunden eine Frühwarnung und innerhalb von 72 Stunden eine Bewertung abzugeben. In der Praxis setzen viele Betreiber sicherheitsrelevante Logs auf sechs bis zwölf Monate an, weil Angriffe oft erst Wochen nach dem Erstzugriff auffallen. Die konkrete Frist solltest du gemeinsam mit Datenschutz und Rechtsabteilung festlegen und schriftlich begründen.
Wie verhindere ich, dass ein Angreifer die Logs manipuliert?
Der wichtigste Schritt ist der zeitnahe Versand vom Host weg, damit ein kompromittiertes System die zentrale Kopie nicht mehr erreicht. Ergänzend gibst du dem Collector nur Schreibrechte ohne Lösch- oder Änderungsrechte, trennst die Administration der Loginfrastruktur von der Administration der überwachten Systeme und legst sicherheitsrelevante Daten auf Storage mit Object Lock oder WORM-Funktion ab. Ein Alarm auf abreißende Logströme deckt zusätzlich den Fall ab, dass jemand den Agenten einfach stoppt.
Wie viel Logvolumen entsteht pro Server und Tag?
Das hängt stark von Rolle und Loglevel ab und lässt sich nicht seriös pauschalisieren. Ein ruhiger Applikationsserver bleibt oft im niedrigen zweistelligen Megabyte-Bereich pro Tag, ein Reverse Proxy mit hohem Requestaufkommen oder eine Datenbank mit aktiviertem Statement-Log erzeugt schnell ein Vielfaches davon. Miss deshalb vor dem Rollout eine Woche lang an repräsentativen Systemen, etwa über die Größe der Journal-Dateien, und rechne daraus mit Puffer hoch.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Monitoring & Betrieb Nagios ablösen, ohne deine Checks wegzuwerfen Ansehen Monitoring & Betrieb Linux-Server langsam? So findest du die Ursache systematisch Ansehen Monitoring & Betrieb Monitoring Tools im Vergleich: Welches Open-Source-Werkzeug passt zu deiner Infrastruktur? Ansehen Einstieg & Karriere Quereinstieg als Linux-Administrator: Was du wirklich brauchst Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
“
Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

Logging mit uns aufbauen statt im Vorfall improvisieren

In der Grafana Loki Schulung für Log-Management baust du eine komplette Logpipeline von der Sammlung bis zur Abfrage mit LogQL auf. Wenn du Metriken und Alarmierung gleich mitdenken willst, passen die Kurse zu Prometheus und Grafana oder der Zabbix Administration Komplettkurs dazu, und für die Analyse nach einem Vorfall gibt es das Linux Troubleshooting Training sowie die Digitale Forensik für Linux und Unix Systeme. Alle Termine finden als Präsenz- oder Live-Online-Schulung statt. Melde dich einfach, wenn du unsicher bist, welcher Einstieg zu deiner Umgebung passt.

Beratung anfragen 0800 71 20000