புரோஹோஸ்டர் > Блог > நிர்வாகம் > IP(TS) ஸ்ட்ரீம்களை கண்காணிக்க TSDuck ஐப் பயன்படுத்துதல்

IP(TS) ஸ்ட்ரீம்களை கண்காணிக்க TSDuck ஐப் பயன்படுத்துதல்

இன்று, IP(TS) ஸ்ட்ரீம்களைக் கண்காணிப்பதற்கான ஆயத்த (தனியுரிமை) தீர்வுகள் உள்ளன, உதாரணமாக VB и iQ, அவை மிகவும் வளமான செயல்பாடுகளைக் கொண்டுள்ளன, பொதுவாக டிவி சேவைகளைக் கையாளும் பெரிய ஆபரேட்டர்கள் அத்தகைய தீர்வுகளைக் கொண்டுள்ளனர். இந்தக் கட்டுரை ஒரு திறந்த மூல திட்டத்தின் அடிப்படையில் ஒரு தீர்வை விவரிக்கிறது TSDuck, CC(தொடர்ச்சி கவுண்டர்) கவுண்டர் மற்றும் பிட்ரேட் மூலம் IP(TS) ஸ்ட்ரீம்களின் குறைந்தபட்ச கட்டுப்பாட்டிற்காக வடிவமைக்கப்பட்டுள்ளது. குத்தகைக்கு விடப்பட்ட L2 சேனல் மூலம் பாக்கெட்டுகளின் இழப்பை அல்லது முழு ஓட்டத்தையும் கட்டுப்படுத்துவது சாத்தியமான பயன்பாடாகும் (இதை சாதாரணமாக கண்காணிக்க முடியாது, எடுத்துக்காட்டாக, வரிசைகளில் உள்ள இழப்பு கவுண்டர்களைப் படிப்பதன் மூலம்).

TSDuck பற்றி மிக சுருக்கமாக

TSDuck என்பது TS ஸ்ட்ரீம்களைக் கையாள ஒரு திறந்த மூல (2-கிளாஸ் BSD உரிமம்) மென்பொருள் (கன்சோல் பயன்பாடுகளின் தொகுப்பு மற்றும் தனிப்பயன் பயன்பாடுகள் அல்லது செருகுநிரல்களை உருவாக்குவதற்கான ஒரு நூலகம்). உள்ளீடாக, இது ஐபி (மல்டிகாஸ்ட்/யூனிகாஸ்ட்), http, hls, dvb ட்யூனர்கள், dektec dvb-asi demodulator ஆகியவற்றுடன் வேலை செய்ய முடியும், உள் TS-ஸ்ட்ரீம் ஜெனரேட்டர் மற்றும் கோப்புகளைப் படிக்கும் வசதி உள்ளது. வெளியீடு ஒரு கோப்பு, IP (மல்டிகாஸ்ட்/யூனிகாஸ்ட்), hls, dektec dvb-asi மற்றும் HiDes மாடுலேட்டர்கள், பிளேயர்கள் (mplayer, vlc, xine) மற்றும் டிராப் ஆகியவற்றிற்கு எழுதலாம். உள்ளீடு மற்றும் வெளியீட்டிற்கு இடையே பல்வேறு டிராஃபிக் செயலிகள் சேர்க்கப்படலாம், உதாரணமாக, PID ரீமேப்பிங், ஸ்கிராம்பிங் / டிஸ்கிராம்பிங், CC கவுண்டர் பகுப்பாய்வு, பிட்ரேட் கணக்கீடு மற்றும் TS ஸ்ட்ரீம்களுக்கான பிற வழக்கமான செயல்பாடுகள்.

இந்தக் கட்டுரையில், ஐபி ஸ்ட்ரீம்கள் (மல்டிகாஸ்ட்) உள்ளீடாகப் பயன்படுத்தப்படும், பிட்ரேட்_மானிட்டர் செயலிகள் (பெயரிலிருந்து அது என்னவென்று தெளிவாகத் தெரியும்) மற்றும் தொடர்ச்சி (சிசி கவுண்டர்களின் பகுப்பாய்வு) ஆகியவை பயன்படுத்தப்படுகின்றன. TSDuck ஆல் ஆதரிக்கப்படும் மற்றொரு உள்ளீட்டு வகையுடன் IP மல்டிகாஸ்ட்டை எளிதாக மாற்றலாம்.

கிடைக்கும் உத்தியோகபூர்வ உருவாக்கங்கள்/தொகுப்புகள் பெரும்பாலான தற்போதைய இயக்க முறைமைகளுக்கு TSDuck. டெபியனுக்கு அவை கிடைக்கவில்லை, ஆனால் டெபியன் 8 மற்றும் டெபியன் 10 ஆகியவற்றின் கீழ் எந்த பிரச்சனையும் இல்லாமல் அவற்றை உருவாக்க முடிந்தது.

அடுத்து, பதிப்பு TSDuck 3.19-1520 பயன்படுத்தப்படுகிறது, லினக்ஸ் OS ஆகப் பயன்படுத்தப்படுகிறது (தீர்வைத் தயாரிக்க debian 10 பயன்படுத்தப்பட்டது, உண்மையான பயன்பாட்டிற்கு CentOS 7 பயன்படுத்தப்பட்டது)

TSDuck மற்றும் OS ஐ தயார்படுத்துகிறது

உண்மையான ஓட்டங்களைக் கண்காணிப்பதற்கு முன், TSDuck சரியாகச் செயல்படுவதையும், பிணைய அட்டை அல்லது OS (சாக்கெட்) மட்டத்தில் எந்தக் குறையும் இல்லை என்பதையும் உறுதிப்படுத்திக் கொள்ள வேண்டும். நெட்வொர்க்கில் அல்லது "சேவையகத்தின் உள்ளே" - சொட்டுகள் எங்கு நிகழ்ந்தன என்பதை பின்னர் யூகிக்காமல் இருக்க இது தேவைப்படுகிறது. ethtool -S ethX கட்டளை மூலம் நெட்வொர்க் கார்டு மட்டத்தில் டிராப்களை நீங்கள் சரிபார்க்கலாம், அதே எத்தூலால் டியூனிங் செய்யப்படுகிறது (வழக்கமாக, நீங்கள் RX இடையகத்தை (-G) அதிகரிக்க வேண்டும் மற்றும் சில நேரங்களில் சில ஆஃப்லோடுகளை (-K) முடக்க வேண்டும்). ஒரு பொதுவான பரிந்துரையாக, பகுப்பாய்வு செய்யப்பட்ட ட்ராஃபிக்கைப் பெறுவதற்கு ஒரு தனி போர்ட்டைப் பயன்படுத்த அறிவுறுத்தப்படலாம், முடிந்தால், இது மற்ற போக்குவரத்து இருப்பதால் பகுப்பாய்வி போர்ட்டில் சரியாக வீழ்ச்சி ஏற்பட்டது என்ற உண்மையுடன் தொடர்புடைய தவறான நேர்மறைகளைக் குறைக்கிறது. இது சாத்தியமில்லை என்றால் (ஒரு போர்ட் கொண்ட ஒரு மினி-கம்ப்யூட்டர்/என்யூசி பயன்படுத்தப்படுகிறது), பின்னர் பகுப்பாய்வி இணைக்கப்பட்டுள்ள சாதனத்தில் மற்றவற்றுடன் தொடர்புடைய பகுப்பாய்வு செய்யப்பட்ட போக்குவரத்தின் முன்னுரிமையை அமைப்பது மிகவும் விரும்பத்தக்கது. மெய்நிகர் சூழல்களைப் பொறுத்தவரை, இங்கே நீங்கள் கவனமாக இருக்க வேண்டும் மற்றும் இயற்பியல் போர்ட்டில் இருந்து தொடங்கி ஒரு மெய்நிகர் இயந்திரத்திற்குள் ஒரு பயன்பாட்டுடன் முடிவடையும் பாக்கெட் துளிகளைக் கண்டறிய முடியும்.

ஹோஸ்டுக்குள் ஒரு ஸ்ட்ரீமின் உருவாக்கம் மற்றும் வரவேற்பு

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 ஆக அதிகரிக்க முயற்சிக்கவும். பகுப்பாய்வி 75 க்கு பதிலாக சுமார் 100 Mbps பிழைகள் மற்றும் 700000 Mbps ஐப் புகாரளிக்கிறது. யாரைக் குறை கூறுவது என்பதை நாங்கள் கண்டுபிடிக்க முயற்சிக்கிறோம் - ஜெனரேட்டருக்கு நேரம் இல்லை அல்லது சிக்கல் அதில் இல்லை, இதற்காக நாங்கள் ஒரு நிலையான எண்ணிக்கையை உருவாக்கத் தொடங்குகிறோம். பாக்கெட்டுகள் (100000 TS பாக்கெட்டுகள் = XNUMX 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 ஐபி பாக்கெட்டுகள் உருவாக்கப்பட்டன (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 பிழைகள் எதுவும் இல்லை.

tsp பயன்பாட்டின் CPU நுகர்வு படி. ஒரு கோர் i5-4260U CPU @ 1.40GHz, 10Mbps ஓட்ட பகுப்பாய்வுக்கு 3-4% CPU, 100Mbps - 25%, 200Mbps - 46% தேவைப்படும். % பாக்கெட் இழப்பை அமைக்கும் போது, ​​CPU இல் சுமை நடைமுறையில் அதிகரிக்காது (ஆனால் குறையலாம்).

அதிக உற்பத்தி வன்பொருளில், எந்த பிரச்சனையும் இல்லாமல் 1Gb / s க்கும் அதிகமான ஸ்ட்ரீம்களை உருவாக்க மற்றும் பகுப்பாய்வு செய்ய முடியும்.

உண்மையான நெட்வொர்க் கார்டுகளில் சோதனை

ஒரு வெத் ஜோடியைச் சோதித்த பிறகு, நீங்கள் இரண்டு ஹோஸ்ட்கள் அல்லது ஒரு ஹோஸ்டின் இரண்டு போர்ட்களை எடுக்க வேண்டும், போர்ட்களை ஒன்றோடொன்று இணைக்க வேண்டும், ஒன்றில் ஜெனரேட்டரைத் தொடங்கவும், இரண்டாவது பகுப்பாய்வைத் தொடங்கவும். இங்கே எந்த ஆச்சரியமும் இல்லை, ஆனால் உண்மையில் அது அனைத்து இரும்பு, பலவீனமான, மிகவும் சுவாரசியமான அது இங்கே இருக்கும் பொறுத்தது.

கண்காணிப்பு அமைப்பு (Zabbix) மூலம் பெறப்பட்ட தரவைப் பயன்படுத்துதல்

tsp இல் SNMP அல்லது அதைப் போன்ற எந்த இயந்திரத்திலும் படிக்கக்கூடிய API இல்லை. CC செய்திகள் குறைந்தபட்சம் 1 வினாடிக்கு ஒருங்கிணைக்கப்பட வேண்டும் (அதிக சதவீத பாக்கெட் இழப்புடன், பிட்ரேட்டைப் பொறுத்து வினாடிக்கு நூற்றுக்கணக்கான/ஆயிரம்/பத்தாயிரங்கள் இருக்கலாம்).

எனவே, தகவல் இரண்டையும் சேமித்து, சிசி பிழைகள் மற்றும் பிட்ரேட் ஆகியவற்றிற்கான வரைபடங்களை வரையவும் மற்றும் சில வகையான விபத்துக்களை உருவாக்கவும், பின்வரும் விருப்பங்கள் இருக்கலாம்:

  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

ஏற்றுக்கொள்ள முடியாத அளவுக்கு மெதுவாக இருப்பதுடன், பாஷில் சாதாரண த்ரெட்கள் இல்லை, பாஷ் வேலைகள் தனி செயல்முறைகள், பக்கவிளைவில் (ஒவ்வொரு நொடியும் வரும் பிட்ரேட் செய்திகளைப் பெறும்போது) மிஸ்ஸிங் பேக்கெட்டுகளின் மதிப்பை நொடிக்கு ஒருமுறை எழுத வேண்டியிருந்தது. இதன் விளைவாக, பாஷ் தனியாக விடப்பட்டது மற்றும் கோலாங்கில் ஒரு ரேப்பரை (பாகுபடுத்தி + திரட்டி) எழுத முடிவு செய்யப்பட்டது. இதேபோன்ற கோலாங் குறியீட்டின் CPU நுகர்வு tsp செயல்முறையை விட 4-5 மடங்கு குறைவாக உள்ளது. பாஷை கோலாங்குடன் மாற்றியதன் காரணமாக ரேப்பரின் வேகம் சுமார் 16 மடங்கு அதிகமாக இருந்தது, பொதுவாக இதன் விளைவாக ஏற்றுக்கொள்ளத்தக்கது (மோசமான நிலையில் CPU மேல்நிலை 25%). கோலாங் மூல கோப்பு அமைந்துள்ளது இங்கே.

ரேப்பரை இயக்கவும்

ரேப்பரைத் தொடங்க, systemd க்கான எளிய சேவை டெம்ப்ளேட் உருவாக்கப்பட்டது (இங்கே) /opt/tsduck-stat/ இல் அமைந்துள்ள பைனரி கோப்பாக (go build tsduck-stat.go) ரேப்பர் தொகுக்கப்பட வேண்டும். மோனோடோனிக் கடிகாரத்திற்கான ஆதரவுடன் நீங்கள் கோலாங்கைப் பயன்படுத்துகிறீர்கள் என்று கருதப்படுகிறது (>=1.9).

சேவையின் நிகழ்வை உருவாக்க, நீங்கள் systemctl enable கட்டளையை இயக்க வேண்டும் [மின்னஞ்சல் பாதுகாக்கப்பட்டது]:1234 பின்னர் systemctl தொடக்கத்துடன் இயக்கவும் [மின்னஞ்சல் பாதுகாக்கப்பட்டது]: 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/*). மல்டிகாஸ்ட் ஸ்ட்ரீம்களின் எண்ணிக்கையால் சேவைகளின் எண்ணிக்கை. இங்கே நீங்கள் மல்டிகாஸ்ட் குழுவிற்கு ஒரு வழியை உருவாக்க வேண்டும், ஒருவேளை rp_filter ஐ முடக்கலாம் அல்லது மூல ip க்கு ஒரு வழியை உருவாக்கலாம்.
  6. Discovery.sh ஐ இயக்கவும், அது json உருவாக்குகிறது என்பதை உறுதிப்படுத்தவும்.
  7. zabbix முகவர் கட்டமைப்பைச் சேர்க்கவும், zabbix முகவரை மறுதொடக்கம் செய்யவும்.
  8. டெம்ப்ளேட்டை zabbix க்கு பதிவேற்றவும், கண்காணிக்கப்படும் மற்றும் zabbix-ஏஜென்ட் நிறுவப்பட்ட ஹோஸ்டில் அதைப் பயன்படுத்தவும், சுமார் 5 நிமிடங்கள் காத்திருக்கவும், புதிய உருப்படிகள், வரைபடங்கள் மற்றும் தூண்டுதல்கள் உள்ளதா எனப் பார்க்கவும்.

விளைவாக

IP(TS) ஸ்ட்ரீம்களை கண்காணிக்க TSDuck ஐப் பயன்படுத்துதல்

பாக்கெட் இழப்பைக் கண்டறியும் பணிக்கு, இது கிட்டத்தட்ட போதுமானது, குறைந்தபட்சம் கண்காணிப்பு இல்லாததை விட இது சிறந்தது.

உண்மையில், வீடியோ துண்டுகளை இணைக்கும்போது சிசி “இழப்புகள்” ஏற்படலாம் (எனக்குத் தெரிந்தவரை, ரஷ்ய கூட்டமைப்பில் உள்ள உள்ளூர் தொலைக்காட்சி மையங்களில் செருகல்கள் இப்படித்தான் செய்யப்படுகின்றன, அதாவது சிசி கவுண்டரை மீண்டும் கணக்கிடாமல்), இதை நினைவில் கொள்ள வேண்டும். தனியுரிம தீர்வுகள் SCTE-35 லேபிள்களைக் கண்டறிவதன் மூலம் இந்த சிக்கலை ஓரளவு தவிர்க்கின்றன (ஸ்ட்ரீம் ஜெனரேட்டரால் சேர்க்கப்பட்டால்).

போக்குவரத்துத் தரக் கண்காணிப்பைப் பொறுத்தவரை, நடுக்கம் கண்காணிப்பு (IAT) இல்லாமை உள்ளது. டிவி உபகரணங்கள் (அது மாடுலேட்டர்கள் அல்லது இறுதி சாதனங்கள்) இந்த அளவுருவின் தேவைகளைக் கொண்டுள்ளன, மேலும் ஜிட்பஃபரை முடிவிலிக்கு உயர்த்துவது எப்போதும் சாத்தியமில்லை. பெரிய இடையகங்களைக் கொண்ட உபகரணங்களை போக்குவரத்தில் பயன்படுத்தும்போது நடுக்கம் மிதக்கும் மற்றும் QoS உள்ளமைக்கப்படவில்லை அல்லது அத்தகைய நிகழ்நேர போக்குவரத்தை அனுப்பும் அளவுக்கு நன்றாக உள்ளமைக்கப்படவில்லை.

ஆதாரம்: www.habr.com

கருத்தைச் சேர்