🥇Nganggo TSDuck kanggo ngawasi aliran IP(TS)

Saiki, ana solusi siap-digawe (proprietary) kanggo ngawasi IP(TS), contone VB и iQ, padha duwe pesawat cukup sugih saka fungsi lan biasane operator gedhe dealing with layanan TV duwe solusi kuwi. Artikel iki nerangake solusi adhedhasar proyek open source TSDuck, dirancang kanggo kontrol minimal IP(TS) stream dening CC(kontinuitas counter) counter lan bitrate. A aplikasi bisa kontrol mundhut saka paket utawa kabeh aliran liwat saluran L2 disewakake (sing ora bisa ngawasi biasane, contone, dening maca mundhut counters ing antrian).

Sedhela banget babagan TSDuck

TSDuck minangka piranti lunak open source (lisensi 2-Clause BSD) (sakumpulan utilitas konsol lan perpustakaan kanggo ngembangake utilitas utawa plugin khusus) kanggo manipulasi aliran TS. Minangka input, bisa karo IP (multicast / unicast), http, hls, dvb tuners, dektec dvb-asi demodulator, ana internal TS-stream generator lan maca saka file. Output bisa nulis menyang file, IP (multicast / unicast), hls, dektec dvb-asi lan modulator HiDes, pemain (mplayer, vlc, xine) lan nyelehake. Macem-macem pemroses lalu lintas bisa kalebu ing antarane input lan output, contone, remapping PID, scrambling / descrambling, analisis kontra CC, pitungan bitrate, lan operasi khas liyane kanggo aliran TS.

Ing artikel iki, IP stream (multicast) bakal digunakake minangka input, prosesor bitrate_monitor (saka jeneng iku cetha apa iku) lan lampahing (analisis CC counters) digunakake. Sampeyan bisa kanthi gampang ngganti IP multicast karo jinis input liyane sing didhukung dening TSDuck.

kasedhiya bangunan resmi / paket TSDuck kanggo paling sistem operasi saiki. Dheweke ora kasedhiya kanggo Debian, nanging kita bisa mbangun ing debian 8 lan debian 10 tanpa masalah.

Sabanjure, versi TSDuck 3.19-1520 digunakake, Linux digunakake minangka OS (debian 10 digunakake kanggo nyiapake solusi, CentOS 7 digunakake kanggo panggunaan nyata)

Nyiyapake TSDuck lan OS

Sadurunge ngawasi aliran nyata, sampeyan kudu mesthekake yen TSDuck bisa digunakake kanthi bener lan ora ana tetes ing tingkat kertu jaringan utawa OS (soket). Iki dibutuhake supaya ora ngira ing endi tetesan kasebut kedadeyan - ing jaringan utawa "ing server". Sampeyan bisa mriksa irungnya ing tingkat kertu jaringan karo printah ethtool -S ethX, tuning wis rampung dening ethtool padha (biasane, sampeyan kudu nambah buffer RX (-G) lan kadhangkala mateni sawetara offloads (-K)). Minangka Rekomendasi umum, iku bisa menehi saran kanggo nggunakake port kapisah kanggo nampa lalu lintas analisa, yen bisa, iki minimalake positif palsu gadhah kasunyatan sing gulung kedaden persis ing port analyzer amarga ana lalu lintas liyane. Yen iki ora bisa (mini-komputer / NUC karo siji port digunakake), iku Highly seng di pengeni kanggo nyetel prioritization saka lalu lintas analisa ing hubungan kanggo liyane ing piranti kang analyzer disambungake. Babagan lingkungan virtual, ing kene sampeyan kudu ngati-ati lan bisa nemokake tetes paket wiwit saka port fisik lan diakhiri karo aplikasi ing mesin virtual.

Generasi lan reception saka stream nang inang

Minangka langkah pisanan kanggo nyiapake TSDuck, kita bakal ngasilake lan nampa lalu lintas ing host siji nggunakake netns.

Persiapan lingkungan:

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

Lingkungan wis siyap. Kita miwiti analisa lalu lintas:

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

ing ngendi "-p 1 -t 1" tegese sampeyan kudu ngetung bitrate saben detik lan nampilake informasi babagan bitrate saben detik
Kita miwiti generator lalu lintas kanthi kacepetan 10Mbps:

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

ngendi "-p 7 -e" tegese sampeyan kudu Pack 7 paket TS menyang 1 paket IP lan nindakake hard (-e), i.e. tansah ngenteni 7 paket TS saka prosesor pungkasan sadurunge ngirim paket IP.

Analyzer wiwit ngasilake pesen sing dikarepake:

* 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

Saiki nambah sawetara tetes:

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

lan pesen kaya iki katon:

* 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

kang dikarepake. Pateni mundhut paket (ip netns exec P iptables -F) lan nyoba kanggo nambah bitrate generator kanggo 100Mbps. Analyzer nglaporake akeh kesalahan CC lan udakara 75 Mbps tinimbang 100. Kita nyoba ngerteni sapa sing kudu disalahake - generator ora duwe wektu utawa masalah ora ana, mula mula ngasilake nomer tetep. paket (700000 paket TS = 100000 paket 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

Kaya sing sampeyan ngerteni, persis 100000 paket IP digawe (151925460-151825460). Dadi ayo ngerteni apa sing kedadeyan karo penganalisa, mula kita mriksa karo counter RX ing veth1, iku padha karo counter TX ing veth0, banjur ndeleng apa sing kedadeyan ing tingkat soket:

# 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

Kene sampeyan bisa ndeleng nomer irungnya = 24355. Ing paket TS, iki 170485 utawa 24.36% saka 700000, supaya kita waca sing padha 25% bitrate ilang irungnya ing soket udp. Tetes ing soket UDP biasane kedadeyan amarga kekurangan buffer, deleng ukuran buffer soket standar lan ukuran buffer soket maksimal:

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

Mangkono, yen aplikasi ora kanthi tegas njaluk ukuran buffer, soket digawe kanthi buffer 208 KB, nanging yen njaluk luwih akeh, dheweke ora bakal nampa apa sing dijaluk. Awit sampeyan bisa nyetel ukuran buffer ing tsp kanggo input IP (-buffer-size), kita ora bakal ndemek ukuran soket standar, nanging mung nyetel ukuran buffer soket maksimum lan nemtokake ukuran buffer tegas liwat bantahan 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

Kanthi tuning buffer soket, saiki bitrate sing dilaporake kira-kira 100Mbps, ora ana kesalahan CC.

Miturut konsumsi CPU saka aplikasi tsp dhewe. Relatif siji inti i5-4260U CPU @ 1.40GHz, analisis aliran 10Mbps mbutuhake 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%. Nalika nyetel% Packet Loss, beban ing CPU prakteke ora nambah (nanging bisa nyuda).

Ing hardware sing luwih produktif, bisa ngasilake lan nganalisa aliran luwih saka 1Gb / s tanpa masalah.

Testing ing kertu jaringan nyata

Sawise nyoba ing pasangan veth, sampeyan kudu njupuk loro sarwa dumadi utawa loro bandar siji inang, nyambung bandar kanggo saben liyane, miwiti generator ing siji, lan analyzer ing kaloro. Ora ana kejutan ing kene, nanging nyatane kabeh gumantung saka wesi, sing luwih lemah, sing luwih menarik bakal ana ing kene.

Nggunakake data sing ditampa dening sistem pemantauan (Zabbix)

tsp ora duwe API sing bisa diwaca mesin kaya SNMP utawa sing padha. Pesen CC kudu dikumpulake paling sethithik 1 detik (kanthi persentase mundhut paket sing dhuwur, bisa uga atusan / ewu / puluhan ewu per detik, gumantung saka bitrate).

Dadi, kanggo nyimpen informasi lan nggambar grafik kanggo kesalahan CC lan bitrate lan nggawe sawetara kacilakan, bisa uga ana pilihan ing ngisor iki:

Parse lan agregat (dening CC) output saka tsp, i.e. Ngonversi menyang wangun sing dikarepake.
Rampung tsp dhewe lan / utawa plugin prosesor bitrate_monitor lan lampahing supaya asil diwenehi ing wangun mesin-diwaca cocok kanggo sistem ngawasi.
Tulis aplikasi sampeyan ing ndhuwur perpustakaan tsduck.

Temenan, pilihan 1 minangka sing paling gampang babagan upaya, utamane amarga tsduck dhewe ditulis ing basa tingkat rendah (kanthi standar modern) (C ++)

Prototipe bash parser + aggregator prasaja nuduhake yen ing stream 10Mbps lan mundhut paket 50% (kasus paling awon), proses bash nggunakake CPU kaping 3-4 luwih akeh tinimbang proses tsp dhewe. Skenario iki ora bisa ditampa. Bener, potongan prototipe ing ngisor iki

Mie ing ndhuwur

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

Saliyane ora bisa ditampa kanthi alon, ora ana benang normal ing bash, proyek bash minangka proses sing kapisah lan aku kudu nulis nilai missingPackets sapisan sapisan ing efek sisih (nalika nampa pesen bitrate sing teka saben detik). Akibaté, bash ditinggalake lan diputusake kanggo nulis bungkus (parser + aggregator) ing golang. Konsumsi CPU kode golang padha 4-5 kaping kurang saka proses tsp dhewe. Nyepetake pambungkus amarga ngganti bash karo golang dadi kira-kira 16 kaping lan umume asil bisa ditampa (CPU overhead 25% ing kasus paling awon). File sumber golang dumunung kene.

Mbukak bungkus

Kanggo miwiti pambungkus, template layanan paling gampang kanggo systemd digawe (kene). Pambungkus dhewe mesthine bakal dikompilasi dadi file binar (go build tsduck-stat.go) sing ana ing /opt/tsduck-stat/. Dianggep sampeyan nggunakake golang kanthi dhukungan kanggo jam monoton (>=1.9).

Kanggo nggawe conto layanan kasebut, sampeyan kudu mbukak perintah systemctl enable [email dilindhungi]: 1234 banjur mbukak karo systemctl wiwitan [email dilindhungi]: 1234.

Panemuan saka Zabbix

Supaya zabbix bisa nemokake layanan sing mlaku, wis rampung dhaftar grup generator (discovery.sh), ing format sing dibutuhake kanggo panemuan Zabbix, dianggep sing dumunung ing panggonan sing padha - ing /opt/tsduck-stat. Kanggo mbukak panemuan liwat zabbix-agen, sampeyan kudu nambah file .conf menyang direktori konfigurasi zabbix-agen kanggo nambah parameter pangguna.

Cithakan Zabbix

Cithakan sing digawe (tsduck_stat_template.xml) ngemot aturan autodiscover, prototipe item, grafik, lan pemicu.

Dhaptar priksa singkat (ya, yen ana sing mutusake nggunakake)

Priksa manawa tsp ora nyelehake paket ing kahanan "becik" (generator lan analisa disambungake langsung), yen ana tetes, deleng paragraf 2 utawa teks artikel babagan perkara iki.
Nggawe tuning buffer soket maksimum (net.core.rmem_max=8388608).
Kompilasi tsduck-stat.go (go mbangun tsduck-stat.go).
Sijine template layanan ing /lib/systemd/system.
Miwiti layanan karo systemctl, priksa manawa counter wis wiwit katon (grep "" / dev / shm / tsduck-stat / *). Jumlah layanan kanthi jumlah aliran multicast. Kene sampeyan bisa uga kudu nggawe rute menyang grup multicast, mbok menawa mateni rp_filter utawa nggawe rute menyang ip sumber.
Jalanake discovery.sh, priksa manawa nggawe json.
Tambah konfigurasi agen zabbix, restart agen zabbix.
Upload cithakan kanggo zabbix, aplikasi menyang inang sing lagi teliti lan zabbix-agen diinstal, ngenteni bab 5 menit, ndeleng yen ana item anyar, grafik lan pemicu.

asil

Kanggo tugas ndeteksi mundhut paket, meh cukup, paling ora luwih apik tinimbang ora ngawasi.

Pancen, "rugi" CC bisa kedadeyan nalika nggabungake fragmen video (sing aku ngerti, iki cara sisipan digawe ing pusat TV lokal ing Federasi Rusia, yaiku tanpa ngitung ulang counter CC), iki kudu dieling-eling. Solusi kepemilikan sebagian ngatasi masalah iki kanthi ndeteksi label SCTE-35 (yen ditambahake dening generator stream).

Ing babagan ngawasi kualitas transportasi, ana kekurangan jitter monitoring (IAT). peralatan TV (dadi modulators utawa piranti pungkasan) nduweni syarat kanggo parameter iki lan ora tansah bisa kanggo inflate jitbuffer kanggo tanpa wates. Lan jitter bisa ngambang nalika peralatan karo buffer gedhe digunakake ing transit lan QoS ora diatur utawa ora cukup diatur kanggo ngirim lalu lintas realtime kuwi.

Source: www.habr.com

Nggunakake TSDuck kanggo ngawasi IP (TS) Aliran