Monitoring & Betrieb

Logs zentral sammeln: rsyslog, Loki und OpenSearch

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
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. Seit das NIS2-Umsetzungsgesetz im Dezember 2025 in Kraft getreten ist, verlangt § 32 BSIG von betroffenen Einrichtungen eine frühe Erstmeldung innerhalb von 24 Stunden, eine Meldung mit erster Bewertung innerhalb von 72 Stunden und eine Abschlussmeldung nach einem Monat. 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 Grafana Alloy, der Nachfolger von Promtail, das seit März 2026 keine Updates mehr bekommt. 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. Je nach Distribution liegt das Journal standardmäßig nur im RAM, und das eingebaute Rate Limiting 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

Mit Storage=persistent legt journald das Verzeichnis /var/log/journal selbst an, beim Standardwert auto schreibt es nur dann auf die Platte, wenn das Verzeichnis schon existiert. ForwardToSyslog=yes brauchst du dort, wo rsyslog die Meldungen über den Syslog-Socket bekommt, etwa unter Debian und Ubuntu. Auf der RHEL-Familie liest rsyslog das Journal über das Modul imjournal direkt, dort ist die Weiterleitung überflüssig und erzeugt im schlimmsten Fall doppelte Zeilen.

Ü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                          # Syntaxprüfung, 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 wegräumen, Aufbewahrungsfrist einsetzen
# (mit chattr +a versiegelte Dateien vorher per chattr -a freigeben)
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. Denk daran, dass auch deine Löschroutine nach Fristablauf das Attribut erst mit chattr -a entfernen muss.
  • 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 zusätzlich 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 = constants.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 (Promtail ist seit dem 2. März 2026 End-of-Life) und liest das Journal direkt. Der Benutzer alloy muss dafür in den Gruppen adm und systemd-journal sein, sonst startet die Komponente ohne Fehler und liefert schlicht nichts. 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.

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Passender Lernpfad

Karrierepfad

Dein Weg zum Linux Junior Administrator (LPIC-1)

Du willst Linux im Arbeitsalltag sicher bedienen, Systeme zuverlässig verwalten und dich gezielt auf die LPIC-1 Prüfung vorbereiten? In diesem Lernpfad baust du Schritt für Schritt das Wissen auf, das du als Linux Junior Administrator brauchst: von der Kommandozeile über Benutzer- und Rechteverwaltung bis zu Netzwerkgrundlagen und Systemdiensten.

Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

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 intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Gut zu wissen

Häufige Fragen zu zentralem Logging unter Linux

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

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 rsyslog ist in allen großen Distributionen paketiert. Auf RHEL und Ubuntu ist es meist schon installiert, Debian richtet es seit Version 12 nicht mehr standardmäßig ein. 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. Lizenzrechtlich sind beide Volltext-Varianten wieder quelloffen: OpenSearch steht unter der Apache-2.0-Lizenz und wird von einer Stiftung unter dem Dach der Linux Foundation getragen, Elasticsearch gibt es seit 2024 zusätzlich unter der AGPL.
Wie lange muss ich Logs unter NIS2 aufbewahren?
Die NIS2-Richtlinie und das BSIG in der seit Dezember 2025 geltenden Fassung nennen keine feste Zahl an Monaten. Verlangt werden Verfahren zur Bewältigung von Sicherheitsvorfällen (§ 30 BSIG) und die Fähigkeit, innerhalb von 24 Stunden eine frühe Erstmeldung und innerhalb von 72 Stunden eine Bewertung abzugeben (§ 32 BSIG). 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.

Zuletzt geprüft am 05. Oktober 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick

Passt thematisch dazu

Kommen die Logs nicht nur vom Betriebssystem, sondern aus verteilten Anwendungen, zeigt OpenTelemetry für Logs, Metriken und Traces , wie du sie mit Metriken und Traces über einen gemeinsamen Collector zusammenführst.

Liegen Teile der Landschaft bei einem Cloud-Anbieter, klärt die NIS2-Pflichten beim Cloud-Betrieb , welche Protokollierungs- und Meldepflichten trotzdem bei dir bleiben.

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.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

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

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, für den Volltext-Weg die OpenSearch Schulung: Dashboards, Betrieb, Migration, 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.