Supervisão do push¶

media.push.supervisor

Sapsan pode enviar um stream de maneira ativa: para as CDNs e plataformas de streaming por RTMP, para outro servidor por SRT ou RIST, ou para a rede por UDP (multicast/unicast). Um stream pode ter vários pushes ao mesmo tempo.

Reconexão¶

O pusher não tem política de novas tentativas própria — quem o levanta de novo é o stream. A cada cinco segundos o stream coteja os pushes em execução com a configuração e substitui um pusher morto por um novo; o contador reconnects conta exatamente essas substituições. Por isso o envio para um destino inalcançável nunca «desiste» nem precisa de reinício manual: ele continuará sendo levantado enquanto o push estiver ativado.

O que não conta como reconexão:

• editar a configuração de um push — o pusher também é reiniciado, mas é uma decisão do operador, não uma falha do canal;
• desligar e ligar (enabled: false) — desligar não é excluir: a configuração e os contadores acumulados permanecem, só o envio cessa.

Desativação e exclusão¶

Um push desativado permanece na configuração com o seu nome: as estatísticas o mostram como desativado, seus contadores ficam congelados nos últimos valores, e ao ligá-lo a contagem continua dali. Excluir a chave exclui também as estatísticas: os contadores pertencem ao nome.

Monitoramento¶

Cada push tem estatísticas próprias — destino, status, causa da falha, taxa, bytes, erros, reconexões. A referência de campos, as séries do Prometheus e as receitas de alerta estão na página Estatísticas.

O que vem a seguir¶

• Estatísticas de push
• Monitore os pushes

Estatísticas de pushes¶

A entrega de saída é contada à parte da captura e por push: a chave da estatística é o par «nome do stream, nome do push», o mesmo da configuração. Um stream pode sair para cinco destinatários, e «o stream envia 40 Mbit/s» não responde se ele chega a algum deles em particular.

A seção pushes¶

GET /streamer/api-v4/streams/stats/{name} (e cada item de GET /streamer/api-v4/streams/stats) traz um objeto indexado pelo nome do push:

"pushes": {
  "cdn-main": {
    "status": "running",
    "proto": "udp",
    "url": "udp://127.0.0.1:5500",
    "opened_at": "2026-08-13T11:17:53Z",
    "bitrate_kbit": 2113.4,
    "bytes_total": 19053048,
    "datagrams_total": 14478
  },
  "youtube": {
    "status": "error",
    "proto": "rtmp",
    "url": "rtmp://198.51.100.7/live/secret-key",
    "error": "rtmp connect failed: timeout after 5s",
    "reconnects_total": 22
  },
  "backup-dc": {"status": "disabled", "proto": "srt", "url": "srt://203.0.113.10:9000"}
}

Campos zerados são omitidos da resposta: um push RTMP não tem datagramas, um UDP não tem quadros nem retransmissões.

Ao lado dos contadores do stream, como campos de nível superior da mesma resposta, há três somas sobre todos os pushes — push_bytes_total, push_errors_total, push_reconnects_total. Elas respondem «quanto o stream enviou no total» sem percorrer o mapa.

Pushes ativos¶

A lista de pushes em funcionamento de todo o cluster não é um percurso pelos streams, mas uma projeção pronta do plano de estatísticas:

curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
  'http://central:8080/central/api-v4/pushes/active?limit=100'

O mesmo caminho existe no streamer: /streamer/api-v4/pushes/active. A chave do registo é a tríade «stream, push, nó»: um grupo standby mantém dois registos por par stream×push, o ativo e o em espera, distinguíveis pelo nó e pelo campo standby_status. O registo leva o destino sem segredos, o transporte, o proprietário da etiqueta user_id_<nome> quando definido, e valores atuais: status, momento de arranque do pusher atual, velocidade, erros, reconexões, retransmissões, bytes e datagramas, o atraso do pusher em relação ao anel de distribuição e, no SRT, o RTT.

{
  "pushes": [
    {
      "stream": "tv1",
      "push": "cdn-main",
      "node": "node-7",
      "transport": "srt",
      "endpoint": "srt://203.0.113.10:9000",
      "user_id": "ivan",
      "status": "running",
      "opened_at": "2026-10-21T09:15:02Z",
      "bitrate_kbit": 2113.4,
      "rtt_ms": 34,
      "rtt_max_ms": 61,
      "error_events": [
        {"at": 1792845002, "close_reason": "error"},
        {"at": 1792845062, "error": "srt connect failed: timeout after 5s"}
      ],
      "closures_by_reason": {"error": 22, "reconfigure": 1}
    }
  ]
}

Os eventos de error_events vão do mais antigo ao mais recente e são limitados por um anel: o transbordo expulsa os mais antigos, e a crónica completa não é guardada em nenhum lugar. O anel pertence ao push, não ao pusher — os eventos conservam-se após uma reconexão. O recurso aceita os filtros stream, push, user_id, node, transport e limit; os registos vêm do mais recente para cima, pelo momento de arranque do pusher. Um push desligado e um push sem pusher não entram na lista; uma resposta vazia significa «não há pushes funcionando».

Os eventos, os totais de paradas por causa e a profundidade SRT de protocolo (stream_push_srt_*) mantêm-se apenas para os pushes destacados — aqueles cuja configuração leva a etiqueta de proprietário user_id_<nome> em labels. Um push sem proprietário vive com a família básica de séries e os campos de status; retirar a etiqueta interrompe os pontos novos, e os já escritos permanecem até que a janela do armazém os expulse.

Séries do Prometheus¶

Cada contador de push é uma série própria com o rótulo push:

No servidor Prometheus embutido os mesmos contadores estão disponíveis com os rótulos name (o stream) e push; no central soma-se node a eles. A profundidade de protocolo — stream_push_srt_* e stream_push_rist_* — chega no scrape do nó junto com a opção de contadores estendidos. A série stream_push_closures_total conta as paradas do pusher por causa do dicionário fechado e é mais ampla que reconnects_total: aquela conta só os arranques depois de uma queda, esta — todas as paradas; também se mantém apenas para os pushes destacados.

# velocidade de envio por destino
rate(stream_push_bytes_total{stream="tv1"}[1m])

# a saída total do stream por todos os pushes
sum by (name) (rate(stream_push_bytes_total{name="tv1"}[1m]))

# canais que rompem: reconexões em cinco minutos
increase(stream_push_reconnects_total[5m]) > 0

# perdas no caminho até o receptor por SRT/RIST
rate(stream_push_retransmitted_packets_total[1m])

# destino inacessível: uma sequência de paradas por erro de envio
increase(stream_push_closures_total{reason="error"}[5m]) > 0

Como ler o estado¶

• status: error com error não vazio — nada está sendo enviado, e a causa está nomeada. O push continua se levantando sozinho, uma vez a cada cinco segundos.
• status: running, mas bitrate_kbit zerado — a conexão está lá, os dados não: confira se o próprio stream está rodando.
• status: running com reconnects_total crescente — o canal rompe e se recupera; olhe opened_at, ele mostra a idade da conexão atual.
• um closures_by_reason crescente com causa error — o destino não responde e o pusher continua reiniciando; o ritmo vê-se nos momentos dos eventos de error_events. As paradas com disabled e reconfigure são do operador, não falhas de rede.
• rtt_max_ms de um push SRT bem acima da latência configurada — a latência não dá para recuperar as perdas: aumente a latência do push.
• status: disabled — o push está desligado na configuração. Seus contadores ficam congelados nos últimos valores; nada é perdido.

Configuração¶

Configure os pushes nomeados do stream pelo central. enabled: false pausa a entrega e mantém a configuração.

Transporte¶

Cada push nomeado seleciona seu transporte. A supervisão não adiciona um protocolo de transporte.

Codecs compatíveis¶

Os codecs dependem do protocolo selecionado: UDP, RTMP, SRT, RIST, SDI.