🥇आईपी(टीएस) स्ट्रीम की निगरानी के लिए टीएसडक का उपयोग करना

उदाहरण के लिए, आज आईपी(टीएस) स्ट्रीम की निगरानी के लिए तैयार (मालिकाना) समाधान मौजूद हैं VB и iQ, उनके पास कार्यों का काफी समृद्ध समूह है और आमतौर पर टीवी सेवाओं से जुड़े बड़े ऑपरेटरों के पास ऐसे समाधान होते हैं। यह आलेख एक ओपन सोर्स प्रोजेक्ट पर आधारित समाधान का वर्णन करता है टीएसडकसीसी (निरंतरता काउंटर) काउंटर और बिटरेट द्वारा आईपी (टीएस) धाराओं के न्यूनतम नियंत्रण के लिए डिज़ाइन किया गया। एक संभावित अनुप्रयोग पट्टे पर दिए गए L2 चैनल के माध्यम से पैकेटों के नुकसान या संपूर्ण प्रवाह को नियंत्रित करना है (जिसे सामान्य रूप से मॉनिटर नहीं किया जा सकता है, उदाहरण के लिए, कतारों में नुकसान काउंटरों को पढ़कर)।

TSDuck के बारे में बहुत संक्षेप में

टीएसडक टीएस स्ट्रीम में हेरफेर करने के लिए एक खुला स्रोत (2-क्लॉज बीएसडी लाइसेंस) सॉफ्टवेयर (कंसोल यूटिलिटीज का एक सेट और कस्टम यूटिलिटीज या प्लगइन्स विकसित करने के लिए एक लाइब्रेरी) है। इनपुट के रूप में, यह आईपी (मल्टीकास्ट/यूनिकैस्ट), http, hls, dvb ट्यूनर, डेक्टेक dvb-asi डेमोडुलेटर के साथ काम कर सकता है, इसमें एक आंतरिक टीएस-स्ट्रीम जनरेटर और फाइलों से रीडिंग है। आउटपुट एक फ़ाइल, आईपी (मल्टीकास्ट/यूनिकास्ट), एचएलएस, डेक्टेक डीवीबी-एएसआई और हाईडेस मॉड्यूलेटर, प्लेयर्स (एमप्लेयर, वीएलसी, एक्सईएन) और ड्रॉप पर लिख सकता है। इनपुट और आउटपुट के बीच विभिन्न ट्रैफ़िक प्रोसेसर को शामिल किया जा सकता है, उदाहरण के लिए, पीआईडी रीमैपिंग, स्क्रैम्बलिंग / डिसक्रैम्बलिंग, सीसी काउंटर विश्लेषण, बिटरेट गणना और टीएस स्ट्रीम के लिए अन्य विशिष्ट संचालन।

इस लेख में, आईपी स्ट्रीम (मल्टीकास्ट) का उपयोग इनपुट के रूप में किया जाएगा, प्रोसेसर बिटरेट_मॉनिटर (नाम से यह स्पष्ट है कि यह क्या है) और निरंतरता (सीसी काउंटरों का विश्लेषण) का उपयोग किया जाता है। आप आईपी मल्टीकास्ट को TSDuck द्वारा समर्थित किसी अन्य इनपुट प्रकार से आसानी से बदल सकते हैं।

उपलब्ध हैं आधिकारिक निर्माण/पैकेज अधिकांश मौजूदा ऑपरेटिंग सिस्टम के लिए TSDuck। वे डेबियन के लिए उपलब्ध नहीं हैं, लेकिन हम उन्हें बिना किसी समस्या के डेबियन 8 और डेबियन 10 के तहत बनाने में कामयाब रहे।

इसके बाद, संस्करण TSDuck 3.19-1520 का उपयोग किया जाता है, Linux को OS के रूप में उपयोग किया जाता है (समाधान तैयार करने के लिए डेबियन 10 का उपयोग किया गया था, वास्तविक उपयोग के लिए CentOS 7 का उपयोग किया गया था)

TSDuck और OS तैयार कर रहा हूँ

वास्तविक प्रवाह की निगरानी करने से पहले, आपको यह सुनिश्चित करना होगा कि TSDuck सही ढंग से काम करता है और नेटवर्क कार्ड या OS (सॉकेट) स्तर पर कोई गिरावट नहीं है। यह इसलिए आवश्यक है ताकि बाद में यह अनुमान न लगाया जा सके कि गिरावट कहां हुई - नेटवर्क पर या "सर्वर के अंदर"। आप एथटूल -एस एथएक्स कमांड के साथ नेटवर्क कार्ड स्तर पर गिरावट की जांच कर सकते हैं, ट्यूनिंग उसी एथटूल द्वारा की जाती है (आमतौर पर, आपको आरएक्स बफर (-जी) को बढ़ाने की आवश्यकता होती है और कभी-कभी कुछ ऑफलोड (-के) को अक्षम करना पड़ता है)। एक सामान्य अनुशंसा के रूप में, यदि संभव हो तो विश्लेषण किए गए ट्रैफ़िक को प्राप्त करने के लिए एक अलग पोर्ट का उपयोग करने की सलाह दी जा सकती है, यह इस तथ्य से जुड़ी झूठी सकारात्मकता को कम करता है कि गिरावट अन्य ट्रैफ़िक की उपस्थिति के कारण विश्लेषक पोर्ट पर हुई थी। यदि यह संभव नहीं है (एक पोर्ट के साथ एक मिनी-कंप्यूटर/एनयूसी का उपयोग किया जाता है), तो उस डिवाइस पर बाकी के संबंध में विश्लेषण किए गए ट्रैफ़िक की प्राथमिकता निर्धारित करना अत्यधिक वांछनीय है जिससे विश्लेषक जुड़ा हुआ है। आभासी वातावरण के संबंध में, यहां आपको सावधान रहने की जरूरत है और एक भौतिक पोर्ट से शुरू होकर एक वर्चुअल मशीन के अंदर एक एप्लिकेशन के साथ समाप्त होने वाले पैकेट ड्रॉप्स को ढूंढने में सक्षम होना चाहिए।

मेजबान के अंदर एक धारा का निर्माण और स्वागत

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" का अर्थ है कि आपको हर सेकंड बिटरेट की गणना करने और हर सेकंड बिटरेट के बारे में जानकारी प्रदर्शित करने की आवश्यकता है
हम ट्रैफ़िक जनरेटर को 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) करने की आवश्यकता है, अर्थात। आईपी पैकेट भेजने से पहले हमेशा अंतिम प्रोसेसर से 7 टीएस पैकेट की प्रतीक्षा करें।

विश्लेषक अपेक्षित संदेश आउटपुट करना प्रारंभ करता है:

* 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

जो अपेक्षित है. पैकेट हानि को अक्षम करें (आईपी नेटएनएस निष्पादन पी आईपीटेबल्स -एफ) और जनरेटर बिटरेट को 100 एमबीपीएस तक बढ़ाने का प्रयास करें। विश्लेषक सीसी त्रुटियों का एक समूह और 75 के बजाय लगभग 100 एमबीपीएस की रिपोर्ट करता है। हम यह पता लगाने की कोशिश कर रहे हैं कि किसे दोषी ठहराया जाए - जनरेटर के पास समय नहीं है या समस्या उसमें नहीं है, इसके लिए हम एक निश्चित संख्या उत्पन्न करना शुरू करते हैं पैकेट (700000 टीएस पैकेट = 100000 आईपी पैकेट):

# 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 आईपी पैकेट तैयार किए गए (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 देख सकते हैं। टीएस पैकेट में, यह 170485 या 24.36 का 700000% है, इसलिए हम देखते हैं कि खोई हुई बिटरेट का वही 25% यूडीपी सॉकेट में बूंदें हैं। यूडीपी सॉकेट में गिरावट आमतौर पर बफर की कमी के कारण होती है, डिफ़ॉल्ट सॉकेट बफर आकार और अधिकतम सॉकेट बफर आकार देखें:

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

इस प्रकार, यदि एप्लिकेशन स्पष्ट रूप से बफर आकार का अनुरोध नहीं करते हैं, तो सॉकेट 208 केबी के बफर के साथ बनाए जाते हैं, लेकिन यदि वे अधिक अनुरोध करते हैं, तो भी उन्हें वह प्राप्त नहीं होगा जो अनुरोध किया गया था। चूंकि आप आईपी इनपुट (-बफर-आकार) के लिए बफर आकार को टीएसपी में सेट कर सकते हैं, हम डिफ़ॉल्ट सॉकेट आकार को नहीं छूएंगे, लेकिन केवल अधिकतम सॉकेट बफर आकार सेट करेंगे और टीएसपी तर्कों के माध्यम से बफर आकार को स्पष्ट रूप से निर्दिष्ट करेंगे:

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 एमबीपीएस है, कोई सीसी त्रुटियां नहीं हैं।

टीएसपी एप्लिकेशन की सीपीयू खपत के अनुसार ही। एक कोर i5-4260U CPU @ 1.40GHz के सापेक्ष, 10Mbps प्रवाह विश्लेषण के लिए 3-4% CPU, 100Mbps - 25%, 200Mbps - 46% की आवश्यकता होगी। % पैकेट लॉस सेट करते समय, सीपीयू पर लोड व्यावहारिक रूप से नहीं बढ़ता है (लेकिन घट सकता है)।

अधिक उत्पादक हार्डवेयर पर, बिना किसी समस्या के 1Gb/s से अधिक की स्ट्रीम उत्पन्न करना और उनका विश्लेषण करना संभव था।

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

वीथ जोड़ी पर परीक्षण करने के बाद, आपको दो होस्ट या एक होस्ट के दो पोर्ट लेने होंगे, पोर्ट को एक दूसरे से कनेक्ट करना होगा, एक पर जनरेटर शुरू करना होगा और दूसरे पर विश्लेषक। यहां कोई आश्चर्य नहीं था, लेकिन वास्तव में यह सब लोहे पर निर्भर करता है, जितना कमजोर होगा, यहां उतना ही दिलचस्प होगा।

निगरानी प्रणाली (ज़ैबिक्स) द्वारा प्राप्त डेटा का उपयोग करना

टीएसपी में एसएनएमपी या इसके समान कोई मशीन-पठनीय एपीआई नहीं है। सीसी संदेशों को कम से कम 1 सेकंड के लिए एकत्र किया जाना चाहिए (पैकेट हानि के उच्च प्रतिशत के साथ, बिटरेट के आधार पर प्रति सेकंड सैकड़ों/हजारों/दसियों हजार हो सकते हैं)।

इस प्रकार, जानकारी को सहेजने और सीसी त्रुटियों और बिटरेट के लिए ग्राफ़ बनाने और किसी प्रकार की दुर्घटनाएं करने के लिए, निम्नलिखित विकल्प हो सकते हैं:

टीएसपी के आउटपुट को पार्स और एकत्रीकरण (सीसी द्वारा), यानी। इसे वांछित रूप में परिवर्तित करें।
टीएसपी स्वयं और/या प्रोसेसर प्लगइन्स बिटरेट_मॉनिटर और निरंतरता को समाप्त करें ताकि परिणाम मॉनिटरिंग सिस्टम के लिए उपयुक्त मशीन-पठनीय रूप में दिया जा सके।
अपना आवेदन tsduck लाइब्रेरी के शीर्ष पर लिखें।

जाहिर है, प्रयास की दृष्टि से विकल्प 1 सबसे आसान है, विशेष रूप से यह देखते हुए कि tsduck स्वयं निम्न-स्तरीय (आधुनिक मानकों के अनुसार) भाषा (C++) में लिखा गया है।

एक साधारण बैश पार्सर+एग्रीगेटर प्रोटोटाइप से पता चला कि 10 एमबीपीएस स्ट्रीम और 50% पैकेट हानि (सबसे खराब स्थिति) पर, बैश प्रक्रिया टीएसपी प्रक्रिया की तुलना में 3-4 गुना अधिक सीपीयू की खपत करती है। यह परिदृश्य अस्वीकार्य है. वास्तव में इस प्रोटोटाइप का एक टुकड़ा नीचे है

शीर्ष पर नूडल्स

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

अस्वीकार्य रूप से धीमी होने के अलावा, बैश में कोई सामान्य थ्रेड नहीं हैं, बैश जॉब अलग-अलग प्रक्रियाएं हैं, और मुझे साइड इफेक्ट पर एक सेकंड में एक बार मिसिंगपैकेट का मान लिखना पड़ता था (जब हर सेकंड आने वाले बिटरेट संदेश प्राप्त होते हैं)। परिणामस्वरूप, बैश को अकेला छोड़ दिया गया और गोलांग में एक रैपर (पार्सर + एग्रीगेटर) लिखने का निर्णय लिया गया। समान गोलांग कोड की सीपीयू खपत टीएसपी प्रक्रिया से 4-5 गुना कम है। गोलांग के साथ बैश के प्रतिस्थापन के कारण रैपर की गति लगभग 16 गुना हो गई और सामान्य तौर पर परिणाम स्वीकार्य है (सबसे खराब स्थिति में सीपीयू ओवरहेड 25%)। गोलांग स्रोत फ़ाइल स्थित है यहां.

रैपर लॉन्च करना

रैपर शुरू करने के लिए, सिस्टमडी के लिए सबसे सरल सेवा टेम्पलेट बनाया गया था (यहां). माना जाता है कि रैपर को /opt/tsduck-stat/ में स्थित एक बाइनरी फ़ाइल (go build tsduck-stat.go) में संकलित किया जाना चाहिए। यह माना जाता है कि आप मोनोटोनिक घड़ी (>=1.9) के समर्थन के साथ गोलांग का उपयोग कर रहे हैं।

सेवा का एक उदाहरण बनाने के लिए, आपको systemctl सक्षम कमांड चलाने की आवश्यकता है [ईमेल संरक्षित]:1234 फिर systemctl प्रारंभ के साथ चलाएँ [ईमेल संरक्षित]: 1234।

ज़ैबिक्स से खोज

ज़ैबिक्स को चालू सेवाओं की खोज करने में सक्षम बनाने के लिए, यह किया जाता है समूह सूची जनरेटर (discovery.sh), ज़ैबिक्स खोज के लिए आवश्यक प्रारूप में, यह माना जाता है कि यह उसी स्थान पर स्थित है - /opt/tsduck-stat में। ज़ैबिक्स-एजेंट के माध्यम से डिस्कवरी चलाने के लिए, आपको जोड़ना होगा .conf फ़ाइल उपयोगकर्ता पैरामीटर जोड़ने के लिए zabbix-एजेंट कॉन्फ़िगरेशन निर्देशिका में।

ज़ैबिक्स टेम्पलेट

टेम्पलेट बनाया गया (tsduck_stat_template.xml) में ऑटोडिस्कवर नियम, आइटम प्रोटोटाइप, ग्राफ़ और ट्रिगर शामिल हैं।

संक्षिप्त चेकलिस्ट (ठीक है, अगर कोई इसका उपयोग करने का निर्णय लेता है तो क्या होगा)

सुनिश्चित करें कि टीएसपी "आदर्श" परिस्थितियों में पैकेट नहीं गिराता है (जनरेटर और विश्लेषक सीधे जुड़े हुए हैं), यदि बूंदें हैं, तो पैराग्राफ 2 या इस मामले पर लेख का पाठ देखें।
अधिकतम सॉकेट बफ़र को ट्यूनिंग करें (net.core.rmem_max=8388608)।
tsduck-stat.go संकलित करें (tsduck-stat.go बनाएं)।
सेवा टेम्पलेट को /lib/systemd/system में रखें।
Systemctl के साथ सेवाएँ प्रारंभ करें, जाँचें कि काउंटर दिखाई देने लगे हैं (grep "" /dev/shm/tsduck-stat/*)। मल्टीकास्ट स्ट्रीम की संख्या के आधार पर सेवाओं की संख्या। यहां आपको मल्टीकास्ट समूह के लिए एक मार्ग बनाने की आवश्यकता हो सकती है, शायद rp_filter को अक्षम करें या स्रोत आईपी के लिए एक मार्ग बनाएं।
डिस्कवरी.श चलाएँ, सुनिश्चित करें कि यह json उत्पन्न करता है।
ज़ैबिक्स एजेंट कॉन्फ़िगरेशन जोड़ें, ज़ैबिक्स एजेंट को पुनरारंभ करें।
टेम्पलेट को ज़ैबिक्स पर अपलोड करें, इसे उस होस्ट पर लागू करें जिस पर निगरानी की जाती है और ज़ैबिक्स-एजेंट स्थापित है, लगभग 5 मिनट तक प्रतीक्षा करें, देखें कि नए डेटा तत्व, ग्राफ़ और ट्रिगर दिखाई देते हैं।

परिणाम

पैकेट हानि का पता लगाने के कार्य के लिए, यह लगभग पर्याप्त है, कम से कम यह निगरानी न करने से तो बेहतर है।

वास्तव में, वीडियो अंशों को मर्ज करते समय CC "नुकसान" हो सकता है (जहाँ तक मुझे पता है, रूसी संघ में स्थानीय टीवी केंद्रों पर इसी तरह से प्रविष्टियाँ की जाती हैं, अर्थात CC काउंटर की पुनर्गणना किए बिना), इसे याद रखना चाहिए। मालिकाना समाधान SCTE-35 लेबल (यदि स्ट्रीम जनरेटर द्वारा जोड़ा गया है) का पता लगाकर इस समस्या को आंशिक रूप से दूर कर देते हैं।

परिवहन गुणवत्ता निगरानी के संदर्भ में, जिटर मॉनिटरिंग (आईएटी) की कमी है। टीवी उपकरण (चाहे वह मॉड्यूलेटर हो या अंतिम उपकरण) में इस पैरामीटर की आवश्यकताएं होती हैं और जिटबफर को अनंत तक फुलाना हमेशा संभव नहीं होता है। और जब पारगमन में बड़े बफ़र्स वाले उपकरण का उपयोग किया जाता है और क्यूओएस कॉन्फ़िगर नहीं किया जाता है या ऐसे रीयलटाइम ट्रैफ़िक को प्रसारित करने के लिए पर्याप्त रूप से कॉन्फ़िगर नहीं किया जाता है तो जिटर तैर सकता है।

स्रोत: www.habr.com

आईपी(टीएस) स्ट्रीम की निगरानी के लिए टीएसडक का उपयोग करना