# ELK Stack Deep Dive: Zentrales Logging im großen Stil

TL;DR / Management Summary Wenn man mehr als 10 Server verwaltet, ist das Einloggen per SSH für grep nicht mehr praktikabel. Der ELK-Stack (Elasticsearch, Logstash, Kibana) ist die Standard-Lösung für zentrales Logging. Er sammelt Daten aus verschiedensten Quellen (Syslog, App-Logs, Metrics), transformiert sie und ermöglicht eine blitzschnelle Suche über Millionen von Einträgen hinweg. Empfehlung: Heute oft ergänzt durch Beats (Filebeat), um Ressourcen auf den Clients zu sparen.

# 1. Einführung & Architektur

Die Log-Pipeline.

• Elasticsearch: Die Herz der Suche. Eine NoSQL-Datenbank, die JSON-Dokumente indiziert.
• Logstash: Die Fabrik. Empfängt Daten, filtert sie (Parsing) und schickt sie weiter.
• Kibana: Das Fenster. Das Web-Frontend für die Visualisierung.
• Beats: Die Agenten. Leichtgewichtige Shipper auf den Quell-Servern.

graph LR
    A[Client: Filebeat] -->|Lumberjack Protocol| B[Logstash / Pipeline]
    B -->|Filter & Parse| C[Elasticsearch / Index]
    C -->|Search API| D[Kibana / UI]
    E[App: Syslog] -->|TCP/UDP 514| B

# 2. Installation: Der schnelle Weg (Docker)

ELK ist komplex – Docker vereinfacht es.

In der Enterprise-Praxis wird ELK oft als Cluster betrieben. Für ein Einzelsetup ist Docker-Compose der sauberste Weg.

version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.10.0
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
    ulimits:
      memlock:
        soft: -1
        hard: -1
  kibana:
    image: docker.elastic.co/kibana/kibana:8.10.0
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

# 3. Logstash: Die Macht der Filter (Grok)

Aus Text mach Struktur.

Der wichtigste Teil von Logstash sind die Filter. Mit Grok (Regex-basiert) zerlegen wir Logzeilen in Felder.

# Beispiel Logstash Config

input {
  beats { port => 5044 }
}

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{IPORHOST:host} %{WORD:program}\[%{POSINT:pid}\]: %{GREEDYDATA:msg}" }
    }
  }
}

output {
  elasticsearch { hosts => ["localhost:9200"] }
}

# 4. Day-2 Operations: Retention & Index-Management

Die Disk-Flut bändigen.

Logs sammeln sich schnell an. Ohne Management läuft die Disk in Tagen voll.

# Index Lifecycle Management (ILM)

Nutzen Sie in Kibana die ILM Policies.

• Hot Phase: Neue Logs werden geschrieben (SSD).
• Warm Phase: Logs werden nur noch gelesen (HDD).
• Delete Phase: Logs werden nach 30 Tagen automatisch gelöscht.

# 5. Troubleshooting & “War Stories”

Wenn der Stack hinkt.

# Story 1: “Der Elasticsearch-OOM”

Symptom: Elasticsearch stürzt ab, Kibana zeigt “Red Cluster Health”. Ursache: Java Heap Space ist voll. Elasticsearch ist extrem hungrig nach RAM. Lösung: JVM Heap-Größe festlegen. Faustregel: 50% des RAMs für ES, aber maximal 31GB (wegen Compressed OOPs). Datei: jvm.options -> -Xms4g -Xmx4g.

# Story 2: “Das Grok-Parsing frisst die CPU”

Symptom: Logstash kommt mit dem Verarbeiten nicht hinterher, Logs haben massiven Zeitversatz. Ursache: Zu komplexe oder ineffiziente Grok-Muster (Regex Backtracking). Lösung: Nutzen Sie einfachere Filter oder verschieben Sie das Parsing in die Applikation (JSON Logging).

# 6. Fazit & Empfehlung

• Alternative: Für kleinere Setups schauen Sie sich Grafana Loki an. Es ist deutlich ressourcensparender.
• Hardware: Geben Sie Elasticsearch schnelle SSDs. I/O ist meist der Flaschenhals.
• Sicherheit: Lassen Sie ELK niemals offen im Netz stehen. Aktivieren Sie X-Pack Security (Auth/TLS).

# Anhang: Cheatsheet