Mūsdienās ir gatavi (patentēti) risinājumi, piemēram, IP(TS) straumju uzraudzībai и , tiem ir diezgan bagātīgs funkciju komplekts, un parasti lielajiem operatoriem, kas nodarbojas ar TV pakalpojumiem, ir šādi risinājumi. Šajā rakstā ir aprakstīts risinājums, kura pamatā ir atvērtā pirmkoda projekts , kas paredzēts minimālai IP (TS) straumju kontrolei, izmantojot CC (nepārtrauktības skaitītāja) skaitītāju un bitu pārraides ātrumu. Iespējama lietojumprogramma ir kontrolēt pakešu vai visas plūsmas zudumu caur nomātu L2 kanālu (kuru nevar normāli uzraudzīt, piemēram, nolasot zaudējumu skaitītājus rindās).
Ļoti īsi par TSDuck
TSDuck ir atvērtā koda (2-Clause BSD licences) programmatūra (konsoles utilītu komplekts un bibliotēka pielāgotu utilītu vai spraudņu izstrādei) manipulēšanai ar TS straumēm. Kā ievade var strādāt ar IP (multicast/unicast), http, hls, dvb uztvērējiem, dektec dvb-asi demodulatoru, ir iekšējais TS-stream ģenerators un lasīšana no failiem. Izvade var būt rakstīšana failā, IP (multicast/unicast), hls, dektec dvb-asi un HiDes modulatori, atskaņotāji (mplayer, vlc, xine) un drop. Starp ievadi un izvadi var iekļaut dažādus trafika procesorus, piemēram, PID pārveidošanu, šifrēšanu / atšifrēšanu, CC skaitītāja analīzi, bitu pārraides ātruma aprēķināšanu un citas tipiskas darbības TS straumēm.
Šajā rakstā kā ievade tiks izmantotas IP straumes (multicast), procesori bitrate_monitor (pēc nosaukuma ir skaidrs, kas tas ir) un nepārtrauktība (CC skaitītāju analīze). Varat viegli aizstāt IP multiraidi ar citu ievades veidu, ko atbalsta TSDuck.
Tur ir TSDuck lielākajai daļai pašreizējo operētājsistēmu. Tie nav pieejami Debian, taču mums izdevās tos bez problēmām izveidot zem debian 8 un debian 10.
Tālāk tiek izmantota versija TSDuck 3.19-1520, kā operētājsistēma Linux (risinājuma sagatavošanai tika izmantots Debian 10, reālai lietošanai tika izmantota CentOS 7)
TSDuck un OS sagatavošana
Pirms reālo plūsmu pārraudzības jums jāpārliecinās, vai TSDuck darbojas pareizi un nav kritumu tīkla kartes vai OS (ligzdas) līmenī. Tas ir nepieciešams, lai vēlāk neuzminētu, kur notika kritumi - tīklā vai “servera iekšpusē”. Tīkla kartes līmeņa kritumus var pārbaudīt ar komandu ethtool -S ethX, regulēšanu veic tas pats ethtool (parasti jāpalielina RX buferis (-G) un dažreiz jāatspējo dažas izkraušanas (-K)). Kā vispārīgs ieteikums ir ieteicams izmantot atsevišķu portu analizētās trafika uztveršanai, ja iespējams, tādējādi samazinot viltus pozitīvos gadījumus, kas saistīti ar faktu, ka kritums notika tieši analizatora portā citas trafika klātbūtnes dēļ. Ja tas nav iespējams (tiek izmantots minidators/NUC ar vienu portu), ir ļoti vēlams iestatīt analizētās trafika prioritāti attiecībā pret pārējo ierīcē, kurai ir pievienots analizators. Runājot par virtuālajām vidēm, šeit jums jābūt uzmanīgiem un jāspēj atrast pakešu kritumus, sākot no fiziskā porta un beidzot ar lietojumprogrammu virtuālajā mašīnā.
Straumes ģenerēšana un uztveršana saimniekdatorā
Kā pirmais solis TSDuck sagatavošanā mēs ģenerēsim un saņemsim trafiku vienā resursdatorā, izmantojot netns.
Vides sagatavošana:
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 в сторону veth0Vide ir gatava. Mēs sākam satiksmes analizatoru:
ip netns exec P tsp --realtime -t
-I ip 239.0.0.1:1234
-P continuity
-P bitrate_monitor -p 1 -t 1
-O dropkur "-p 1 -t 1" nozīmē, ka jums ir jāaprēķina bitu pārraides ātrums katru sekundi un jāparāda informācija par bitu pārraides ātrumu katru sekundi
Mēs iedarbinām satiksmes ģeneratoru ar ātrumu 10Mbps:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234kur "-p 7 -e" nozīmē, ka jāiepako 7 TS paketes 1 IP paketē un jādara grūti (-e), t.i. vienmēr nogaidiet 7 TS paketes no pēdējā procesora, pirms nosūtāt IP paketi.
Analizators sāk izvadīt gaidītos ziņojumus:
* 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/sTagad pievienojiet dažus pilienus:
ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROPun parādās šādi ziņojumi:
* 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 kas ir sagaidāms. Atspējojiet pakešu zudumu (ip netns exec P iptables -F) un mēģiniet palielināt ģeneratora bitu pārraides ātrumu līdz 100 Mbps. Analizators ziņo par daudzām CC kļūdām un aptuveni 75 Mbps, nevis 100. Mēs cenšamies noskaidrot, kurš ir vainīgs - ģeneratoram nav laika vai problēma nav tajā, tāpēc mēs sākam ģenerēt noteiktu skaitu paketes (700000 100000 TS pakešu = XNUMX XNUMX IP pakešu):
# 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 0Kā redzat, tika ģenerētas tieši 100000 151925460 IP pakešu (151825460-1). Tātad, izdomāsim, kas notiek ar analizatoru, šim nolūkam mēs pārbaudām ar RX skaitītāju uz veth0, tas ir stingri vienāds ar TX skaitītāju uz vethXNUMX, tad mēs skatāmies, kas notiek ligzdas līmenī:
# 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 Šeit jūs varat redzēt kritumu skaitu = 24355. TS paketēs tas ir 170485 jeb 24.36% no 700000, tāpēc mēs redzam, ka tie paši 25% no zaudētā bitu ātruma ir kritumi udp ligzdā. UDP ligzdas kritumi parasti rodas bufera trūkuma dēļ, skatiet noklusējuma ligzdas bufera izmēru un maksimālo ligzdas bufera izmēru:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Tādējādi, ja lietojumprogrammas nepārprotami nepieprasa bufera lielumu, tiek izveidotas ligzdas ar 208 KB buferi, bet, ja tās pieprasa vairāk, tās joprojām nesaņems pieprasīto. Tā kā jūs varat iestatīt bufera lielumu tsp IP ievadei (-buffer-size), mēs nepieskaramies noklusējuma ligzdas izmēram, bet tikai iestatīsim maksimālo ligzdas bufera izmēru un skaidri norādīsim bufera lielumu, izmantojot tsp argumentus:
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 dropAr šo ligzdas bufera regulēšanu tagad ziņotais bitu pārraides ātrums ir aptuveni 100 Mbps, nav CC kļūdu.
Atbilstoši pašas tsp lietojumprogrammas CPU patēriņam. Salīdzinot ar vienu kodolu i5-4260U CPU @ 1.40 GHz, 10Mbps plūsmas analīzei būs nepieciešami 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%. Iestatot pakešu zudumu %, CPU slodze praktiski nepalielinās (bet var samazināties).
Izmantojot produktīvāku aparatūru, bez problēmām bija iespējams ģenerēt un analizēt straumes, kas pārsniedz 1 Gb / s.
Testēšana uz reālām tīkla kartēm
Pēc testēšanas ar veth pāri jums ir jāņem divi saimniekdatori vai divi viena resursdatora porti, jāsavieno porti viens ar otru, jāieslēdz ģenerators vienā un analizators ar otro. Pārsteigumu te nebija, bet patiesībā viss atkarīgs no dzelzs, jo vājāks, jo interesantāk šeit būs.
Izmantojot uzraudzības sistēmas (Zabbix) saņemtos datus
tsp nav mašīnlasāmas API, piemēram, SNMP vai līdzīga. CC ziņojumiem jābūt apkopotiem vismaz 1 sekundi (ar lielu pakešu zuduma procentuālo daļu var būt simtiem/tūkstošiem/desmitiem tūkstošu sekundē atkarībā no bitu pārraides ātruma).
Tādējādi, lai saglabātu gan informāciju, gan uzzīmētu grafikus CC kļūdām un bitu pārraides ātrumam un veiktu sava veida avārijas, var būt šādas iespējas:
- Parsēt un apkopot (pēc CC) tsp izlaidi, t.i. pārvērst to vēlamajā formā.
- Pabeigt pašu tsp un/vai procesora spraudņus bitrate_monitor un nepārtrauktību, lai rezultāts tiktu sniegts mašīnlasāmā, uzraudzības sistēmai piemērotā formā.
- Uzrakstiet savu pieteikumu tsduck bibliotēkas augšpusē.
Acīmredzot 1. variants ir visvieglākais piepūles ziņā, īpaši ņemot vērā, ka pati tsduck ir rakstīta zema līmeņa (pēc mūsdienu standartiem) valodā (C ++)
Vienkāršs bash parsētājs+agregatora prototips parādīja, ka pie 10Mbps straumes un 50% pakešu zuduma (sliktākajā gadījumā) bash process patērēja 3–4 reizes vairāk CPU nekā pats tsp process. Šis scenārijs ir nepieņemams. Patiesībā šī prototipa gabals zemāk
Virsū nūdeles
#!/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
donePapildus tam, ka bash ir nepieņemami lēns, bash nav normālu pavedienu, bash darbi ir atsevišķi procesi, un man blakus efektā (saņemot bitrate ziņojumus, kas nāk katru sekundi) reizi sekundē bija jāraksta trūkstPackets vērtība. Rezultātā bash palika viens un tika nolemts golangā rakstīt iesaiņojumu (parsētājs + agregators). Līdzīga golang koda CPU patēriņš ir 4-5 reizes mazāks nekā pašam tsp procesam. Aptinuma paātrinājums, pateicoties bash aizstāšanai ar golangu, izrādījās apmēram 16 reizes, un kopumā rezultāts ir pieņemams (CPU pārtēriņš sliktākajā gadījumā par 25%). Golang avota fails atrodas .
Palaist iesaiņojumu
Lai palaistu iesaiņojumu, tika izveidota vienkāršākā sistēmasd pakalpojuma veidne (). Paredzams, ka pats iesaiņojums ir jāapkopo binārā failā (go build tsduck-stat.go), kas atrodas mapē /opt/tsduck-stat/. Tiek pieņemts, ka jūs izmantojat golangu ar monotoniskā pulksteņa atbalstu (>=1.9).
Lai izveidotu pakalpojuma gadījumu, ir jāpalaiž komanda systemctl enable [e-pasts aizsargāts]:1234 pēc tam palaist ar systemctl start [e-pasts aizsargāts]: 1234.
Atklājums no Zabbix
Lai zabbix varētu atklāt darbojošos servisus, tas tiek darīts (discovery.sh), Zabbix atklāšanai nepieciešamajā formātā tiek pieņemts, ka tas atrodas tajā pašā vietā - mapē /opt/tsduck-stat. Lai palaistu atklāšanu, izmantojot zabbix-agent, jums ir jāpievieno zabbix-agent konfigurācijas direktorijā, lai pievienotu lietotāja parametru.
Zabbix veidne
(tsduck_stat_template.xml) satur automātiskās atklāšanas kārtulu, vienumu prototipus, diagrammas un aktivizētājus.
Īss kontrolsaraksts (labi, ja kāds nolems to izmantot)
- Pārliecinieties, ka tsp neizlaiž paketes "ideālos" apstākļos (ģenerators un analizators ir tieši savienoti), ja ir kritumi, skatiet 2. punktu vai raksta tekstu par šo jautājumu.
- Noregulējiet maksimālo ligzdas buferi (net.core.rmem_max=8388608).
- Kompilējiet tsduck-stat.go (izveidojiet tsduck-stat.go).
- Ievietojiet pakalpojuma veidni mapē /lib/systemd/system.
- Sāciet pakalpojumus ar systemctl, pārbaudiet, vai ir sākuši parādīties skaitītāji (grep "" /dev/shm/tsduck-stat/*). Pakalpojumu skaits pēc multiraides straumju skaita. Šeit, iespējams, būs jāizveido maršruts uz multiraides grupu, iespējams, jāatspējo rp_filter vai jāizveido maršruts uz avota IP.
- Palaidiet discovery.sh, pārliecinieties, vai tas ģenerē json.
- Pievienojiet zabbix agent konfigurāciju, restartējiet zabbix agent.
- Augšupielādējiet veidni zabbix, lietojiet to resursdatoram, kas tiek uzraudzīts un zabbix-agent ir instalēts, pagaidiet apmēram 5 minūtes, pārbaudiet, vai ir jauni vienumi, diagrammas un aktivizētāji.
Piedzīvojiet efektīvu rezultātu spēku
Lai noteiktu pakešu zudumu, ar to gandrīz pietiek, vismaz labāk nekā bez uzraudzības.
Patiešām, CC “zaudējumi” var rasties, sapludinot video fragmentus (cik zinu, Krievijas Federācijas vietējos TV centros šādi tiek taisīti ieliktņi, t.i., nepārrēķinot CC skaitītāju), tas ir jāatceras. Patentēti risinājumi daļēji apiet šo problēmu, atklājot SCTE-35 etiķetes (ja tās ir pievienojis straumes ģenerators).
Runājot par transporta kvalitātes uzraudzību, trūkst nervozitātes monitoringa (IAT). TV aprīkojumam (vai tie būtu modulatori vai gala ierīces) ir prasības šim parametram, un ne vienmēr ir iespējams uzpūst džitbuferi līdz bezgalībai. Un nervozitāte var peldēt, ja tranzītā tiek izmantots aprīkojums ar lieliem buferiem un QoS nav konfigurēts vai nav pietiekami labi konfigurēts, lai pārraidītu šādu reāllaika trafiku.
Avots: www.habr.com