Skip to content

Errores de entrada

Un solo contador de errores responde únicamente a la pregunta «hay un problema en la entrada». Para una cabecera eso no basta: la causa decide a quién llamar. Los paquetes perdidos son la red, la conexión rechazada es el socio, el tiempo de espera del handshake es su codificador o el cortafuegos entre ustedes.

Por eso los errores de entrada se cuentan por causa, y cada causa es una línea propia en el gráfico y una serie propia en las métricas.

Dos familias de causas

  • Defectos de medios de un stream vivo — los datos llegan, pero dañados: lost_packets, broken_payload, desync, ts_pat.
  • Fallos de la fuente — no hay datos, y la causa de muerte está nombrada: connection_closed, connection_refused, timeout, http_request_error, not_found, denied, decode_error, protocol_error, io_error, other.

La diferencia es práctica. La primera familia significa que la señal corre y hay que repararla a nivel de transporte — lo siguiente que hay que mirar son los contadores TR 101 290. La segunda significa que no hay señal en absoluto, y lo que hay que reparar es la conexión.

Cómo se cuenta:

  • la clasificación sale de la categoría tipada del error, y no del texto del log — reformular un mensaje no rompe el contador;
  • un fallo al abrir una fuente también entra en el detalle, no solo el fallo de una conexión ya en marcha;
  • cada fallo entra también en el contador agregado errors, de modo que las sumas cuadran;
  • los fallos repetidos en los reintentos se cuentan cada vez: la frecuencia de eventos es exactamente la señal de que «la fuente sigue muerta»;
  • las paradas normales — reconfiguración, fin del stream, desalojo por una entrada de mayor prioridad — no se cuentan como errores.

El gráfico en la tarjeta del stream

El panel Errores de la fuente en la pestaña Fuentes dibuja los errores por minuto como líneas separadas por causa. Las causas sin eventos no ocupan lugar en la leyenda — el gráfico muestra exactamente lo que está pasando.

Los minutos en los que el ritmo de fotogramas de entrada fue cero se resaltan como outage. Eso responde a una pregunta que un solo contador de errores nunca cierra: si aquellos errores eran con la señal viva, o si en ese momento no había señal en absoluto.

Pérdida de una fuente SRT: bandas de outage y tiempos de espera de los reintentos

Una fuente HLS o HTTP MPEG-TS inaccesible da http_request_error en cada reintento, y un handshake SRT que falla por tiempo de espera da timeout:

Entradas muertas: http_request_error y timeout

Sin la opción de contadores ampliados el panel muestra una sola línea agregada; las líneas detalladas aparecen junto con la opción.

La serie de métricas

En el servidor Prometheus incorporado el detalle viaja como una serie con la etiqueta de causa — errors_detail_total{name, cause}; cuando hay más de una estación, las series llevan también node. Las causas sin eventos no crean series.

# stream errors over 5 minutes broken down by cause
sum by (cause) (increase(errors_detail_total{name="tv1"}[5m]))

# every input currently seeing connection failures
sum by (name) (rate(errors_detail_total{cause="connection_closed"}[5m])) > 0

Cómo leerlo

Qué se ve Qué significa
lost_packets con bitrate vivo está perdiendo la red entre la fuente y la estación; use los contadores de transporte para encontrar el PID afectado
timeout a ráfagas, bandas de outage la fuente no responde; cada ráfaga es un reintento más
http_request_error como peine constante la fuente HTTP es inaccesible: dirección, DNS, cortafuegos o un origen caído
connection_closed con el stream vivo el socio corta la conexión él mismo; mire su lado
denied, not_found acceso o ruta: la clave, el streamid, el nombre del recurso
desync, broken_payload los datos llegan rotos — el transporte o el codificador del otro lado

Un error suelto en el gráfico es lo normal en una red. El diagnóstico lo pone la forma: un peine constante de una causa, ráfagas alrededor de las bandas de outage, crecimiento con el bitrate sin cambios.

Qué viene después