Skip to main content
Logs en temps réel
Le Playground de l’API est désactivé pour cet endpoint en raison de la nature des connexions SSE, qui ne sont pas universellement prises en charge par les navigateurs.
string
requis
La clé d’API de votre compte. Vous pouvez la trouver dans les paramètres de votre compte.
Utilisez cet endpoint chaque fois que vous avez besoin d’une vue en direct d’une application plutôt que d’un polling : suivre la progression d’un déploiement, tailer les logs au fur et à mesure de leur écriture, ou alimenter le graphique CPU/RAM d’un tableau de bord sans solliciter en boucle Obtenir le statut d’une application ou Obtenir les logs de l’application. Il remplace les deux pendant toute la durée de la connexion. En interne, l’ouverture d’une connexion ici établit un flux unique en amont sur le cluster de l’application et le relaie via SSE, avec une reconnexion interne transparente si ce flux amont est interrompu. Comme chaque connexion ouverte occupe un socket jusqu’à 10 minutes, les ouvertures sont limitées séparément des plafonds de connexions simultanées décrits ci-dessous : 1 ouverture toutes les 5 secondes par (utilisateur, application), et 20 ouvertures toutes les 10 secondes par utilisateur toutes applications confondues, avec un temps de repos de 30 secondes une fois ce plafond atteint.

Paramètres

string
requis
L’ID de l’application dont vous souhaitez surveiller les logs. Cet ID se trouve dans l’URL du panneau de gestion de votre application.

Réponse

string
Indique si l’appel a réussi. success en cas de succès, error sinon.
En cas d’échec, la réponse inclura un champ code accompagné du statut d’erreur, détaillant la cause. Si la requête réussit, la réponse sera un flux text/event-stream contenant le flux temps réel de l’application. Chaque connexion dure jusqu’à 10 minutes. Chaque compte peut maintenir 5 connexions temps réel simultanées (REALTIME_MAX_CONNECTIONS) et chaque application 30 tous utilisateurs confondus (REALTIME_MAX_CONNECTIONS_APP) ; dépasser l’une ou l’autre renvoie un 429.

Structure des Server-Sent Events (SSE)

La réponse est un flux continu au format text/event-stream. Chaque message est composé d’un champ event et d’un champ data. Les structures varient selon l’événement, analysez donc les charges utiles de manière défensive.

Types d’événements

  • system : signaux au niveau du protocole. La ligne data est un unique code en majuscules : REALTIME_CONNECTING | <sseId> à la connexion, puis l’un de REALTIME_TIMEOUT, REALTIME_DISCONNECTED, REALTIME_RECONNECT ou REALTIME_ERROR.
  • logs : une seule ligne de log dont le premier caractère est un octet d’identifiant de flux : \x01 (stdout) ou \x02 (stderr). Lisez data.charCodeAt(0) (1 = stdout, 2 = stderr), puis data.slice(1) pour le texte. Une ligne sans cet octet de préfixe est du stdout.
  • status : métriques du conteneur en direct sous forme de chaîne JSON, environ une trame par seconde. La première trame de chaque (re)connexion est complète : { cpu, cpuLimit, ram: [usedMB, limitMB], status, netIO: { i, o, new: { i, o } }, bIO: { i, o }, uptime } (uptime est l’heure de démarrage en ms epoch ; netIO.new est en octets par seconde). Chaque trame ultérieure est allégée, ne transportant que { cpu, ram, netIO, bIO } — fusionnez chacune sur la dernière trame complète, en conservant les précédents cpuLimit, status et uptime. Tant que ce flux est ouvert, privilégiez-le plutôt que d’interroger GET /v2/apps/{app_id}/status, qui peut être obsolète d’environ une minute pour une application ayant un flux temps réel ouvert.
  • error : transporte un code d’erreur tel que CONTAINER_NOT_FOUND.
Dans l’exemple ci-dessous, \x01 / \x02 représentent les octets de préfixe stdout / stderr bruts.

Erreurs courantes