ProHoster > Блог > басқарма > IP(TS) ағындарын бақылау үшін TSDuck пайдалану

IP(TS) ағындарын бақылау үшін TSDuck пайдалану

Бүгінгі таңда IP(TS) ағындарын бақылауға арналған дайын (меншікті) шешімдер бар, мысалы VB и iQ, оларда жеткілікті бай функциялар жиынтығы бар және әдетте теледидар қызметтерімен айналысатын ірі операторлар ұқсас шешімдерге ие. Бұл мақала ашық бастапқы жобаға негізделген шешімді сипаттайды TSDuck, CC (үздіксіздік санауышы) санауышы мен бит жылдамдығын пайдаланып IP(TS) ағындарын минималды басқаруға арналған. Ықтимал қолданба пакеттердің жоғалуын немесе жалға алынған L2 арнасы арқылы бүкіл ағынды бақылау болып табылады (оны қалыпты жағдайда бақылау мүмкін емес, мысалы, кезектердегі жоғалту есептегіштерін оқу арқылы).

TSDuck туралы өте қысқаша

TSDuck - бұл TS ағындарын басқаруға арналған ашық бастапқы бағдарламалық құрал (2-бапты BSD лицензиясы) (консольдік утилиталар жиынтығы және жеке утилиталарды немесе плагиндерді әзірлеуге арналған кітапхана). Кіріс ретінде ол IP (көп тарату/уникаст), http, hls, dvb тюнерлері, dektec dvb-asi демодуляторымен жұмыс істей алады, ішкі TS ағынының генераторы және файлдардан оқу бар. Шығару файлға, IP (көп тарату/уникаст), hls, dektec dvb-asi және HiDes модуляторларына, ойнатқыштарға (mplayer, vlc, xine) және түсіруге жазылуы мүмкін. Кіріс пен шығыс арасында әртүрлі трафик процессорларын қосуға болады, мысалы, PID карталарын қайта құру, шифрлау/дескрамбациялау, CC есептегіштерін талдау, бит жылдамдығын есептеу және TS ағындарына тән басқа әрекеттер.

Бұл мақалада IP ағындары (көп тарату) кіріс ретінде пайдаланылады, бит жылдамдығы_мониторы процессорлары (атасынан бұл не екені түсінікті) және үздіксіздік (CC есептегіш талдау) процессорлары пайдаланылады. Ешбір қиындықсыз IP мультикастты TSDuck қолдайтын басқа кіріс түрімен ауыстыруға болады.

Бар ресми құрылыстар/пакеттер Ең қазіргі ОЖ үшін TSDuck. Debian үшін олар жоқ, бірақ біз оларды Debian 8 және Debian 10 үшін еш қиындықсыз құрастыра алдық.

Әрі қарай, TSDuck 3.19-1520 нұсқасы пайдаланылады, операциялық жүйе ретінде Linux пайдаланылады (шешімді дайындау үшін debian 10, CentOS 7 нақты пайдалану үшін пайдаланылды)

TSDuck және ОЖ дайындау

Нақты ағындарды бақыламас бұрын, TSDuck дұрыс жұмыс істейтініне және желілік карта немесе ОЖ (розетка) деңгейінде құлдырау болмайтынына көз жеткізу керек. Бұл желіде немесе «сервер ішінде» құлдыраудың қай жерде болғанын кейінірек болжай алмау үшін қажет. Желілік карта деңгейінде ethtool -S ethX пәрменімен құлдырауды тексеруге болады, баптау дәл сол ethtool арқылы жүзеге асырылады (әдетте RX буферін (-G) ұлғайту керек және кейде кейбір түсірулерді (-K) өшіру керек). Жалпы ұсыныс ретінде талданған трафикті алу үшін бөлек портты пайдаланған жөн, егер мүмкін болса, бұл басқа трафиктің болуына байланысты анализатор портында бір уақытта құлдырау орын алғандықтан, жалған позитивтерді азайтады. Егер бұл мүмкін болмаса (сіз бір порты бар шағын компьютерді/NUC пайдаланып жатсаңыз), анализатор қосылған құрылғыдағы қалған бөлігіне қатысты талданатын трафиктің басымдылығын конфигурациялаған жөн. Виртуалды орталарға келетін болсақ, мұнда мұқият болу керек және физикалық порттан бастап виртуалды машинаның ішіндегі қолданбаға дейін пакеттердің түсуін таба білу керек.

Хост ішінде ағынды жасау және қабылдау

TSDuck дайындаудың бірінші қадамы ретінде біз netns көмегімен бір хост ішінде трафикті жасаймыз және қабылдаймыз.

Қоршаған ортаны дайындау:

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

Қоршаған орта дайын. Трафик анализаторын іске қосыңыз:

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

мұндағы “-p 1 -t 1” секунд сайын бит жылдамдығын есептеп, секунд сайын бит жылдамдығы туралы ақпаратты көрсету керек дегенді білдіреді.
Біз жылдамдығы 10 Мбит/с трафик генераторын іске қосамыз:

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

мұндағы “-p 7 -e” 7 TS пакетін 1 IP пакетіне буып, оны қатты (-e) жасау керек дегенді білдіреді, яғни. әрқашан IP пакетін қалыптастыруды жібермес бұрын соңғы процессордан 7 TS пакетін күтіңіз.

Талдаушы күтілетін хабарламаларды көрсете бастайды:

* 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

Енді бірнеше тамшы қосайық:

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

және келесідей хабарламалар пайда болады:

* 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

бұл күтілуде. Біз пакетті жоғалтуды өшіреміз (ip netns exec P iptables -F) және генератордың бит жылдамдығын 100 Мбит/с дейін арттыруға тырысамыз. Анализатор көптеген CC қателері туралы хабарлайды және 75 орнына шамамен 100 Мбит/с. Біз кім кінәлі екенін анықтауға тырысамыз - генератор жұмыс істемейді немесе мәселе онда емес, ол үшін біз генерациялай бастаймыз. дестелердің тіркелген саны (700000 100000 TS пакеті = XNUMX XNUMX 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 0

Көріп отырғаныңыздай, дәл 100000 151925460 IP пакеттері жасалды (151825460-1). Сонымен, біз анализатормен не болып жатқанын анықтаймыз, ол үшін veth0 жүйесіндегі RX есептегішімен тексереміз, ол vethXNUMX жүйесіндегі TX есептегішімен қатаң тең, содан кейін розетка деңгейінде не болып жатқанын қарастырамыз:

# 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

Мұнда сіз тамшылардың санын көре аласыз = 24355. TS пакеттерінде бұл 170485 немесе 24.36 700000%, сондықтан жоғалған бит жылдамдығының бірдей 25% UDP ұяшығындағы тамшылар екенін көреміз. UDP ұяшығындағы құлдырау әдетте буфердің болмауына байланысты болады, әдепкі розетка буферінің өлшемі мен ұяшық буферінің максималды өлшемі қандай екенін көрейік:

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

Осылайша, егер қолданбалар буфер өлшемін нақты сұрамаса, ұяшықтар 208 КБ буфермен жасалады, бірақ олар көбірек сұраса, олар әлі де сұраған нәрсені алмайды. tsp ішінде IP кірісі үшін буфер өлшемін орнатуға болатындықтан (--buffer-size), біз әдепкі ұяшық өлшеміне қол тигізбейміз, тек ең үлкен ұяшық буферінің өлшемін орнатамыз және буфер өлшемін 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

Розетка буферінің осы баптауымен хабарланған бит жылдамдығы шамамен 100 Мбит/с құрайды, CC қателері жоқ.

tsp қолданбасының өзі CPU тұтынуына негізделген. Бір ядролы i5-4260U CPU @ 1.40GHz болса, 10Мбит/с ағынды талдау үшін процессордың 3-4%, 100Мбит/с - 25%, 200Мбит/с - 46% қажет болады. Пакеттің жоғалуын % орнату кезінде процессордың жүктемесі іс жүзінде өспейді (бірақ төмендеуі мүмкін).

Неғұрлым өнімді жабдықта 1 Гб/с-тан асатын ағындарды еш қиындықсыз генерациялауға және талдауға болады.

Нақты желілік карталарда тестілеу

Вет жұбында тестілеуден кейін екі хостты немесе бір хосттың екі портын алып, порттарды бір-біріне қосу керек, генераторды біреуінде, ал екіншісінде анализаторды іске қосу керек. Мұнда тосынсыйлар болған жоқ, бірақ шын мәнінде бәрі аппараттық құралға байланысты, ол неғұрлым әлсіз болса, соғұрлым бұл жерде қызықты болады.

Мониторинг жүйесі арқылы алынған деректерді пайдалану (Zabbix)

tsp-де SNMP немесе соған ұқсас машинада оқылатын API жоқ. CC хабарламаларын бір уақытта кемінде 1 секунд біріктіру қажет (дестелердің жоғалу пайызы жоғары, бит жылдамдығына байланысты секундына жүздеген/мыңдаған/он мыңдаған болуы мүмкін).

Осылайша, ақпаратты сақтау және CC қателері мен бит жылдамдығының графиктерін сызу және одан әрі апаттардың кейбір түрлерін жасау үшін келесі опциялар болуы мүмкін:

  1. Шай қасық шығысын талдау және жинақтау (CC бойынша), яғни. оны қажетті пішінге айналдырыңыз.
  2. Нәтижені бақылау жүйесіне қолайлы машина оқылатын пішінде шығару үшін tsp өзін және/немесе bitrate_monitor және үздіксіздік процессорының плагиндерін қосыңыз.
  3. Өтінішіңізді tsduck кітапханасының үстіне жазыңыз.

Әлбетте, еңбек шығындары бойынша 1-нұсқа ең қарапайым, әсіресе tsduck өзі төмен деңгейлі (заманауи стандарттар бойынша) тілде (C++) жазылғанын ескерсек.

Bash-тегі талдаушы + агрегатордың қарапайым прототипі 10 Мбит/с ағынында және 50% пакет жоғалтуында (ең нашар жағдайда) bash процесі tsp процесінің өзінен 3-4 есе көп процессорды тұтынатынын көрсетті. Бұл сценарий қабылданбайды. Іс жүзінде бұл прототиптің бір бөлігі төменде

Башадағы кеспе

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

Мұның қолайсыз баяу жұмыс істеуіне қоса, bash-та қалыпты ағындар жоқ, bash тапсырмалары тәуелсіз процестер болып табылады және мен жанама әсерге секундына бір рет missingPackets мәнін жазуға тура келді (әр секунд сайын келетін бит жылдамдығы туралы хабарламаларды алғанда). Нәтижесінде, bash жалғыз қалды және голанг тілінде ораманы (талдауыш + агрегатор) жазу туралы шешім қабылданды. Голангтағы ұқсас кодтың CPU тұтынуы tsp процесінің өзінен 4-5 есе аз. Bash-ті голангпен ауыстыру арқылы қаптаманың жылдамдауы шамамен 16 есе болды және жалпы нәтиже қолайлы (ең нашар жағдайда процессордың үстеме шығыны 25%). Голанг бастапқы файлы орналасқан осында.

Қаптаманы іске қосу

Қаптаманы іске қосу үшін systemd үшін қарапайым қызмет үлгісі жасалды (осында). Қаптаманың өзі /opt/tsduck-stat/ ішінде орналасқан екілік файлға (go build tsduck-stat.go) құрастырылған деп болжанады. Голанг монотонды сағат қолдауымен қолданылады деп болжанады (>=1.9).

Қызметтік дананы жасау үшін systemctl enable пәрменін іске қосу керек [электрондық пошта қорғалған]:1234, содан кейін systemctl бастауымен іске қосыңыз [электрондық пошта қорғалған]: 1234.

Заббикстің ашылуы

Осылайша, zabbix іске қосылған қызметтерді таба алады, топтық тізім генераторы (discovery.sh), Zabbix ашылуына қажетті пішімде, ол бір жерде - /opt/tsduck-stat ішінде орналасқан деп болжанады. Zabbix-агент арқылы табуды іске қосу үшін қосу керек .conf файлы пайдаланушы параметрін қосу үшін zabbix-агент конфигурациялары бар каталогқа.

Zabbix үлгісі

Құрылған үлгі (tsduck_stat_template.xml) автоматты түрде табу ережесін, элементті, графикті және триггер прототиптерін қамтиды.

Қысқаша бақылау тізімі (біреу оны пайдалануды шешсе ше)

  1. Шай қасық пакеттерді «идеалды» жағдайларда (генератор мен анализатор тікелей қосылған) түсірмейтініне көз жеткізіңіз, егер тамшылар болса, 2-тармақты немесе осы тақырыптағы мақаланың мәтінін қараңыз.
  2. Максималды розетка буферін реттеңіз (net.core.rmem_max=8388608).
  3. tsduck-stat.go құрастырыңыз (tsduck-stat.go құрастырыңыз).
  4. Қызмет үлгісін /lib/systemd/system ішіне орналастырыңыз.
  5. Systemctl арқылы қызметтерді бастаңыз, есептегіштер пайда бола бастағанын тексеріңіз (grep "" /dev/shm/tsduck-stat/*). Көп тарату ағындарының саны бойынша қызметтер саны. Мұнда мультикаст тобына маршрут жасау қажет болуы мүмкін, мүмкін rp_filter өшіру немесе бастапқы ip жолын жасау.
  6. Discovery.sh іске қосыңыз, оның json жасайтынына көз жеткізіңіз.
  7. Zabbix агент конфигурациясын орналастырыңыз, zabbix агентін қайта іске қосыңыз.
  8. Үлгіні zabbix-ке жүктеңіз, оны бақылау жүргізілетін және zabbix-агент орнатылған хостқа қолданыңыз, шамамен 5 минут күтіңіз, жаңа деректер элементтері, графиктер және триггерлер пайда болғанын көріңіз.

нәтиже

IP(TS) ағындарын бақылау үшін TSDuck пайдалану

Пакеттің жоғалуын анықтау тапсырмасы үшін бұл жеткілікті дерлік, кем дегенде, бұл бақылаудың болмауынан жақсы.

Шындығында, бейне фрагменттерін біріктіру кезінде CC «шығындар» болуы мүмкін (менің білуімше, Ресей Федерациясының жергілікті теледидар орталықтарында кірістірулер осылай жасалады, яғни CC есептегішін қайта есептемей), мұны есте сақтау керек. Меншікті шешімдерде бұл мәселе SCTE-35 тегтерін анықтау арқылы ішінара айналып өтеді (егер олар ағын генераторымен қосылса).

Көлік сапасының мониторингі тұрғысынан алғанда, джиттер мониторингі (IAT) жеткіліксіз, өйткені Теледидар жабдығында (модуляторлар немесе соңғы құрылғылар) осы параметрге қойылатын талаптар бар және джитбуферді шексіз толтыру әрқашан мүмкін емес. Транзит үлкен буферлері бар жабдықты пайдаланғанда және QoS конфигурацияланбаған немесе нақты уақыттағы трафикті жіберу үшін жеткілікті түрде конфигурацияланбаған кезде діріл қалқып кетуі мүмкін.

Ақпарат көзі: www.habr.com

пікір қалдыру