Site icon bintorosoft.com

Logs und Metriken unter Ubuntu zentral sammeln und auswerten

Red Snapper

Wer mehrere Ubuntu-Systeme betreibt, merkt schnell: Einzelne Befehle wie journalctl, top oder df -h helfen zwar im Moment, reichen aber für eine saubere Übersicht über viele Server nicht aus. Genau hier wird das Thema Logs und Metriken unter Ubuntu zentral sammeln und auswerten besonders wichtig. Zentrale Protokolle und zentrale Metriken helfen dabei, Fehler früher zu erkennen, Lastspitzen sichtbar zu machen und Probleme über mehrere Systeme hinweg besser zu verstehen. Canonical beschreibt in der Ubuntu-Server-Dokumentation, dass ein Logging-, Monitoring- und Alerting-Stack helfen soll, Probleme bei Last, Netzwerk und anderen Ressourcen zu erkennen, bevor sie zu einem Ausfall werden. :contentReference[oaicite:0]{index=0}

Für Anfänger wirkt das Thema zuerst technisch, weil mehrere Bausteine zusammenkommen. Auf der Log-Seite spielen unter Ubuntu oft systemd-journald, journalctl und zentrale Logsammler eine Rolle. Auf der Metrik-Seite sind Prometheus, Exporter und Grafana sehr verbreitet. Grafana Loki ist zusätzlich eine moderne Lösung für zentrale Logaggregation und unterscheidet sich von Prometheus dadurch, dass es Logs statt Metriken sammelt und Daten per Push entgegennimmt. Genau diese Trennung zwischen Logs und Metriken ist wichtig, damit Sie ein Ubuntu-System professionell beobachten können. :contentReference[oaicite:1]{index=1}

Was sind Logs und was sind Metriken?

Logs sind Protokolle über Ereignisse. Ein Dienst schreibt zum Beispiel, dass er gestartet wurde, ein Fehler aufgetreten ist oder eine Anmeldung fehlgeschlagen ist. Unter Ubuntu werden viele dieser Einträge im systemd-Journal gesammelt. Die Ubuntu-Manpage erklärt ausdrücklich, dass journalctl die von systemd-journald gespeicherten Protokolle anzeigen und filtern kann. Metriken sind dagegen Zahlenwerte über den Zustand eines Systems, zum Beispiel CPU-Auslastung, RAM-Verbrauch, freie Platte oder Netzwerkverkehr. Prometheus beschreibt sich selbst als Monitoring-Plattform, die Metriken von überwachten Zielen über HTTP-Scraping sammelt. :contentReference[oaicite:2]{index=2}

Einfacher Unterschied

Warum zentrale Sammlung unter Ubuntu sinnvoll ist

Solange nur ein einzelner Testserver läuft, können Sie Logs und Metriken direkt lokal prüfen. Sobald aber mehrere Ubuntu-Server, virtuelle Maschinen oder Container im Spiel sind, wird das unübersichtlich. Dann ist es sinnvoll, Protokolle und Metriken zentral zu sammeln. Canonical empfiehlt in seiner Observability-Dokumentation heute die Canonical Observability Stack oder alternativ den klassischen LMA-Ansatz. In der Ubuntu-Server-Dokumentation wird ausdrücklich erklärt, dass diese Werkzeuge für Infrastruktur-Observability gedacht sind. :contentReference[oaicite:3]{index=3}

Vorteile einer zentralen Lösung

Welche Ubuntu-Werkzeuge lokal schon wichtig sind

Bevor Logs und Metriken zentral gesammelt werden, sollten Sie die lokalen Grundlagen kennen. Für Logs ist unter Ubuntu journalctl sehr wichtig. Die Manpage erklärt, dass sich damit Protokolle anzeigen und anhand von Feldern oder Diensten filtern lassen. Für Metriken sind lokale Werkzeuge wie top, free oder df hilfreich, aber für zentrale Beobachtung meist nicht genug. Wer Logs und Metriken zentral sammeln möchte, sollte deshalb lokale Sicht und zentrale Plattform zusammendenken. :contentReference[oaicite:4]{index=4}

Typische lokale Log-Befehle

journalctl
journalctl -u ssh
journalctl -xe

Ein praxistauglicher Aufbau für zentrale Logs und Metriken

Ein gut verständlicher Aufbau für Ubuntu besteht aus drei Ebenen. Erstens liefern die Ubuntu-Hosts ihre Daten. Zweitens sammelt eine zentrale Plattform die Daten. Drittens zeigt eine Oberfläche die Ergebnisse an. Für Metriken ist ein typischer Weg Prometheus + Node Exporter + Grafana. Prometheus sammelt Metriken, der Node Exporter liefert Linux-Systemmetriken und Grafana zeigt diese Daten in Dashboards an. Die offizielle Prometheus-Dokumentation erklärt genau diesen Weg mit dem Node Exporter für Host-Metriken. Für Logs ist ein moderner Weg Loki + ein Log-Agent + Grafana. Die Loki-Dokumentation beschreibt Loki als horizontale Log-Aggregationslösung, die sich gut in eine Grafana-basierte Beobachtungsumgebung einfügt. :contentReference[oaicite:5]{index=5}

Prometheus für zentrale Metriken verstehen

Prometheus ist für viele Ubuntu-Administratoren die erste Wahl für Metriken. Die offizielle Dokumentation beschreibt Prometheus als Monitoring-Plattform, die Metriken von überwachten Zielen durch Scraping von HTTP-Endpunkten sammelt. Das bedeutet: Der Zielhost stellt einen Metrik-Endpunkt bereit, und Prometheus fragt diesen regelmäßig ab. Genau das ist für Ubuntu-Systeme sehr praktisch, weil sich Host-Metriken mit einem Exporter einfach bereitstellen lassen. :contentReference[oaicite:6]{index=6}

Was Prometheus gut kann

Node Exporter für Ubuntu-Metriken einsetzen

Wenn Sie CPU, RAM, Dateisysteme oder Netzwerkdaten von Ubuntu-Hosts sammeln möchten, ist der Node Exporter besonders wichtig. Die offizielle Prometheus-Dokumentation erklärt, dass der Node Exporter eine große Zahl von Systemmetriken ausliefert und dass diese Metriken typischerweise mit dem Präfix node_ erscheinen. Das macht ihn zu einem Standardbaustein für Linux- und Ubuntu-Monitoring. :contentReference[oaicite:7]{index=7}

Typische Node-Exporter-Metriken

Ein lokaler Test des Metrics-Endpunkts

curl http://localhost:9100/metrics | grep "node_"

Genau ein solcher Test wird auch in der offiziellen Node-Exporter-Anleitung gezeigt. :contentReference[oaicite:8]{index=8}

Prometheus unter Ubuntu mit mehreren Hosts konfigurieren

Prometheus nutzt eine Konfigurationsdatei mit scrape_configs. In der offiziellen Getting-Started-Dokumentation wird erklärt, dass dort Jobs und Targets definiert werden. Für ein zentrales Ubuntu-Monitoring tragen Sie dort nicht nur localhost, sondern mehrere Server ein. So können mehrere Ubuntu-Hosts von einem zentralen Prometheus-Server überwacht werden. :contentReference[oaicite:9]{index=9}

Einfaches Beispiel für mehrere Hosts

global:
  scrape_interval: 15s

scrape_configs:


    

  • 

    job_name: 'ubuntu-nodes'
    
static_configs:
    

      

    • 

      targets:
      

        

      • 

        '192.168.1.101:9100'
        

        • 

      • 

        '192.168.1.102:9100'
        

        • 

      • 

        '192.168.1.103:9100'

Damit fragt Prometheus drei Ubuntu-Server regelmäßig ab und sammelt deren Host-Metriken zentral. :contentReference[oaicite:10]{index=10}

Grafana für die zentrale Auswertung nutzen

Grafana ist die typische Oberfläche für Metriken und in vielen Umgebungen auch für Logs. Die offizielle Debian-/Ubuntu-Dokumentation von Grafana erklärt, dass Grafana auf Ubuntu installiert, als Dienst gestartet und anschließend zur Arbeit mit Datenquellen genutzt werden kann. In Kombination mit Prometheus wird daraus eine sehr praktische Beobachtungsoberfläche für Ubuntu-Server. :contentReference[oaicite:11]{index=11}

Typische Dashboards in Grafana

Logs zentral sammeln: warum Loki interessant ist

Für zentrale Logs ist Grafana Loki besonders interessant. Die Loki-Dokumentation beschreibt Loki als horizontale, hochverfügbare Log-Aggregationslösung. Sie erklärt außerdem, dass Loki im Unterschied zu Prometheus auf Logs statt auf Metriken fokussiert ist und Logs per Push entgegennimmt. Genau das macht Loki zu einer passenden Ergänzung für zentrale Ubuntu-Protokolle. :contentReference[oaicite:12]{index=12}

Warum Loki oft gut passt

Wie zentrale Logsammlung mit Loki grundsätzlich funktioniert

Ein typischer Aufbau für Logs besteht aus einem Log-Agent auf dem Ubuntu-Host, einem zentralen Loki-Server und Grafana zur Auswertung. Die aktuelle Loki-Dokumentation zeigt in ihren Quickstart- und Tutorial-Seiten, dass Grafana Alloy oder andere Agenten Logs lesen und an Loki weiterleiten können. Loki speichert diese Logs, und Grafana macht sie dann durchsuchbar. :contentReference[oaicite:13]{index=13}

Typischer Ablauf

journald unter Ubuntu als wichtige Log-Quelle

Unter Ubuntu ist das Journal eine sehr wichtige Log-Quelle. Die Ubuntu-Manpage erklärt, dass journalctl Protokolle ausgibt, die von systemd-journald gespeichert wurden, und dass auch die Filterung nach Feldern oder Units möglich ist. Für zentrale Logsammlung bedeutet das: Bevor Logs überhaupt nach Loki oder eine andere zentrale Stelle gehen, sollten Sie verstehen, welche wichtigen Informationen lokal bereits im Journal liegen. :contentReference[oaicite:14]{index=14}

Wichtige lokale Journal-Abfragen

journalctl -u ssh
journalctl -u nginx
journalctl --since "1 hour ago"

Diese Befehle helfen auch später bei der Fehlersuche, wenn zentrale Logsammlung einmal nicht wie erwartet funktioniert. :contentReference[oaicite:15]{index=15}

Logs und Metriken sauber trennen – aber gemeinsam auswerten

Ein häufiger Anfängerfehler ist, Logs und Metriken als dasselbe zu betrachten. In Wirklichkeit ergänzen sie sich. Metriken zeigen oft, dass ein Problem entsteht. Logs zeigen oft, warum etwas passiert ist. Ein CPU-Anstieg in Grafana kann zum Beispiel sichtbar machen, dass ein Dienst plötzlich Last erzeugt. Die zugehörigen Logs in Loki oder im Journal zeigen dann vielleicht Fehlversuche, Neustarts oder konkrete Ursachen. Genau diese gemeinsame Auswertung macht zentrale Beobachtung unter Ubuntu so stark. :contentReference[oaicite:16]{index=16}

Ein einfacher Ubuntu-Workflow für Anfänger

Für Anfänger ist es meist sinnvoll, zuerst nur die Metrik-Seite einzurichten. Das bedeutet: Prometheus auf einem zentralen Ubuntu-System, Node Exporter auf den Zielhosts und Grafana als Dashboard. Erst wenn dieses Grundmodell sauber läuft, sollte die Log-Seite mit Loki und einem Log-Agent ergänzt werden. Genau so bleibt das Thema beherrschbar und die Fehlersuche einfacher. Canonical beschreibt in seiner Observability-Dokumentation ebenfalls, dass verschiedene Werkzeuge zu einem Stack zusammenwirken und dass schrittweises Vorgehen für eine saubere Infrastrukturbeobachtung sinnvoll ist. :contentReference[oaicite:17]{index=17}

Empfohlene Reihenfolge

Wichtige Dashboards und Auswertungen

Wenn die technische Basis steht, kommt die eigentliche Auswertung. Für Ubuntu-Administratoren sind einige Anzeigen besonders nützlich: CPU pro Host, RAM-Nutzung, Dateisystem-Auslastung, Netzwerkverkehr und die Verfügbarkeit von Diensten. In Grafana können diese Informationen in einem Dashboard zusammengeführt werden. Auf der Log-Seite sollten Filter für wichtige Services wie SSH, Webserver oder Datenbankdienste vorhanden sein. So entsteht ein zentrales Bild über Zustand und Ereignisse Ihrer Ubuntu-Systeme. :contentReference[oaicite:18]{index=18}

Typische Fehler beim zentralen Sammeln vermeiden

Viele Probleme in Monitoring- und Logging-Setups entstehen nicht durch die Werkzeuge selbst, sondern durch kleine Konfigurationsfehler. Häufig wird ein Exporter nicht korrekt von Prometheus gescrapt, ein Port ist durch die Firewall blockiert oder ein Log-Agent liefert keine Daten an Loki. Auch falsche Labels, uneinheitliche Hostnamen oder fehlende Dienste sind klassische Fehlerquellen. Canonical und die jeweiligen Herstellerdokumentationen betonen durch ihre Schritt-für-Schritt-Anleitungen immer wieder, wie wichtig korrekte Konfiguration und klare Architektur sind. :contentReference[oaicite:19]{index=19}

Häufige Fehler

Warum zentrale Beobachtung für Ubuntu-Admins professionell ist

Zentrale Logs und zentrale Metriken sind kein Luxus, sondern ein wichtiger Teil professioneller Serververwaltung. Wer nur lokal prüft, sieht Probleme oft zu spät oder nur auf einem einzelnen Host. Wer dagegen Logs und Metriken zentral sammelt und auswertet, kann mehrere Systeme vergleichen, Entwicklungen über Zeit beobachten und Fehler schneller eingrenzen. Genau deshalb empfehlen offizielle Ubuntu-Dokumente Observability-Stacks für Infrastrukturüberwachung und verweisen auf unterstützte Monitoring-Werkzeuge. :contentReference[oaicite:20]{index=20}

Wichtige Befehle und Muster im Überblick

Wenn Sie Logs und Metriken unter Ubuntu zentral sammeln und auswerten möchten, sollten Sie diese Grundlagen sicher kennen. Die folgenden Befehle sind typische Startpunkte für die Praxis. :contentReference[oaicite:21]{index=21}

Journal lokal prüfen

journalctl
journalctl -u ssh
journalctl --since "1 hour ago"

Node-Exporter-Metriken lokal testen

curl http://localhost:9100/metrics | grep "node_"

Prometheus-Konfiguration mit mehreren Hosts

scrape_configs:
  - job_name: 'ubuntu-nodes'
    static_configs:
      - targets:
          - '192.168.1.101:9100'
          - '192.168.1.102:9100'

Grafana- und Monitoring-Dienste prüfen

sudo systemctl status grafana-server
sudo systemctl status prometheus
sudo systemctl status node_exporter

Wer diese Grundlagen sauber versteht und Schritt für Schritt praktisch umsetzt, kann aus einzelnen Ubuntu-Servern eine deutlich besser beobachtbare Infrastruktur machen. Genau das ist der eigentliche Mehrwert: Metriken zeigen, wie sich Systeme verhalten, Logs zeigen, was auf ihnen passiert, und die zentrale Auswertung macht beides an einer Stelle sichtbar und nutzbar. :contentReference[oaicite:22]{index=22}

::contentReference[oaicite:23]{index=23}

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Exit mobile version