Pular para o conteúdo
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoMonitorar serviçoParaDevOps & infraParaEquipes de desenvolvimentoServiçosPipePor que HoodyHTTP-nativoPor que HoodyMultiplayer por padrão
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoMonitorar serviçoParaDevOps & infraParaEquipes de desenvolvimentoServiçosPipePor que HoodyHTTP-nativoPor que HoodyMultiplayer por padrão
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoMonitorar serviçoParaDevOps & infraParaEquipes de desenvolvimentoServiçosPipePor que HoodyHTTP-nativoPor que HoodyMultiplayer por padrão
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoMonitorar serviçoParaDevOps & infraParaEquipes de desenvolvimentoServiçosPipePor que HoodyHTTP-nativoPor que HoodyMultiplayer por padrão
Voltar aos casos de uso
use-cases / tail-prod-logs-to-a-url / hero
PIPE · STREAMING DE LOGS AO VIVO

Acompanhe logs de produção em uma URL que qualquer um pode curl

Acontece um incêndio. Três engenheiros querem os mesmos logs ao mesmo tempo. Um remetente envia tail -F para uma URL do Hoody Pipe. Quem tiver o link roda curl e vê os bytes passando em tempo real. Sem bastion, sem instalação de agente, sem assento de dashboard.

Ler a documentação do pipe
use-cases / tail-prod-logs-to-a-url / mechanism

Um remetente. Vários curls. Sem agente.

No contêiner de produção, uma linha envia tail direto para uma URL do Hoody Pipe. Os receptores fazem GET no mesmo caminho. O pipe não retém nada — os bytes passam em streaming. O primeiro receptor a se conectar desbloqueia o remetente; até 256 leitores podem entrar no mesmo caminho.

prod-app-7 · /var/log/app
PUT · remetente
# No contêiner de produção — uma linha.
# tail -F segue novas linhas para sempre; curl -T - faz PUT do stdin
# direto em um caminho de pipe. ?n=4 diz "esperar por 4 leitores".

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)...
o pipe não retém nada · os bytes passam em streaming
qualquer notebook · sem ssh
GET · leitores
# Qualquer engenheiro com a URL — mesmo comando, mesmo caminho.
# O corpo da resposta É o stdout ao vivo do remetente.
# Até 256 leitores podem entrar. Progresso via SSE também disponível.

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

Duas peças da Pipe API documentada: PUT /api/v1/pipe/[path] no remetente, GET /api/v1/pipe/[path] em cada leitor, ambos com a mesma chave n. O servidor encaminha o Content-Type do remetente, mantém a conexão por um TTL de até 5 minutos enquanto espera os leitores e aplica backpressure se algum leitor for lento.

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

O que o pipe te dá que um dashboard não dá

Uma URL de logs se comporta diferente de um assento Datadog. Acessa-se por URL, não por login. Some quando o remetente para. E escala para um canal de incidente inteiro.

MULTIPLAYER POR PADRÃO

Até 256 curls em um stream

n=N está documentado na Pipe API: cada leitor que entra no mesmo caminho com o mesmo n recebe uma cópia idêntica em fan-out. SREs, plantão, o fundador olhando do celular — todos acompanham o mesmo stream ao mesmo tempo.

NATIVO DE HTTP

Sem agente. Sem encaminhador. Só curl.

Não há nada para instalar do lado dos leitores. Qualquer coisa que fale HTTP — curl, fetch, uma aba do navegador, um canal de incidente do Slack que mostra a URL — é um tail de log válido. Os bytes são o corpo da resposta.

EFÊMERO

ctrl-C e o pipe some

Quando o remetente desconecta, o pipe desaparece. Sem retenção para configurar, sem volume de log para limpar, sem endpoint sobrando exposto na internet. A URL era um caminho, não um lugar — e o caminho fecha quando o incêndio termina.

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

Os números por trás da URL

Da especificação da Pipe API. Limites e comportamentos que fazem uma URL parecer infraestrutura em vez de brinquedo.

  1. LEITORES POR CAMINHO256

    O limite documentado de n. Seu canal de incidente não vai ficar sem assentos.

  2. BYTES ARMAZENADOS0

    O pipe é direct-streamed de ponta a ponta. Sem disco intermediário, sem retenção para gerenciar.

  3. TTL DE ESPERA5 min

    Os receptores podem se conectar antes do remetente; o servidor mantém o slot por até 5 minutos.

Fonte: Hoody Pipe API — limites documentados para /api/v1/pipe/[path], parâmetro n e TTL do pipe não estabelecido.

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

Logs não são mais um lugar. São um caminho.

sem bastion · sem assento · sem encaminhadoruma URL · até 256 curls
ontemssh bastion → tail -f /var/log/app.log
hojehttps://prod-pipe.../api/v1/pipe/live
Ler a pipe API
use-cases / tail-prod-logs-to-a-url / replaces

O que isto substitui

O conjunto de ferramentas e rituais que você invoca hoje para colocar três engenheiros olhando o mesmo log de produção. Cada um cobra por assento, por agente ou por dashboard. O pipe é uma URL.

  • Assentos do Datadog LogsLicença por usuário para ver os mesmos bytes
  • Bastion SSH + tail -fSalto, ssh, achar o arquivo de log, repetir por engenheiro
  • Encaminhadores Loggly / LogtailInstalação de agente, config, conta de retenção
  • Dashboards ELK / SplunkStack pesada para hospedar um tail
  • Compartilhar tela do tail -f no SlackUma pessoa acompanha, o resto aperta os olhos
  • Log groups do provedor de nuvemAssento no console mais IAM por leitor
use-cases / tail-prod-logs-to-a-url / cta

O incêndio termina. Você dá ctrl-C no remetente. O pipe some. Não há nada para limpar.

Ler a pipe API
use-cases / tail-prod-logs-to-a-url / related

Leia os outros