IP(TS) प्रवाहांचे निरीक्षण करण्यासाठी TSDuck वापरणे

आज, आयपी(टीएस) प्रवाहांचे निरीक्षण करण्यासाठी तयार (मालकीचे) उपाय आहेत, उदाहरणार्थ VB и iQ, त्यांच्याकडे फंक्शन्सचा बऱ्यापैकी समृद्ध संच आहे आणि सहसा टीव्ही सेवांशी संबंधित मोठ्या ऑपरेटरकडे असे उपाय असतात. हा लेख ओपन सोर्स प्रकल्पावर आधारित समाधानाचे वर्णन करतो TSDuck, CC(सातत्य काउंटर) काउंटर आणि बिटरेटद्वारे IP(TS) प्रवाहांच्या किमान नियंत्रणासाठी डिझाइन केलेले. संभाव्य ऍप्लिकेशन म्हणजे पॅकेट्सचे नुकसान किंवा लीज्ड L2 चॅनेलद्वारे संपूर्ण प्रवाह नियंत्रित करणे (ज्याचे सामान्यपणे परीक्षण केले जाऊ शकत नाही, उदाहरणार्थ, रांगेतील नुकसान काउंटर वाचून).

TSDuck बद्दल थोडक्यात

टीएसडक हे ओपन सोर्स (2-क्लॉज बीएसडी परवाना) सॉफ्टवेअर आहे (कन्सोल युटिलिटीजचा संच आणि सानुकूल युटिलिटीज किंवा प्लगइन विकसित करण्यासाठी लायब्ररी) TS प्रवाह हाताळण्यासाठी. इनपुट म्हणून, ते IP (मल्टीकास्ट/युनिकास्ट), http, hls, dvb ट्यूनर्स, dektec dvb-asi demodulator सह कार्य करू शकते, अंतर्गत TS-stream जनरेटर आहे आणि फाइल्समधून वाचन आहे. आउटपुट फाईल, IP (मल्टीकास्ट/युनिकास्ट), hls, dektec dvb-asi आणि HiDes मॉड्युलेटर, प्लेयर्स (mplayer, vlc, xine) आणि ड्रॉपवर लिहू शकते. इनपुट आणि आउटपुटमध्ये विविध ट्रॅफिक प्रोसेसर समाविष्ट केले जाऊ शकतात, उदाहरणार्थ, पीआयडी रीमॅपिंग, स्क्रॅम्बलिंग / डिसकॅम्बलिंग, सीसी काउंटर विश्लेषण, बिटरेट कॅल्क्युलेशन आणि टीएस प्रवाहांसाठी इतर विशिष्ट ऑपरेशन्स.

या लेखात, IP प्रवाह (मल्टीकास्ट) इनपुट म्हणून वापरले जातील, प्रोसेसर bitrate_monitor (नावावरून ते काय आहे ते स्पष्ट आहे) आणि सातत्य (CC काउंटरचे विश्लेषण) वापरले जातात. तुम्ही TSDuck द्वारे समर्थित अन्य इनपुट प्रकारासह IP मल्टीकास्ट सहजपणे बदलू शकता.

उपलब्ध अधिकृत बिल्ड/पॅकेज बहुतेक वर्तमान ऑपरेटिंग सिस्टमसाठी TSDuck. ते डेबियनसाठी उपलब्ध नाहीत, परंतु आम्ही त्यांना कोणत्याही समस्यांशिवाय डेबियन 8 आणि डेबियन 10 अंतर्गत तयार करण्यात व्यवस्थापित केले.

पुढे, आवृत्ती TSDuck 3.19-1520 वापरली जाते, लिनक्सचा वापर OS म्हणून केला जातो (डेबियन 10 सोल्यूशन तयार करण्यासाठी वापरला गेला होता, CentOS 7 वास्तविक वापरासाठी वापरला गेला होता)

TSDuck आणि OS तयार करत आहे

रिअल फ्लोचे निरीक्षण करण्यापूर्वी, तुम्हाला हे सुनिश्चित करणे आवश्यक आहे की TSDuck योग्यरित्या कार्य करते आणि नेटवर्क कार्ड किंवा OS (सॉकेट) स्तरावर कोणतेही थेंब नाहीत. नेटवर्कवर किंवा "सर्व्हरच्या आत" - थेंब कोठे आले याचा नंतर अंदाज न येण्यासाठी हे आवश्यक आहे. तुम्ही 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" चा अर्थ असा आहे की तुम्हाला प्रत्येक सेकंदाला बिटरेटची गणना करणे आणि प्रत्येक सेकंदाला बिटरेटबद्दल माहिती प्रदर्शित करणे आवश्यक आहे.
आम्ही ट्रॅफिक जनरेटर 10Mbps च्या गतीने सुरू करतो:

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) आणि जनरेटर बिटरेट 100Mbps पर्यंत वाढवण्याचा प्रयत्न करा. विश्लेषक CC त्रुटींचा एक समूह आणि 75 ऐवजी सुमारे 100 Mbps नोंदवतो. आम्ही दोष कोणाला द्यायचा हे शोधण्याचा प्रयत्न करत आहोत - जनरेटरला वेळ नाही किंवा समस्या त्यात नाही, यासाठी आम्ही निश्चित संख्या तयार करणे सुरू करतो. पॅकेट्स (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). चला तर मग विश्लेषकासोबत काय घडत आहे ते शोधून काढूया, यासाठी आम्ही veth1 वरील RX काउंटर तपासतो, ते veth0 वरील 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 KB च्या बफरसह सॉकेट तयार केले जातात, परंतु त्यांनी अधिक विनंती केल्यास, त्यांना विनंती केलेली प्राप्त होणार नाही. तुम्ही IP इनपुट (-buffer-size) साठी tsp मध्ये बफर आकार सेट करू शकत असल्याने, आम्ही डीफॉल्ट सॉकेट आकाराला स्पर्श करणार नाही, परंतु फक्त जास्तीत जास्त सॉकेट बफर आकार सेट करू आणि 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

सॉकेट बफरच्या या ट्यूनिंगसह, आता नोंदवलेला बिटरेट सुमारे 100Mbps आहे, CC त्रुटी नाहीत.

टीस्पी ऍप्लिकेशनच्या CPU वापरानुसार. एका कोर i5-4260U CPU @ 1.40GHz च्या सापेक्ष, 10Mbps प्रवाह विश्लेषणासाठी 3-4% CPU, 100Mbps - 25%, 200Mbps - 46% आवश्यक असेल. % पॅकेट लॉस सेट करताना, सीपीयूवरील भार व्यावहारिकरित्या वाढत नाही (परंतु कमी होऊ शकतो).

अधिक उत्पादनक्षम हार्डवेअरवर, कोणत्याही समस्यांशिवाय 1Gb/s पेक्षा जास्त प्रवाह निर्माण करणे आणि त्यांचे विश्लेषण करणे शक्य होते.

वास्तविक नेटवर्क कार्ड्सवर चाचणी

व्हेथ जोडीवर चाचणी केल्यानंतर, तुम्हाला दोन होस्ट किंवा एका होस्टचे दोन पोर्ट घेणे आवश्यक आहे, पोर्ट एकमेकांना जोडणे आवश्यक आहे, एकावर जनरेटर सुरू करा आणि दुसऱ्यावर विश्लेषक. येथे कोणतेही आश्चर्य नव्हते, परंतु खरं तर हे सर्व लोखंडावर अवलंबून असते, कमकुवत, अधिक मनोरंजक ते येथे असेल.

मॉनिटरिंग सिस्टमद्वारे प्राप्त डेटा वापरणे (Zabbix)

tsp मध्ये SNMP किंवा तत्सम कोणतेही मशीन-वाचनीय API नाही. CC संदेश किमान 1 सेकंदासाठी एकत्रित केले जाणे आवश्यक आहे (पॅकेट गमावण्याच्या उच्च टक्केवारीसह, बिटरेटवर अवलंबून प्रति सेकंद शेकडो/हजार/दहा हजार असू शकतात).

अशा प्रकारे, दोन्ही माहिती जतन करण्यासाठी आणि CC त्रुटी आणि बिटरेटसाठी आलेख काढण्यासाठी आणि काही प्रकारचे अपघात करण्यासाठी, खालील पर्याय असू शकतात:

1. tsp चे आउटपुट पार्स आणि एकत्रित करा (CC द्वारे), उदा. इच्छित फॉर्ममध्ये रूपांतरित करा.
2. tsp स्वतः आणि/किंवा प्रोसेसर प्लगइन्स bitrate_monitor आणि सातत्य पूर्ण करा जेणेकरून परिणाम मॉनिटरिंग सिस्टमसाठी योग्य असलेल्या मशीन-वाचनीय स्वरूपात दिला जाईल.
3. तुमचा अर्ज tsduck लायब्ररीच्या वर लिहा.

अर्थात, प्रयत्नांच्या दृष्टीने पर्याय 1 हा सर्वात सोपा आहे, विशेषत: tsduck स्वतः निम्न-स्तरीय (आधुनिक मानकांनुसार) भाषेत (C ++) लिहिलेला आहे हे लक्षात घेता.

एका साध्या बॅश पार्सर+एग्रीगेटर प्रोटोटाइपने दाखवले की 10Mbps प्रवाह आणि 50% पॅकेट लॉस (सर्वात वाईट केस) वर, बॅश प्रक्रियेने 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

अस्वीकार्यपणे मंद असण्याव्यतिरिक्त, बॅशमध्ये कोणतेही सामान्य थ्रेड नाहीत, बॅश जॉब ही स्वतंत्र प्रक्रिया आहेत आणि मला साइड इफेक्टवर (दर सेकंदाला येणारे बिटरेट संदेश प्राप्त करताना) सेकंदात एकदा missingPackets चे मूल्य लिहावे लागले. परिणामी, बाश एकटाच राहिला आणि गोलंगमध्ये रॅपर (पार्सर + एग्रीगेटर) लिहिण्याचा निर्णय घेण्यात आला. समान गोलांग कोडचा CPU वापर टीस्पून प्रक्रियेपेक्षा 4-5 पट कमी आहे. गोलंगसह बॅश बदलल्यामुळे रॅपरची गती सुमारे 16 पट झाली आणि सर्वसाधारणपणे परिणाम स्वीकार्य आहे (सर्वात वाईट परिस्थितीत सीपीयू ओव्हरहेड 25% ने). गोलंग स्त्रोत फाइल स्थित आहे येथे.

रॅपर चालवा

रॅपर सुरू करण्यासाठी, systemd साठी सर्वात सोपा सर्व्हिस टेम्पलेट बनवला होता (येथे). रॅपर स्वतःच /opt/tsduck-stat/ मध्ये असलेल्या बायनरी फाइल (go build tsduck-stat.go) मध्ये संकलित केले जाणे अपेक्षित आहे. असे गृहीत धरले जाते की तुम्ही मोनोटोनिक घड्याळ (>=1.9) च्या समर्थनासह गोलंग वापरत आहात.

सेवेचे उदाहरण तयार करण्यासाठी, तुम्हाला systemctl enable कमांड चालवावी लागेल [ईमेल संरक्षित]:1234 नंतर systemctl start सह चालवा [ईमेल संरक्षित]: 1234

Zabbix कडून शोध

zabbix साठी चालू सेवा शोधण्यात सक्षम होण्यासाठी, ते केले जाते गट सूची जनरेटर (discovery.sh), Zabbix शोधासाठी आवश्यक असलेल्या फॉरमॅटमध्ये, असे गृहीत धरले जाते की ते त्याच ठिकाणी आहे - /opt/tsduck-stat मध्ये. zabbix-agent द्वारे शोध चालवण्यासाठी, तुम्हाला जोडणे आवश्यक आहे .conf फाइल वापरकर्ता पॅरामीटर जोडण्यासाठी zabbix-एजंट कॉन्फिगरेशन निर्देशिकेत.

Zabbix टेम्पलेट

टेम्पलेट तयार केले (tsduck_stat_template.xml) मध्ये ऑटोडिस्कव्हर नियम, आयटम प्रोटोटाइप, आलेख आणि ट्रिगर समाविष्ट आहेत.

संक्षिप्त चेकलिस्ट (चांगले, जर कोणी ते वापरायचे ठरवले तर काय होईल)

1. टीएसपी "आदर्श" परिस्थितीत पॅकेट सोडत नाही याची खात्री करा (जनरेटर आणि विश्लेषक थेट कनेक्ट केलेले आहेत), थेंब असल्यास, परिच्छेद 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 मिनिटे प्रतीक्षा करा, नवीन आयटम, आलेख आणि ट्रिगर आहेत का ते पहा.

परिणाम

पॅकेटचे नुकसान शोधण्याच्या कार्यासाठी, ते जवळजवळ पुरेसे आहे, कमीतकमी ते निरीक्षण न करण्यापेक्षा चांगले आहे.

खरंच, व्हिडिओ तुकड्यांचे विलीनीकरण करताना सीसी "नुकसान" होऊ शकते (माझ्या माहितीनुसार, रशियन फेडरेशनमधील स्थानिक टीव्ही केंद्रांवर अशा प्रकारे इन्सर्ट केले जातात, म्हणजे सीसी काउंटरची पुनर्गणना न करता), हे लक्षात ठेवले पाहिजे. SCTE-35 लेबले शोधून (स्ट्रीम जनरेटरने जोडल्यास) प्रोप्रायटरी सोल्यूशन्स अंशतः या समस्येला दूर करतात.

वाहतुकीच्या गुणवत्तेच्या देखरेखीच्या बाबतीत, जिटर मॉनिटरिंगचा (आयएटी) अभाव आहे. टीव्ही उपकरणे (मग ते मॉड्युलेटर असो किंवा एंड डिव्हाइसेस असो) या पॅरामीटरसाठी आवश्यकता असते आणि जिटबफरला अनंतापर्यंत वाढवणे नेहमीच शक्य नसते. जेव्हा मोठे बफर असलेली उपकरणे ट्रांझिटमध्ये वापरली जातात आणि QoS कॉन्फिगर केलेले नसते किंवा अशा रिअलटाइम रहदारीचे प्रसारण करण्यासाठी पुरेसे कॉन्फिगर केलेले नसते तेव्हा जिटर तरंगू शकते.

स्त्रोत: www.habr.com