Skip to content

Monitorización

Mcaster siempre recolecta el conjunto completo de contadores. La licencia y la tarea solo deciden por qué canal los lee usted.

Canal Qué da Disponibilidad
El panel y la API una instantánea: qué hacen ahora mismo el stream y sus destinos todos
El servidor Prometheus integrado un datasource de Grafana listo para usar, con unas horas de historia todos
El scrape de Prometheus métricas en bruto para su propia TSDB y su alertmanager la opción de contadores extendidos
Retroview la monitorización en la nube del fabricante: meses de historia, tendencias, alertas listas suscripción

La regla de elección es sencilla:

  • «¿Qué está pasando ahora?» — el panel o la API.
  • «¿Qué pasó en las últimas horas?» — el servidor Prometheus integrado.
  • «¿Qué pasó la semana pasada y por qué se cayó de noche?» — Retroview.
  • «Quiero mi propio Prometheus, Grafana y alertmanager» — el scrape.

Qué mirar exactamente

Los contadores en sí están explicados en las páginas de cada tarea, no aquí:

El servidor Prometheus integrado

Dentro de Mcaster corre un servidor Prometheus: la HTTP API /api/v1/query, /api/v1/query_range, /api/v1/series, /api/v1/labels, /api/v1/label/{name}/values sobre un almacén propio en memoria. Para Grafana es un datasource listo — añada un datasource de tipo Prometheus y apúntelo a la URL de la cabecera. Con esas mismas consultas se alimentan los gráficos del panel.

Límites por construcción:

  • la historia es de unas horas, en memoria; tras un reinicio el almacén queda vacío. Es el canal del «qué está pasando ahora», no un archivo de métricas;
  • PromQL está soportado como un subconjunto: selectores con matchers de etiquetas, rate/irate/increase, las agregaciones sum/avg/min/max/count con by()/without(), aritmética, offset. Una construcción no soportada devuelve un error explícito, no un resultado distorsionado;
  • el conjunto de series es el básico; la profundidad por PID, SRT y RTP llega con la opción de contadores extendidos.
# la velocidad de captura del stream
rate(stream_input_bytes_total{stream="tv1"}[1m])

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

# la salida por cada destino
rate(stream_push_bytes_total{stream="tv1"}[1m])

Cuando hay más de una cabecera, cada serie lleva una etiqueta node, y un mismo dashboard funciona tanto contra una cabecera única como contra el plano de control: agregue con sum without (node) — en una máquina única la etiqueta no está y la agregación no cambia nada.

El scrape para su propia monitorización

La opción de contadores extendidos

Los endpoints del scrape están disponibles solo con esta opción de licencia. Sin ella, use el servidor Prometheus integrado y Retroview.

Métricas en el formato de texto de Prometheus:

  • GET /streamer/api-v4/live-metrics — streams y entradas;
  • GET /streamer/api-v4/sessions-metrics — sesiones;
  • GET /streamer/api-v4/dvr/metrics — los discos del archivo y el catálogo;
  • GET /streamer/api-v4/runtime/metrics — el proceso y el asignador de memoria.

La historia la guarda usted y solo la limita el retention de su TSDB; está disponible la profundidad completa, incluidas las métricas por PID, SRT y RTP; las alertas las maneja su alertmanager. Los contadores son monótonos y sobreviven a la observación de los reinicios.

Retroview

Retroview es la monitorización en la nube del fabricante. La cabecera envía telemetría una vez por minuto — el catálogo completo de contadores, incluido todo el detalle extendido — y Retroview la guarda durante meses. En la cabecera no hay que configurar nada: el canal funciona junto con la licencia.

Cuándo ir allí y no al servidor Prometheus integrado:

  • historia y tendencias — el crecimiento de la carga a lo largo de los meses, la planificación de capacidad;
  • post-mortems — qué hacía el stream de noche: la telemetría sobrevive a los reinicios;
  • conciliación de consumo — los contadores son muestreados en el tiempo por un sistema externo;
  • análisis de causas sin la opción de contadores extendidos — la telemetría siempre lleva el detalle;
  • alertas listas — reglas de producto en lugar de reglas caseras.

Los logs

Los logs son estructurados y el nivel se fija con la variable RUST_LOG:

journalctl -u mcaster -f

Los registros llevan el nombre del stream y el módulo de destino, así que el filtrado por un stream concreto funciona sin un indexador externo. Las trazas se exportan por OpenTelemetry (OTLP).

La salud de la cabecera

  • Sonda de readiness: GET /streamer/api-v3/monitoring/readiness — para balanceadores y orquestadores.
  • Memoria por parte del pipeline: sum by (part) (stream_memory_bytes) — un crecimiento monótono sin crecimiento de la carga merece una investigación.