Monitoramento¶

O Mcaster sempre coleta o conjunto completo de contadores. A licença e a tarefa só decidem por qual canal você os lê.

A regra de escolha é simples:

• «O que está acontecendo agora?» — o painel ou a API.
• «O que aconteceu nas últimas horas?» — o servidor Prometheus embutido.
• «O que aconteceu na semana passada e por que caiu de madrugada?» — Retroview.
• «Quero meu próprio Prometheus, Grafana e alertmanager» — o scrape.

O que olhar exatamente¶

Os contadores em si estão explicados nas páginas de cada tarefa, não aqui:

• Monitoramento de entrega — destinos: status, velocidade, erros, reconexões, retransmissões.
• Erros de entrada — causas das falhas e minutos sem sinal.
• TR 101 290 — qualidade do transporte por cada PID.
• Redundância de entradas — tempo na principal e na reserva.

O servidor Prometheus embutido¶

Dentro do Mcaster roda um servidor Prometheus: a HTTP API /api/v1/query, /api/v1/query_range, /api/v1/series, /api/v1/labels, /api/v1/label/{name}/values sobre um armazenamento próprio em memória. Para o Grafana é um datasource pronto — adicione um datasource do tipo Prometheus e aponte para a URL da cabeça de rede. Os gráficos do painel se alimentam dessas mesmas consultas.

Limites de construção:

• o histórico é de algumas horas, em memória; depois de um restart o armazenamento fica vazio. É o canal do «o que está acontecendo agora», não um arquivo de métricas;
• o PromQL é suportado como um subconjunto: seletores com matchers de rótulos, rate/irate/increase, as agregações sum/avg/min/max/count com by()/without(), aritmética, offset. Uma construção não suportada devolve um erro explícito, não um resultado distorcido;
• o conjunto de séries é o básico; a profundidade por PID, SRT e RTP chega com a opção de contadores estendidos.

# a velocidade de captura do stream
rate(stream_input_bytes_total{stream="tv1"}[1m])

# erros de entrada em 5 minutos por causa
sum by (cause) (increase(errors_detail_total{name="tv1"}[5m]))

# a saída por cada destino
rate(stream_push_bytes_total{stream="tv1"}[1m])

Quando há mais de uma cabeça de rede, cada série carrega um rótulo node, e um mesmo dashboard funciona tanto contra uma cabeça de rede única quanto contra o plano de controle: agregue com sum without (node) — numa máquina única o rótulo não existe e a agregação não muda nada.

O scrape para o seu próprio monitoramento¶

Métricas no formato de texto do Prometheus:

• GET /streamer/api-v4/live-metrics — streams e entradas;
• GET /streamer/api-v4/sessions-metrics — sessões;
• GET /streamer/api-v4/dvr/metrics — discos do arquivo e catálogo;
• GET /streamer/api-v4/runtime/metrics — o processo e o alocador de memória.

O histórico fica com você e é limitado só pelo retention da sua TSDB; a profundidade completa está disponível, incluindo métricas por PID, SRT e RTP; o alerting é o seu alertmanager. Os contadores são monótonos e sobrevivem à observação de restarts.

Retroview¶

O Retroview é o monitoramento em nuvem do fabricante. A cabeça de rede envia telemetria uma vez por minuto — o catálogo completo de contadores, incluindo todo o detalhe estendido — e o Retroview o guarda por meses. Nada precisa ser configurado na cabeça de rede: o canal funciona junto com a licença.

Quando ir lá, e não ao servidor Prometheus embutido:

• histórico e tendências — crescimento de carga ao longo de meses, planejamento de capacidade;
• post-mortems — o que o stream estava fazendo de madrugada: a telemetria sobrevive a restarts;
• conciliação de consumo — os contadores são amostrados no tempo por um sistema externo;
• análise de causas sem a opção de contadores estendidos — a telemetria sempre carrega o detalhe;
• alertas prontos — regras de produto em vez de regras caseiras.

Os logs¶

Os logs são estruturados e o nível é definido pela variável RUST_LOG:

journalctl -u mcaster -f

Os registros carregam o nome do stream e o módulo de destino, então filtrar por um stream específico funciona sem um indexador externo. Os traces são exportados por OpenTelemetry (OTLP).

A saúde da cabeça de rede¶

• Sonda de readiness: GET /streamer/api-v3/monitoring/readiness — para balanceadores e orquestradores.
• Memória por parte do pipeline: sum by (part) (stream_memory_bytes) — crescimento monótono sem crescimento de carga merece investigação.