TSDuck-ის გამოყენება IP(TS) ნაკადების მონიტორინგისთვის

დღეს, არსებობს მზა (საკუთრების) გადაწყვეტილებები IP(TS) ნაკადების მონიტორინგისთვის, მაგალითად VB и iQმათ აქვთ ფუნქციების საკმაოდ მდიდარი ნაკრები და, როგორც წესი, მსხვილ ოპერატორებს, რომლებიც სატელევიზიო სერვისებით არიან დაკავებულნი, აქვთ ასეთი გადაწყვეტილებები. ეს სტატია აღწერს გამოსავალს, რომელიც დაფუძნებულია ღია კოდის პროექტზე TSDuck, შექმნილია IP(TS) ნაკადების მინიმალური კონტროლისთვის CC (განგრძობითობის მრიცხველი) მრიცხველისა და ბიტის სიჩქარით. შესაძლო აპლიკაციაა პაკეტების დაკარგვის ან მთელი ნაკადის კონტროლი იჯარით L2 არხზე (რომლის მონიტორინგი ნორმალურად შეუძლებელია, მაგალითად, რიგებში დანაკარგების მრიცხველების წაკითხვით).

ძალიან მოკლედ TSDuck-ის შესახებ

TSduck არის ღია კოდის (2-პუნქტიანი BSD ლიცენზია) პროგრამული უზრუნველყოფა (კონსოლის კომუნალური საშუალებების ნაკრები და ბიბლიოთეკა პერსონალური კომუნალური საშუალებების ან დანამატების შესაქმნელად) TS ნაკადების მანიპულირებისთვის. როგორც შეყვანა, მას შეუძლია იმუშაოს IP (multicast/unicast), http, hls, dvb ტიუნერებით, dektec dvb-asi დემოდულატორით, არის შიდა TS ნაკადის გენერატორი და ფაილებიდან კითხვა. გამომავალი შეიძლება იყოს ჩაწერა ფაილზე, IP (multicast/unicast), hls, dektec dvb-asi და HiDes მოდულატორები, მოთამაშეები (mplayer, vlc, xine) და ჩამოაგდეს. სხვადასხვა ტრაფიკის პროცესორები შეიძლება ჩართული იყოს შეყვანასა და გამომავალს შორის, მაგალითად, PID ხელახალი რუქა, გადარევა/დაშლა, CC მრიცხველის ანალიზი, ბიტის სიჩქარის გაანგარიშება და სხვა ტიპიური ოპერაციები TS ნაკადებისთვის.

ამ სტატიაში გამოყენებული იქნება IP ნაკადები (multicast) როგორც შეყვანა, პროცესორები bitrate_monitor (სახელიდან ირკვევა რა არის) და უწყვეტობა (CC მრიცხველების ანალიზი). თქვენ შეგიძლიათ მარტივად შეცვალოთ IP multicast სხვა შეყვანის ტიპით, რომელსაც მხარს უჭერს TSDuck.

ხელმისაწვდომია ოფიციალური ნაგებობები/პაკეტები TSDuck უმრავლესობის მიმდინარე ოპერაციული სისტემებისთვის. ისინი მიუწვდომელია Debian-ისთვის, მაგრამ ჩვენ მოვახერხეთ მათი აშენება debian 8-ზე და debian 10-ზე უპრობლემოდ.

შემდეგი, ვერსია TSDuck 3.19-1520 გამოიყენება, Linux გამოიყენება როგორც OS (debian 10 გამოიყენებოდა გადაწყვეტის მოსამზადებლად, CentOS 7 გამოიყენებოდა რეალური გამოყენებისთვის)

TSDuck-ისა და OS-ის მომზადება

რეალური ნაკადების მონიტორინგამდე, თქვენ უნდა დარწმუნდეთ, რომ TSDuck მუშაობს სწორად და არ არის ვარდნა ქსელის ბარათის ან OS (სოკეტის) დონეზე. ეს საჭიროა იმისათვის, რომ მოგვიანებით არ გამოიცნოთ სად მოხდა ვარდნა - ქსელში ან "სერვერის შიგნით". თქვენ შეგიძლიათ შეამოწმოთ ვარდნა ქსელის ბარათის დონეზე ethtool -S ethX ბრძანებით, ტიუნინგი კეთდება იმავე ethtool-ით (ჩვეულებრივ, საჭიროა RX ბუფერის გაზრდა (-G) და ზოგჯერ გამორთოთ ზოგიერთი გადმოტვირთვა (-K)). როგორც ზოგადი რეკომენდაცია, შეიძლება გირჩიოთ ცალკე პორტის გამოყენება გაანალიზებული ტრაფიკის მისაღებად, თუ ეს შესაძლებელია, ეს ამცირებს ცრუ პოზიტივებს, რომლებიც დაკავშირებულია იმ ფაქტთან, რომ ვარდნა მოხდა ზუსტად ანალიზატორის პორტზე სხვა ტრაფიკის არსებობის გამო. თუ ეს შეუძლებელია (გამოიყენება მინი კომპიუტერი/NUC ერთი პორტით), მაშინ ძალიან სასურველია გაანალიზებული ტრაფიკის პრიორიტეტების დაყენება დანარჩენთან მიმართებაში მოწყობილობაზე, რომელსაც უკავშირდება ანალიზატორი. რაც შეეხება ვირტუალურ გარემოს, აქ თქვენ უნდა იყოთ ფრთხილად და შეგეძლოთ იპოვოთ პაკეტის წვეთები, დაწყებული ფიზიკური პორტიდან და დამთავრებული აპლიკაციით ვირტუალური მანქანის შიგნით.

ნაკადის გენერაცია და მიღება მასპინძლის შიგნით

როგორც TSDuck-ის მომზადების პირველი ნაბიჯი, ჩვენ გამოვქმნით და მივიღებთ ტრაფიკს ერთ ჰოსტში ქსელების გამოყენებით.

გარემოს მომზადება:

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 Mbps სიჩქარით:

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), ე.ი. ყოველთვის დაელოდეთ 7 TS პაკეტს ბოლო პროცესორიდან IP პაკეტის გაგზავნამდე.

ანალიზატორი იწყებს მოსალოდნელი შეტყობინებების გამოტანას:

* 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 Mbps-მდე. ანალიზატორი აცნობებს CC შეცდომებს და დაახლოებით 75 Mbps 100-ის ნაცვლად. ჩვენ ვცდილობთ გავარკვიოთ ვინ არის დამნაშავე - გენერატორს დრო არ აქვს ან პრობლემა მასში არ არის, ამისათვის ვიწყებთ ფიქსირებული რაოდენობის გენერირებას. პაკეტები (700000 TS პაკეტი = 100000 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 IP პაკეტი (151925460-151825460). მოდით გავარკვიოთ რა ხდება ანალიზატორთან, ამისათვის ჩვენ ვამოწმებთ RX მრიცხველს veth1-ზე, ის მკაცრად უდრის TX მრიცხველს veth0-ზე, შემდეგ ვუყურებთ რა ხდება სოკეტის დონეზე:

# 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 KB ბუფერით, მაგრამ თუ ისინი მოითხოვენ მეტს, ისინი მაინც ვერ მიიღებენ იმას, რაც მოითხოვეს. იმის გამო, რომ თქვენ შეგიძლიათ დააყენოთ ბუფერის ზომა 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 Mbps, არ არის CC შეცდომები.

თავად tsp აპლიკაციის CPU მოხმარების მიხედვით. ერთი ბირთვით i5-4260U CPU @ 1.40GHz-თან შედარებით, 10Mbps ნაკადის ანალიზს დასჭირდება 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%. % Packet Loss-ის დაყენებისას, CPU-ზე დატვირთვა პრაქტიკულად არ იზრდება (მაგრამ შეიძლება შემცირდეს).

უფრო პროდუქტიულ აპარატურაზე, უპრობლემოდ იყო შესაძლებელი 1 გბ/წმ-ზე მეტი ნაკადების გენერირება და ანალიზი.

ტესტირება რეალურ ქსელის ბარათებზე

Veth წყვილზე ტესტირების შემდეგ, თქვენ უნდა აიღოთ ორი ჰოსტი ან ერთი ჰოსტის ორი პორტი, დააკავშიროთ პორტები ერთმანეთთან, ჩართოთ გენერატორი ერთზე, ხოლო ანალიზატორი მეორეზე. აქ სიურპრიზები არ ყოფილა, მაგრამ სინამდვილეში ყველაფერი რკინაზეა დამოკიდებული, რაც უფრო სუსტი იქნება, მით უფრო საინტერესო იქნება აქ.

მონიტორინგის სისტემის მიერ მიღებული მონაცემების გამოყენება (Zabbix)

tsp-ს არ აქვს მანქანით წაკითხვადი API, როგორიცაა SNMP ან მსგავსი. CC შეტყობინებები უნდა იყოს აგრეგირებული მინიმუმ 1 წამის განმავლობაში (პაკეტების დაკარგვის მაღალი პროცენტით, შეიძლება იყოს ასობით/ათასობით/ათიათასობით წამში, ბიტის სიჩქარის მიხედვით).

ამრიგად, ინფორმაციის შესანახად და CC შეცდომების და ბიტური სიჩქარის გრაფიკების დასახატად და რაიმე სახის უბედური შემთხვევისთვის, შეიძლება არსებობდეს შემდეგი ვარიანტები:

1. ჩ/კ-ის გამომავალი გაანალიზება და აგრეგაცია (CC-ით), ე.ი. გადაიყვანეთ იგი სასურველ ფორმაში.
2. დაასრულეთ ს/კ თავად და/ან პროცესორის დანამატები bitrate_monitor და უწყვეტობა ისე, რომ შედეგი მოყვანილი იყოს მანქანით წაკითხვადი ფორმით, რომელიც შესაფერისია მონიტორინგის სისტემისთვის.
3. დაწერეთ თქვენი განაცხადი tsduck ბიბლიოთეკის თავზე.

ცხადია, ვარიანტი 1 ყველაზე მარტივია ძალისხმევის თვალსაზრისით, განსაკუთრებით იმის გათვალისწინებით, რომ თავად tsduck იწერება დაბალი დონის (თანამედროვე სტანდარტებით) ენაზე (C ++)

მარტივი bash parser+agregator პროტოტიპმა აჩვენა, რომ 10Mbps ნაკადზე და 50% პაკეტის დაკარგვაზე (ყველაზე უარესი შემთხვევაში), bash პროცესი მოიხმარდა 3-4-ჯერ მეტ CPU-ს, ვიდრე თავად tsp პროცესი. ეს სცენარი მიუღებელია. რეალურად ამ პროტოტიპის ნაწილი ქვემოთ

ზემოდან ნუდლები

#!/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-ის მნიშვნელობის დაწერა (ბიტრატის შეტყობინებების მიღებისას, რომლებიც ყოველ წამს მოდის). შედეგად, ბაში მარტო დარჩა და გადაწყდა გოლანგში შეფუთვა (პარსერი + აგრეგატორი). მსგავსი გოლანგის კოდის CPU მოხმარება 4-5-ჯერ ნაკლებია, ვიდრე თავად ჩ/კ პროცესზე. შეფუთვის სისწრაფე ბაშის გოლანგით გამოცვლის გამო დაახლოებით 16-ჯერ აღმოჩნდა და ზოგადად შედეგი მისაღებია (CPU ზედმეტად უარეს შემთხვევაში 25%-ით). გოლანგის წყაროს ფაილი მდებარეობს აქ.

გაუშვით შეფუთვა

შეფუთვის დასაწყებად, გაკეთდა სისტემის უმარტივესი სერვისის შაბლონი (აქ). თავად wrapper უნდა იყოს შედგენილი ბინარულ ფაილში (go build tsduck-stat.go), რომელიც მდებარეობს /opt/tsduck-stat/-ში. ვარაუდობენ, რომ თქვენ იყენებთ გოლანგს მონოტონური საათის მხარდაჭერით (>=1.9).

სერვისის ინსტანციის შესაქმნელად, თქვენ უნდა გაუშვათ systemctl enable ბრძანება [ელ.ფოსტით დაცულია]:1234 შემდეგ გაუშვით systemctl start-ით [ელ.ფოსტით დაცულია]: 1234.

აღმოჩენა Zabbix-ისგან

იმისათვის, რომ zabbix-მა შეძლოს გაშვებული სერვისების აღმოჩენა, ეს კეთდება ჯგუფის სიების გენერატორი (discovery.sh), Zabbix-ის აღმოჩენისთვის საჭირო ფორმატში, ვარაუდობენ, რომ იგი მდებარეობს იმავე ადგილას - /opt/tsduck-stat-ში. აღმოჩენის გასაშვებად zabbix-agent-ის საშუალებით, თქვენ უნდა დაამატოთ .conf ფაილი zabbix-agent-ის კონფიგურაციის დირექტორიაში მომხმარებლის პარამეტრის დასამატებლად.

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/*). სერვისების რაოდენობა მრავალჯერადი ნაკადების რაოდენობის მიხედვით. აქ შეიძლება დაგჭირდეთ მარშრუტის შექმნა multicast ჯგუფში, შესაძლოა გამორთოთ rp_filter ან შექმნათ მარშრუტი წყაროს IP-მდე.
6. გაუშვით discovery.sh, დარწმუნდით, რომ ის ქმნის json-ს.
7. დაამატეთ zabbix აგენტის კონფიგურაცია, გადატვირთეთ zabbix აგენტი.
8. ატვირთეთ შაბლონი zabbix-ზე, გამოიყენეთ ის ჰოსტზე, რომლის მონიტორინგიც მიმდინარეობს და zabbix-აგენტი დაინსტალირებულია, დაელოდეთ დაახლოებით 5 წუთი, ნახეთ არის თუ არა ახალი ელემენტები, გრაფიკები და ტრიგერები.

შედეგი

პაკეტის დაკარგვის გამოვლენის მიზნით, ეს თითქმის საკმარისია, ყოველ შემთხვევაში, უკეთესია, ვიდრე მონიტორინგის გარეშე.

მართლაც, CC "ზარალი" შეიძლება მოხდეს ვიდეო ფრაგმენტების შერწყმისას (რამდენადაც მე ვიცი, ასე კეთდება ჩანართები რუსეთის ფედერაციის ადგილობრივ სატელევიზიო ცენტრებში, ანუ CC მრიცხველის გადაანგარიშების გარეშე), ეს უნდა გახსოვდეთ. საკუთრების გადაწყვეტილებები ნაწილობრივ აცილებს ამ პრობლემას SCTE-35 ეტიკეტების აღმოჩენით (თუ დამატებულია ნაკადის გენერატორის მიერ).

ტრანსპორტის ხარისხის მონიტორინგის კუთხით, არსებობს ჯიტერის მონიტორინგის (IAT) ნაკლებობა. სატელევიზიო მოწყობილობას (იქნება ეს მოდულატორები თუ ბოლო მოწყობილობები) აქვს მოთხოვნები ამ პარამეტრზე და ყოველთვის არ არის შესაძლებელი ჯიტბუფერის უსასრულობამდე გაბერვა. და ჟიტერი შეიძლება იცუროს, როდესაც დიდი ბუფერების მქონე მოწყობილობა გამოიყენება ტრანზიტში და QoS არ არის კონფიგურირებული ან საკმარისად არ არის კონფიგურირებული ასეთი რეალურ დროში ტრაფიკის გადასაცემად.

წყარო: www.habr.com