Aller au contenu
TypeDéverrouilléÉtapeProductionDifficultéSimpleTravailSurveiller un servicePourDevOps & infraPourÉquipes de devServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyMultijoueur par défaut
TypeDéverrouilléÉtapeProductionDifficultéSimpleTravailSurveiller un servicePourDevOps & infraPourÉquipes de devServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyMultijoueur par défaut
TypeDéverrouilléÉtapeProductionDifficultéSimpleTravailSurveiller un servicePourDevOps & infraPourÉquipes de devServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyMultijoueur par défaut
TypeDéverrouilléÉtapeProductionDifficultéSimpleTravailSurveiller un servicePourDevOps & infraPourÉquipes de devServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyMultijoueur par défaut
Retour aux cas d'utilisation
use-cases / tail-prod-logs-to-a-url / hero
PIPE · STREAMING DE LOGS EN DIRECT

Suivez les logs de production sur une URL accessible avec curl

Un incident éclate. Trois ingénieurs veulent les mêmes logs en même temps. Un émetteur envoie tail -F dans une URL Hoody Pipe. Toute personne avec le lien lance curl et voit les octets défiler en temps réel. Pas de bastion, pas d'agent à installer, pas de siège dashboard.

Lire la doc pipe
use-cases / tail-prod-logs-to-a-url / mechanism

Un émetteur. Plusieurs curl. Aucun agent.

Sur le conteneur de prod, une seule ligne envoie tail directement dans une URL Hoody Pipe. Les récepteurs font GET sur le même chemin. Le pipe ne retient rien — les octets traversent. Le premier récepteur à se connecter débloque l'émetteur ; jusqu'à 256 lecteurs peuvent rejoindre le même chemin.

prod-app-7 · /var/log/app
PUT · émetteur
# On the production container — one line.
# tail -F follows new lines forever; curl -T - PUTs stdin
# straight into a pipe path. ?n=4 says "wait for 4 readers".

tail -F /var/log/app/*.log \
  | curl -T - \
      "https://prod-pipe.containers.hoody.com/api/v1/pipe/live?n=4"

# [INFO] Waiting for 4 receiver(s) to connect...
# [INFO] Streaming to 4 receiver(s)...
le pipe ne retient rien · les octets traversent
n'importe quel laptop · sans ssh
GET · lecteurs
# Any engineer with the URL — same command, same path.
# The response body IS the live stdout of the sender.
# Up to 256 readers can join. SSE progress is available too.

curl "https://prod-pipe.containers.hoody.com/api/v1/pipe/live?n=4"

# 200 GET /v1/orders/8421 · 18ms
# POST /v1/checkout user=u_28f payload=ok
# 500 POST /v1/checkout · stripe timeout
# retrying charge attempt=2/3

Deux pièces de l'API Pipe documentée : PUT /api/v1/pipe/[path] sur l'émetteur, GET /api/v1/pipe/[path] sur chaque lecteur, tous deux indexés par le même n. Le serveur transmet le Content-Type de l'émetteur, maintient la connexion jusqu'à un TTL de 5 minutes en attendant les lecteurs, et applique un backpressure si un lecteur est lent.

use-cases / tail-prod-logs-to-a-url / powers

Ce que le pipe vous offre que le dashboard n'offre pas

Une URL de logs se comporte différemment d'un siège Datadog. Elle se lit par URL, pas par login. Elle disparaît quand l'émetteur s'arrête. Et elle s'étend à tout un canal d'incident.

MULTIJOUEUR PAR DÉFAUT

Jusqu'à 256 curl sur un seul flux

n=N est documenté dans l'API Pipe : chaque lecteur qui rejoint le même chemin avec le même n reçoit une copie identique en fan-out. SRE, on-call, fondateur sur son téléphone — tous suivent le même flux en même temps.

HTTP NATIF

Pas d'agent. Pas de forwarder. Juste curl.

Il n'y a rien à installer côté lecteurs. Tout ce qui parle HTTP — curl, fetch, un onglet de navigateur, un canal d'incident Slack qui prévisualise l'URL — est un tail valide. Les octets sont le corps de la réponse.

ÉPHÉMÈRE

ctrl-C et le pipe disparaît

Quand l'émetteur se déconnecte, le pipe disparaît. Pas de rétention à configurer, pas de volume de logs à nettoyer, pas d'endpoint résiduel exposé sur Internet. L'URL était un chemin, pas un lieu — et le chemin se referme quand l'incident est terminé.

use-cases / tail-prod-logs-to-a-url / capacity

Les chiffres derrière l'URL

Tirés de la spec de l'API Pipe. Limites et comportements qui font qu'une URL ressemble à de l'infrastructure plutôt qu'à un jouet.

  1. LECTEURS PAR CHEMIN256

    Le plafond documenté de n. Votre canal d'incident ne manquera jamais de places.

  2. OCTETS STOCKÉS0

    Le pipe est en streaming direct de bout en bout. Aucun disque intermédiaire, aucune rétention à gérer.

  3. TTL D'ATTENTE5 min

    Les récepteurs peuvent se connecter avant l'émetteur ; le serveur garde la place jusqu'à 5 minutes.

Source : API Hoody Pipe — limites documentées pour /api/v1/pipe/[path], paramètre n et TTL des pipes non établis.

use-cases / tail-prod-logs-to-a-url / punchline

Les logs ne sont plus un lieu. Ce sont un chemin.

pas de bastion · pas de siège · pas de forwarderune URL · jusqu'à 256 curl
hierssh bastion → tail -f /var/log/app.log
aujourd'huihttps://prod-pipe.../api/v1/pipe/live
Lire l'API pipe
use-cases / tail-prod-logs-to-a-url / replaces

Ce que cela remplace

L'ensemble d'outils et de rituels que vous invoquez aujourd'hui pour avoir trois ingénieurs devant le même log de prod. Chacun facture par siège, par agent ou par dashboard. Le pipe est une seule URL.

  • Sièges Datadog LogsLicence par utilisateur pour voir les mêmes octets
  • Bastion SSH + tail -fHop, ssh, trouver le fichier de log, répéter pour chaque ingénieur
  • Forwarders Loggly / LogtailInstallation d'agent, configuration, facture de rétention
  • Dashboards ELK / SplunkStack lourde pour héberger un seul tail
  • Partage d'écran Slack du tail -fUne personne suit, les autres plissent les yeux
  • Groupes de logs des fournisseurs cloudSiège console plus IAM par lecteur
use-cases / tail-prod-logs-to-a-url / cta

L'incident se termine. Vous faites ctrl-C sur l'émetteur. Le pipe disparaît. Il n'y a rien à nettoyer.

Lire l'API pipe
use-cases / tail-prod-logs-to-a-url / related

Découvrez les autres