Allgemeine Elasticsearch-Protokollanalyse für effektive Fehlerbehebung

Die Elasticsearch-Protokollanalyse ist in der Regel der schnellste Weg, um einen roten Cluster, fehlgeschlagene Indizierungsanfragen oder Beschwerden über langsame Suchen zu erklären. Wenn ein Cluster mehrere Knoten hat, zeigen die Protokolle, welcher Knoten den ersten Fehler gesehen hat, welche Komponente reagiert hat und ob das Problem Festplatte, Speicher, Erkennung, Sicherheit oder Shard-Wiederherstellung betrifft.

Diese Anleitung zeigt Ihnen, wie Sie Elasticsearch-Protokolle lesen, ohne sich in Rauschen zu verlieren. Sie erfahren, wo Protokolle normalerweise gespeichert sind, welche Felder wichtig sind, was häufige Fehlermeldungen bedeuten und wann Sie vom Hauptserverprotokoll zu langsamen Protokollen oder Allokations-APIs wechseln sollten.

Verständnis der Elasticsearch-Protokollstruktur

Elasticsearch verwendet Log4j 2 für die Protokollierung. Paketinstallationen schreiben Protokolldateien normalerweise unter /var/log/elasticsearch/. Containerisierte Bereitstellungen senden Protokolle oft an die Standardausgabe, wo Ihre Container-Laufzeit oder Ihr Protokollierungsagent sie sammelt. Abhängig von Ihrer Version und log4j2.properties können Sie Klartextprotokolle, JSON-Protokolle oder beides sehen.

Installationstyp	Typischer Protokollpfad
RPM/DEB Linux-Paket	/var/log/elasticsearch/
Docker	Container-Standardausgabe
ZIP oder Tarball	$ES_HOME/logs/

Zu den üblichen Dateien gehören das Hauptserverprotokoll, Deprecation-Protokolle, langsame Protokolle und manchmal Audit-Protokolle, wenn die Sicherheitsüberwachung aktiviert ist.

JSON-Protokolleinträge enthalten normalerweise Felder wie diese:

• @timestamp: Wann das Ereignis aufgetreten ist.
• level: Der Schweregrad, wie INFO, WARN oder ERROR.
• component: Die Elasticsearch-Klasse oder das Subsystem, das die Nachricht protokolliert hat.
• cluster.uuid: Die Cluster-Kennung.
• node.name: Der Knoten, der die Protokollzeile generiert hat.
• message: Der für Menschen lesbare Ereignistext.

{
  "@timestamp": "2024-01-15T10:30:00.123Z",
  "level": "WARN",
  "component": "o.e.c.r.a.DiskThresholdMonitor",
  "cluster.uuid": "abcde12345",
  "node.name": "es-node-01",
  "message": "high disk watermark [90%] exceeded on [es-node-01]"
}

Priorisierung von Nachrichten nach Protokollebene

Filtern Sie zuerst nach WARN und ERROR, erweitern Sie dann die Suche um denselben Zeitstempel. Die Zeilen vor dem ersten ERROR erklären die Ursache oft besser als der endgültige Stacktrace.

Ebene	Was es normalerweise bedeutet	Erste Aktion
ERROR	Eine Anfrage, ein Shard, ein Knoten oder ein Subsystem ist fehlgeschlagen.	Sofort untersuchen.
WARN	Elasticsearch hat einen riskanten Zustand erkannt.	Überprüfen, bevor es zu einem Ausfall wird.
INFO	Normale Lebenszyklusaktivität.	Für Kontext um Warnungen und Fehler herum verwenden.
DEBUG / TRACE	Tiefgehende Diagnosedetails.	Nur kurz aktivieren, wenn Sie es benötigen.

Vermeiden Sie es, Produktionsknoten auf DEBUG oder TRACE zu belassen. Ausführliche Protokollierung kann schnell Festplattenplatz verbrauchen und unnötigen Overhead verursachen.

Fehlerbehebung bei häufigen Protokollmustern

Elasticsearch-Protokolle sagen selten in einem einzigen klaren Satz "die Ursache ist X". Suchen Sie nach einem Muster: der ersten Warnung, dem Komponentennamen, dem betroffenen Index oder Shard und der wiederholten Nachricht, die folgt.

Bootstrap-Überprüfungsfehler

Elasticsearch führt Bootstrap-Überprüfungen in produktionsähnlichen Netzwerkkonfigurationen durch. Diese Überprüfungen erkennen unsichere Host-Einstellungen wie niedrige Dateideskriptor-Limits, niedrige Limits für virtuellen Speicher oder Speichersperrprobleme. Wenn eine erforderliche Überprüfung fehlschlägt, weigert sich der Knoten zu starten.

Suchen Sie nach bootstrap checks failed:

[2024-01-15T10:00:00,123][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] bootstrap checks failed
[2024-01-15T10:00:00,124][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

Beheben Sie die Host-Einstellung, starten Sie den Knoten neu und bestätigen Sie, dass das Startprotokoll den Punkt erreicht, an dem der Knoten dem Cluster beitritt.

Netzwerkbindungs- und Erkennungsfehler

Wenn der Knoten startet, aber nicht dem Cluster beitritt, suchen Sie nach BindException, master not discovered, discovery und cluster.initial_master_nodes. Eine BindException weist normalerweise auf einen Adress- oder Portkonflikt hin. Erkennungsnachrichten weisen oft auf fehlerhafte Seed-Hosts, blockierten Transport-Port 9300, nicht übereinstimmende Clusternamen oder Sicherheitseinstellungen hin, die verhindern, dass Knoten einander vertrauen.

Circuit-Breaker-Ausnahmen

Circuit-Breaker stoppen Anfragen, die zu viel Speicher verbrauchen würden. Die fehlgeschlagene Anfrage gibt einen Fehler zurück, aber der Knoten sollte am Leben bleiben.

Suchen Sie nach CircuitBreakingException oder Data too large:

[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02]
CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [500mb]

Häufige Ursachen sind große Aggregationen, Anfragen, die zu viele Felder zurückgeben, umfangreiche Bulk-Indizierung oder für Textfelder geladene Felddaten. Identifizieren Sie das Anforderungsmuster, reduzieren Sie dann die Anforderungsgröße, korrigieren Sie Zuordnungen oder erhöhen Sie die Kapazität.

Garbage-Collection-Warnungen

Das Haupt-Elasticsearch-Protokoll kann über lange JVM-Garbage-Collection-Pausen berichten. Suchen Sie nach gc, JvmGcMonitorService und overhead. Einige Warnungen während einer Lastspitze können normal sein. Wiederholte Warnungen in Verbindung mit steigender Suchlatenz bedeuten normalerweise, dass der Heap unter Druck steht.

Shard-Wiederherstellung und -Beschädigung

Wenn ein Shard nicht zugewiesen werden kann oder ein Knoten eine fehlerhafte lokale Shard-Kopie erkennt, protokolliert Elasticsearch den Index und die Shard-Nummer.

Suchen Sie nach shard failed, failed shard, failed to recover oder dem betroffenen Indexnamen:

[2024-01-15T12:05:10,999][ERROR][o.e.i.e.Engine] [es-node-03] [my_index][2] fatal error in engine loop
java.io.IOException: Corrupt index files, checksum mismatch

Wenn die Nachricht eine Beschädigung erwähnt, löschen Sie keine Dateien von Hand. Bewahren Sie Protokolle auf, prüfen Sie, ob ein gutes Replikat existiert, und verwenden Sie Elasticsearch-Wiederherstellungstools und -APIs, anstatt den Datenpfad direkt zu bearbeiten.

Festplatten-Watermarks

Elasticsearch ändert das Shard-Allokationsverhalten, wenn Knoten Festplatten-Watermarks überschreiten. Suchen Sie nach DiskThresholdMonitor, low disk watermark, high disk watermark oder flood-stage disk watermark. Standardwerte können je nach Version und Konfiguration variieren, bestätigen Sie daher Ihre Clustereinstellungen, bevor Sie handeln:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Wenn ein Index nach einem Flood-Stage-Ereignis schreibgeschützt wird, schaffen Sie zuerst Festplattenplatz frei. Entfernen Sie dann den Block erst, nachdem der Knoten sicher unter dem Watermark ist:

PUT /my-index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Verwendung langsamer Protokolle für Leistungsprobleme

Bei langsamen Such- oder Indizierungsvorgängen ist das Hauptserverprotokoll oft zu breit gefasst. Langsame Protokolle verfolgen Vorgänge, die konfigurierte Schwellenwerte überschreiten. Konfigurieren Sie sie pro Index mit der Indexeinstellungs-API.

PUT /my_index/_settings
{
  "index.search.slowlog.threshold.query.warn": "1s",
  "index.search.slowlog.threshold.query.info": "500ms",
  "index.indexing.slowlog.threshold.index.warn": "1s"
}

Langsame Protokolle zeigen den Index, Shard, die verstrichene Zeit und die Anforderungsquelle, wenn sie so konfiguriert sind, dass sie diese enthalten. Verwenden Sie sie, um wiederholte teure Abfragen, breite Datumsbereiche, suchintensive Platzhalter und Aggregationen für Felder zu erkennen, die nicht für eine effiziente Aggregation zugeordnet sind.

Ein praktischer Überprüfungs-Workflow

Beginnen Sie mit dem sichtbaren Symptom des Benutzers und arbeiten Sie sich rückwärts:

1. Überprüfen Sie den Cluster-Zustand und den betroffenen Index.
2. Suchen Sie WARN- und ERROR-Protokolle um den Vorfallszeitpunkt.
3. Vergleichen Sie Protokolle über Knoten hinweg mit node.name und cluster.uuid.
4. Folgen Sie der ersten wiederholten Warnung, nicht nur der endgültigen Ausnahme.
5. Verwenden Sie als nächstes eine gezielte API: Allokationserklärung für nicht zugewiesene Shards, langsame Protokolle für langsame Anfragen und Knotenstatistiken für Ressourcendruck.

Wenn Kibana beispielsweise einen roten Index anzeigt, finden Sie zuerst den nicht zugewiesenen Shard und durchsuchen Sie dann die Protokolle nach diesem Index und der Shard-Nummer. Wenn die Protokolle Festplatten-Watermarks erwähnen, beheben Sie den Festplattendruck, bevor Sie etwas umleiten. Wenn sie einen fehlenden Knoten erwähnen, stellen Sie diesen Knoten wieder her oder stellen Sie ihn aus einem Snapshot wieder her, bevor Sie riskante Allokationsbefehle in Betracht ziehen.

Fazit

Beginnen Sie jeden Elasticsearch-Vorfall damit, die erste relevante Warnung oder den ersten relevanten Fehler zu finden, nicht den lautesten endgültigen Stacktrace. Verwenden Sie die Hauptprotokolle für Knoten-, Erkennungs-, Festplatten-, Speicher- und Shard-Fehler. Verwenden Sie langsame Protokolle, wenn der Cluster gesund ist, aber bestimmte Such- oder Indizierungs-Workloads langsam sind.