Heddiw, mae yna atebion parod (perchnogol) ar gyfer monitro ffrydiau IP(TS), er enghraifft ΠΈ , mae ganddynt set eithaf cyfoethog o swyddogaethau ac fel arfer mae gan weithredwyr mawr sy'n delio Γ’ gwasanaethau teledu atebion o'r fath. Mae'r erthygl hon yn disgrifio datrysiad sy'n seiliedig ar brosiect ffynhonnell agored , wedi'i gynllunio ar gyfer rheolaeth fach iawn ar ffrydiau IP(TS) gan gownter a chyfradd didau CC (cownter parhad). Cymhwysiad posibl yw rheoli colli pecynnau neu'r llif cyfan trwy sianel L2 ar brydles (na ellir ei monitro'n normal, er enghraifft, trwy ddarllen cownteri colled mewn ciwiau).
Yn fyr iawn am TSDuck
Mae TSDuck yn feddalwedd ffynhonnell agored (trwydded 2-Gymal BSD) (set o gyfleustodau consol a llyfrgell ar gyfer datblygu cyfleustodau neu ategion personol) ar gyfer trin ffrydiau TS. Fel mewnbwn, gall weithio gyda IP (multicast/unicast), http, hls, tuners dvb, dektec dvb-asi demodulator, mae generadur TS-ffrwd mewnol a darllen o ffeiliau. Gall yr allbwn fod yn ysgrifennu i ffeil, IP (aml-ddarllediad/unicast), hls, modulatyddion dektec dvb-asi a HiDes, chwaraewyr (mplayer, vlc, xine) a drop. Gellir cynnwys proseswyr traffig amrywiol rhwng mewnbwn ac allbwn, er enghraifft, ailfapio PID, sgramblo / dadsgramblo, dadansoddiad cownter CC, cyfrifo cyfradd didau, a gweithrediadau nodweddiadol eraill ar gyfer ffrydiau TS.
Yn yr erthygl hon, bydd ffrydiau IP (aml-ddarllediad) yn cael eu defnyddio fel mewnbwn, defnyddir y proseswyr bitrate_monitor (o'r enw mae'n amlwg beth ydyw) a pharhad (dadansoddiad o gownteri CC). Gallwch chi yn hawdd ddisodli IP multicast gyda math mewnbwn arall a gefnogir gan TSDuck.
Ar gael TSDuck ar gyfer y rhan fwyaf o systemau gweithredu cyfredol. Nid ydynt ar gael ar gyfer Debian, ond fe wnaethom lwyddo i'w hadeiladu o dan debian 8 a debian 10 heb unrhyw broblemau.
Nesaf, defnyddir fersiwn TSDuck 3.19-1520, defnyddir Linux fel yr OS (defnyddiwyd debian 10 i baratoi'r datrysiad, defnyddiwyd CentOS 7 i'w ddefnyddio go iawn)
Paratoi TSDuck ac OS
Cyn monitro llifoedd go iawn, mae angen i chi sicrhau bod TSDuck yn gweithio'n gywir ac nad oes unrhyw ddiferion ar lefel cerdyn rhwydwaith neu OS (soced). Mae hyn yn ofynnol er mwyn peidio Γ’ dyfalu yn ddiweddarach lle digwyddodd y diferion - ar y rhwydwaith neu "y tu mewn i'r gweinydd". Gallwch wirio diferion ar lefel y cerdyn rhwydwaith gyda'r gorchymyn ethtool -S ethX, mae tiwnio yn cael ei wneud gan yr un ethtool (fel arfer, mae angen i chi gynyddu'r byffer RX (-G) ac weithiau analluogi rhai dadlwythiadau (-K)). Fel argymhelliad cyffredinol, gellir ei gynghori i ddefnyddio porthladd ar wahΓ’n ar gyfer derbyn y traffig a ddadansoddwyd, os yn bosibl, mae hyn yn lleihau'r positifau ffug sy'n gysylltiedig Γ’'r ffaith bod y gostyngiad wedi digwydd yn union ar y porthladd dadansoddwr oherwydd presenoldeb traffig arall. Os nad yw hyn yn bosibl (defnyddir cyfrifiadur mini / NUC gydag un porthladd), yna mae'n ddymunol iawn sefydlu blaenoriaethu'r traffig a ddadansoddwyd mewn perthynas Γ’ gweddill y ddyfais y mae'r dadansoddwr wedi'i gysylltu Γ’ hi. O ran amgylcheddau rhithwir, yma mae angen i chi fod yn ofalus a gallu dod o hyd i ddiferion pecynnau yn dechrau o borthladd ffisegol ac yn gorffen gyda chymhwysiad y tu mewn i beiriant rhithwir.
Cynhyrchu a derbyn nant y tu mewn i'r gwesteiwr
Fel cam cyntaf wrth baratoi TSDuck, byddwn yn cynhyrchu ac yn derbyn traffig o fewn un gwesteiwr gan ddefnyddio netns.
Paratoi'r amgylchedd:
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 Π² ΡΡΠΎΡΠΎΠ½Ρ veth0Mae'r amgylchedd yn barod. Rydyn ni'n dechrau'r dadansoddwr traffig:
ip netns exec P tsp --realtime -t
-I ip 239.0.0.1:1234
-P continuity
-P bitrate_monitor -p 1 -t 1
-O droplle mae "-p 1 -t 1" yn golygu bod angen i chi gyfrifo'r gyfradd didau bob eiliad ac arddangos gwybodaeth am y gyfradd didau bob eiliad
Rydym yn cychwyn y generadur traffig gyda chyflymder o 10Mbps:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234lle mae "-p 7 -e" yn golygu bod angen i chi bacio 7 pecyn TS i mewn i becyn 1 IP a'i wneud yn galed (-e), h.y. arhoswch bob amser 7 pecyn TS o'r prosesydd olaf cyn anfon pecyn IP.
Mae'r dadansoddwr yn dechrau allbynnu'r negeseuon disgwyliedig:
* 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/sNawr ychwanegwch rai diferion:
ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROPac mae negeseuon fel hyn yn ymddangos:
* 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 a ddisgwylir. Analluogi colled pecyn (ip netns exec P iptables -F) a cheisiwch gynyddu cyfradd didau'r generadur i 100Mbps. Mae'r dadansoddwr yn adrodd criw o wallau CC a thua 75 Mbps yn lle 100. Rydym yn ceisio darganfod pwy sydd ar fai - nid oes gan y generadur amser neu nid yw'r broblem ynddo, ar gyfer hyn rydym yn dechrau cynhyrchu nifer sefydlog o pecynnau (700000 o becynnau TS = 100000 o becynnau IP):
# 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 0Fel y gallwch weld, cynhyrchwyd union 100000 o becynnau IP (151925460-151825460). Felly gadewch i ni ddarganfod beth sy'n digwydd gyda'r dadansoddwr, ar gyfer hyn rydym yn gwirio gyda'r cownter RX ar veth1, mae'n hollol gyfartal Γ’'r cownter TX ar veth0, yna edrychwn ar yr hyn sy'n digwydd ar lefel y soced:
# 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 Yma gallwch weld nifer y diferion = 24355. Mewn pecynnau TS, mae hyn yn 170485 neu 24.36% o 700000, felly rydym yn gweld bod yr un 25% o'r bitrate a gollwyd yn diferion yn y soced udp. Mae diferion mewn soced CDU yn digwydd fel arfer oherwydd diffyg byffer, edrychwch ar faint byffer y soced rhagosodedig ac uchafswm maint byffer y soced:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Felly, os nad yw ceisiadau'n gofyn yn benodol am faint byffer, mae socedi'n cael eu creu gyda byffer o 208 KB, ond os ydyn nhw'n gofyn am fwy, ni fyddant yn derbyn yr hyn y gofynnwyd amdano o hyd. Gan y gallwch chi osod maint y byffer mewn tsp ar gyfer y mewnbwn IP (-buffer-size), ni fyddwn yn cyffwrdd Γ’ maint y soced rhagosodedig, ond dim ond gosod maint clustogi uchafswm y soced a nodi maint y byffer yn benodol trwy'r dadleuon tsp:
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 dropGyda'r tiwnio hwn o'r byffer soced, nawr mae'r gyfradd did a adroddir tua 100Mbps, nid oes unrhyw wallau CC.
Yn Γ΄l y defnydd CPU y cais tsp ei hun. O'i gymharu ag un craidd i5-4260U CPU @ 1.40GHz, bydd angen dadansoddiad llif 10Mbps 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%. Wrth osod y % Colled Pecyn, yn ymarferol nid yw'r llwyth ar y CPU yn cynyddu (ond gall leihau).
Ar galedwedd mwy cynhyrchiol, roedd yn bosibl cynhyrchu a dadansoddi ffrydiau o fwy na 1Gb / s heb unrhyw broblemau.
Profi ar gardiau rhwydwaith go iawn
Ar Γ΄l profi ar veth pair, mae angen i chi gymryd dau westeiwr neu ddau borthladd un gwesteiwr, cysylltu'r porthladdoedd Γ’'i gilydd, cychwyn y generadur ar un, a'r dadansoddwr ar yr ail. Nid oedd unrhyw syndod yma, ond mewn gwirionedd mae'r cyfan yn dibynnu ar yr haearn, y gwannach, y mwyaf diddorol fydd yma.
Defnyddio'r data a dderbyniwyd gan y system fonitro (Zabbix)
Nid oes gan tsp unrhyw API y gellir ei ddarllen gan beiriant fel SNMP neu debyg. Rhaid agregu negeseuon CC am o leiaf 1 eiliad (gyda chanran uchel o golled pecynnau, gall fod cannoedd/miloedd/degau o filoedd yr eiliad, yn dibynnu ar y gyfradd didau).
Felly, er mwyn arbed gwybodaeth a llunio graffiau ar gyfer gwallau CC a bitrate a gwneud rhyw fath o ddamweiniau, efallai y bydd yr opsiynau canlynol:
- Dosrannu ac agregu (yn Γ΄l CC) allbwn tsp, h.y. ei drosi i'r ffurf a ddymunir.
- Gorffen tsp ei hun a/neu ategion prosesydd bitrate_monitor a pharhad fel bod y canlyniad yn cael ei roi ar ffurf y gellir ei darllen gan beiriant sy'n addas ar gyfer y system fonitro.
- Ysgrifennwch eich cais ar ben y llyfrgell tsduck.
Yn amlwg, opsiwn 1 yw'r hawsaf o ran ymdrech, yn enwedig o ystyried bod tsduck ei hun wedi'i ysgrifennu mewn iaith lefel isel (yn Γ΄l safonau modern) (C ++)
Dangosodd prototeip syml parser + agregydd bash, ar ffrwd 10Mbps a cholled pecyn o 50% (yr achos gwaethaf), bod y broses bash yn defnyddio 3-4 gwaith yn fwy o CPU na'r broses tsp ei hun. Mae'r senario hwn yn annerbyniol. Mewn gwirionedd darn o'r prototeip hwn isod
Nwdls ar y top
#!/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
doneYn ogystal Γ’ bod yn annerbyniol o araf, nid oes unrhyw edafedd arferol mewn bash, mae swyddi bash yn brosesau ar wahΓ’n ac roedd yn rhaid i mi ysgrifennu gwerth Pecynau ar goll unwaith yr eiliad ar yr effaith ochr (wrth dderbyn negeseuon bitrate sy'n dod bob eiliad). O ganlyniad, gadawyd llonydd i bash a phenderfynwyd ysgrifennu papur lapio (parser + aggregator) mewn golang. Mae defnydd CPU o god golang tebyg 4-5 gwaith yn llai na'r broses tsp ei hun. Trodd cyflymdra'r papur lapio o ganlyniad i amnewid bash gyda golang tua 16 gwaith ac yn gyffredinol mae'r canlyniad yn dderbyniol (CPU uwchben o 25% yn yr achos gwaethaf). Lleolir y ffeil ffynhonnell golang .
Rhedeg papur lapio
I gychwyn y papur lapio, gwnaed y templed gwasanaeth symlaf ar gyfer systemd (). Mae'r papur lapio ei hun i fod i gael ei lunio mewn ffeil ddeuaidd (ewch adeiladu tsduck-stat.go) wedi'i leoli yn /opt/tsduck-stat/. Tybir eich bod yn defnyddio golang gyda chefnogaeth ar gyfer cloc monotonig (>=1.9).
I greu enghraifft o'r gwasanaeth, mae angen i chi redeg y gorchymyn galluogi systemctl [e-bost wedi'i warchod]:1234 yna rhedeg gyda systemctl cychwyn [e-bost wedi'i warchod]: 1234.
Darganfod o Zabbix
Er mwyn i zabbix allu darganfod rhedeg gwasanaethau, mae'n cael ei wneud (discovery.sh), yn y fformat sy'n ofynnol ar gyfer darganfyddiad Zabbix, rhagdybir ei fod wedi'i leoli yn yr un lle - yn /opt/tsduck-stat. I redeg darganfyddiad trwy zabbix-agent, mae angen i chi ychwanegu i'r cyfeiriadur cyfluniad zabbix-agent i ychwanegu'r paramedr defnyddiwr.
Templed Zabbix
(tsduck_stat_template.xml) yn cynnwys y rheol autodarganfod, prototeipiau eitem, graffiau, a sbardunau.
Rhestr wirio gryno (wel, beth os bydd rhywun yn penderfynu ei ddefnyddio)
- Gwnewch yn siΕ΅r nad yw tsp yn gollwng pecynnau o dan amodau "delfrydol" (mae generadur a dadansoddwr wedi'u cysylltu'n uniongyrchol), os oes diferion, gweler paragraff 2 neu destun yr erthygl ar y mater hwn.
- Gwnewch diwnio'r byffer soced uchaf (net.core.rmem_max=8388608).
- Llunio tsduck-stat.go (ewch adeiladu tsduck-stat.go).
- Rhowch y templed gwasanaeth yn /lib/systemd/system.
- Cychwyn gwasanaethau gyda systemctl, gwiriwch fod cownteri wedi dechrau ymddangos (grep "" /dev/shm/tsduck-stat/*). Nifer y gwasanaethau yn Γ΄l nifer y ffrydiau aml-ddarlledu. Yma efallai y bydd angen i chi greu llwybr i'r grΕ΅p aml-ddarlledwr, efallai analluogi rp_filter neu greu llwybr i'r ip ffynhonnell.
- Rhedeg discovery.sh, gwnewch yn siΕ΅r ei fod yn cynhyrchu json.
- Ychwanegu config asiant zabbix, ailgychwyn asiant zabbix.
- Llwythwch y templed i zabbix, cymhwyswch ef i'r gwesteiwr sy'n cael ei fonitro a gosodir yr asiant zabbix, arhoswch tua 5 munud, gweld a oes eitemau, graffiau a sbardunau newydd.
Canlyniad
Ar gyfer y dasg o ganfod colled pecyn, mae bron yn ddigon, o leiaf mae'n well na dim monitro.
Yn wir, gall βcolledionβ CC ddigwydd wrth uno darnau fideo (hyd y gwn i, dyma sut mae mewnosodiadau yn cael eu gwneud mewn canolfannau teledu lleol yn Ffederasiwn Rwsia, hy heb ailgyfrifo'r cownter CC), rhaid cofio hyn. Mae datrysiadau perchnogol yn rhannol yn osgoi'r broblem hon trwy ganfod labeli SCTE-35 (os ychwanegir gan y generadur ffrwd).
O ran monitro ansawdd trafnidiaeth, mae diffyg monitro jitter (IAT). Mae gan offer teledu (boed yn fodiwleiddwyr neu ddyfeisiau terfynol) ofynion ar gyfer y paramedr hwn ac nid yw bob amser yn bosibl chwyddo'r jitbuffer i anfeidredd. A gall jitter arnofio pan ddefnyddir offer gyda byfferau mawr wrth eu cludo ac nad yw QoS wedi'i ffurfweddu neu heb ei ffurfweddu'n ddigon da i drosglwyddo traffig amser real o'r fath.
Ffynhonnell: hab.com