ProHoster > Blog > башкаруу > IP(TS) агымдарын көзөмөлдөө үчүн TSDuck колдонуу

IP(TS) агымдарын көзөмөлдөө үчүн TSDuck колдонуу

Бүгүнкү күндө IP(TS) агымын көзөмөлдөө үчүн даяр (приетардык) чечимдер бар, мисалы VB и iQ, алар бир топ бай функцияларга ээ жана адатта телекөрсөтүү кызматтары менен алектенген ири операторлор ушундай чечимдерге ээ. Бул макалада ачык булак долбооруна негизделген чечим сүрөттөлөт TSDuck, CC (үзгүлтүксүздүк эсептегич) эсептегичти жана бит ылдамдыгын колдонуу менен IP(TS) агымдарын минималдуу башкаруу үчүн иштелип чыккан. Мүмкүн болгон тиркеме пакеттердин жоголушуна же ижарага алынган L2 каналы аркылуу бүт агымга мониторинг жүргүзүү болуп саналат (бул адаттагыдай эле көзөмөлгө алынбайт, мисалы, кезектеги жоготууларды эсептегичтерди окуу менен).

TSDuck жөнүндө кыскача

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

Бул макалада киргизүү катары IP агымдары (мультикаст) колдонулат, bitrate_monitor процессорлору (атынан бул эмне экени түшүнүктүү) жана үзгүлтүксүздүк (CC эсептегич анализи) процессорлору колдонулат. Эч кандай көйгөйсүз, сиз IP мультикастты TSDuck колдогон башка киргизүү түрү менен алмаштыра аласыз.

жеткиликтүү расмий курулуштар/пакеттер Көпчүлүк учурдагы OS үчүн TSDuck. Debian үчүн эч ким жок, бирок биз аларды Debian 8 жана Debian 10 үчүн эч кандай көйгөйсүз түзө алдык.

Андан кийин, TSDuck 3.19-1520 версиясы колдонулат, OS катары Linux колдонулат (дебиан 10 чечимди даярдоо үчүн колдонулган, CentOS 7 иш жүзүндө колдонуу үчүн колдонулган)

TSDuck жана OS даярдалууда

Чыныгы агымдарды көзөмөлдөөдөн мурун, сиз 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 киргизүү үчүн буфердин өлчөмүн (--bufer-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 келсек, 10Mbit/s агымын талдоо үчүн CPU 3-4%, 100Mbit/s - 25%, 200Mbit/s - 46% талап кылынат. Пакеттин жоголушу % орнотулганда, CPU жүктөмү дээрлик көбөйбөйт (бирок төмөндөшү мүмкүн).

Көбүрөөк жемиштүү жабдыктарда 1 Гб/секден ашык агымдарды эч кандай көйгөйсүз жаратып, талдоо мүмкүн болду.

Чыныгы тармак карталарында тестирлөө

Veth жупта тестирлөөдөн кийин, сиз эки хостту же бир хосттун эки портун алып, портторду бири-бирине туташтырыңыз, биринде генераторду, экинчисинде анализаторду иштетишиңиз керек. Бул жерде эч кандай сюрприз болгон жок, бирок чындыгында баары аппараттык жабдыктардан көз каранды, ал канчалык алсыз болсо, бул жерде ошончолук кызыктуу болот.

Мониторинг системасы тарабынан алынган маалыматтарды колдонуу (Zabbix)

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

Ошентип, маалыматты сактоо жана CC каталары жана бит ылдамдыгы үчүн графиктерди тартуу жана андан ары кандайдыр бир кырсыктарды жасоо үчүн төмөнкү варианттар болушу мүмкүн:

  1. tsp чыгарууну талдоо жана бириктирүү (CC боюнча), б.а. аны каалаган формага айландырыңыз.
  2. Натыйжа мониторинг системасына ылайыктуу машина окуй турган формада чыгышы үчүн tsp өзүн жана/же bitrate_monitor жана үзгүлтүксүздүк процессорунун плагиндерин кошуңуз.
  3. Арызыңызды tsduck китепканасынын үстүнө жазыңыз.

Албетте, эмгек чыгымдары боюнча, 1-вариант эң жөнөкөй, айрыкча tsduck өзү төмөн деңгээлдеги (заманбап стандарттар боюнча) тилде (C++) жазылганын эске алганда.

Bashдагы талдоочу + агрегатордун жөнөкөй прототиби көрсөткөндөй, 10 Мбит/сек агымда жана 50% пакет жоготууда (эң начар учурда) bash процесси tsp процессинин өзүнө караганда 3-4 эсе көп CPU керектелет. Бул сценарий кабыл алынгыс. Чынында, бул прототиптин бир бөлүгү төмөндө

Башадагы кесме

#!/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 эсе аз. Башты голанг менен алмаштыруу менен оромонун тездеши болжол менен 16 эсеге жеткен жана жалпысынан натыйжа алгылыктуу (Эң начар учурда CPU кошумча чыгымы 25% га). Голанг булак файлы жайгашкан бул жерде.

Капкакты ишке киргизүү

Капкакты ишке киргизүү үчүн, systemd үчүн жөнөкөй тейлөө шаблону жасалган (бул жерде). Ороочу өзү /opt/tsduck-stat/ ичинде жайгашкан бинардык файлга (go build tsduck-stat.go) түзүлөт деп болжолдонууда. Бул голанг монотондук саат колдоо менен колдонулат деп болжолдонууда (>=1.9).

Кызмат инстанциясын түзүү үчүн systemctl иштетүү буйругун иштетүү керек [электрондук почта корголгон]:1234, андан кийин systemctl start менен иштетиңиз [электрондук почта корголгон]: 1234.

Заббикстен ачылыш

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

Zabbix шаблоны

Түзүлгөн шаблон (tsduck_stat_template.xml) автоматтык ачылыш эрежесин, элементти, графикти жана триггер прототиптерин камтыйт.

Кыскача текшерүү тизмеси (эгер кимдир бирөө аны колдонууну чечсе)

  1. tsp "идеалдуу" шарттарда (генератор менен анализатор түздөн-түз туташтырылган) пакеттерди таштабагандыгын текшериңиз, эгерде тамчылар болсо, 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 конфигурацияланбаганда же реалдуу убакыттагы трафикти өткөрүү үчүн жетиштүү конфигурацияланбаганда життер калкып кетиши мүмкүн.

Source: www.habr.com

Комментарий кошуу