Skip to main content
Log in Tempo Reale
L’API Playground è disabilitato per questo endpoint a causa della natura delle connessioni SSE, che non sono supportate universalmente dai browser.
string
obbligatorio
La chiave API del tuo account. Puoi trovarla nelle impostazioni del tuo account.
Usa questo endpoint ogni volta che hai bisogno di una vista in tempo reale di un’applicazione invece del polling: seguire l’avanzamento di un deploy, seguire i log man mano che vengono scritti, oppure alimentare il grafico CPU/RAM di una dashboard senza martellare Ottieni lo Stato dell’Applicazione o Ottieni Log Applicazione a intervalli regolari. Sostituisce entrambi per la durata della connessione. Internamente, l’apertura di una connessione qui stabilisce un singolo stream upstream sul cluster dell’applicazione e lo inoltra tramite SSE, con una riconnessione interna trasparente in caso quello stream upstream cada. Poiché ogni connessione aperta mantiene un socket per un massimo di 10 minuti, le aperture hanno un limite di frequenza separato rispetto ai tetti di connessioni simultanee descritti di seguito: 1 apertura ogni 5 secondi per (utente, applicazione), e 20 aperture ogni 10 secondi per utente su tutte le applicazioni, con un cooldown di 30 secondi al raggiungimento di tale limite.

Parametri

string
obbligatorio
L’ID dell’applicazione di cui vuoi monitorare i log. Questo ID può essere trovato nell’URL del pannello di gestione della tua applicazione.

Risposta

string
Indica se la chiamata è andata a buon fine. success in caso di successo, error in caso contrario.
In caso di fallimento, la risposta includerà un campo code insieme allo stato di errore, che ne dettaglia la causa. Se la richiesta ha esito positivo, la risposta sarà uno stream text/event-stream contenente il feed in tempo reale dell’applicazione. Ogni connessione dura fino a 10 minuti. Ogni account può mantenere 5 connessioni realtime simultanee (REALTIME_MAX_CONNECTIONS) e ogni applicazione 30 tra tutti gli utenti (REALTIME_MAX_CONNECTIONS_APP); il superamento di uno dei due limiti restituisce 429.

Struttura dei Server-Sent Events (SSE)

La risposta è uno stream continuo in formato text/event-stream. Ogni messaggio è composto da un campo event e da un campo data. Le forme variano a seconda dell’evento, quindi analizza i payload in modo difensivo.

Tipi di Evento

  • system: Segnali a livello di protocollo. La riga data è un singolo codice in maiuscolo: REALTIME_CONNECTING | <sseId> alla connessione, poi uno qualsiasi tra REALTIME_TIMEOUT, REALTIME_DISCONNECTED, REALTIME_RECONNECT o REALTIME_ERROR.
  • logs: Una singola riga di log il cui primo carattere è un byte di identificazione dello stream: \x01 (stdout) o \x02 (stderr). Leggi data.charCodeAt(0) (1 = stdout, 2 = stderr), poi data.slice(1) per il testo. Una riga senza quel byte di prefisso è stdout.
  • status: Metriche live del container come stringa JSON, circa un frame al secondo. Il primo frame di ogni (ri)connessione è completo: { cpu, cpuLimit, ram: [usedMB, limitMB], status, netIO: { i, o, new: { i, o } }, bIO: { i, o }, uptime } (uptime è l’orario di avvio in ms epoch; netIO.new è in byte al secondo). Ogni frame successivo è ridotto, portando solo { cpu, ram, netIO, bIO } — unisci ciascuno all’ultimo frame completo, mantenendo i precedenti cpuLimit, status e uptime. Mentre questo stream è aperto, preferiscilo al polling di GET /v2/apps/{app_id}/status, che può essere fino a circa un minuto obsoleto per un’app con uno stream realtime aperto.
  • error: Porta un codice di errore come CONTAINER_NOT_FOUND.
Nell’esempio seguente, \x01 / \x02 rappresentano i byte di prefisso grezzi stdout / stderr.

Errori comuni