Supervisión del push¶

media.push.supervisor

Sapsan puede enviar un stream de manera activa: a las CDN y plataformas de streaming por RTMP, a otro servidor por SRT o RIST, o a la red por UDP (multicast/unicast). Un stream puede tener varios pushes a la vez.

Reconexión¶

El pusher no tiene política de reintentos propia — lo vuelve a levantar el stream. Cada cinco segundos el stream coteja los pushes en marcha con la configuración y reemplaza un pusher muerto por uno nuevo; el contador reconnects cuenta exactamente esos reemplazos. Por eso el envío a un destino inalcanzable nunca «se rinde» ni necesita reinicio manual: se seguirá levantando mientras el push esté activado.

Lo que no cuenta como reconexión:

• editar la configuración de un push — el pusher también se reinicia, pero es una decisión del operador, no un fallo del canal;
• desactivar y activar (enabled: false) — desactivar no es eliminar: la configuración y los contadores acumulados se quedan, solo se detiene el envío.

Desactivación y eliminación¶

Un push desactivado permanece en la configuración con su nombre: las estadísticas lo muestran como desactivado, sus contadores quedan congelados en los últimos valores, y al activarlo el conteo continúa desde ellos. Eliminar la clave elimina también las estadísticas: los contadores pertenecen al nombre.

Monitorización¶

Cada push tiene estadísticas propias — destino, estado, causa del fallo, velocidad, bytes, errores, reconexiones. La referencia de campos, las series de Prometheus y las recetas de alertas están en la página Estadísticas.

Qué viene después¶

• Estadísticas de push
• Monitorice los pushes

Estadísticas de pushes¶

La entrega saliente se cuenta aparte de la captura y por cada push: la clave de la estadística es el par «nombre del stream, nombre del push», el mismo que en la configuración. Un stream puede salir a cinco destinos, y «el stream envía 40 Mbit/s» no responde a si llega a alguno de ellos en concreto.

La sección pushes¶

GET /streamer/api-v4/streams/stats/{name} (y cada elemento de GET /streamer/api-v4/streams/stats) trae un objeto indexado por nombre de 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"}
}

Los campos en cero se omiten de la respuesta: un push RTMP no tiene datagramas, uno UDP no tiene ni fotogramas ni retransmisiones.

Junto a los contadores del stream, como campos de nivel superior de la misma respuesta, hay tres sumas sobre todos los pushes — push_bytes_total, push_errors_total, push_reconnects_total. Responden «cuánto envió el stream en total» sin recorrer el mapa.

Pushes activos¶

La lista de pushes en funcionamiento de todo el clúster no es un recorrido por los streams, sino una proyección ya lista del plano de estadísticas:

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

El mismo camino existe en el streamer: /streamer/api-v4/pushes/active. La clave del registro es la terna «stream, push, nodo»: un grupo standby mantiene dos registros por par stream×push, el activo y el en espera, distinguibles por el nodo y el campo standby_status. El registro lleva el destino sin secretos, el transporte, el propietario de la etiqueta user_id_<nombre> cuando está definido, y valores actuales: estado, momento de arranque del pusher actual, velocidad, errores, reconexiones, retransmisiones, bytes y datagramas, el retraso del pusher respecto al anillo de distribución y, en SRT, el 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}
    }
  ]
}

Los eventos de error_events van de más antiguos a más recientes y están limitados por un anillo: el desbordamiento expulsa a los más antiguos y la crónica completa no se guarda en ninguna parte. El anillo pertenece al push, no al pusher — los eventos se conservan tras una reconexión. El recurso acepta los filtros stream, push, user_id, node, transport y limit; los registros van del más reciente hacia arriba, por el momento de arranque del pusher. Un push apagado y un push sin pusher no entran en la lista; una respuesta vacía significa «no hay pushes funcionando».

Los eventos, los totales de paradas por causa y la profundidad SRT de protocolo (stream_push_srt_*) se mantienen solo para los pushes destacados — aquellos cuya configuración lleva la etiqueta de propietario user_id_<nombre> en labels. Un push sin propietario vive con la familia básica de series y los campos de estado; retirar la etiqueta detiene los puntos nuevos, y los ya escritos permanecen hasta que la ventana del almacén los expulse.

Series de Prometheus¶

Cada contador de push es una serie propia con la etiqueta push:

En el servidor Prometheus integrado los mismos contadores están disponibles con las etiquetas name (el stream) y push; en central se les añade node. La profundidad de protocolo — stream_push_srt_* y stream_push_rist_* — llega en el scrape del nodo junto con la opción de contadores extendidos. La serie stream_push_closures_total cuenta las paradas del pusher por causa del diccionario cerrado y es más amplia que reconnects_total: aquella cuenta solo los arranques tras una caída, esta — todas las paradas; también se mantiene solo para los pushes destacados.

# velocidad de envío por destino
rate(stream_push_bytes_total{stream="tv1"}[1m])

# la salida total del stream por todos los pushes
sum by (name) (rate(stream_push_bytes_total{name="tv1"}[1m]))

# canales que se cortan: reconexiones en cinco minutos
increase(stream_push_reconnects_total[5m]) > 0

# pérdidas en el camino hacia el receptor por SRT/RIST
rate(stream_push_retransmitted_packets_total[1m])

# destino inaccesible: una racha de paradas por error de envío
increase(stream_push_closures_total{reason="error"}[5m]) > 0

Cómo leer el estado¶

• status: error con un error no vacío — no se está enviando nada y la causa está nombrada. El push, aun así, sigue levantándose solo, una vez cada cinco segundos.
• status: running pero bitrate_kbit en cero — la conexión está, los datos no: compruebe si el propio stream está corriendo.
• status: running con un reconnects_total creciente — el canal se corta y se recupera; mire opened_at, muestra la edad de la conexión actual.
• un closures_by_reason creciente con causa error — el destino no responde y el pusher sigue reiniciándose; el ritmo se ve en los momentos de los eventos de error_events. Las paradas con disabled y reconfigure son del operador, no fallos de red.
• rtt_max_ms de un push SRT claramente por encima de la latencia configurada — la latencia no da para recuperar las pérdidas: suba la latencia del push.
• status: disabled — el push está apagado en la configuración. Sus contadores quedan congelados en sus últimos valores; no se pierde nada.

Configuración¶

Configure los pushes con nombre del stream mediante central. enabled: false pausa la entrega y conserva la configuración.

Transporte¶

Cada push con nombre selecciona su transporte. La supervisión no añade un protocolo de transporte.

Códecs compatibles¶

Los códecs dependen del protocolo seleccionado: UDP, RTMP, SRT, RIST, SDI.