🥇Kutumia TSDuck kufuatilia mitiririko ya IP(TS)

Leo, kuna suluhisho zilizotengenezwa tayari (za umiliki) za ufuatiliaji wa mitiririko ya IP (TS), kwa mfano. VB и iQ, wana seti nyingi za utendaji na kwa kawaida waendeshaji wakubwa wanaoshughulika na huduma za TV wana suluhu kama hizo. Nakala hii inaelezea suluhisho kulingana na mradi wa chanzo wazi TSDuck, iliyoundwa kwa ajili ya udhibiti mdogo wa mitiririko ya IP(TS) kwa kaunta na kasi ya biti ya CC(continuity counter). Programu inayowezekana ni kudhibiti upotevu wa pakiti au mtiririko mzima kupitia chaneli ya L2 iliyokodishwa (ambayo haiwezi kufuatiliwa kawaida, kwa mfano, kwa kusoma vihesabio vya upotezaji kwenye foleni).

Kwa kifupi sana kuhusu TSDuck

TSDuck ni programu huria (leseni ya 2-Kifungu cha BSD) (seti ya huduma za kiweko na maktaba ya kutengeneza huduma maalum au programu-jalizi) kwa kuchezea mitiririko ya TS. Kama kiingizio, inaweza kufanya kazi na IP (multicast/unicast), http, hls, vibadilishaji umeme vya dvb, dektec dvb-asi demodulator, kuna jenereta ya ndani ya TS-stream na kusoma kutoka kwa faili. Matokeo yanaweza kuandikia faili, IP (multicast/unicast), hls, dektec dvb-asi na vidhibiti vya HiDes, wachezaji (mplayer, vlc, xine) na drop. Vichakataji mbalimbali vya trafiki vinaweza kujumuishwa kati ya ingizo na pato, kwa mfano, upangaji upya wa PID, kusugua/kuchambua, uchanganuzi wa kaunta wa CC, ukokotoaji wa kasi ya biti, na shughuli zingine za kawaida za mitiririko ya TS.

Katika nakala hii, mitiririko ya IP (multicast) itatumika kama pembejeo, wasindikaji bitrate_monitor (kutoka kwa jina ni wazi ni nini) na mwendelezo (uchambuzi wa vihesabio vya CC) hutumiwa. Unaweza kubadilisha kwa urahisi upeperushaji wa IP na aina nyingine ya ingizo inayoungwa mkono na TSDuck.

Inapatikana rasmi hujenga/vifurushi TSDuck kwa mifumo mingi ya uendeshaji ya sasa. Hazipatikani kwa Debian, lakini tuliweza kuziunda chini ya debian 8 na debian 10 bila shida yoyote.

Ifuatayo, toleo la TSDuck 3.19-1520 linatumika, Linux inatumiwa kama OS (debian 10 ilitumiwa kuandaa suluhisho, CentOS 7 ilitumika kwa matumizi halisi)

Inatayarisha TSDuck na OS

Kabla ya kufuatilia mtiririko halisi, unahitaji kuhakikisha kuwa TSDuck inafanya kazi kwa usahihi na hakuna matone kwenye kadi ya mtandao au kiwango cha OS (tundu). Hii inahitajika ili usidhani baadaye ambapo matone yalitokea - kwenye mtandao au "ndani ya seva". Unaweza kuangalia matone kwenye kiwango cha kadi ya mtandao na amri ya ethtool -S ethX, tuning inafanywa na ethtool sawa (kawaida, unahitaji kuongeza bafa ya RX (-G) na wakati mwingine afya ya upakiaji (-K)). Kama pendekezo la jumla, inaweza kushauriwa kutumia bandari tofauti kwa kupokea trafiki iliyochambuliwa, ikiwezekana, hii inapunguza chanya za uwongo zinazohusiana na ukweli kwamba kushuka kulitokea haswa kwenye bandari ya analyzer kwa sababu ya uwepo wa trafiki nyingine. Ikiwa hii haiwezekani (kompyuta ndogo / NUC yenye bandari moja hutumiwa), basi ni kuhitajika sana kuanzisha kipaumbele cha trafiki iliyochambuliwa kuhusiana na wengine kwenye kifaa ambacho analyzer imeunganishwa. Kuhusu mazingira pepe, hapa unahitaji kuwa mwangalifu na uweze kupata matone ya pakiti kuanzia lango halisi na kumalizia na programu ndani ya mashine pepe.

Uzalishaji na upokeaji wa mtiririko ndani ya mwenyeji

Kama hatua ya kwanza katika kuandaa TSDuck, tutazalisha na kupokea trafiki ndani ya seva pangishi moja kwa kutumia neti.

Kuandaa mazingira:

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 в сторону veth0

Mazingira ni tayari. Tunaanza uchambuzi wa trafiki:

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

ambapo "-p 1 -t 1" inamaanisha kuwa unahitaji kuhesabu kasi ya biti kila sekunde na kuonyesha habari kuhusu kasi ya biti kila sekunde.
Tunaanzisha jenereta ya trafiki kwa kasi ya 10Mbps:

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

ambapo "-p 7 -e" inamaanisha kwamba unahitaji kufunga pakiti 7 za TS kwenye pakiti 1 ya IP na uifanye kwa bidii (-e), i.e. subiri kila pakiti 7 za TS kutoka kwa kichakataji cha mwisho kabla ya kutuma pakiti ya IP.

Kichanganuzi huanza kutoa ujumbe unaotarajiwa:

* 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/s

Sasa ongeza matone kadhaa:

ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROP

na ujumbe kama huu unaonekana:

* 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

ambayo inatarajiwa. Zima upotezaji wa pakiti (ip netns exec P iptables -F) na ujaribu kuongeza kasi ya jenereta hadi 100Mbps. Mchambuzi anaripoti rundo la makosa ya CC na karibu 75 Mbps badala ya 100. Tunajaribu kujua ni nani wa kulaumiwa - jenereta haina wakati au shida haiko ndani yake, kwa hili tunaanza kutoa nambari maalum ya pakiti (700000 TS pakiti = 100000 IP pakiti):

# 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 0

Kama unaweza kuona, pakiti 100000 za IP haswa zilitolewa (151925460-151825460). Kwa hivyo hebu tuone kinachotokea na kichanganuzi, kwa hili tunaangalia na kihesabu cha RX kwenye veth1, ni sawa kabisa na kihesabu cha TX kwenye veth0, kisha tunaangalia kile kinachotokea kwa kiwango cha tundu:

# 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

Hapa unaweza kuona idadi ya matone = 24355. Katika pakiti za TS, hii ni 170485 au 24.36% ya 700000, kwa hiyo tunaona kwamba wale sawa 25% ya bitrate iliyopotea ni matone kwenye tundu la udp. Matone kwenye tundu la UDP kawaida hutokea kwa sababu ya ukosefu wa bafa, angalia saizi ya bafa ya tundu chaguo-msingi na saizi ya juu ya bafa ya soketi:

# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992

Kwa hivyo, ikiwa programu haziombi kwa uwazi ukubwa wa bafa, soketi zinaundwa na bafa ya KB 208, lakini ikiwa zitaomba zaidi, bado hazitapokea kile kilichoombwa. Kwa kuwa unaweza kuweka saizi ya bafa katika tsp kwa ingizo la IP (-buffer-size), hatutagusa saizi chaguo-msingi ya tundu, lakini weka tu saizi ya juu zaidi ya bafa na ubainishe saizi ya bafa kwa uwazi kupitia hoja za 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 drop

Kwa urekebishaji huu wa bafa ya soketi, sasa bitrate iliyoripotiwa ni takriban 100Mbps, hakuna makosa ya CC.

Kulingana na matumizi ya CPU ya programu ya tsp yenyewe. Kuhusiana na msingi mmoja i5-4260U CPU @ 1.40GHz, uchanganuzi wa mtiririko wa 10Mbps utahitaji 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%. Wakati wa kuweka % Upotezaji wa Pakiti, mzigo kwenye CPU kivitendo hauongezeki (lakini unaweza kupungua).

Kwenye maunzi yenye tija zaidi, iliwezekana kutoa na kuchanganua mitiririko ya zaidi ya 1Gb/s bila matatizo yoyote.

Kujaribu kwenye kadi za mtandao halisi

Baada ya kupima kwenye jozi ya veth, unahitaji kuchukua majeshi mawili au bandari mbili za jeshi moja, kuunganisha bandari kwa kila mmoja, kuanza jenereta kwa moja, na analyzer kwa pili. Hakukuwa na mshangao hapa, lakini kwa kweli yote inategemea chuma, dhaifu, itakuwa ya kuvutia zaidi hapa.

Kutumia data iliyopokelewa na mfumo wa ufuatiliaji (Zabbix)

tsp haina API yoyote inayoweza kusomeka kwa mashine kama SNMP au sawa. Ujumbe wa CC lazima ujumuishwe kwa angalau sekunde 1 (pamoja na asilimia kubwa ya upotevu wa pakiti, kunaweza kuwa na mamia/maelfu/makumi ya maelfu kwa sekunde, kulingana na kasi ya biti).

Kwa hivyo, ili kuokoa habari zote mbili na kuchora grafu kwa makosa ya CC na bitrate na kufanya aina fulani ya ajali, kunaweza kuwa na chaguzi zifuatazo:

Changanua na ujumuishe (kwa CC) pato la tsp, i.e. ubadilishe kwa fomu inayotaka.
Maliza tsp yenyewe na/au programu-jalizi za bitrate_monitor na mwendelezo ili matokeo yatolewe katika fomu inayoweza kusomeka na mashine inayofaa kwa mfumo wa ufuatiliaji.
Andika programu yako juu ya maktaba ya tsduck.

Kwa wazi, chaguo la 1 ndilo rahisi zaidi katika suala la jitihada, hasa kwa kuzingatia kwamba tsduck yenyewe imeandikwa kwa kiwango cha chini (kwa viwango vya kisasa) lugha (C ++)

Mfano rahisi wa bash parser+aggregator ulionyesha kuwa kwenye mtiririko wa 10Mbps na upotezaji wa pakiti 50% (hali mbaya zaidi), mchakato wa bash ulitumia CPU mara 3-4 zaidi kuliko mchakato wa tsp yenyewe. Hali hii haikubaliki. Kwa kweli kipande cha mfano huu hapa chini

Noodles juu

#!/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
done

Kwa kuongezea kuwa polepole bila kukubalika, hakuna nyuzi za kawaida kwenye bash, kazi za bash ni michakato tofauti, na ilibidi niandike dhamana ya kukosaPaketi mara moja kwa sekunde kwenye athari ya upande (wakati wa kupokea ujumbe wa bitrate ambao huja kila sekunde). Kama matokeo, bash iliachwa peke yake na iliamuliwa kuandika wrapper (parser + aggregator) kwa golang. Matumizi ya CPU ya msimbo sawa wa golang ni mara 4-5 chini ya mchakato wa tsp yenyewe. Kuongeza kasi ya wrapper kwa sababu ya uingizwaji wa bash na golang iligeuka kuwa mara 16 na kwa ujumla matokeo yanakubalika (CPU ya juu kwa 25% katika hali mbaya zaidi). Faili ya chanzo cha golang iko hapa.

Kukimbia wrapper

Kuanza kanga, templeti rahisi zaidi ya huduma ya systemd ilitengenezwa (hapa) Kanga yenyewe inapaswa kukusanywa kuwa faili ya binary (nenda ujenge tsduck-stat.go) iliyoko /opt/tsduck-stat/. Inachukuliwa kuwa unatumia golang na usaidizi wa saa ya monotonic (>=1.9).

Ili kuunda mfano wa huduma, unahitaji kuendesha amri ya kuwezesha systemctl [barua pepe inalindwa]:1234 kisha endesha na systemctl start [barua pepe inalindwa]: 1234.

Ugunduzi kutoka kwa Zabbix

Ili zabbix iweze kugundua huduma zinazoendesha, imefanywa jenereta ya orodha ya kikundi (discovery.sh), katika umbizo linalohitajika kwa ugunduzi wa Zabbix, inachukuliwa kuwa iko katika sehemu moja - katika /opt/tsduck-stat. Ili kuendesha ugunduzi kupitia zabbix-agent, unahitaji kuongeza .conf faili kwa saraka ya usanidi wa wakala wa zabbix ili kuongeza kigezo cha mtumiaji.

Kiolezo cha Zabbix

Kiolezo kilichoundwa (tsduck_stat_template.xml) ina sheria ya ugunduzi kiotomatiki, mifano ya vipengee, grafu na vichochezi.

Orodha fupi ya ukaguzi (vipi, ikiwa mtu ataamua kuitumia)

Hakikisha kwamba tsp haina kuacha pakiti chini ya hali "bora" (jenereta na analyzer huunganishwa moja kwa moja), ikiwa kuna matone, angalia aya ya 2 au maandishi ya makala juu ya suala hili.
Tengeneza kiwango cha juu zaidi cha bafa ya tundu (net.core.rmem_max=8388608).
Unganisha tsduck-stat.go (nenda ujenge tsduck-stat.go).
Weka kiolezo cha huduma ndani /lib/systemd/system.
Anzisha huduma na systemctl, angalia kuwa vihesabio vimeanza kuonekana (grep "" /dev/shm/tsduck-stat/*). Idadi ya huduma kulingana na idadi ya mitiririko mingi. Hapa unaweza kuhitaji kuunda njia kwa kikundi cha utangazaji anuwai, labda kuzima rp_filter au kuunda njia ya ip chanzo.
Endesha discovery.sh, hakikisha inazalisha json.
Ongeza usanidi wa wakala wa zabbix, anzisha tena wakala wa zabbix.
Pakia kiolezo kwenye zabbix, kitumie kwa mwenyeji anayefuatiliwa na wakala wa zabbix amewekwa, subiri kama dakika 5, angalia ikiwa kuna vitu vipya, grafu na vichochezi.

Matokeo

Kwa kazi ya kuchunguza upotevu wa pakiti, ni karibu kutosha, angalau ni bora kuliko hakuna ufuatiliaji.

Hakika, "hasara" za CC zinaweza kutokea wakati wa kuunganisha vipande vya video (kwa kadiri ninavyojua, hii ndio jinsi kuingizwa kunafanywa kwenye vituo vya TV vya ndani katika Shirikisho la Urusi, yaani bila kuhesabu upya counter CC), hii lazima ikumbukwe. Suluhu za umiliki hukwepa kwa kiasi tatizo hili kwa kugundua lebo za SCTE-35 (ikiwa zimeongezwa na jenereta ya mtiririko).

Kwa upande wa ufuatiliaji wa ubora wa usafiri, kuna ukosefu wa ufuatiliaji wa jitter (IAT). Vifaa vya TV (viwe vidhibiti au vifaa vya mwisho) vina mahitaji ya kigezo hiki na si mara zote inawezekana kuingiza jitbuffer hadi isiyo na mwisho. Na jita inaweza kuelea wakati kifaa kilicho na vibafa vikubwa kinatumiwa katika usafiri na QoS haijasanidiwa au haijasanidiwa vya kutosha kusambaza trafiki ya wakati halisi.

Chanzo: mapenzi.com

Kutumia TSDuck Kufuatilia Mitiririko ya IP(TS).