Skip to main content
Echtzeit-Logs
Der API-Playground ist für diesen Endpoint deaktiviert, da SSE-Verbindungen ihrer Natur nach nicht von allen Browsern unterstützt werden.
string
erforderlich
Der API-Schlüssel für Ihr Konto. Sie finden ihn in Ihren Kontoeinstellungen.
Verwende diesen Endpoint immer dann, wenn du eine Live-Ansicht einer Anwendung statt Polling brauchst: um den Fortschritt eines Deploys zu beobachten, Logs beim Schreiben live mitzuverfolgen oder das CPU/RAM-Diagramm eines Dashboards zu speisen, ohne Anwendungsstatus abrufen oder Anwendungslogs abrufen im Sekundentakt abzufragen. Er ersetzt beide für die Dauer der Verbindung. Intern wählt eine hier geöffnete Verbindung einen einzelnen Upstream-Stream auf dem Cluster der Anwendung an und leitet ihn über SSE weiter, mit einem transparenten internen Reconnect, falls dieser Upstream abbricht. Da jede offene Verbindung bis zu 10 Minuten lang einen Socket belegt, sind Verbindungsaufbauten separat von den unten beschriebenen Limits für gleichzeitige Verbindungen rate-limitiert: 1 Verbindungsaufbau alle 5 Sekunden pro (Benutzer, Anwendung) sowie 20 Verbindungsaufbauten alle 10 Sekunden pro Benutzer über alle Anwendungen hinweg, gefolgt von einer 30-sekündigen Abkühlphase.

Parameter

string
erforderlich
Die ID der Anwendung, deren Logs du überwachen möchtest. Diese ID findest du in der URL des Verwaltungspanels deiner Anwendung.

Antwort

string
Gibt an, ob der Aufruf erfolgreich war. success bei Erfolg, error andernfalls.
Im Fehlerfall enthält die Antwort ein Feld code zusätzlich zum Fehlerstatus, das die Ursache erläutert. Ist die Anfrage erfolgreich, ist die Antwort ein text/event-stream-Stream, der den Echtzeit-Feed der Anwendung enthält. Jede Verbindung dauert bis zu 10 Minuten. Jedes Konto kann 5 gleichzeitige Echtzeit-Verbindungen halten (REALTIME_MAX_CONNECTIONS) und jede Anwendung 30 über alle Nutzer hinweg (REALTIME_MAX_CONNECTIONS_APP); wird eines der beiden Limits überschritten, wird 429 zurückgegeben.

Struktur der Server-Sent Events (SSE)

Die Antwort ist ein kontinuierlicher Stream im Format text/event-stream. Jede Nachricht besteht aus einem Feld event und einem Feld data. Die Formen variieren je nach Event, parse die Payloads daher defensiv.

Event-Typen

  • system: Signale auf Protokollebene. Die data-Zeile ist ein einzelner Code in Großbuchstaben: REALTIME_CONNECTING | <sseId> beim Verbindungsaufbau, danach einer von REALTIME_TIMEOUT, REALTIME_DISCONNECTED, REALTIME_RECONNECT oder REALTIME_ERROR.
  • logs: Eine einzelne Log-Zeile, deren erstes Zeichen ein Stream-ID-Byte ist: \x01 (stdout) oder \x02 (stderr). Lies data.charCodeAt(0) (1 = stdout, 2 = stderr), dann data.slice(1) für den Text. Eine Zeile ohne dieses Präfix-Byte ist stdout.
  • status: Live-Container-Metriken als JSON-String, etwa ein Frame pro Sekunde. Der erste Frame jeder (Wieder-)Verbindung ist vollständig: { cpu, cpuLimit, ram: [usedMB, limitMB], status, netIO: { i, o, new: { i, o } }, bIO: { i, o }, uptime } (uptime ist die Startzeit als Epoch-ms; netIO.new sind Bytes pro Sekunde). Jeder spätere Frame ist schlank und trägt nur { cpu, ram, netIO, bIO } — führe jeden mit dem letzten vollständigen Frame zusammen und behalte dabei die vorherigen Werte von cpuLimit, status und uptime. Solange dieser Stream offen ist, bevorzuge ihn gegenüber dem Polling von GET /v2/apps/{app_id}/status, das bei einer Anwendung mit offenem Echtzeit-Stream bis zu etwa einer Minute veraltet sein kann.
  • error: Trägt einen Fehlercode wie CONTAINER_NOT_FOUND.
Im folgenden Beispiel stehen \x01 / \x02 für die rohen stdout-/stderr-Präfix-Bytes.

Häufige Fehler