Haut ginn et fäerdeg (propriétaire) Léisunge fir d'Iwwerwaachung vun IP(TS) Fluxen, zum Beispill и , Si hunn e zimlech räiche Set vu Funktiounen an normalerweis grouss Betreiber, déi mat Fernsehdéngschter handelen, hunn ähnlech Léisungen. Dësen Artikel beschreift eng Léisung baséiert op engem Open Source Projet , entworf fir minimal Kontroll vun IP (TS) Flux mat der CC (Kontinuitéit Konter) Konter an bitrate. Eng méiglech Applikatioun iwwerwaacht de Verloscht vu Paketen oder de ganze Floss duerch e gelounte L2 Kanal (dee kann net normalerweis iwwerwaacht ginn, zum Beispill, andeems d'Verlustzähler an de Schlaangen liesen).
Ganz kuerz iwwer TSDuck
TSDuck ass Open Source (2-Klausel BSD Lizenz) Software (eng Rei vu Konsol Utilities an eng Bibliothéik fir Är eege Utilities oder Plugins z'entwéckelen) fir TS Streamen ze manipuléieren. Als Input kann et mat IP (Multicast / Unicast), http, hls, dvb Tuners, dektec dvb-asi Demodulator funktionnéieren, et gëtt en internen TS Stream Generator a Liest vu Dateien. D'Ausgab kann op eng Datei opgeholl ginn, IP (Multicast / Unicast), hls, dektec dvb-asi an HiDes Modulatoren, Spiller (mplayer, vlc, xine) an drop. Tëscht dem Input an Output kënnt Dir verschidde Trafficprozessoren aktivéieren, zum Beispill, PIDs ëmsetzen, Scrambling / Descrambling maachen, CC-Zähler analyséieren, de Bitrate berechnen an aner Operatiounen typesch fir TS Streamen.
An dësem Artikel ginn IP Streams (Multicast) als Input benotzt, bitrate_monitor Prozessoren (vum Numm ass kloer wat dëst ass) a Kontinuitéit (CC Konter Analyse) Prozessoren ginn benotzt. Ouni Probleemer kënnt Dir IP Multicast ersetzen mat engem aneren Input Typ ënnerstëtzt vun TSDuck.
Et gi sinn TSDuck fir déi meescht aktuell OS. Et gi keng fir Debian, awer mir hunn et fäerdeg bruecht se fir Debian 8 an Debian 10 ouni Probleemer ze kompiléieren.
Als nächst gëtt d'TSDuck Versioun 3.19-1520 benotzt, Linux gëtt als OS benotzt (debian 10 gouf benotzt fir d'Léisung ze preparéieren, CentOS 7 gouf fir tatsächlech Benotzung benotzt)
TSDuck an OS virbereeden
Ier Dir real Flux iwwerwaacht, musst Dir sécher sinn datt TSDuck richteg funktionnéiert an datt Drëpsen net op der Netzwierkkaart oder OS (Socket) Niveau optrieden. Dëst ass erfuerderlech fir datt Dir net méi spéit muss roden wou d'Drëpsen opgetruede sinn - am Netz oder "am Server." Dir kënnt Drëpsen um Netzwierkkaartniveau mam Kommando ethtool -S ethX kontrolléieren, Tuning gëtt vum selwechte ethtool gemaach (normalerweis musst Dir de RX-Puffer erhéijen (-G) an heiansdo e puer Offloads deaktivéieren (-K)). Als allgemeng Empfehlung ass et unzeroden en separaten Hafen ze benotzen fir den analyséierten Traffic ze kréien, wa méiglech, dëst wäert falsch Positiver minimiséieren wéinst der Tatsaach datt de Réckgang gläichzäiteg um Analyserport geschitt ass wéinst der Präsenz vun anere Verkéier. Wann dëst net méiglech ass (Dir benotzt e Mini-Computer / NUC mat engem Hafen), ass et ganz ubruecht d'Prioritéit vum analyséierten Traffic par rapport zu de Rescht op dem Apparat ze konfiguréieren, an deem den Analysator ugeschloss ass. Wat virtuell Ëmfeld ugeet, hei musst Dir virsiichteg sinn a fäeg sinn Paketdrëpsen ze fannen déi vum physeschen Hafen unzefänken a mat der Applikatioun an der virtueller Maschinn ophalen.
Generéiere a kréien e Stream am Host
Als éischte Schrëtt fir TSDuck virzebereeden, generéiere mir Traffic bannent engem Host mat Netns.
Ëmweltvirbereedung:
ip netns add P #создаём netns P, в нём будет происходить анализ трафика
ip link add type veth #создаём veth-пару - veth0 оставляем в netns по умолчанию (в этот интерфейс будет генерироваться трафик)
ip link set dev veth1 netns P #veth1 - помещаем в netns P (на этом интерфейсе будет приём трафика)
ip netns exec P ifconfig veth1 192.0.2.1/30 up #поднимаем IP на veth1, не имеет значения какой именно
ip netns exec P ip ro add default via 192.0.2.2 #настраиваем маршрут по умолчанию внутри nents P
sysctl net.ipv6.conf.veth0.disable_ipv6=1 #отключаем IPv6 на veth0 - это делается для того, чтобы в счётчик TX не попадал посторонний мусор
ifconfig veth0 up #поднимаем интерфейс veth0
ip route add 239.0.0.1 dev veth0 #создаём маршрут, чтобы ОС направляла трафик к 239.0.0.1 в сторону veth0D'Ëmwelt ass prett. Start de Traffic Analyser:
ip netns exec P tsp --realtime -t
-I ip 239.0.0.1:1234
-P continuity
-P bitrate_monitor -p 1 -t 1
-O dropwou "-p 1 -t 1" heescht datt Dir de Bitrate all Sekonn muss berechnen an Informatioun iwwer de Bitrate all Sekonn weisen
Mir starten e Verkéiersgenerator mat enger Geschwindegkeet vun 10 Mbit/s:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234wou "-p 7 -e" heescht datt Dir 7 TS Paketen an 1 IP Paket packe musst an et schwéier maachen (-e), d.h. ëmmer wait fir 7 TS Pak vun der leschter Prozessor virun der Formatioun vun engem IP Pak schéckt.
Den Analyser fänkt un déi erwaart Messagen ze weisen:
* 2020/01/03 14:55:44 - bitrate_monitor: 2020/01/03 14:55:44, TS bitrate: 9,970,016 bits/s
* 2020/01/03 14:55:45 - bitrate_monitor: 2020/01/03 14:55:45, TS bitrate: 10,022,656 bits/s
* 2020/01/03 14:55:46 - bitrate_monitor: 2020/01/03 14:55:46, TS bitrate: 9,980,544 bits/sLoosst eis elo e puer Drëpsen derbäi:
ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROPa Messagen wéi dës schéngen:
* 2020/01/03 14:57:11 - continuity: packet index: 80,745, PID: 0x0000, missing 7 packets
* 2020/01/03 14:57:11 - continuity: packet index: 83,342, PID: 0x0000, missing 7 packets déi erwaart gëtt. Mir deaktivéieren Paketverloscht (ip netns exec P iptables -F) a probéieren de Generator Bitrate op 100 Mbit / s ze erhéijen. Den Analyser mellt eng Rëtsch CC Feeler an ongeféier 75 Mbit/s amplaz vun 100. Mir probéieren erauszefannen wien d'Schold ass - de Generator hält net mat oder de Problem ass net dran, fir dëst ze maachen fänken mir un eng generéieren fix Zuel vu Paketen (700000 TS Pakete = 100000 IP Pakete):
# ifconfig veth0 | grep TX
TX packets 151825460 bytes 205725459268 (191.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# tsp -I craft -c 700000 -P regulate -b 100000000 -P count -O ip -p 7 -e --local-port 6000 239.0.0.1:1234
* count: PID 0 (0x0000): 700,000 packets
# ifconfig veth0 | grep TX
TX packets 151925460 bytes 205861259268 (191.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Wéi Dir gesitt, sinn genee 100000 IP Pakete generéiert (151925460-151825460). Also mir erausfannen wat mam Analysator geschitt, fir dëst ze maachen, kontrolléiere mir mam RX Konter op veth1, et ass strikt gläich wéi den TX Konter op veth0, da kucke mir wat um Socketniveau geschitt:
# ip netns exec P cat /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
133: 010000EF:04D2 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 72338 2 00000000e0a441df 24355 Hei kënnt Dir d'Zuel vun den Drëpsen gesinn = 24355. An TS Paketen ass dëst 170485 oder 24.36% vun 700000, sou datt mir gesinn datt déi selwecht 25% vun der verluerene Bitrate Drëpsen am UDP Socket sinn. Drops op engem UDP Socket geschéien normalerweis wéinst engem Manktem u Puffer, loosst eis kucken wat d'Standard Socket Puffer Gréisst an déi maximal Socket Puffer Gréisst sinn:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Also, wann Uwendungen net explizit d'Puffergréisst ufroen, ginn Sockets mat engem 208 KB-Puffer erstallt, awer wa se méi froen, kréien se ëmmer nach net wat se gefrot hunn. Well an tsp kënnt Dir d'Puffergréisst fir IP-Input (--Puffer-Gréisst) setzen, wäerte mir d'Standard Socketgréisst net beréieren, awer nëmmen déi maximal Socket-Puffergréisst setzen an d'Puffergréisst explizit duerch d'tsp Argumenter spezifizéieren:
sysctl net.core.rmem_max=8388608
ip netns exec P tsp --realtime -t -I ip 239.0.0.1:1234 -b 8388608 -P continuity -P bitrate_monitor -p 1 -t 1 -O dropMat dëser Ofstëmmung vum Socket-Puffer ass de gemellt Bitrate elo ongeféier 100Mbps, et gi keng CC Feeler.
Baséiert op CPU Konsum vun der tsp Applikatioun selwer. Betreffend ee Kär i5-4260U CPU @ 1.40GHz, fir en 10Mbit/s Flow ze analyséieren, wäert 3-4% vun der CPU erfuerderlech sinn, 100Mbit/s - 25%, 200Mbit/s - 46%. Wann Dir % Paketverloscht setzt, erhéicht d'CPU Belaaschtung praktesch net (awer kann erofgoen).
Op méi produktiv Hardware war et méiglech Streams vu méi wéi 1Gb / s ouni Probleemer ze generéieren an ze analyséieren.
Testen op real Netzwierkkaarten
Nodeems Dir op engem Veth Pair getest hutt, musst Dir zwee Hosten oder zwee Häfen vun engem Host huelen, d'Ports matenee verbannen, de Generator op engem lafen, an den Analyser op der zweeter. Et waren keng Iwwerraschungen hei, awer tatsächlech hänkt alles vun der Hardware of, wat méi schwaach et ass, wat méi interessant et hei wäert sinn.
Benotzt déi kritt Donnéeën vum Iwwerwaachungssystem (Zabbix)
tsp huet keng Maschinn liesbar API wéi SNMP oder ähnlech. CC Messagen mussen op d'mannst 1 Sekonn gläichzäiteg aggregéiert ginn (mat engem héije Prozentsaz vu Paketverloscht kann et Honnerte / Dausende / Zéngdausende pro Sekonn sinn, ofhängeg vum Bitrate).
Also, fir Informatioun ze späicheren a Grafike fir CC Feeler a Bitrate ze zéien an eng Aart Accident weider ze maachen, kënnen et déi folgend Optiounen sinn:
- Parse an aggregéiert (duerch CC) den Tsp Output, d.h. transforméiert et an déi gewënscht Form.
- Füügt den Tsp selwer an / oder d'Bitrate_monitor a Kontinuitéitsprozessor Plugins sou datt d'Resultat an enger Maschinn liesbar Form ausgëtt, déi gëeegent ass fir den Iwwerwaachungssystem.
- Schreift Är Uwendung uewen op der tsduck Bibliothéik.
Selbstverständlech, wat d'Aarbechtskäschte ugeet, ass d'Optioun 1 déi einfachst, besonnesch wann Dir bedenkt datt den tsduck selwer an enger niddereger Niveau (no modernen Normen) Sprooch (C++) geschriwwe gëtt.
En einfache Prototyp vun engem Parser + Aggregator am Bash huet gewisen datt bei engem Floss vun 10 Mbit / s an 50% Paketverloscht (schlëmmste Fall), de Bash-Prozess 3-4 Mol méi CPU verbraucht wéi den tsp Prozess selwer. Dëst Szenario ass inakzeptabel. Eigentlech ass e Stéck vun dësem Prototyp hei ënnen
Nuddelen op Basha
#!/usr/bin/env bash
missingPackets=0
ccErrorSeconds=0
regexMissPackets='^* (.+) - continuity:.*missing ([0-9]+) packets$'
missingPacketsTime=""
ip netns exec P tsp --realtime -t -I ip -b 8388608 "239.0.0.1:1234" -O drop -P bitrate_monitor -p 1 -t 1 -P continuity 2>&1 |
while read i
do
#line example:* 2019/12/28 23:41:14 - continuity: packet index: 6,078, PID: 0x0100, missing 5 packets
#line example 2: * 2019/12/28 23:55:11 - bitrate_monitor: 2019/12/28 23:55:11, TS bitrate: 4,272,864 bits/s
if [[ "$i" == *continuity:* ]]
then
if [[ "$i" =~ $regexMissPackets ]]
then
missingPacketsTimeNew="${BASH_REMATCH[1]}" #timestamp (seconds)
if [[ "$missingPacketsTime" != "$missingPacketsTimeNew" ]] #new second with CC error
then
((ccErrorSeconds += 1))
fi
missingPacketsTime=$missingPacketsTimeNew
packets=${BASH_REMATCH[2]} #TS missing packets
((missingPackets += packets))
fi
elif [[ "$i" == *bitrate_monitor:* ]]
then
: #...
fi
doneZousätzlech zu der Tatsaach, datt dëst inakzeptabel lues funktionnéiert, ginn et keng normal Threads am Bash, Bash Jobs sinn onofhängeg Prozesser an ech hunn de missingPackets Wäert eemol eng Sekonn op der Säit Effekt schreiwen (wann ech Bitrate Messagen kréien, déi all Sekonn kommen). Als Resultat gouf de Bash eleng gelooss an et gouf decidéiert e Wrapper (Parser + Aggregator) a Golang ze schreiwen. De CPU Konsum vun ähnlechen Code am Golang ass 4-5 Mol manner wéi den tsp Prozess selwer. D'Beschleunegung vum Wrapper andeems de Bash duerch Golang ersat gouf war ongeféier 16 Mol an allgemeng ass d'Resultat akzeptabel (CPU Overhead ëm 25% am schlëmmste Fall). D'golang Quelldatei ass lokaliséiert .
Lancéiere vun der Wrapper
Fir de Wrapper ze starten, gouf eng einfach Service Template fir systemd gemaach (). Et gëtt ugeholl datt de Wrapper selwer an eng binär Datei kompiléiert ass (go build tsduck-stat.go), an /opt/tsduck-stat/. Et gëtt ugeholl datt Golang mat monotonescher Auerunterstëtzung benotzt gëtt (>= 1.9).
Fir eng Serviceinstanz ze kreéieren musst Dir de Systemctl Enable Kommando ausféieren [Email geschützt]:1234, lafen dann mat systemctl Start [Email geschützt]: 1234.
Entdeckung vun Zabbix
Also datt zabbix eng Entdeckung vu lafende Servicer maache kann, (discovery.sh), am Format erfuerderlech fir Zabbix Entdeckung, gëtt ugeholl datt et op der selwechter Plaz läit - an /opt/tsduck-stat. Fir Entdeckung iwwer zabbix-Agent ze lafen, musst Dir derbäi an den Dossier mat zabbix-Agent Konfiguratiounen fir e Benotzerparameter ze addéieren.
Zabbix Schabloun
(tsduck_stat_template.xml) enthält d'Autodiscovery Regel, Element, Grafik an Ausléiser Prototypen.
Eng kuerz Checklëscht (wat wann een decidéiert se ze benotzen)
- Vergewëssert Iech datt d'Tsp net Päckchen ënner "idealen" Konditiounen fällt (de Generator an den Analyser sinn direkt ugeschloss), wann et Drëpsen ass, kuckt de Punkt 2 oder den Text vum Artikel iwwer dës Matière.
- Maacht Tuning vum maximalen Socketbuffer (net.core.rmem_max = 8388608).
- Kompiléiert tsduck-stat.go (goen bauen tsduck-stat.go).
- Place de Service Template an /lib/systemd/system.
- Start Servicer mat Systemctl, kontrolléiert datt d'Zähler ugefaang hunn ze erschéngen (grep "" /dev/shm/tsduck-stat/*). Zuel vu Servicer no Zuel vu Multicast Streams. Hei musst Dir vläicht e Wee fir de Multicast-Grupp erstellen, vläicht rp_filter deaktivéieren oder e Wee op d'Quell-IP erstellen.
- Run discovery.sh, gitt sécher datt et json generéiert.
- Plaz den Zabbix Agent Config, start den Zabbix Agent nei.
- Eroplueden d'Schabloun op zabbix, gëllen se op den Host, op deem d'Iwwerwaachung duerchgefouert gëtt an den Zabbix-Agent installéiert ass, waart ongeféier 5 Minutten, kuckt datt nei Datenelementer, Grafiken an Ausléiser erscheinen.
Resultat
Fir d'Aufgab fir Paketverloscht z'identifizéieren ass et bal genuch, op d'mannst ass et besser wéi keng Iwwerwaachung.
Tatsächlech kënnen CC "Verloschter" geschéien wann Dir Videofragmenter splizéiert (souwäit ech weess, dat ass wéi Inserts op lokalen Fernsehzentren an der russescher Federatioun gemaach ginn, dh ouni den CC-Zähler nei ze berechnen), dëst muss erënnert ginn. A propriétaire Léisungen gëtt dëse Problem deelweis ëmgoen andeems SCTE-35 Tags z'entdecken (wann se vum Streamgenerator bäigefüügt ginn).
Aus der Siicht vun der Transportqualitéit Iwwerwaachung ass d'Jitter Iwwerwaachung (IAT) net genuch, well Fernsehgeräter (egal ob Modulatoren oder Endgeräter) hunn Ufuerderunge fir dëse Parameter an et ass net ëmmer méiglech den Jitbuffer onbestëmmt opzebauen. A Jitter ka schwammen wann Transit Ausrüstung mat grousse Puffer benotzt an QoS net konfiguréiert ass oder net gutt genuch konfiguréiert ass fir sou Echtzäitverkéier ze vermëttelen.
Source: will.com