OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
≋

Validator-Log-Analyse

Fehlermuster in Knoten-Logs finden
EingabeBis 2 MB / 20 000 Zeilen — größere Eingaben werden gekürzt.
Ergebnis1 Befunde
GutKein bekanntes Validator-Fehlermuster erkannt.Unbekannt1× · L1–1Hoch

IPs, Hostnamen, Pfade und Token werden in Ausschnitten maskiert.

Einführung

Die Validator-Log-Analyse durchsucht eingefügte Knoten- oder Validator-Logs nach bekannten Fehlermustern: Speichermangel, volle Platten, verpasste Slots und Attestierungen, doppelte Validator-Schlüssel, Slashing-Risiko, Uhrdrift, niedrige Peer-Anzahl, Zeitüberschreitungen, Verbindungsfehler, Datenbank-Korruption, inkompatible Snapshots und wiederholte Neustarts.

Jede Erkennung zeigt Schwere, Kategorie, Anzahl, erste und letzte Fundzeile, einen maskierten Ausschnitt, die wahrscheinliche Ursache, empfohlene Prüfungen und ein Konfidenzniveau. Die Analyse läuft vollständig im Browser: Logs werden weder hochgeladen noch gespeichert.

Ziel

  • Die Fehlermuster erkennen, die Validator-Knoten am häufigsten lahmlegen oder bestrafen.
  • Vorkommen je Muster mit Anzahl, erster und letzter Zeile und maskiertem Ausschnitt gruppieren.
  • Gemeinsame Linux-Regeln von Chain-spezifischen Konsensregeln trennen.
  • IPv4/IPv6-Adressen, Hostnamen, Pfade, Token und mögliche Geheimnisse maskieren und Seed-/Private-Key-Material nie vollständig wiedergeben.

Eingaben

  • Ein Einfügen von journald-, syslog-, Knoten- oder Validator-Ausgabe oder eine .log/.txt-Datei.
  • Eingaben sind auf 2 MB und 20 000 Zeilen begrenzt; größere Eingaben werden mit Hinweis gekürzt.
  • Nichts wird hochgeladen; die Daten lassen sich mit einem Klick löschen.

So funktioniert es

Jede Zeile wird gegen gemeinsame Linux-Muster geprüft (OOM, volle Platte, E/A-Fehler, Uhrdrift, Auth-Fehler, abgelehnte Verbindungen, Zeitüberschreitungen, Portkonflikte, Datenbank-Korruption, Neustart-Schleifen) und gegen Validator-/Konsensmuster (verpasste Slots, verpasste Attestierungen, Abstimmungsfehler, doppelte Validator-Schlüssel, Slashing-Indikatoren, Snapshot- und Versionsabweichungen).

Vorkommen werden je Muster mit erster und letzter Zeilennummer gezählt; ein kurzer Ausschnitt der ersten Fundstelle bleibt und wird maskiert.

Zeilen, die wie Seed-Phrasen oder private Schlüssel aussehen, werden nie wiederholt: Sie erzeugen einen geschwärzten Befund hoher Schwere.

Wiederholte Start-Marker erzeugen einen Neustart-Schleifen-Befund; wiederkehrende Fehlerzeilen ohne bekanntes Muster einen Unbekannt-Fehler-Befund.

Erkennungen werden nach Schwere sortiert und mit Ursache, empfohlenen Prüfungen und Konfidenz dargestellt.

Testbares Beispiel

Ausprobieren — die Analyse läuft lokal in Ihrem Browser.

Beispiel

Aug 22 14:06:11 node1 kernel: Out of memory: Killed process 8492 (geth)
Aug 22 14:07:02 node1 geth[8492]: ERROR[08-22|14:07:02] Failed to write block   err="no space left on device"
Aug 22 14:08:40 node1 geth[8492]: WARN[08-22|14:08:40] Missed slot            slot=512344

Erwartete Ausgabe

HOCH  OOM-Killer       · 1 Vorkommen · Zeile 1
HOCH  Platte voll      · 1 Vorkommen · Zeile 2
WARN  Slot verpasst    · 1 Vorkommen · Zeile 3
Wahrscheinliche Ursache: Speicherdruck + volle Platte → Knoten blieb stehen und verpasste einen Slot.

Ausgabe verstehen

  • Hohe Befunde (OOM, volle Platte, Datenbank-Korruption, Slashing-Risiko, doppelter Validator) brauchen Maßnahmen, bevor der Knoten wieder vertrauenswürdig ist.
  • Ein verpasster Slot oder eine verpasste Attestierung ist eine Warnung: Einmal ist Rauschen, ein Muster ist ein Problem.
  • Der maskierte Ausschnitt erhält Kontext für die Suche, schützt aber IPs, Pfade und Token.
  • Ein sauberes Ergebnis bedeutet, dass kein bekanntes Muster passte — es ist kein Beweis, dass der Knoten gesund ist.

Risiken

  • Ein per OOM getöteter Knoten mitten im Sync kann seine Datenbank beschädigen und einen Re-Sync erzwingen.
  • Doppelte Validator-Schlüssel und Slashing-Indikatoren sind die gefährlichsten Befunde: sofort handeln und den betroffenen Prozess stoppen.
  • Logs können Geheimnisse enthalten. Das Werkzeug maskiert sie, aber fügen Sie Logs mit echten Schlüsseln nirgendwo ein.

Grenzen

  • Musterabgleich ist heuristisch; Fehlalarme und Lücken sind möglich.
  • Es analysiert nur das eingefügte Fenster — Ereignisse davor oder danach sieht es nicht.
  • Es ist ein Triage-Helfer, kein Monitoring-System.

Offizielle Referenzen

FAQ

Wohin gehen meine Logdaten?

Nirgendwohin. Die Analyse läuft lokal in Ihrem Browser. Es gibt keinen Upload-Endpunkt, die Daten werden nicht gespeichert und die URL enthält nie Log-Inhalte. Die Löschtaste leert das Textfeld.

Was tun bei einem Slashing-Indikator?

Den Validator-Prozess sofort stoppen, nicht mit denselben Schlüsseln neu starten, bis die Ursache klar ist, und die Slashing-Dokumentation der Chain prüfen. Dieses Werkzeug erkennt nur Muster; die Entscheidung liegt bei Ihnen.

Warum werden IPs und Pfade durch <ip>/<path> ersetzt?

Logs sind sensibel. Maskierung erlaubt Suchen und Teilen von Ausschnitten, ohne Infrastrukturdaten oder mögliche Zugangsdaten aus Logzeilen preiszugeben.