Bugungi kunda IP (TS) oqimlarini kuzatish uchun tayyor (xususiy) echimlar mavjud, masalan. и , ular juda boy funktsiyalar to'plamiga ega va odatda televizor xizmatlari bilan shug'ullanadigan yirik operatorlar shunga o'xshash echimlarga ega. Ushbu maqola ochiq kodli loyihaga asoslangan yechimni tasvirlaydi , CC (uzluksizlik hisoblagichi) hisoblagichi va bit tezligi yordamida IP(TS) oqimlarini minimal nazorat qilish uchun mo'ljallangan. Mumkin bo'lgan dastur paketlarning yo'qolishini yoki ijaraga olingan L2 kanali orqali butun oqimni kuzatishdir (buni odatdagidek kuzatib bo'lmaydi, masalan, navbatdagi yo'qotish hisoblagichlarini o'qish orqali).
TSDuck haqida juda qisqacha
TSDuck TS oqimlarini manipulyatsiya qilish uchun ochiq kodli (2-bandli BSD litsenziyasi) dasturiy ta'minot (konsol yordam dasturlari to'plami va shaxsiy yordamchi dasturlar yoki plaginlarni ishlab chiqish uchun kutubxona). Kirish sifatida u IP (multicast/unicast), http, hls, dvb tyunerlari, dektec dvb-asi demodulyatori bilan ishlashi mumkin, ichki TS oqim generatori va fayllardan o'qish mavjud. Chiqish faylga, IP (multicast/unicast), hls, dektec dvb-asi va HiDes modulatorlariga, pleerlarga (mplayer, vlc, xine) va tushirishga yozib olish bo'lishi mumkin. Kirish va chiqish o'rtasida siz turli xil trafik protsessorlarini yoqishingiz mumkin, masalan, PID-larni qayta ko'rsatish, shifrlash/deskrambling qilish, CC hisoblagichlarini tahlil qilish, bit tezligini hisoblash va TS oqimlari uchun xos bo'lgan boshqa operatsiyalar.
Ushbu maqolada IP oqimlari (multicast) kirish sifatida ishlatiladi, bitrate_monitor protsessorlari (nomidan bu nima ekanligi aniq) va uzluksizlik (CC hisoblagich tahlili) protsessorlari ishlatiladi. Hech qanday muammosiz IP multicastni TSDuck tomonidan qo'llab-quvvatlanadigan boshqa kirish turiga almashtirishingiz mumkin.
Mavjud Eng so'nggi operatsion tizimlar uchun TSDuck. Uchun Debian hech qanday narsa yo'q, lekin men uni hech qanday muammosiz yig'ishga muvaffaq bo'ldim debian 8 va debian 10.
Keyin, TSDuck 3.19-1520 versiyasi ishlatiladi va OS quyidagicha Linux (eritmani tayyorlash uchun ishlatiladi) debian 10, haqiqiy foydalanish uchun - CentOS 7)
TSDuck va OS tayyorlanmoqda
Haqiqiy oqimlarni kuzatishdan oldin siz TSDuck to'g'ri ishlashiga ishonch hosil qilishingiz kerak va tarmoq kartasi yoki OS (rozetka) darajasida pasayish sodir bo'lmasligi kerak. Bu pasayishlar qaerda sodir bo'lganligini - tarmoqda yoki "server ichida" keyinroq taxmin qilmaslik uchun talab qilinadi. Siz tarmoq kartasi darajasidagi pasayishlarni ethtool -S ethX buyrug'i bilan tekshirishingiz mumkin, sozlash bir xil ettool tomonidan amalga oshiriladi (odatda siz RX buferini (-G) oshirishingiz kerak va ba'zida ba'zi yuklamalarni (-K) o'chirib qo'yishingiz kerak). Umumiy tavsiya sifatida tahlil qilingan trafikni qabul qilish uchun alohida portdan foydalanish tavsiya etiladi, agar iloji bo'lsa, bu boshqa trafik mavjudligi sababli analizator portida bir vaqtning o'zida pasayish sodir bo'lganligi sababli noto'g'ri pozitivlarni minimallashtiradi. Agar buning iloji bo'lmasa (siz bitta portli mini-kompyuter/NUC dan foydalanayotgan bo'lsangiz), tahlil qilingan trafikning ustuvorligini analizator ulangan qurilmada qolgan qismiga nisbatan sozlash juda tavsiya etiladi. Virtual muhitga kelsak, bu erda siz ehtiyot bo'lishingiz va jismoniy portdan boshlab virtual mashina ichidagi dastur bilan tugaydigan paket tomchilarini topishingiz kerak.
Xost ichida oqim yaratish va qabul qilish
TSDuck-ni tayyorlashda birinchi qadam sifatida biz netns-dan foydalangan holda bitta xost ichida trafik hosil qilamiz va qabul qilamiz.
Atrof muhitni tayyorlash:
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 в сторону veth0Atrof-muhit tayyor. Trafik analizatorini ishga tushiring:
ip netns exec P tsp --realtime -t
-I ip 239.0.0.1:1234
-P continuity
-P bitrate_monitor -p 1 -t 1
-O dropbu erda "-p 1 -t 1" har soniyada bit tezligini hisoblashingiz va har soniyada bit tezligi haqidagi ma'lumotlarni ko'rsatishingiz kerakligini anglatadi.
Biz 10 Mbit/s tezlikdagi trafik generatorini ishga tushiramiz:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234bu erda "-p 7 -e" 7 ta TS paketini 1 IP-paketga to'plashingiz va uni qattiq (-e) qilishingiz kerakligini anglatadi, ya'ni. IP paketini shakllantirishdan oldin har doim oxirgi protsessordan 7 ta TS paketini kuting.
Analizator kutilgan xabarlarni ko'rsatishni boshlaydi:
* 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/sEndi bir necha tomchi qo'shamiz:
ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROPva shunga o'xshash xabarlar paydo bo'ladi:
* 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 kutilayotgan. Biz paket yo'qolishini o'chirib qo'yamiz (ip netns exec P iptables -F) va generatorning bit tezligini 100 Mbit/s ga oshirishga harakat qilamiz. Analizator bir qator CC xatoliklari haqida xabar beradi va 75 o'rniga taxminan 100 Mbit/s. belgilangan paketlar soni (700000 100000 TS paket = XNUMX XNUMX IP paket):
# 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 0Ko'rib turganingizdek, roppa-rosa 100000 151925460 IP-paketlar yaratilgan (151825460-1). Shunday qilib, biz analizator bilan nima sodir bo'layotganini aniqlaymiz, buni amalga oshirish uchun veth0-dagi RX hisoblagichi bilan tekshiramiz, u vethXNUMX-dagi TX hisoblagichiga qat'iy teng, keyin rozetka darajasida nima sodir bo'layotganini ko'rib chiqamiz:
# 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 Bu erda siz tomchilar sonini ko'rishingiz mumkin = 24355. TS paketlarida bu 170485 ning 24.36 yoki 700000% ni tashkil qiladi, shuning uchun biz yo'qolgan bit tezligining bir xil 25% UDP soketidagi tomchilar ekanligini ko'ramiz. UDP soketidagi pasayishlar odatda bufer etishmasligi tufayli yuzaga keladi, keling, standart rozetka buferining o'lchami va soket buferining maksimal hajmi qanday ekanligini ko'rib chiqaylik:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Shunday qilib, agar ilovalar bufer hajmini aniq talab qilmasa, rozetkalar 208 KB bufer bilan yaratiladi, lekin agar ular ko'proq so'rasa, ular hali ham so'ragan narsani olmaydilar. tsp da siz IP kiritish uchun bufer hajmini (--bufer-size) o'rnatishingiz mumkin bo'lganligi sababli, biz standart rozetka o'lchamiga tegmaymiz, faqat maksimal soket bufer hajmini o'rnatamiz va bufer hajmini tsp argumentlari orqali aniq belgilaymiz:
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 dropSoket buferining bunday sozlanishi bilan xabar qilingan bit tezligi hozir taxminan 100 Mbit / s ni tashkil qiladi, CC xatosi yo'q.
tsp ilovasining o'zi tomonidan CPU iste'moliga asoslangan. Bitta yadroli i5-4260U CPU @ 1.40GHzga kelsak, 10Mbit/s oqimni tahlil qilish uchun protsessorning 3-4%, 100Mbit/s - 25%, 200Mbit/s - 46% kerak boʻladi. Paket yo'qotilishi% ni o'rnatganda, protsessor yuki deyarli oshmaydi (lekin kamayishi mumkin).
Samaradorroq uskunada hech qanday muammosiz 1 Gb/s dan ortiq oqimlarni yaratish va tahlil qilish mumkin edi.
Haqiqiy tarmoq kartalarida sinov
Veth juftligini sinab ko'rgandan so'ng, siz ikkita xostni yoki bitta xostning ikkita portini olishingiz, portlarni bir-biriga ulashingiz, generatorni birida, ikkinchisida analizatorni ishga tushirishingiz kerak. Bu erda hech qanday kutilmagan hodisalar yo'q edi, lekin aslida hamma narsa apparatga bog'liq, u qanchalik zaif bo'lsa, bu erda qiziqroq bo'ladi.
Monitoring tizimi tomonidan olingan ma'lumotlardan foydalanish (Zabbix)
tsp-da SNMP yoki shunga o'xshash kompyuterda o'qiladigan API mavjud emas. CC xabarlari bir vaqtning o'zida kamida 1 soniya davomida jamlanishi kerak (paket yo'qotishning yuqori foizi bilan, bit tezligiga qarab soniyada yuzlab/minglab/o'n minglab bo'lishi mumkin).
Shunday qilib, ma'lumotni saqlash va CC xatolari va bit tezligi uchun grafiklarni chizish va ba'zi bir baxtsiz hodisalarni davom ettirish uchun quyidagi variantlar bo'lishi mumkin:
- tsp chiqishini tahlil qilish va yig'ish (CC bo'yicha), ya'ni. uni kerakli shaklga aylantiring.
- Natija monitoring tizimiga mos keladigan mashina o'qiy oladigan shaklda chiqishi uchun tsp ning o'zini va/yoki bitrate_monitor va uzluksizlik protsessor plaginlarini qo'shing.
- Arizangizni tsduck kutubxonasi ustiga yozing.
Shubhasiz, mehnat xarajatlari nuqtai nazaridan, 1-variant eng sodda, ayniqsa tsduckning o'zi past darajadagi (zamonaviy standartlar bo'yicha) tilda (C++) yozilganligini hisobga olsak.
Bash-dagi parser + agregatorning oddiy prototipi shuni ko'rsatdiki, 10 Mbit / s tezlikda va 50% paket yo'qolishida (eng yomon holatda) bash jarayoni tsp jarayonining o'ziga qaraganda 3-4 baravar ko'proq CPU iste'mol qiladi. Bu stsenariy qabul qilinishi mumkin emas. Aslida, ushbu prototipning bir qismi quyida keltirilgan
Basha ustidagi noodle
#!/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
doneBu qabul qilib bo'lmaydigan darajada sekin ishlashiga qo'shimcha ravishda, bash-da oddiy ish zarralari yo'q, bash ishlari mustaqil jarayonlardir va men soniyada bir marta missingPackets qiymatini yon ta'sirga yozishim kerak edi (har soniyada keladigan bit tezligi xabarlarini qabul qilganda). Natijada, bash yolg'iz qoldi va golangda o'rash (parser + agregator) yozishga qaror qilindi. Golangda shunga o'xshash kodning CPU iste'moli tsp jarayonining o'zidan 4-5 baravar kam. Bashni golang bilan almashtirish orqali o'ramning tezlashishi taxminan 16 baravarni tashkil etdi va umuman natija maqbuldir (eng yomon holatda CPU qo'shimcha yuki 25% ga). Golang manba fayli joylashgan .
O'ramni ishga tushirish
O'ramni ishga tushirish uchun systemd uchun oddiy xizmat shablonini yaratildi (). O'ramning o'zi /opt/tsduck-stat/ da joylashgan ikkilik faylga (go build tsduck-stat.go) tuzilgan deb taxmin qilinadi. Golang monotonik soatni qo'llab-quvvatlash bilan ishlatiladi deb taxmin qilinadi (>=1.9).
Xizmatning namunasini yaratish uchun systemctl enable tsduck-stat@239.0.0.1:1234 buyrug'ini ishga tushirishingiz kerak, so'ngra systemctl start tsduck-stat@239.0.0.1:1234 yordamida ishga tushirishingiz kerak.
Zabbixdan kashfiyot
Shunday qilib, zabbix ishlaydigan xizmatlarni kashf qilishi mumkin, (discovery.sh), Zabbix kashfiyoti uchun zarur bo'lgan formatda, u bir joyda - /opt/tsduck-statda joylashgan deb taxmin qilinadi. Zabbix-agent orqali kashfiyotni ishga tushirish uchun siz qo'shishingiz kerak foydalanuvchi parametrini qo'shish uchun zabbix-agent konfiguratsiyasi bilan katalogga.
Zabbix shablon
(tsduck_stat_template.xml) avtomatik kashfiyot qoidasi, element, grafik va trigger prototiplarini o'z ichiga oladi.
Qisqa nazorat ro'yxati (agar kimdir undan foydalanishga qaror qilsa nima bo'ladi)
- tsp "ideal" sharoitlarda (generator va analizator to'g'ridan-to'g'ri ulangan) paketlarni tashlab ketmasligiga ishonch hosil qiling, agar tomchilar bo'lsa, 2-bandga yoki ushbu masala bo'yicha maqola matniga qarang.
- Maksimal rozetka buferini sozlashni amalga oshiring (net.core.rmem_max=8388608).
- Tsduck-stat.go-ni tuzing (tsduck-stat.go-ni yarating).
- Xizmat shablonini /lib/systemd/system-ga joylashtiring.
- Systemctl yordamida xizmatlarni ishga tushiring, hisoblagichlar paydo bo'lganligini tekshiring (grep "" /dev/shm/tsduck-stat/*). Multicast oqimlar soni bo'yicha xizmatlar soni. Bu erda siz multicast guruhiga marshrut yaratishingiz kerak bo'lishi mumkin, ehtimol rp_filterni o'chirib qo'yishingiz yoki IP manbasiga marshrut yaratishingiz mumkin.
- Discovery.sh ni ishga tushiring, u json ni yaratganiga ishonch hosil qiling.
- Zabbix agent konfiguratsiyasini joylashtiring, zabbix agentini qayta ishga tushiring.
- Shablonni zabbix-ga yuklang, uni monitoring olib boriladigan va zabbix-agent o'rnatilgan xostga qo'llang, taxminan 5 daqiqa kuting, yangi ma'lumotlar elementlari, grafiklar va triggerlar paydo bo'lganiga qarang.
natija
Paket yo'qotilishini aniqlash vazifasi uchun bu deyarli etarli, hech bo'lmaganda kuzatuvsiz yaxshiroqdir.
Aslida, CC "yo'qotishlar" video qismlarini birlashtirganda sodir bo'lishi mumkin (mening bilishimcha, Rossiya Federatsiyasining mahalliy televizion markazlarida qo'shimchalar shunday qilinadi, ya'ni CC hisoblagichini qayta hisoblamasdan), buni esga olish kerak. Xususiy echimlarda bu muammo SCTE-35 teglarini aniqlash orqali qisman chetlab o'tiladi (agar ular oqim generatori tomonidan qo'shilsa).
Transport sifati monitoringi nuqtai nazaridan jitter monitoringi (IAT) etarli emas, chunki Televizor uskunalari (modulyatorlar yoki so'nggi qurilmalar bo'ladimi) ushbu parametr uchun talablarga ega va jitbuferni cheksiz ravishda shishirish har doim ham mumkin emas. Tranzit katta buferli uskunadan foydalanganda va QoS sozlanmagan yoki real vaqtda bunday trafikni uzatish uchun yetarlicha sozlanmagan boʻlsa, jitter suzishi mumkin.
Manba: www.habr.com
