Bu gün, məsələn, IP(TS) axınlarının monitorinqi üçün hazır (mülkiyyət) həllər var и , onların kifayət qədər zəngin funksiyalar dəsti var və adətən televiziya xidmətləri ilə məşğul olan böyük operatorlar belə həllərə malikdirlər. Bu məqalə açıq mənbə layihəsinə əsaslanan həlli təsvir edir , CC (davamlılıq sayğacı) sayğacı və bit sürəti ilə IP(TS) axınlarına minimal nəzarət üçün nəzərdə tutulmuşdur. Mümkün bir tətbiq paketlərin itirilməsinə və ya icarəyə götürülmüş L2 kanalı vasitəsilə bütün axına nəzarət etməkdir (bu, məsələn, növbələrdə itki sayğaclarını oxumaqla normal şəkildə izlənilə bilməz).
TSDuck haqqında çox qısa
TSDuck TS axınlarını manipulyasiya etmək üçün açıq mənbəli (2-bəndli BSD lisenziyası) proqram təminatıdır (konsol yardım proqramları dəsti və xüsusi yardım proqramları və ya plaginlər hazırlamaq üçün kitabxana). Giriş kimi IP (multicast/unicast), http, hls, dvb tunerləri, dektec dvb-asi demodulyatoru ilə işləyə bilər, daxili TS-stream generatoru və faylların oxunması mövcuddur. Çıxış fayla, IP (multicast/unicast), hls, dektec dvb-asi və HiDes modulatorlarına, pleyerlərə (mplayer, vlc, xine) və düşməyə yazıla bilər. Giriş və çıxış arasında müxtəlif trafik prosessorları daxil edilə bilər, məsələn, PID remapping, scrambling/descrambling, CC counter analizi, bitrate hesablanması və TS axınları üçün digər tipik əməliyyatlar.
Bu məqalədə giriş kimi IP axınları (multicast) istifadə olunacaq, bitrate_monitor prosessorları (adından aydındır ki, nə olduğu aydındır) və davamlılıq (CC sayğaclarının təhlili) istifadə olunur. Siz asanlıqla IP multicast TSDuck tərəfindən dəstəklənən başqa giriş növü ilə əvəz edə bilərsiniz.
Var var Ən müasir əməliyyat sistemləri üçün TSDuck. Onlar Debian üçün mövcud deyil, lakin biz onları debian 8 və debian 10 altında heç bir problem olmadan qura bildik.
Sonra TSDuck 3.19-1520 versiyası istifadə olunur, OS kimi Linux istifadə olunur (həllin hazırlanması üçün debian 10, real istifadə üçün CentOS 7 istifadə edilmişdir)
TSDuck və ƏS-nin hazırlanması
Həqiqi axınları izləməzdən əvvəl TSDuck-un düzgün işlədiyinə və şəbəkə kartı və ya OS (soket) səviyyəsində heç bir düşmə olmadığına əmin olmalısınız. Bu, sonradan düşmələrin harada baş verdiyini təxmin etməmək üçün tələb olunur - şəbəkədə və ya "server daxilində". Siz ethtool -S ethX əmri ilə şəbəkə kartı səviyyəsində düşmələri yoxlaya bilərsiniz, sazlama eyni ettool tərəfindən həyata keçirilir (adətən, RX buferini (-G) artırmaq və bəzən bəzi yüklənmələri (-K) deaktiv etmək lazımdır). Ümumi bir tövsiyə olaraq, təhlil edilən trafiki qəbul etmək üçün ayrıca bir portdan istifadə etmək tövsiyə edilə bilər, əgər mümkünsə, bu, digər trafikin olması səbəbindən düşmənin dəqiq analizator portunda baş verməsi ilə əlaqəli yanlış müsbətləri minimuma endirir. Əgər bu mümkün deyilsə (bir portlu mini-kompüter/NUC istifadə olunur), onda analizatorun qoşulduğu cihazda qalan hissəsi ilə bağlı təhlil edilən trafikin prioritetini konfiqurasiya etmək çox məqsədəuyğundur. Virtual mühitlərə gəlincə, burada diqqətli olmalı və fiziki portdan başlayaraq virtual maşın daxilindəki proqramla bitən paket düşmələrini tapa bilməlisiniz.
Host daxilində axının yaradılması və qəbulu
TSDuck-un hazırlanmasında ilk addım olaraq biz netns-dən istifadə edərək bir host daxilində trafik yaradacaq və qəbul edəcəyik.
Ətraf mühitin hazırlanması:
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Ətraf mühit hazırdır. Trafik analizatorunu işə salırıq:
ip netns exec P tsp --realtime -t
-I ip 239.0.0.1:1234
-P continuity
-P bitrate_monitor -p 1 -t 1
-O dropburada "-p 1 -t 1" o deməkdir ki, siz hər saniyə bit sürətini hesablamalısınız və hər saniyə bit sürəti haqqında məlumat göstərməlisiniz.
Trafik generatorunu 10 Mbit / s sürətlə işə salırıq:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234burada "-p 7 -e" o deməkdir ki, 7 TS paketini 1 IP paketinə yığmalı və bunu çətin (-e) etməlisiniz, yəni. IP paketini göndərməzdən əvvəl həmişə sonuncu prosessordan 7 TS paketini gözləyin.
Analizator gözlənilən mesajları çıxarmağa başlayır:
* 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İndi bir neçə damcı əlavə edin:
ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROPvə bu kimi mesajlar görünür:
* 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 gözlənilən. Paket itkisini söndürün (ip netns exec P iptables -F) və generatorun bit sürətini 100Mbps-ə qədər artırmağa çalışın. Analizator bir dəstə CC səhvləri və 75 əvəzinə təxminən 100 Mbit / s məlumat verir. Biz kimin günahkar olduğunu anlamağa çalışırıq - generatorun vaxtı yoxdur və ya problem onda deyil, bunun üçün biz sabit sayda yaratmağa başlayırıq. paketlər (700000 TS paket = 100000 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 0Göründüyü kimi, tam olaraq 100000 IP paket yaradılıb (151925460-151825460). Beləliklə, analizatorla nə baş verdiyini anlayaq, bunun üçün veth1-də RX sayğacı ilə yoxlayırıq, o, veth0-dakı TX sayğacına ciddi şəkildə bərabərdir, sonra rozetka səviyyəsində nə baş verdiyinə baxırıq:
# 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 Burada damcıların sayını görə bilərsiniz = 24355. TS paketlərində bu, 170485-dən 24.36 və ya 700000% -dir, beləliklə, itirilmiş bit sürətinin eyni 25% -nin udp yuvasındakı damlalar olduğunu görürük. UDP yuvasındakı düşmələr adətən bufer çatışmazlığı səbəbindən baş verir, standart soket bufer ölçüsünə və maksimum yuva bufer ölçüsünə baxın:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Beləliklə, tətbiqlər bufer ölçüsünü açıq şəkildə tələb etmirsə, soketlər 208 KB buferlə yaradılır, lakin daha çox tələb etsələr, hələ də tələb olunanı qəbul etməyəcəklər. IP girişi üçün bufer ölçüsünü tsp-də təyin edə bildiyiniz üçün (-bufer ölçüsü), biz standart rozetka ölçüsünə toxunmayacağıq, ancaq maksimum soket bufer ölçüsünü təyin edəcəyik və tsp arqumentləri vasitəsilə bufer ölçüsünü açıq şəkildə təyin edəcəyik:
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 buferinin bu tənzimləməsi ilə indi bildirilən bit sürəti təxminən 100Mbps-dir, CC səhvləri yoxdur.
TSP tətbiqinin özünün CPU istehlakına görə. Bir nüvəli i5-4260U CPU @ 1.40GHz ilə müqayisədə, 10Mbps axını təhlili üçün 3-4% CPU, 100Mbps - 25%, 200Mbps - 46% tələb olunur. % Paket İtkisini təyin edərkən CPU-ya yük praktiki olaraq artmır (lakin azala bilər).
Daha məhsuldar aparatda heç bir problem olmadan 1Gb/s-dən çox axını yaratmaq və təhlil etmək mümkün idi.
Real şəbəkə kartlarında sınaq
Bir veth cütündə sınaqdan keçirdikdən sonra iki host və ya bir hostun iki portunu götürməli, portları bir-birinə qoşmalı, birində generatoru, ikincisində isə analizatoru işə salmalısınız. Burada sürprizlər yox idi, amma əslində hər şey dəmirdən asılıdır, nə qədər zəif olsa, burada daha maraqlı olacaq.
Monitorinq sistemi (Zabbix) tərəfindən alınan məlumatlardan istifadə
tsp-də SNMP və ya bənzəri kimi maşın tərəfindən oxuna bilən API yoxdur. CC mesajları ən azı 1 saniyə ərzində birləşdirilməlidir (paket itkisinin yüksək faizi ilə bit sürətindən asılı olaraq saniyədə yüzlərlə/minlərlə/on minlərlə ola bilər).
Beləliklə, həm məlumatı saxlamaq, həm də CC səhvləri və bit sürəti üçün qrafiklər çəkmək və bir növ qəza etmək üçün aşağıdakı seçimlər ola bilər:
- tsp-nin çıxışını təhlil edin və birləşdirin (CC ilə), yəni. onu istədiyiniz formaya çevirin.
- TSP-nin özünü və/yaxud prosessor plaginlərini bitrate_monitor və davamlılığı bitirin ki, nəticə monitorinq sistemi üçün uyğun maşın tərəfindən oxuna bilən formada verilsin.
- Ərizənizi tsduck kitabxanasının üstünə yazın.
Aydındır ki, 1-ci seçim səy baxımından ən asandır, xüsusən də tsduck-in özünün aşağı səviyyəli (müasir standartlara görə) bir dildə (C ++) yazıldığını nəzərə alsaq.
Sadə bir bash parser+aqreqator prototipi göstərdi ki, 10Mbps axın və 50% paket itkisi zamanı (ən pis halda) bash prosesi tsp prosesinin özündən 3-4 dəfə çox CPU istehlak edir. Bu ssenari qəbuledilməzdir. Əslində aşağıda bu prototipin bir parçası
Üstündə əriştə
#!/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
doneYolverilməz dərəcədə yavaş olması ilə yanaşı, bash-da normal mövzular yoxdur, bash jobs ayrı-ayrı proseslərdir və yan təsirə saniyədə bir dəfə missingPackets dəyərini yazmalı oldum (hər saniyədə gələn bit sürəti mesajları qəbul edərkən). Nəticədə, bash tək qaldı və qolanqda sarmalayıcı (parser + aqreqator) yazmaq qərara alındı. Bənzər golanq kodunun CPU istehlakı tsp prosesinin özündən 4-5 dəfə azdır. Başın golanq ilə dəyişdirilməsi səbəbindən sarğı sürəti təxminən 16 dəfə oldu və ümumiyyətlə nəticə məqbuldur (ən pis halda CPU-nun 25% yükü). Golang mənbə faylı yerləşir .
Qapağı işə salın
Paketi işə salmaq üçün systemd üçün ən sadə xidmət şablonu hazırlanmışdır (). Qapağın özünün /opt/tsduck-stat/-də yerləşən ikili fayla (go build tsduck-stat.go) yığılması nəzərdə tutulur. Güman edilir ki, siz monoton saat dəstəyi ilə qolanqdan istifadə edirsiniz (>=1.9).
Xidmətin nümunəsini yaratmaq üçün systemctl enable əmrini işlətməlisiniz [e-poçt qorunur]:1234 sonra systemctl start ilə işləyin [e-poçt qorunur]: 1234.
Zabbix-dən kəşf
Zabbix-in işləyən xidmətləri kəşf edə bilməsi üçün bu edilir (discovery.sh), Zabbix kəşfi üçün tələb olunan formatda onun eyni yerdə - /opt/tsduck-stat-da yerləşdiyi güman edilir. Zabbix-agent vasitəsilə kəşfi işə salmaq üçün əlavə etməlisiniz istifadəçi parametrini əlavə etmək üçün zabbix-agent konfiqurasiya qovluğuna.
Zabbix şablonu
(tsduck_stat_template.xml) avtomatik kəşf qaydasını, element prototiplərini, qrafikləri və triggerləri ehtiva edir.
Qısa yoxlama siyahısı (yaxşı, kimsə ondan istifadə etmək qərarına gəlsə nə olacaq)
- TSP-nin "ideal" şəraitdə paketləri atmamasına əmin olun (generator və analizator birbaşa bağlıdır), düşmələr varsa, 2-ci paraqrafa və ya bu mövzuda məqalənin mətninə baxın.
- Maksimum yuva buferini tənzimləyin (net.core.rmem_max=8388608).
- Tsduck-stat.go-nu tərtib edin (get, tsduck-stat.go-nu qurun).
- Xidmət şablonunu /lib/systemd/system-ə qoyun.
- Systemctl ilə xidmətləri işə salın, sayğacların görünməyə başladığını yoxlayın (grep "" /dev/shm/tsduck-stat/*). Multicast axınların sayına görə xidmətlərin sayı. Burada multicast qrupuna marşrut yaratmaq, bəlkə də rp_filter-i söndürmək və ya mənbə ip-ə marşrut yaratmaq lazım ola bilər.
- Discovery.sh-i işə salın, onun json yaratdığından əmin olun.
- Zabbix agent konfiqurasiyasını əlavə edin, zabbix agentini yenidən başladın.
- Şablonu zabbix-ə yükləyin, onu nəzarət edilən və zabbix-agent quraşdırılmış hosta tətbiq edin, təxminən 5 dəqiqə gözləyin, yeni elementlərin, qrafiklərin və tetikleyicilərin olub-olmamasına baxın.
Nəticə
Paket itkisini aşkar etmək vəzifəsi üçün demək olar ki, kifayətdir, heç olmasa monitorinq etməməkdən yaxşıdır.
Həqiqətən, video fraqmentləri birləşdirərkən CC "itkiləri" baş verə bilər (bildiyimə görə, Rusiya Federasiyasının yerli televiziya mərkəzlərində əlavələr belə edilir, yəni CC sayğacını yenidən hesablamadan), bunu xatırlamaq lazımdır. Mülkiyyət həlləri SCTE-35 etiketlərini aşkar edərək (axın generatoru tərəfindən əlavə olunarsa) bu problemi qismən aradan qaldırır.
Nəqliyyat keyfiyyətinin monitorinqi baxımından citter monitorinqinin (IAT) çatışmazlığı var. Televiziya avadanlıqları (istər modulyatorlar, istərsə də son qurğular) bu parametr üçün tələblərə malikdir və jitbuferi sonsuza qədər şişirtmək həmişə mümkün deyil. Böyük buferləri olan avadanlıq tranzitdə istifadə edildikdə və QoS konfiqurasiya edilmədikdə və ya belə real vaxt trafikini ötürmək üçün kifayət qədər yaxşı konfiqurasiya edilmədikdə titrəmə baş verə bilər.
Mənbə: www.habr.com