Contadores detallados¶
media.probe.counters
Contadores extendidos¶
La opción de contadores extendidos abre el detalle causal y de protocolo en todas partes a la vez: en las secciones input y dvr.write del Admin API, en las series del servidor Prometheus integrado y en el scrape de Prometheus. A la telemetría de Retroview estos contadores van siempre, independientemente de la opción — por eso el análisis de causas está disponible en Retroview incluso sin ella.
Causas de los errores de entrada¶
El errors agregado responde «en la entrada hay un problema»; el desglose causal responde «cuál exactamente». Las causas vienen en dos familias:
- defectos de medios de un stream vivo —
lost_packets,broken_payload,desync,ts_pat: los datos llegan, pero dañados; - fallos de la fuente —
connection_closed,connection_refused,timeout,http_request_error,not_found,denied,decode_error,protocol_error,io_error,other: la fuente murió y la causa de muerte está clasificada.
La clasificación sale de la categoría tipada del error y no del texto del log, y cubre también los fallos al abrir una fuente. Cada fallo entra además en el errors agregado; 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 fuente de mayor prioridad — no se cuentan como errores.
La serie del desglose¶
En el servidor Prometheus integrado el desglose viaja como una serie con la etiqueta de causa — errors_detail_total{name, cause}; en central las series llevan también node. Las causas sin eventos no crean series.
# errores del stream en 5 minutos, desglosados por causa
sum by (cause) (increase(errors_detail_total{name="tv1"}[5m]))
MPEG-TS por cada PID¶
Por cada PID del flujo de transporte: errors_ts_cc (violaciones del continuity counter — el indicador principal de pérdidas de transporte), errors_ts_tei, errors_ts_scrambled (no se retiró el cifrado — problemas de CAM/llaves), errors_ts_psi_checksum, PES rotos, buckets de jitter del PCR, vaciamientos del búfer del decodificador (HRD).
Por qué: este es material de monitorización de nivel broadcast. Una alerta sobre rate(errors_ts_cc) > 0 por cada PID caza la degradación del transporte antes de que la vea el espectador; el jitter del PCR y el HRD muestran si el stream sobrevivirá a un decodificador de hardware.
SRT¶
RTT y su variación, pérdidas y retransmisiones en ambas direcciones, descartes por llegar tarde, llenado de los búferes, tiempos de espera de keepalive.
Por qué: ajustar latency al canal real y diagnosticar «quién pierde — nosotros o el lado remoto». Las retransmisiones crecen con el RTT estable — pérdidas en el camino; el RTT salta — el canal está congestionado.
RTP/RTSP por canal¶
Paquetes perdidos, saltos y bloqueos de los timestamps, NACK, desbordamientos de búfer — por cada canal RTP (video/audio) de una cámara.
Por qué: diagnóstico del parque de cámaras — qué cámara está fallando, antes de que lleguen las quejas por artefactos.
Captura SDI¶
Los contadores de captura V4L2 utilizan el prefijo stream_input_sdi_. El nivel básico incluye:
-
Estado de la línea —
sdi_line_state. -
Reinicios de captura —
sdi_producer_restarts_total. -
Fotogramas perdidos desde la tarjeta —
sdi_boundary_loss_total, según los huecos en la secuencia de búferes.
Los contadores ampliados añaden:
-
Causas de reinicio — cambio de estándar o ausencia de fotogramas.
-
Tipos y modos ST 337 no admitidos —
sdi_unsupported_codec_total. -
Datos VANC desconocidos —
sdi_vanc_unknown_total. -
Datos CDP — número de paquetes y pares
cc_data. -
Código de tiempo — valores aceptados, rechazados y ausentes, y cambios de la línea temporal.
Los nombres con producer se conservan por compatibilidad y corresponden a la captura V4L2. sdi_boundary_loss_total indica pérdidas según los números de búfer; un salto PTS por sí solo no demuestra la pérdida de un fotograma. Consulte Captura SDI.
Rendimiento de escritura del DVR¶
segments_written_slow, segments_written_delayed, segments_written_collapsed, segments_discontinuity.
Por qué: una señal temprana de «el disco no da abasto». La proporción de slow/delayed crece con el mismo tráfico — el almacenamiento se está degradando; discontinuity significa huecos que luego verá en recorded_hours.
Contadores de calidad¶
Lo que hay disponible para alertar:
- HLS MPEG-TS para decodificadores: segmentos
ts/mux/incompletos y ensamblajes fuera de la caché. Véase Entrega de HLS MPEG-TS. - Captura MPEG-TS: por cada PID — errores CC, TEI, paquetes cifrados, errores CRC de PSI, PES rotos, estado del búfer del decodificador (HRD).
- SRT: RTT, pérdidas y retransmisiones en ambas direcciones, tamaños de búfer, tiempos de espera de keepalive.
- Fuentes (LSI): tiempo en la entrada principal/reserva, tiempo sin datos, reintentos, validez de las reservas, divergencia de parámetros entre las entradas.
- Sesiones: abiertas, rechazadas, autorizadas, denegaciones de reautorización.
- DVR: espacio en los discos, contadores de operaciones, número de blobs, bytes ocupados por el archivo, progreso de la reconstrucción del catálogo.
- Pushes: por cada push — estado con la causa del fallo, velocidad de envío, bytes, errores, reconexiones, retransmisiones SRT/RIST. Véase Estadísticas de pushes.
- Agentes de Peeklio: estado de las conexiones, bytes, errores.
Entrega de HLS MPEG-TS para decodificadores¶
La entrega mixta ts/mux/ ensambla cada segmento a partir del vídeo y el audio, y en el borde en vivo el audio puede no llegar a tiempo. Dos contadores del stream muestran lo que el espectador recibió de verdad:
| Serie de Prometheus | Qué cuenta | Cómo leerla |
|---|---|---|
stream_mpegts_hls_incomplete_segments_total |
segmentos de la ventana en vivo entregados sin parte del audio: el audio se retrasó, desapareció en la entrada, está declarado pero no llega, o el inicio de su ventana ya salió de la ventana en vivo | crecimiento constante — el audio de la entrada va por detrás del vídeo o no existe; una unidad por segmento de variante, así que un stream con tres vídeos da +3 por un trozo de audio retrasado |
stream_mpegts_hls_uncached_segments_total |
segmentos ensamblados fuera de la caché: el conjunto de pistas no está entre las variantes del maestro en vivo (una ventana de archivo sobre datos en vivo, un conjunto anterior al cambio de la descripción del stream, un subconjunto que el cliente pide por su cuenta) | crecimiento constante — los decodificadores reproducen lo que la caché no guarda, y cada ensamblaje cuesta procesador |
Ambas series son de nivel básico: en el servidor Prometheus integrado las tienen todos, en el scrape del nodo — con la opción de contadores extendidos. En la Admin API llegan como tasas en la sección mpegts_hls de las estadísticas del stream (incomplete_segments_rate, uncached_segments_rate); la sección está presente desde que el stream tuvo un segmento así. A la telemetría de Retroview llega el incremento por ventana.
# streams cuyos decodificadores reciben segmentos sin audio
rate(stream_mpegts_hls_incomplete_segments_total[5m]) > 0
El contador no distingue «el audio llegó tarde» de «no hay audio en la entrada»: mire la entrada del stream.