Monitoring en meetwaarden

Meetwaarden per zender

Elke zender stelt het volgende beschikbaar in de interface en via de HTTP-API.

Bitrate op de kabel

De snelheid van de transportstreamdata die de interface daadwerkelijk verlaat naar de bestemming van die zender, gemeten via pakketcapture in plaats van gerapporteerd door de engine. Dit is het enige cijfer dat u kunt vertrouwen. Het is onafhankelijk van de engine, en het is de enige meting die buiten het proces plaatsvindt dat de stream maakt, dus een engine die denkt dat hij werkt, kan hem niet om de tuin leiden.

Frames per seconde

Gedecodeerde framerate. Alleen remux-engine.

Afspeelsnelheid

Voortgang door de bron ten opzichte van realtime. Een aanhoudende waarde onder 1.0 betekent dat de zender het niet bijhoudt. Alleen remux-engine.

Encoderbitrate

De snelheid die de engine denkt te produceren, te onderscheiden van de snelheid die op de kabel wordt waargenomen. Alleen remux-engine.

Uptime

Tijd sinds het huidige engineproces is gestart. Wordt bij elke herstart op nul gezet, waardoor een korte uptime op een zender waar u niet aan hebt gezeten op zichzelf al een signaal is.

Kijkers

Aantal televisies dat op dit moment bij de bestemmingsgroep is aangemeld, met hun adressen. Zie On-demand streaming voor hoe dit wordt gemeten en wanneer het als gedegradeerd wordt gemarkeerd.

Round-trip-tijd naar de bron

Latentie naar de host van de originserver. Nuttig om „de originserver is traag” te onderscheiden van „het pad naar de originserver is traag”.

Zenderlog

Een buffer per zender met de laatste 1000 regels of 24 uur, wat het eerst wordt bereikt, leesbaar in de interface zonder shelltoegang tot het apparaat.

Baseer geen meldingen op frames per seconde of afspeelsnelheid

Deze komen uit de eigen rapportage van de remux-engine. De pass-through-engine decodeert nooit video — dat is juist het hele punt — dus die levert geen framerate en geen afspeelsnelheid. Voor zulke zenders staan die velden op n/a, en dat is de juiste waarde, geen storing.

Elke watchdog die daarop is gebaseerd, leest n/a als nul en herstart eindeloos een volkomen gezonde zender. Dat is in productie twee keer gebeurd, vanuit twee verschillende controles. Maak zulke controles afhankelijk van de gebruikte engine, of baseer ze op de bitrate op de kabel, die voor beide bestaat.

Kwaliteit van de transportstream

Naast „verlaat er data de box” meet Castmux of de transportstream zelf gezond is. Zo wordt „zender 4 valt soms weg” een getal dat zegt of de schade met de bron binnenkwam of op de weg naar buiten is ontstaan. De knop Stats op de kaart van een zender toont grafieken van de laatste 30 minuten. Alle waarden zijn beschikbaar via GET /api/channels/{id}/ts-quality, en de meetwaarden onder OpenTelemetry worden geëxporteerd.

Bitrate en CBR-spreiding

De snelheid van de transportstream, en hoeveel die over de laatste minuut varieert. Een grote spreiding op een zender die een constante bitrate hoort te hebben, wilt u kennen voordat die via DVB-C wordt doorgegeven, waar elke multiplex een vaste capaciteit heeft.

Continuïteitsfouten

Ontbrekende pakketten of pakketten in de verkeerde volgorde, gedetecteerd aan de hand van de continuity counter van elk pakket en opgeteld over de PID’s van de zender. Dit is de meest directe maat voor verlies. Op de pass-through-engine geeft hij de bron getrouw weer. De remux-engine nummert de continuity counters opnieuw bij het schrijven, dus verlies vóór die engine is hier niet zichtbaar.

Transportfouten en synchronisatieverlies

Pakketten die de verzender zelf als beschadigd heeft gemarkeerd, en plekken waar de stream zijn pakketuitlijning kwijtraakte. Beide wijzen op een storing vóór het apparaat.

PCR-sprongen en PCR-nauwkeurigheid

PCR-sprongen zijn sprongen in de programmaklok. PCR-nauwkeurigheid controleert of elke klokreferentie aankwam op het moment dat haar tijdstempel aangeeft. Een referentie die verder afwijkt dan ts_pcr_jitter_max_ms (standaard 200 ms) telt als jitter-gebeurtenis. Die drempel is ingesteld om leveringspieken te signaleren die de buffer van een ontvanger zou moeten opvangen, niet gewone interleaving. PCR-nauwkeurigheid wordt gemeten voor SRT- en MPEG-TS-bronnen, en op de kabel voor zenders op de remux-engine. Voor HLS op de pass-through-engine wordt ze niet gemeten: segmenten komen daar per definitie in pieken binnen, en een meting zou er zinloos zijn.

Versleutelde PID’s

Het aantal PID’s van de zender dat versleutelde inhoud draagt. Castmux ontsleutelt niet, dus elke waarde boven nul op een zender die onversleuteld hoort te zijn, is een probleem bij de bron.

Hoe er wordt gemeten, hangt af van de engine. Een pass-through-zender wordt binnen zijn eigen pijplijn gemeten, op het punt waar de stream naar de kabel vertrekt. Een remux-zender krijgt een tweede, alleen-lezen proces dat zich bij de multicastgroep van de zender aanmeldt en meet wat een ontvanger daadwerkelijk krijgt. Geen van beide wijzigt de stream. De meting staat standaard aan en kan met ts_monitoring: false worden uitgezet om de kleine CPU-kosten per zender te besparen — zie Configuratie.

Tellingen worden momenteel over alle PID’s van de zender opgeteld, dus ze laten zien dát een zender beschadigd is, maar niet of het om de video of een audiotrack gaat. Een uitsplitsing per PID staat op de roadmap.

Systeemmeetwaarden

Gemeten voor het apparaat als geheel en naast de zenderlijst weergegeven, omdat de meeste capaciteitsproblemen hier eerder zichtbaar zijn dan per zender:

• CPU-gebruik. Opgeteld over alle cores.
• Geheugengebruik. De bepalende beperking op deze apparaten. Houd het in de gaten vóórdat u zenders toevoegt, niet erna — zie Systeemvereisten.
• CPU-temperatuur. Ventilatorloze boxen in kasten gedragen zich in augustus anders.
• Bitrate per interface, inkomend en uitgaand. Inkomend vertelt u wat de uplink van uw originservers ophaalt; uitgaand vertelt u wat er naar de televisies wordt gestuurd, en via welke interface — vaak de snelste manier om te merken dat het de verkeerde is.

DVB-C-meetwaarden

Waar een DVB-C-modulator is geplaatst, meldt elke multiplex zijn bedrijfstoestand, zijn uptime en een herstartteller. Zie DVB-C-multiplexing.

Gezondheidscontroles die Castmux uitvoert

Castmux bewaakt zijn eigen zenders. Elke onderstaande toestand wordt continu gedetecteerd en heeft een vaste, weloverwogen reactie.

Toestand	Wat het betekent	Wat Castmux doet
Geen data bij het opstarten	De engine is gestart, maar er is nog niets geproduceerd.	Geeft een respijtperiode — een koude start duurt terecht enkele seconden — en herstart daarna.
Stilte midden in de stream	Een zender die data produceerde, is gestopt. Meestal heeft de originserver hem laten vallen.	Herstart zodra de stall-time-out is verstreken.
Uitvoer stil, proces actief	De engine draait en denkt dat alles in orde is, maar er staat niets op de kabel. De ergste storingsvorm, omdat elke interne teller er gezond uitziet.	Herstart na enkele minuten bevestigde stilte.
Dip in de uitvoer	De bitrate op de kabel daalde maar stopte niet. Korte dips zijn normaal op segmentgrenzen en bij haperingen van de originserver.	Getolereerd binnen een respijtvenster, gemeten vanaf het laatste bekende gezonde moment. Op elke dip reageren zou zenders herstarten die op het punt stonden zichzelf te herstellen.
Herhaald vroegtijdig stoppen	De engine stopt steeds kort na het starten. Normaal gesproken een bron die onbereikbaar of onbruikbaar is.	Wacht steeds langer in plaats van de originserver te bestoken. De wachttijd wordt teruggezet na een aanhoudend gezonde periode, zodat een haperende bron niet voor altijd een strafvertraging opbouwt.
Bestemming onrouteerbaar	De multicastroute leidt nergens bruikbaar heen. Gecontroleerd tegen de routeringstabel van buiten het proces, omdat een socket dit niet kan detecteren.	Alleen een melding. Herstart nooit. Zie Probleemoplossing.
Dubbele verzenders	Iets anders zendt naar dezelfde multicastgroep — vaak een oudere installatie die is uitgeschakeld maar niet gestopt. Televisies ontvangen beide streams door elkaar en tonen blokvorming.	Geeft een melding. Herstarten zou niet helpen, en het is niet aan Castmux om te beslissen welke verzender moet worden gestopt.
Weesproces	Een engineproces dat is achtergebleven van een eerdere bewakingscyclus.	Reaped.

Herstart wat een herstart kan oplossen, meld wat hij niet kan oplossen

Dit is de regel die in de tabel hierboven is vastgelegd, en het is goed hem expliciet te noemen, omdat hij verklaart waarom sommige ernstige toestanden helemaal geen herstart opleveren.

Een herstart is de juiste reactie op een vastgelopen proces, een dode verbinding met een originserver of een engine die klem zit. Het is de verkeerde reactie op een netwerkstoring. Wijst de multicastroute naar een interface zonder carrier, dan levert het herstarten van de zender een vers proces op dat in dezelfde leegte zendt — en dat gebeurt om de paar minuten, waardoor de log volloopt met herstartgebeurtenissen die de ene regel met de echte oorzaak begraven. Een herstartlus tegen een netwerkstoring is erger dan de storing zelf, omdat hij het bewijs vernietigt.

Castmux herstart dus wat een herstart redelijkerwijs kan oplossen; bij al het andere stopt het, zegt het wat er mis is en laat het de zender met rust.

Exports

OpenTelemetry-meetwaarden

Castmux exporteert zijn meetwaarden en gebeurtenissen via OpenTelemetry (OTLP via gRPC) naar de Castmux-telemetriecollector op otel.alteox.app, poort 4317. De export staat altijd aan en de collector ligt vast: die kan momenteel niet naar een eigen collector worden omgeleid. Elke reeks krijgt als labels de location_name en re_seller van de locatie, de hostnaam en softwareversie van het apparaat, en per zender de naam, het protocol, de bronhost en -poort en de engine. Is de collector onbereikbaar, dan mislukt de export stilletjes en heeft dat geen invloed op het streamen.

De kwaliteitscijfers van de transportstream worden per zender geëxporteerd als go_udp_channel_ts_bitrate_kbps, go_udp_channel_cbr_spread_percent, go_udp_channel_ts_continuity_errors_total, go_udp_channel_ts_transport_errors_total, go_udp_channel_ts_pcr_leaps_total, go_udp_channel_pcr_jitter_max_microseconds en go_udp_channel_pcr_violation_percent.

Reeksen worden gelabeld met de zendernaam

Een zender hernoemen begint een nieuwe reeks; de oude ontvangt geen punten meer. Hernoemt u zenders regelmatig, reken dan op een onderbreking in dashboards op dat moment. Verwijderingen worden correct afgehandeld — de reeks wordt beëindigd in plaats van verouderd achtergelaten — dus het verwijderen van een zender laat geen permanente vlakke lijn in uw grafieken achter.

Gestructureerde gebeurtenissen

Naast de numerieke meetwaarden geeft Castmux gestructureerde gebeurtenissen af voor alles wat van toestand verandert. Daarmee bouwt u na een incident een tijdlijn op:

• engine gestart, engine gestopt
• herstart gestart
• uitvoer stil, uitvoer hersteld, uitvoer gedegradeerd
• bestemming onrouteerbaar
• dubbele verzenders gedetecteerd
• transportstreamfouten (ts_quality_errors), met de tellingen die de gebeurtenis veroorzaakten, maximaal één keer per minuut per zender
• kijkers aangekomen, kijkers vertrokken
• instellingen gewijzigd

Een herstart op zich zegt weinig. Een herstart voorafgegaan door „uitvoer stil” en gevolgd door „uitvoer hersteld” is een correct afgehandelde hapering van de bron; dezelfde herstart voorafgegaan door „bestemming onrouteerbaar” betekent dat iemand een zender met de hand heeft herstart tegen een netwerkstoring in.

Logs

Castmux schrijft gestructureerde JSON naar stdout, die een logcollector voor containers zonder parseerlaag kan verwerken. Hetzelfde materiaal is per zender in de interface beschikbaar, gebufferd tot 1000 regels of 24 uur; dat is normaal gesproken genoeg om een storing die die ochtend is gemeld te diagnosticeren zonder shelltoegang tot het apparaat.

Bij het openen van een supportverzoek is de zenderlog van de getroffen zender de allernuttigste bijlage. Probleemoplossing noemt de rest.

Roadmap

Het volgende is toegezegd maar nog niet uitgebracht. Het staat hier zodat u rekening kunt houden met het ontbreken ervan, in plaats van dat tijdens de ingebruikname te ontdekken.

Prometheus-endpoint gepland

Een scrape-endpoint naast de OpenTelemetry-export, met een meegeleverd dashboard zodat een locatie niet zelf panelen hoeft te bouwen.

Meldingen via e-mail en webhook gepland

Aflevering van de meldingstoestanden hierboven zonder tussenliggende externe monitoringstack.

Transportstreamanalyse gepland

Ingebouwde analyse die continuity-counter-fouten, PES-fouten en aantallen versleutelde pakketten per PID rapporteert — de metingen die verlies aan de bronzijde onderscheiden van lokaal ontstaan verlies.

Herstartteller en beschikbaarheidsrapport gepland

Herstarttellingen en beschikbaarheid per zender over een periode. Momenteel is de herstartfrequentie alleen uit de logs te halen, waardoor „wordt deze zender slechter?” moeilijker te beantwoorden is dan zou moeten.