Í dag eru til tilbúnar (eiginlegar) lausnir til að fylgjast með IP(TS) straumum, til dæmis и , þeir hafa nokkuð ríka eiginleika og venjulega hafa stórir símafyrirtæki sem fást við sjónvarpsþjónustu slíkar lausnir. Þessi grein lýsir lausn sem byggir á opnum hugbúnaði , hannað fyrir lágmarksstýringu á IP(TS) straumum með CC(continuity counter) teljara og bitahraða. Hugsanlegt forrit er að stjórna tapi pakka eða öllu flæðinu í gegnum leigða L2 rás (sem ekki er hægt að fylgjast með á venjulegan hátt, til dæmis með því að lesa tapteljara í biðröðum).
Mjög stuttlega um TSDuck
TSDuck er opinn uppspretta (2-liðar BSD leyfi) hugbúnaður (sett af leikjatölvum og bókasafni til að þróa sérsniðin tól eða viðbætur) til að vinna með TS strauma. Sem inntak getur það virkað með IP (multicast/unicast), http, hls, dvb tuners, dektec dvb-asi demodulator, það er innri TS stream rafall og lestur úr skrám. Úttakið getur verið að skrifa á skrá, IP (multicast/unicast), hls, dektec dvb-asi og HiDes mótara, spilara (mplayer, vlc, xine) og falla. Þú getur virkjað ýmsa umferðargjörva á milli inntaks og úttaks, til dæmis PID endurkortun, spæna / afrugla, CC teljaragreiningu, bitahraðaútreikninga og aðrar dæmigerðar aðgerðir fyrir TS strauma.
Í þessari grein verða IP straumar (multicast) notaðir sem inntak, örgjörvarnir bitrate_monitor (af nafninu er ljóst hvað það er) og samfella (greining á CC teljara). Þú getur auðveldlega skipt út IP multicast fyrir aðra inntakstegund sem studd er af TSDuck.
Það eru TSDuck fyrir flest núverandi stýrikerfi. Þeir eru ekki fáanlegir fyrir Debian, en okkur tókst að smíða þá undir debian 8 og debian 10 án vandræða.
Næst er útgáfa TSDuck 3.19-1520 notuð, Linux er notað sem stýrikerfi (debian 10 var notað til að undirbúa lausnina, CentOS 7 var notað til raunverulegrar notkunar)
Undirbúningur TSDuck og OS
Áður en þú fylgist með raunverulegu flæði þarftu að ganga úr skugga um að TSDuck virki rétt og að það séu engir dropar á netkorti eða stýrikerfi (socket) stigi. Þetta er nauðsynlegt til að giska ekki á síðar hvar fallin áttu sér stað - á netinu eða „inni á netþjóninum“. Þú getur athugað fall á netkortastigi með ethtool -S ethX skipuninni, stilling er gerð með sama ethtool (venjulega þarftu að auka RX biðminni (-G) og stundum slökkva á sumum afhleðslum (-K)). Sem almenn ráðlegging er hægt að ráðleggja að nota sérstakt tengi til að taka á móti greindri umferð, ef mögulegt er, þetta lágmarkar rangar jákvæðar niðurstöður sem tengjast því að fallið átti sér stað nákvæmlega á greiningargáttinni vegna tilvistar annarrar umferðar. Ef þetta er ekki mögulegt (notuð er smátölva/NUC með einni tengi), þá er mjög æskilegt að setja upp forgangsröðun greindar umferðar miðað við restina á tækinu sem greiningartækið er tengt við. Varðandi sýndarumhverfi, hér þarftu að vera varkár og geta fundið pakkadropa sem byrjar frá líkamlegri höfn og endar með forriti inni í sýndarvél.
Myndun og móttaka á straumi innan hýsilsins
Sem fyrsta skref í að undirbúa TSDuck munum við búa til og taka á móti umferð innan eins gestgjafa með netns.
Undirbúningur umhverfisins:
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 в сторону veth0Umhverfið er tilbúið. Við ræsum umferðargreiningartækið:
ip netns exec P tsp --realtime -t
-I ip 239.0.0.1:1234
-P continuity
-P bitrate_monitor -p 1 -t 1
-O dropþar sem "-p 1 -t 1" þýðir að þú þarft að reikna bitahraðann á hverri sekúndu og birta upplýsingar um bitahraðann á hverri sekúndu
Við ræsum umferðargjafann með 10Mbps hraða:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234þar sem "-p 7 -e" þýðir að þú þarft að pakka 7 TS pakka í 1 IP pakka og gera það erfitt (-e), þ.e. bíddu alltaf 7 TS pakka frá síðasta örgjörva áður en þú sendir IP pakka.
Greiningartækið byrjar að gefa út væntanleg skilaboð:
* 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/sBættu nú við nokkrum dropum:
ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROPog skilaboð eins og þessi birtast:
* 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 sem gert er ráð fyrir. Slökktu á pakkatapinu (ip netns exec P iptables -F) og reyndu að auka rafallbitahraðann í 100Mbps. Greiningartækið tilkynnir fullt af CC villum og um 75 Mbps í stað 100. Við erum að reyna að finna út hverjum er um að kenna - rafallinn hefur ekki tíma eða vandamálið er ekki í honum, til þess byrjum við að búa til fastan fjölda af pakkar (700000 TS pakkar = 100000 IP pakkar):
# 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 0Eins og þú sérð voru nákvæmlega 100000 IP pakkar búnir til (151925460-151825460). Svo við skulum reikna út hvað er að gerast með greiningartækið, fyrir þetta athugum við með RX teljarann á veth1, hann er nákvæmlega jafn TX teljarinn á veth0, þá lítum við á hvað gerist á falsstigi:
# 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 Hér geturðu séð fjölda dropa = 24355. Í TS pökkum er þetta 170485 eða 24.36% af 700000, þannig að við sjáum að þessi sömu 25% af tapaða bitahraða eru dropar í udp falsinu. Fall í UDP fals eiga sér stað venjulega vegna skorts á biðminni, skoðaðu sjálfgefna innstungustærð og hámarksstærð fals biðminni:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Þannig, ef forrit biðja ekki beinlínis um biðminni stærð, eru falsar búnar til með biðminni upp á 208 KB, en ef þeir biðja um meira, munu þeir samt ekki fá það sem beðið var um. Þar sem þú getur stillt biðminni í tsp fyrir IP-inntakið (-buffer-size), munum við ekki snerta sjálfgefna falsstærð, heldur aðeins stilla hámarksstærð fals biðminni og tilgreina biðminni sérstaklega í gegnum tsp rökin:
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 dropMeð þessari stillingu á socket biðminni, nú er tilkynntur bitahraði um 100Mbps, það eru engar CC villur.
Samkvæmt CPU neyslu tsp forritsins sjálfs. Miðað við einn kjarna i5-4260U örgjörva @ 1.40GHz mun 10Mbps flæðisgreining þurfa 3-4% örgjörva, 100Mbps - 25%, 200Mbps - 46%. Þegar þú stillir % Packet Loss eykst álagið á CPU nánast ekki (en gæti minnkað).
Á afkastameiri vélbúnaði var hægt að búa til og greina strauma meira en 1Gb / s án vandræða.
Prófanir á alvöru netkortum
Eftir að hafa prófað á veth pari þarftu að taka tvær vélar eða tvær tengi af einum hýsil, tengja tengin við hvert annað, ræsa rafallinn á annarri og greiningartækið á hinni. Hér kom ekkert á óvart, en í raun veltur þetta allt á járninu, því veikara, því áhugaverðara verður það hér.
Notkun móttekinna gagna af vöktunarkerfinu (Zabbix)
tsp er ekki með nein véllesanleg API eins og SNMP eða álíka. CC-skilaboð verða að vera samanlögð í að minnsta kosti 1 sekúndu (með háu hlutfalli pakkataps geta það orðið hundruðir/þúsundir/tugþúsundir á sekúndu, allt eftir bitahraða).
Þannig að til að vista bæði upplýsingar og teikna línurit fyrir CC villur og bitahraða og gera einhvers konar slys, gætu eftirfarandi valkostir verið til staðar:
- Þekkja og safna saman (með CC) framleiðslu tsk, þ.e. breyttu því í það form sem þú vilt.
- Ljúktu við tsp sjálft og/eða örgjörvaviðbætur bitrate_monitor og continuity þannig að niðurstaðan sé gefin upp á véllesanlegu formi sem hentar eftirlitskerfinu.
- Skrifaðu umsókn þína ofan á tsduck bókasafnið.
Augljóslega er valkostur 1 auðveldasti hvað varðar fyrirhöfn, sérstaklega með hliðsjón af því að tsduck sjálft er skrifað á lágu stigi (samkvæmt nútíma stöðlum) tungumáli (C ++)
Einföld bash parser+aggregator frumgerð sýndi að á 10Mbps straumi og 50% pakkatapi (í versta falli), neytti bash ferlið 3-4 sinnum meiri örgjörva en tsp ferlið sjálft. Þessi atburðarás er óviðunandi. Reyndar hluti af þessari frumgerð hér að neðan
Núðlur á toppnum
#!/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
doneAuk þess að vera óviðunandi hægur eru engir venjulegir þræðir í bash, bash störf eru aðskilin ferli og ég þurfti að skrifa gildi missingPackets einu sinni á sekúndu á aukaverkunina (þegar ég fékk bitahraðaskilaboð sem koma á hverri sekúndu). Fyrir vikið var bash látinn í friði og ákveðið var að skrifa umbúðir (þáttur + samansafn) í golang. Örgjörvanotkun á svipuðum golang kóða er 4-5 sinnum minni en tsp ferlið sjálft. Hraði umbúðirnar vegna þess að bash var skipt út fyrir golang reyndist vera um það bil 16 sinnum og almennt er niðurstaðan ásættanleg (CPU kostnaður um 25% í versta falli). Golang frumskráin er staðsett .
Hlaupa umbúðir
Til að ræsa umbúðirnar var einfaldasta þjónustusniðmátið fyrir systemd búið til (). Umbúðirnar sjálfar eiga að vera settar saman í tvíundarskrá (farðu að byggja tsduck-stat.go) sem er staðsett í /opt/tsduck-stat/. Gert er ráð fyrir að þú notir golang með stuðningi fyrir eintóna klukku (>=1.9).
Til að búa til tilvik af þjónustunni þarftu að keyra systemctl enable skipunina [netvarið]:1234 keyrðu síðan með systemctl start [netvarið]: 1234.
Uppgötvun frá Zabbix
Til þess að zabbix geti uppgötvað hlaupandi þjónustu er það gert (discovery.sh), á því sniði sem krafist er fyrir Zabbix uppgötvun, er gert ráð fyrir að það sé staðsett á sama stað - í /opt/tsduck-stat. Til að keyra uppgötvun í gegnum zabbix-agent þarftu að bæta við í zabbix-agent stillingaskrána til að bæta við notandafæribreytunni.
Zabbix sniðmát
(tsduck_stat_template.xml) inniheldur sjálfvirka uppgötvunarregluna, frumgerðir hluta, línurit og kveikjur.
Stutt gátlisti (jæja, hvað ef einhver ákveður að nota hann)
- Gakktu úr skugga um að tsk falli ekki pakka við "tilvalin" aðstæður (rafall og greiningartæki eru tengd beint), ef það eru dropar, sjá lið 2 eða texta greinarinnar um þetta mál.
- Stilltu hámarks socket biðminni (net.core.rmem_max=8388608).
- Settu saman tsduck-stat.go (farðu að byggja tsduck-stat.go).
- Settu þjónustusniðmátið í /lib/systemd/system.
- Byrjaðu þjónustu með systemctl, athugaðu hvort teljarar séu farnir að birtast (grep "" /dev/shm/tsduck-stat/*). Fjöldi þjónustu eftir fjölda fjölvarpsstrauma. Hér gætir þú þurft að búa til leið að fjölvarpshópnum, kannski slökkva á rp_filter eða búa til leið að uppruna ip.
- Keyrðu discovery.sh, vertu viss um að það búi til json.
- Bættu við zabbix agent config, endurræstu zabbix agent.
- Hladdu upp sniðmátinu á zabbix, settu það á hýsilinn sem verið er að fylgjast með og zabbix-miðillinn er settur upp, bíddu í um það bil 5 mínútur, sjáðu hvort það eru nýir hlutir, línurit og kveikjur.
Niðurstaðan
Fyrir það verkefni að greina pakkatap er það næstum nóg, að minnsta kosti er það betra en ekkert eftirlit.
Reyndar getur „tap“ CC átt sér stað þegar myndbandsbrot eru sameinuð (eftir því sem ég best veit eru innsetningar gerðar á staðbundnum sjónvarpsstöðvum í Rússlandi, þ.e. án þess að endurreikna CC teljarann), þetta verður að hafa í huga. Sérlausnir sniðganga þetta vandamál að hluta með því að greina SCTE-35 merki (ef þeim er bætt við af straumgjafanum).
Hvað varðar vöktun flutningsgæða er skortur á jitter vöktun (IAT). Sjónvarpsbúnaður (hvort sem það er mótara eða endatæki) hefur kröfur um þessa breytu og það er ekki alltaf hægt að blása upp jitbufferinn út í það óendanlega. Og jitter getur fljótið þegar búnaður með stóra biðminni er notaður í flutningi og QoS er ekki stillt eða ekki nógu vel stillt til að senda slíka rauntímaumferð.
Heimild: www.habr.com