Linux-Tools für den Krisenfall

 (brendangregg.com)
2 Punkte von GN⁺ 2024-03-25 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn man Diagnose-Tools erst nach dem Auftreten einer Performance-Störung installiert, geht mehr Zeit für die Vorbereitung als für die Behebung verloren; daher sollten Krisen-Tools vorab in Linux-Server-Images enthalten sein
  • Die empfohlene Liste umfasst procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool und weitere; es handelt sich um die Mindestpakete, um CPU, Festplatte, Netzwerk und Kernel-Tracing sofort prüfen zu können
  • bcc und bpftrace haben viele überlappende Tools, doch bcc bietet umfangreiche CLI-Optionen, während bpftrace vor Ort leichter zu bearbeiten ist; zur Laufzeit geben beide denselben BPF-Bytecode aus
  • Eine Installation während einer Störung kann wegen Variablen wie langsamen SSH-Verbindungen, defekter apt-Konfiguration, blockierten Repositories, Firewalls, unveränderlichen Dateisystemen und Berechtigungsfehlern zu einem Verlust von Dutzenden Minuten führen
  • Die Kosten bestehen hauptsächlich aus Speicherplatz und Image-Verteilzeit; da die empfohlenen Pakete aber meist klein sind, könnten Enterprise-Linux-Distributionen sie standardmäßig aufnehmen, damit die Reaktion auf Performance-Störungen schneller beginnen kann

Mindest-Tools, die vor einer Störung vorhanden sein sollten

  • Wenn eine Performance-Störung auftritt, ist schon die Zeit für die Installation der zur Ursachenanalyse nötigen Tools ein Verlust; auf Linux-Servern ist es daher sicherer, Krisen-Tools standardmäßig zu installieren
  • Die Liste basiert auf der Tabelle „Linux Crisis Tools“ aus Systems Performance 2nd Edition
  • Die empfohlenen Tools auf Basis von Ubuntu-Paketen sind:
    • procps: ps, vmstat, uptime, top
      • Grundlegende Statistiken prüfen
    • util-linux: dmesg, lsblk, lscpu
      • Systemlogs und Geräteinformationen prüfen
    • sysstat: iostat, mpstat, pidstat, sar
      • Geräte- und Systemstatistiken prüfen
    • iproute2: ip, ss, nstat, tc
      • Bevorzugte Netzwerk-Tools
    • numactl: numastat
      • NUMA-Statistiken prüfen
    • tcpdump: tcpdump
      • Netzwerk-Sniffing
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • Profiler- und PMU-Statistiken prüfen
    • bpfcc-tools oder bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile usw.
      • Vorgefertigte eBPF-Tools
    • bpftrace: bpftrace, Basisversionen von opensnoop, execsnoop, runqlat, biosnoop usw.
      • eBPF-Scripting
    • trace-cmd: trace-cmd
      • Ftrace-CLI
    • nicstat: nicstat
      • Statistiken zu Netzwerkgeräten
    • ethtool: ethtool
      • Informationen zu Netzwerkgeräten
    • tiptop: tiptop
      • PMU/PMC top
    • cpuid: cpuid
      • CPU-Details
    • msr-tools: rdmsr, wrmsr
      • Detaillierte CPU-Untersuchung

bcc und bpftrace gemeinsam einordnen

  • bcc und bpftrace haben viele überlappende Tools, unterscheiden sich aber darin, wofür sie besonders praktisch sind
  • bcc-Tools bieten mehr Funktionen wie CLI-Optionen und lassen sich gut wie fertige Tools verwenden
  • bpftrace-Tools können vor Ort sofort bearbeitet werden, wodurch situationsspezifische Prüfungen einfacher sind
  • Das bedeutet nicht, dass eines von beiden schneller ist
    • Beide Tools geben denselben BPF-Bytecode aus
    • Zur Laufzeit sind sie gleich schnell
  • bcc entwickelt sich dahin, Python-basierte Tools nach libbpf C zu übertragen
    • Es verwendet CO-RE und BTF
    • Die Pakete wurden jedoch noch nicht überarbeitet
    • Künftig sollte bpfcc-tools durch ein kleineres Paket libbpf-tools ersetzt werden, das nur die Tool-Binaries enthält

Zusätzliche Tools je nach Servertyp

  • Die obige Liste ist lediglich eine Mindestliste
  • Bei Servern mit Beschleunigern sollten auch Tools zur Analyse der jeweiligen Hardware enthalten sein
    • Intel-GPU-Server: intel-gpu-tools
    • NVIDIA-Server: nvidia-smi
  • Debugging-Tools wie gdb können ebenfalls vorab installiert werden, wenn sie im Krisenfall sofort nutzbar sein sollen
  • Die wichtigsten Analyse-Tools ändern sich nicht häufig, daher muss diese Liste möglicherweise nur alle paar Jahre aktualisiert werden

Die tatsächlichen Kosten einer Standardinstallation

  • Der offensichtlichste Nachteil beim Hinzufügen von Paketen ist die Festplattennutzung
  • Bei Cloud-Instanzen können schon wenige zusätzliche MB im Basis-Server-Image die Bereitstellungszeit einer Instanz um einige Sekunden oder Bruchteile einer Sekunde erhöhen
  • Die empfohlenen Pakete sind größtenteils klein, und auch bcc soll kleiner werden; daher sollten Speicher- und Zeitkosten nicht groß sein
  • Bei debuginfo gab es tatsächlich Größenbedenken, weil der Gesamtumfang bei etwa 1 GB liegt und dadurch eine standardmäßige Aufnahme verhindert wurde

Wie Installationen während einer Störung scheitern können

  • Wer nach dem Auftreten einer Störung Tools installieren will, kann am Ende mehr Zeit mit der Behebung von Installationsproblemen als mit der Diagnose verbringen
  • Ein beispielhafter Ablauf sieht so aus:
    • 4:00pm: Die Unternehmenswebsite ist ausgefallen oder so langsam, dass sie nicht nutzbar ist
    • 4:01pm: Das Monitoring-Dashboard zeigt eine Backend-Servergruppe als fehlerhaft an, und hohe Festplatten-I/O wird vermutet
    • 4:02pm: Man versucht, per SSH auf den Server zuzugreifen, aber der Login ist sehr langsam
    • 4:03pm: Man versucht iostat -xz 1 auszuführen, aber iostat fehlt, und es erscheint ein Hinweis zur Installation von sysstat
    • 4:07pm: Die Paketinstallation schlägt fehl, weil das Repository nicht aufgelöst werden kann, und ein Problem mit der /etc/apt-Konfiguration wird sichtbar
    • 4:10pm: Mit der korrigierten Konfiguration muss apt-get update ausgeführt werden, aber es ist sehr langsam
    • 4:13pm: Es kommt zu einem Verbindungs-Timeout, und man vermutet ein Repository-Verbindungs- oder Performance-Problem
    • 4:17pm: Das Netzwerk-Sicherheitsteam bestätigt, dass es unerwarteten Traffic sowie ausgehende HTTP/HTTPS/FTP-apt-Anfragen blockiert hat
    • 4:20pm: Nach dem Deaktivieren der Firewall funktioniert apt-get update, aber bei der Installation tritt ein Berechtigungsfehler auf
    • 4:24pm: Das Plattform-Sicherheitsteam erklärt, dass es sich um ein unveränderliches System handelt, bei dem Schreibzugriffe auf bestimmte Dateisysteme, etwa Bereiche mit ausführbaren Binaries, blockiert sind
    • 4:27pm: Das SRE-Team meldet eine größere Störung, und die Geschäftsführung verlangt Status-Updates und eine ETA für die Wiederherstellung, doch die eigentliche Diagnose ist kaum vorangekommen
    • 4:30pm: Mit cat /proc/diskstats wird ein grober Ersatz für iostat versucht, doch dafür muss die Linux-Dokumentation gelesen werden, und bestätigt wird nur die bereits bekannte Tatsache, dass die Festplatte ausgelastet ist
    • 4:55pm: Ein neues Server-Image mit beschreibbarem Dateisystem ist gestartet und sysstat kann installiert werden, aber durch den Server-Neustart ist die Website lediglich wieder erreichbar; die Ursache wurde nicht behoben
    • 12:50am: Als Fortsetzung des Beispiels wird die Website wegen der deaktivierten Firewall- und Dateisystem-Sicherheitsmaßnahmen gehackt
  • Der Vorfall um 12:50am ist keine reale Erfahrung, die übrigen Punkte basieren jedoch auf tatsächlichen Erfahrungen
  • Bei einem früheren Arbeitgeber kam es vor, dass das „traffic team“ etwa nach 15 Minuten ein Failover der Cloud-Region startete; wenn iostat schließlich installiert war, konnte das Zielsystem bereits im Leerlauf sein

Warum sie ins Basis-Image gehören

  • Das obige Szenario zeigt, wie anfällig es ist, Tools während einer Produktionsstörung erst nachträglich zu installieren
  • Einige Unternehmen nutzen bereits angepasste Server-Images, die vom OS-Team mit den notwendigen Tools erstellt werden
  • Viele Sites betreiben aber weiterhin unveränderte Standard-Linux-Versionen und erkennen die Notwendigkeit erst nach einer Störung
  • Wenn Enterprise-Linux-Distributionen solche Krisen-Tools standardmäßig aufnehmen, können große wie kleine Unternehmen bei Performance-Störungen sofort mit der Diagnose beginnen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-25
Hacker-News-Kommentare

  • Diese Liste ist nützlich. In Situationen, in denen der Server selbst durcheinandergeraten ist, etwa wenn die Auflösung der apt-Repositories fehlschlägt, passt die Cloud oft gut.
    Statt sich daran festzubeißen, ihn zu reparieren, beendet man die Maschine oder nimmt sie aus dem Pool und startet eine neue; dann kommen neue Maschine und App sauber hoch, und der Ausfall ist beendet. Die problematische Maschine kann man außerhalb des Hot Path separat untersuchen.

    • Nachdem das Problem „gelöst“ ist, hat niemand Zeit oder erlaubt es, die Maschine zu untersuchen; mit der Zeit führt der Ansatz von Grund auf neu bauen dazu, dass echte Problemlösefähigkeit und angesammeltes Wissen verloren gehen.
      Man wird zur Software-Version der Leute in der physischen Welt, die nur Teile austauschen.
    • „16:10 Uhr: Dasselbe Performance-Problem tritt auch auf der neuen Maschine weiterhin auf“
    • Das ist nicht unbedingt ein Vorteil nur der Cloud, sondern eher ein Vorteil des Betriebs virtualisierter, austauschbarer Server (Cattle).
    • Wenn man die Maschine beendet, können auch Beweise verschwinden. Vielleicht liegen alle Logs extern vor, aber meistens fehlt irgendetwas.

  • Nicht alle Server sind containerisiert, aber viele sind Container, und das bringt eigene Schwierigkeiten mit sich.
    Debugging-Tools in Docker-Images werden von automatischen Security-Scannern oft als „unnötige Tools, die einem Angreifer helfen, das Systemverhalten zu beobachten oder zu verändern“ erkannt. Bei gdb gibt es berechtigte Bedenken, bei vielen anderen aber nicht.
    Deshalb liegen manche Tools auf einem separaten Volume, möglichst als statische Binärdateien, oder sie werden mit dem Mount-Pfad als Installationspräfix kompiliert und installiert. Wenn Debugging nötig ist, bittet man das Ops-Team, sie vorübergehend read-only einzuhängen.
    Wenn ein Debug-Tool außerdem die Aktivierung bestimmter Kernel-Funktionen erfordert, kommen häufig Fragen und Bedenken auf, welche Auswirkungen das auf andere Container auf demselben Host hat.

    • Wenn ein Angreifer Dateien aus dem Dateisystem ausführen kann und zum Ausführen nur fehlt, dass diese Datei existiert, könnte er die Datei doch einfach selbst hineinschreiben.
      Mir fällt kein sinnvolles Szenario für diese Policy ein, außer „die Organisation verwendet Security-Scanner falsch“.
    • Besser ist es, ein zweites Image mit Debug-Tools und root-Benutzer zu bauen und es in den PID-Namespace und Netzwerk-Namespace des Produktionscontainers einzuhängen und auszuführen.
      Für Debugger braucht man viele Flags wie SYS_PTRACE-Berechtigung, Benutzer 0 und --privileged, daher ist es meist besser, einen zweiten Container zu starten.
      Mit diesem Ansatz muss der Produktionscontainer nicht neu gestartet werden, wodurch auch die Wahrscheinlichkeit sinkt, Reproduktionsbelege zu verlieren.
      Allerdings ist es in einer Störungssituation nicht leicht, sich an dieses Vorgehen zu erinnern; man sollte es also vorher ausprobieren und die Schritte in ein Runbook schreiben.

  • In diesem Zusammenhang: Seit FreeBSD 5.2, also seit 2004, gibt es auf allen FreeBSD-Systemen /rescue/*.
    Eine statisch gelinkte Binärdatei, die etwa 150 zentrale Tools bündelt, ist per Hardlink unter den üblichen Namen erreichbar und etwa 17 MB groß.
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • In 15 Jahren musste ich das nie benutzen. In den letzten 4–5 Jahren habe ich aus Gründen der psychischen Gesundheit alles Mögliche auf *BSD portiert.

  • Als ich bei Netflix war, sorgten Brendan und sein Team dafür, dass Debugging-Tools wie bpftrace, bcc und ein funktionierendes perf überall installiert waren.
    Diese Tools haben uns mehrfach das Leben gerettet.

  • Ich war überrascht, dass strace auf der Liste fehlt. Normalerweise ist es eines der ersten Tools, zu denen man greift.
    Besonders wenn ein Programm nutzlose oder falsche Fehlermeldungen zurückgibt, ist strace wirklich hilfreich.

  • In Vorstellungsgesprächen für SRE-ähnliche Rollen geht es immer um solche Tools.
    Entscheidend ist nicht, wie viele konkrete Befehle ein Kandidat auswendig kennt; es ist zwar beeindruckend, wenn er einem ein neues Tool zeigt, aber wir achten darauf, ob er ein Gefühl dafür hat, was möglich ist, welche Tools es gibt und wie man sie benutzt.
    Wichtig ist das Verständnis, dass man Netzwerk-Traffic, Systemaufrufe und Ausführungsprofile erfassen und analysieren sowie den Zustand von Betriebssystem und Hardware untersuchen kann.

  • Wenn man in solchen Krisensituationen keine Tools installieren kann, kann man mit Docker mehrere Utilities ausführen.
    Zum Beispiel kann man einen Container in einer Zeile bauen, ihn ans Host-Netzwerk hängen und netstat-ähnliche Tools ausführen, oder /proc mounten und mit --privileged, --net host, --pid host System-Tools wie iostat, sar, vmstat, mpstat und pidstat laufen lassen.
    Natürlich ist yum install besser, aber wenn Docker verfügbar ist und man die nötigen Mappings handhaben kann, ist es eine Alternative. In rootless- oder Podman-Konfigurationen funktioniert das vermutlich eher nicht.

    • Gibt es Situationen, in denen apt Pakete nicht herunterladen und installieren kann, Docker aber einen neuen Container ziehen kann?
      Vielleicht wenn die apt-Bibliotheken kaputt sind oder so?
    • Bei Netzwerksegmentierung ist das eine Ausnahme. Viel Glück beim Pullen eines „Ubuntu“-Images.
    • In diesem Zusammenhang wäre es schön, wenn busybox mehr solcher Tools enthielte.
      Eine etwa 1 MB große Datei, die man auf den Server hochladen und sofort ausführen kann, wäre sehr hilfreich.

  • Bekommen alle root-Zugriff? Ich muss für alles, was ich tun will, ein Systemadministrator-Ticket eröffnen.

    • Ich bin derzeit Consultant und wechsle alle paar Monate in ein neues Unternehmen. Es gibt immer Leute, mit denen man gut auskommen sollte.
      Man sollte sich die Namen der Security-Leute und der Menschen in seltsamen Jacken merken, die einem den Gebäudezugang ermöglichen, und Starbucks-Karten dabeihaben.
      Wenn man auch zum Reinigungspersonal höflich ist und sich ihre Namen merkt, bleibt der eigene Platz sauber. Es lohnt sich, gelegentlich länger zu bleiben und diese Leute kennenzulernen.
      Auch im Accounting-Team sollte man Freunde finden. Wenn man mit ihnen Kaffee trinkt, Mittag isst, auch über anderes als Arbeit spricht und Interesse zeigt, sagen einem die richtigen Leute Bescheid, wenn Entlassungen anstehen oder Firmenbudget frei wird.
      Zu IT, also den Leuten, die Laptops ausgeben und E-Mail verwalten, sollte man ebenfalls gut sein. Dann sieht man, wie schnell sie unsinnige Security-Tools vom eigenen Rechner entfernen oder wie weit vorn man in der Upgrade-Warteschlange landet.
      Am wichtigsten sind die Systemadministratoren. Nicht nur wegen root, sondern weil gute Systemadministratoren programmieren können, das aber nie laut sagen. Gute Admins sagen einem, in welcher dunklen Ecke die Leichen liegen und ob es nur ein Wandschrank oder ein ganzer Friedhof ist. Wenn man lernt, für ihre Plattform zu bauen, bekommt man viel mehr Spielraum. Wenn sie um etwas bitten, sollte man es tun.
    • Früher war ich für IT Operations zuständig; hier meine ich damit Systeme, SRE und Security.
      Dieser Beitrag richtet sich an Leute, die Apps auf von IT bereitgestellter Infrastruktur betreiben. Wenn man so interagieren muss wie im Beispiel, ist das kein technisches Problem, sondern ein organisatorisches Versagen.
      Wir hatten sehr klare und verlässliche Kommunikationswege, und die Leute arbeiteten nicht per Chat, sondern per Telefon oder heutzutage etwa in Teams gemeinsam mit Entwicklung, Betrieb, Security und Compliance.
      In der Praxis gab es in jedem Team mindestens eine Kontaktperson, und typischerweise betrieben Entwickler ihre Apps auf Ressourcen, die das Ops-Team bereitstellte. Compliance genehmigte die Konfiguration, und Service-Zuverlässigkeit war Aufgabe der Entwicklung. Wenn man DevOps in diesem Sinn betreibt, verschwinden viele Probleme.

  • nmap, netstat und nc sehe ich nicht. Auch diese Tools haben mich mehrmals gerettet.

  • Wenn ich nur eines ergänzen würde, dann nmap.
    Probleme mit Netzwerkverbindungen treten in manchen Apps nicht immer klar zutage.

    • screen, tmux, byobu, pv, rsync und natürlich vim braucht man auch.