Zum Inhalt

Live-Tail/SSE zeigt nichts hinter eigenem Proxy

Der Live-Tail unter Logs — und jede andere Stelle, die per Server-Sent-Events (SSE) live aktualisiert, etwa die gestreamte Antwort des KI-Chats — bleibt leer oder aktualisiert nur alle paar Minuten in einem Schwall, statt laufend. Das Symptom tritt fast ausschließlich auf, wenn ein eigener Reverse-Proxy vor Vesana steht (siehe TLS / Reverse-Proxy) — direkt gegen den Vesana-Stack ohne zusätzlichen Proxy funktioniert SSE ohne weitere Konfiguration.

Erst prüfen: Kommen überhaupt Logs an?

Bevor du den Proxy verdächtigst:

  • Die ersten Zeilen brauchen bis zu 30 Sekunden. Agents schicken Logs gesammelt im 30-Sekunden-Takt; sobald jemand die Live-Ansicht eines Geräts geöffnet hat, schaltet der Agent auf den 5-Sekunden-Takt um.
  • Gibt es eine Log-Quelle? Ohne eingerichtete Log-Quelle am Gerät kommt nichts an. journald-Quellen senden je nach Einstellung erst ab einer Mindest-Stufe (neue Quellen ab warning).
  • Recht hosts.view: Live-Tail, Log-Suche und Log-Statistik verlangen es für das jeweilige Gerät.

Zeigt die normale Log-Suche neue Zeilen, der Live-Tail aber nicht, liegt es am Proxy.

Ursache: Response-Buffering

SSE hält eine HTTP-Verbindung offen und schickt einzelne Events, sobald sie anfallen. Ein Reverse-Proxy puffert Antworten standardmäßig, bis ein Puffer voll ist oder die Verbindung endet — bei einem Stream, der lange offen bleibt und nur gelegentlich ein paar Bytes schickt, heißt das: der Client sieht nichts, bis der Proxy den Puffer irgendwann doch leert (oder gar nicht).

Vesana schickt bei den Stream-Antworten den Header X-Accel-Buffering: no mit. nginx wertet ihn standardmäßig aus und schaltet das Puffern für diese Antwort von selbst ab — solange in deiner Konfiguration nichts ihn ignoriert (proxy_ignore_headers X-Accel-Buffering). Sicherer ist es, Buffering für die Stream-Pfade ausdrücklich abzuschalten:

location = /api/v1/logs/stream {
    proxy_pass https://<vesana-stack>;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 3600s;
}

<vesana-stack> ist die Adresse, unter der dein Proxy den Vesana-Stack erreicht. Dasselbe gilt für die Stream-Pfade des KI-Chats und der KI-Analyse (/api/v1/ai/chat/stream, /api/v1/ai/analyze/…/stream).

Bei Traefik entspricht das der Standardeinstellung (kein Response-Buffering für normale Proxy-Requests) — meist reicht dort ein ausreichend hoher Timeout. Bei HAProxy: option http-buffer-request NICHT setzen und timeout server großzügig wählen. Bei Caddy ist SSE ohne zusätzliche Direktiven i. d. R. unproblematisch.

Zwei nginx-Schichten

Steht dein eigenes nginx (oder Caddy/Traefik) vor dem Vesana-Stack, gibt es zwei Proxy-Schichten zwischen Browser und Backend: dein Proxy davor und das nginx im Vesana-Stack selbst dahinter. Beide müssen den Stream ungepuffert durchreichen.

  1. Dein eigener Reverse-Proxy — Buffering für die Stream-Pfade aus (siehe oben), Timeout ausreichend hoch.
  2. Das interne nginx im Stack — hat die Stream-Pfade bereits ungepuffert konfiguriert. Nur wenn du dort eigene Anpassungen eingespielt hast, prüfe, ob Buffering versehentlich wieder aktiviert wurde.

Diagnose: Liegt es wirklich am Proxy?

Am Server selbst, am eigenen Proxy vorbei direkt gegen den Vesana-Stack (Port nach deiner Installation, Standard 443; -k, weil das Stack-Zertifikat oft selbstsigniert ist):

curl -N -k -H "Authorization: Bearer <JWT>" \
  "https://127.0.0.1:443/api/v1/logs/stream?host_ids=<host-id>"

Kommen hier laufend data:-Zeilen an, über den öffentlichen Domain-Namen aber nicht, liegt die Ursache am Reverse-Proxy, nicht an Vesana selbst. -N (--no-buffer) ist hier wichtig, sonst puffert schon curl selbst.

Verwandtes Symptom: Update-Overlay hängt

Der Splash beim Update (siehe UI-Probleme nach Update) fragt den Stand über normale HTTP-Requests ab, nicht per SSE — von Buffering nicht betroffen. Hängt er trotzdem, ist das eine andere Ursache.

Checkliste

  • [ ] Log-Quelle eingerichtet, normale Log-Suche zeigt neue Zeilen?
  • [ ] Bis zu 30 Sekunden auf die ersten Zeilen gewartet?
  • [ ] Buffering auf jeder Proxy-Schicht zwischen Browser und Vesana für die Stream-Pfade aus?
  • [ ] proxy_read_timeout ausreichend hoch (Stream bleibt lange offen)?
  • [ ] Direkter curl -N-Test gegen den Stack zeigt laufende Events?

Anschluss