Contadores detalhados¶

media.probe.counters

Contadores estendidos¶

A opção de contadores estendidos abre o detalhamento causal e de protocolo em todo lugar ao mesmo tempo: nas seções input e dvr.write da Admin API, nas séries do servidor Prometheus embutido e no scrape do Prometheus. Na telemetria do Retroview esses contadores sempre vão, independentemente da opção — por isso a análise de causas está disponível no Retroview mesmo sem ela.

Causas dos erros de entrada¶

O errors agregado responde «há um problema na entrada»; o detalhamento causal responde «qual exatamente». As causas vêm em duas famílias:

• defeitos de mídia de um stream vivo — lost_packets, broken_payload, desync, ts_pat: os dados chegam, mas danificados;
• falhas da fonte — connection_closed, connection_refused, timeout, http_request_error, not_found, denied, decode_error, protocol_error, io_error, other: a fonte morreu, e a causa da morte está classificada.

A classificação vem da categoria tipada do erro, e não do texto do log, e cobre inclusive a falha ao abrir uma fonte. Cada falha entra também no errors agregado; as falhas repetidas nas tentativas são contadas a cada vez — a frequência de eventos é exatamente o sinal de «a fonte ainda está morta». As paradas normais — reconfiguração, fim do stream, desalojo por uma fonte de maior prioridade — não contam como erros.

A série do detalhamento¶

No servidor Prometheus embutido o detalhamento viaja como uma série com o rótulo de causa — errors_detail_total{name, cause}; no central as séries levam também node. Causas sem eventos não criam séries.

# erros do stream em 5 minutos, detalhados por causa
sum by (cause) (increase(errors_detail_total{name="tv1"}[5m]))

MPEG-TS por cada PID¶

Por cada PID do fluxo de transporte: errors_ts_cc (violações de continuity counter — o principal indicador de perdas de transporte), errors_ts_tei, errors_ts_scrambled (a criptografia não foi retirada — problemas de CAM/chaves), errors_ts_psi_checksum, PES quebrados, buckets de jitter do PCR, esvaziamentos do buffer do decodificador (HRD).

Por quê: este é material de monitoramento de nível broadcast. Um alerta sobre rate(errors_ts_cc) > 0 por PID pega a degradação do transporte antes que o espectador a veja; o jitter do PCR e o HRD mostram se o stream sobreviverá a um decodificador de hardware.

SRT¶

RTT e sua variação, perdas e retransmissões nos dois sentidos, descartes por atraso, enchimento dos buffers, tempos limite de keepalive.

Por quê: ajustar a latency ao canal real e diagnosticar «quem perde — nós ou o lado remoto». As retransmissões crescem com o RTT estável — perdas no caminho; o RTT pula — o canal está congestionado.

RTP/RTSP por canal¶

Pacotes perdidos, saltos e travamentos dos timestamps, NACKs, transbordamentos de buffer — por cada canal RTP (vídeo/áudio) de uma câmera.

Por quê: diagnóstico do parque de câmeras — qual câmera está falhando, antes de chegarem as reclamações de artefatos.

Captura SDI¶

Os contadores de captura V4L2 usam o prefixo stream_input_sdi_. O nível básico inclui:

• Estado da linha — sdi_line_state.

• Reinícios da captura — sdi_producer_restarts_total.

• Quadros perdidos da placa — sdi_boundary_loss_total, com base nas lacunas na sequência de buffers.

Os contadores ampliados acrescentam:

• Causas de reinício — mudança de padrão ou ausência de quadros.

• Tipos e modos ST 337 não compatíveis — sdi_unsupported_codec_total.

• Dados VANC desconhecidos — sdi_vanc_unknown_total.

• Dados CDP — número de pacotes e pares cc_data.

• Timecode — valores aceitos, rejeitados e ausentes, e mudanças na linha do tempo.

Os nomes com producer são mantidos por compatibilidade e correspondem à captura V4L2. sdi_boundary_loss_total informa perdas pelos números dos buffers; uma lacuna PTS, por si só, não comprova a perda de um quadro. Consulte Captura SDI.

Desempenho de escrita do DVR¶

segments_written_slow, segments_written_delayed, segments_written_collapsed, segments_discontinuity.

Por quê: um sinal precoce de «o disco não dá conta». A fatia de slow/delayed cresce com o mesmo tráfego — o armazenamento está degradando; discontinuity significa buracos que você verá depois em recorded_hours.

Contadores de qualidade¶

O que está disponível para alertar:

• HLS MPEG-TS para set-top boxes: segmentos ts/mux/ incompletos e montagens fora do cache. Veja Entrega de HLS MPEG-TS.
• Captura MPEG-TS: por cada PID — erros CC, TEI, pacotes cifrados, erros CRC de PSI, PES quebrados, estado do buffer do decodificador (HRD).
• SRT: RTT, perdas e retransmissões nos dois sentidos, tamanhos de buffer, tempos limite de keepalive.
• Fontes (LSI): tempo na entrada principal/reserva, tempo sem dados, tentativas, validade das reservas, divergência de parâmetros entre as entradas.
• Sessões: abertas, recusadas, autorizadas, recusas de reautorização.
• DVR: espaço em disco, contadores de operações, número de blobs, bytes usados pelo arquivo, progresso da reconstrução do catálogo.
• Pushes: por push — status com a causa da falha, velocidade de envio, bytes, erros, reconexões, retransmissões SRT/RIST. Veja Estatísticas de pushes.
• Agentes do Peeklio: estado das conexões, bytes, erros.

Entrega de HLS MPEG-TS para set-top boxes¶

A entrega mista ts/mux/ monta cada segmento a partir do vídeo e do áudio, e na borda ao vivo o áudio pode não chegar a tempo. Dois contadores do stream mostram o que o espectador recebeu de fato:

As duas séries são de nível básico: no servidor Prometheus embutido todos as têm, no scrape do nó — com a opção de contadores estendidos. Na Admin API elas vêm como taxas na seção mpegts_hls das estatísticas do stream (incomplete_segments_rate, uncached_segments_rate); a seção existe a partir do momento em que o stream teve um segmento assim. Para a telemetria do Retroview vai o incremento por janela.

# streams cujos set-top boxes recebem segmentos sem áudio
rate(stream_mpegts_hls_incomplete_segments_total[5m]) > 0

O contador não distingue «o áudio atrasou» de «não há áudio na entrada»: olhe a entrada do stream.