ProHoster > ဘလော့ > အုပ်ချုပ်ရေး > IP(TS) စီးကြောင်းများကို စောင့်ကြည့်ရန် TSDuck ကို အသုံးပြုခြင်း။

IP(TS) စီးကြောင်းများကို စောင့်ကြည့်ရန် TSDuck ကို အသုံးပြုခြင်း။

ယနေ့တွင်၊ ဥပမာ IP(TS) ထုတ်လွှင့်မှုများကို စောင့်ကြည့်ရန်အတွက် အဆင်သင့်လုပ်ထားသော (မူပိုင်) ဖြေရှင်းချက် ရှိပါသည်။ VB и iQ၎င်းတို့တွင် များပြားလှသော လုပ်ဆောင်ချက်များစွာရှိပြီး အများအားဖြင့် တီဗီဝန်ဆောင်မှုများနှင့် ပတ်သက်သည့် အော်ပရေတာကြီးများတွင် ထိုကဲ့သို့သော ဖြေရှင်းချက်များရှိသည်။ ဤဆောင်းပါးသည် open source ပရောဂျက်တစ်ခုအပေါ် အခြေခံ၍ ဖြေရှင်းချက်တစ်ခုကို ဖော်ပြသည်။ TSDuckCC(အဆက်မပြတ်ကောင်တာ) တန်ပြန်နှင့်ဘစ်နှုန်းဖြင့် IP(TS) စီးဆင်းမှုများကို အနည်းဆုံးထိန်းချုပ်ရန်အတွက် ဒီဇိုင်းထုတ်ထားသည်။ ဖြစ်နိုင်ချေရှိသော အပလီကေးရှင်းတစ်ခုသည် ငှားရမ်းထားသော L2 ချန်နယ်တစ်ခုမှတစ်ဆင့် ပက်ကတ်များဆုံးရှုံးမှု သို့မဟုတ် စီးဆင်းမှုတစ်ခုလုံးကို ထိန်းချုပ်ရန်ဖြစ်သည် (ဥပမာ၊ ပုံမှန်အားဖြင့်၊ စီတန်းများတွင် ဆုံးရှုံးမှုကောင်တာများကိုဖတ်ရှုခြင်းဖြင့် ပုံမှန်မစောင့်ကြည့်နိုင်)။

TSDuck အကြောင်း အတိုချုပ်

TSDuck သည် TS ထုတ်လွှင့်မှုများကို ကြိုးကိုင်ခြယ်လှယ်ရန်အတွက် အဖွင့်အရင်းအမြစ် (2-Clause BSD လိုင်စင်) ဆော့ဖ်ဝဲလ် (ကွန်ဆိုးလ်အသုံးအဆောင်များ အစုံလိုက်နှင့် စိတ်ကြိုက်အသုံးအဆောင်များ သို့မဟုတ် ပလပ်အင်များကို ဖန်တီးရန်အတွက် စာကြည့်တိုက်တစ်ခု) ဖြစ်သည်။ ထည့်သွင်းမှုအနေဖြင့်၊ ၎င်းသည် IP (multicast/unicast)၊ http၊ hls၊ dvb tuners၊ dektec dvb-asi demodulator၊ အတွင်းပိုင်း TS stream generator တစ်ခုရှိပြီး ဖိုင်များမှဖတ်ရှုခြင်းတို့ကို လုပ်ဆောင်နိုင်သည်။ အထွက်သည် ဖိုင်တစ်ခု၊ IP (multicast/unicast)၊ hls၊ dektec dvb-asi နှင့် HiDes မော်ဂျူလတာများ၊ ကစားသမားများ (mplayer၊ vlc၊ xine) နှင့် drop လုပ်နိုင်သည်။ အဝင်နှင့်အထွက်ကြားရှိ အမျိုးမျိုးသော traffic ပရိုဆက်ဆာများကို သင်ဖွင့်နိုင်သည်၊ ဥပမာအားဖြင့်၊ PID ပြန်လည်ပုံဖော်ခြင်း၊ မွှေနှောက်ခြင်း / descrambling၊ CC တန်ပြန်ခွဲခြမ်းစိတ်ဖြာခြင်း၊ ဘစ်နှုန်းတွက်ချက်ခြင်းနှင့် TS ထုတ်လွှင့်မှုများအတွက် အခြားသော ပုံမှန်လုပ်ဆောင်မှုများ။

ဤဆောင်းပါးတွင်၊ IP စီးကြောင်းများ (multicast) အား ထည့်သွင်းမှုတစ်ခုအနေဖြင့် အသုံးပြုမည်ဖြစ်ပြီး၊ ပရိုဆက်ဆာများသည် bitrate_monitor (အမည်အားဖြင့် ထင်ရှားသည်) နှင့် ဆက်တိုက် (CC ကောင်တာများကို ခွဲခြမ်းစိတ်ဖြာခြင်း) ကို အသုံးပြုမည်ဖြစ်သည်။ TSDuck ပံ့ပိုးထားသော အခြားထည့်သွင်းမှုအမျိုးအစားဖြင့် IP multicast ကို အလွယ်တကူ အစားထိုးနိုင်ပါသည်။

ရရှိနိုင်ပါသည်။ တရားဝင်တည်ဆောက်မှုများ/ပက်ကေ့ခ်ျများ လက်ရှိလည်ပတ်မှုစနစ်အများစုအတွက် TSDuck။ ၎င်းတို့ကို Debian အတွက် မရရှိနိုင်သော်လည်း ပြဿနာတစ်စုံတစ်ရာမရှိဘဲ debian 8 နှင့် debian 10 အောက်တွင် ၎င်းတို့ကို တည်ဆောက်နိုင်ခဲ့သည်။

ထို့နောက်၊ ဗားရှင်း TSDuck 3.19-1520 ကိုအသုံးပြုသည်၊ Linux ကို OS အဖြစ်အသုံးပြုသည် (ဖြေရှင်းချက်ကိုပြင်ဆင်ရန်အတွက် debian 10 ကိုအသုံးပြုခဲ့သည်၊ CentOS 7 ကို အမှန်တကယ်အသုံးပြုရန်အတွက်အသုံးပြုခဲ့သည်)

TSDuck နှင့် OS ကို ပြင်ဆင်နေပါသည်။

စစ်မှန်သောစီးဆင်းမှုများကိုစောင့်ကြည့်ခြင်းမပြုမီ၊ သင်သည် TSDuck မှန်ကန်စွာအလုပ်လုပ်ပြီး ကွန်ရက်ကတ် သို့မဟုတ် OS (socket) အဆင့်တွင် ကျဆင်းသွားခြင်းမရှိကြောင်း သေချာစေရန်လိုအပ်သည်။ အစက်အပြောက်များဖြစ်ပွားသည့်နေရာ - ကွန်ရက်ပေါ်တွင် သို့မဟုတ် "ဆာဗာအတွင်း" ကို နောက်ပိုင်းတွင် မခန့်မှန်းနိုင်ရန် ၎င်းကို လိုအပ်သည်။ ethtool -S ethX command ဖြင့် ကွန်ရက်ကတ်အဆင့်တွင် ကျဆင်းမှုများကို စစ်ဆေးနိုင်ပြီး တူညီသော ethtool ဖြင့် ချိန်ညှိခြင်းကို လုပ်ဆောင်သည် (ပုံမှန်အားဖြင့် သင်သည် RX ကြားခံ (-G) ကို တိုးမြှင့်ရန်နှင့် တစ်ခါတစ်ရံတွင် အချို့သော offloads (-K) ကို ပိတ်ရန်)။ ယေဘူယျအကြံပြုချက်အနေဖြင့်၊ ခွဲခြမ်းစိတ်ဖြာထားသောအသွားအလာကိုလက်ခံရန်အတွက်သီးခြားဆိပ်ကမ်းကိုအသုံးပြုရန်အကြံပြုနိုင်သည်၊ ဖြစ်နိုင်ပါက၊ ၎င်းသည် အခြားအသွားအလာများရှိနေခြင်းကြောင့် ခွဲခြမ်းစိတ်ဖြာသည့်ပို့တ်တွင် ကျဆင်းသွားခြင်းနှင့်ပတ်သက်၍ မှားယွင်းသောအပြုသဘောဆောင်မှုများကို လျော့နည်းစေသည်။ ၎င်းသည် မဖြစ်နိုင်ပါက ( port တစ်ခုပါသော ကွန်ပြူတာအသေး/ NUC ကို အသုံးပြုထားသည်)၊ ထို့နောက် ခွဲခြမ်းစိတ်ဖြာသူ ချိတ်ဆက်ထားသည့် စက်ပေါ်ရှိ ကျန်အရာများနှင့် ဆက်စပ်၍ ခွဲခြမ်းစိတ်ဖြာထားသော traffic ၏ ဦးစားပေးကို configure လုပ်ရန် အလွန်နှစ်လိုဖွယ်ကောင်းပါသည်။ virtual ပတ် ၀ န်းကျင်နှင့်ပတ်သက်၍၊ ဤနေရာတွင် သင်သတိထားရန်လိုအပ်ပြီး ရုပ်ပိုင်းဆိုင်ရာအပေါက်မှစတင်ကာ ပက်ကက်အစက်များကိုတွေ့နိုင်ပြီး virtual machine အတွင်းရှိအက်ပလီကေးရှင်းတစ်ခုဖြင့်အဆုံးသတ်နိုင်မည်ဖြစ်သည်။

မျိုးဆက်နှင့် ဧည့်ခံသည့်အိမ်ရှင်အတွင်း၌ စမ်းချောင်းတစ်ခု

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 ဖြင့် traffic generator ကို စတင်ပါသည်။

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

"-p 7 -e" ဆိုသည်မှာ TS packet 7 ခုကို IP packet 1 တွင် ထုပ်ပိုးပြီး ခက်ခက်ခဲခဲ လုပ်ရမည်ဟု ဆိုလိုပါသည်။ IP packet မပို့မီ နောက်ဆုံးပရိုဆက်ဆာမှ TS packet 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

မျှော်လင့်ထားသည်။ ပက်ကတ်ဆုံးရှုံးမှု (ip netns exec P iptables -F) ကိုပိတ်ပြီး generator bitrate ကို 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

သင်တွေ့မြင်ရသည့်အတိုင်း IP packet 100000 အတိအကျ (151925460-151825460) ကို ထုတ်ပေးခဲ့သည်။ ထို့ကြောင့် ခွဲခြမ်းစိတ်ဖြာသူနှင့် ဘာဖြစ်နေသည်ကို အဖြေရှာကြည့်ရအောင်၊ ၎င်းအတွက် veth1 ရှိ RX ကောင်တာဖြင့် စစ်ဆေးကြည့်ရာ၊ ၎င်းသည် veth0 ရှိ TX ကောင်တာနှင့် တင်းကြပ်စွာ ညီမျှသည်၊ ထို့နောက် socket အဆင့်တွင် ဘာဖြစ်မည်ကို ကြည့်သည်-

# 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

ဤနေရာတွင် drops အရေအတွက် = 24355 ကိုတွေ့မြင်နိုင်ပါသည်။ TS ထုပ်ပိုးမှုများတွင်၊ ၎င်းသည် 170485 ၏ 24.36% သို့မဟုတ် 700000% ဖြစ်သောကြောင့် ဆုံးရှုံးသွားသောဘစ်နှုန်း၏ 25% သည် udp socket တွင် ကျဆင်းသွားသည်ကို ကျွန်ုပ်တို့မြင်ရသည်။ UDP socket တွင် ကျဆင်းမှုများသည် အများအားဖြင့် ကြားခံမရှိခြင်းကြောင့် ဖြစ်တတ်သည်၊ ပုံမှန် socket ကြားခံအရွယ်အစားနှင့် အများဆုံး socket ကြားခံအရွယ်အစားကိုကြည့်ပါ-

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

ထို့ကြောင့်၊ အပလီကေးရှင်းများသည် ကြားခံအရွယ်အစားကို ပြတ်သားစွာမတောင်းဆိုပါက၊ socket များကို ကြားခံ 208 KB ဖြင့် ဖန်တီးထားသော်လည်း ၎င်းတို့ ထပ်မံတောင်းဆိုပါက၊ တောင်းဆိုထားသည့်အရာကို လက်ခံရရှိမည်မဟုတ်ပါ။ IP ထည့်သွင်းမှု (-buffer-size) အတွက် tsp တွင် ကြားခံအရွယ်အစားကို သင်သတ်မှတ်နိုင်သောကြောင့်၊ ကျွန်ုပ်တို့သည် မူလ socket အရွယ်အစားကို မထိဘဲ၊ အများဆုံး socket ကြားခံအရွယ်အစားကိုသာ သတ်မှတ်ပြီး 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

socket buffer ကို ချိန်ညှိခြင်းဖြင့်၊ ယခု အစီရင်ခံထားသော ဘစ်နှုန်းသည် 100Mbps ခန့်ရှိပြီး CC အမှားအယွင်းများ မရှိပါ။

tsp application ၏ CPU သုံးစွဲမှုအရ၊ core i5-4260U CPU @ 1.40GHz၊ 10Mbps စီးဆင်းမှု ခွဲခြမ်းစိတ်ဖြာမှုတွင် 3-4% CPU၊ 100Mbps - 25%, 200Mbps - 46% လိုအပ်ပါသည်။ % Packet Loss ကို သတ်မှတ်သောအခါ၊ CPU ပေါ်ရှိ ဝန်သည် လက်တွေ့တွင် တိုးမလာဘဲ (သို့သော် ကျဆင်းနိုင်သည်)။

ပိုမိုအကျိုးရှိသော ဟာ့ဒ်ဝဲတွင်၊ ပြဿနာတစ်စုံတစ်ရာမရှိဘဲ 1Gb/s ထက်ပိုသော stream များကို ထုတ်လုပ်ပြီး ခွဲခြမ်းစိတ်ဖြာနိုင်သည်။

စစ်မှန်သောကွန်ရက်ကတ်များပေါ်တွင်စမ်းသပ်ခြင်း။

veth pair တစ်ခုကို စမ်းသပ်ပြီးနောက်၊ host တစ်ခု၏ host နှစ်ခု သို့မဟုတ် port နှစ်ခုကိုယူရန်၊ port များကို တစ်ခုနှင့်တစ်ခုချိတ်ဆက်ရန်၊ generator ကိုတစ်ခုတွင်စတင်ရန်နှင့် ဒုတိယတွင် analyzer ကိုလိုအပ်ပါသည်။ ဒီနေရာမှာ အံ့သြစရာတွေ မရှိပေမယ့် တကယ်တော့ အဲဒါက သံပေါ်မှာပဲ မူတည်တယ်၊ အားနည်းတယ်၊ ပိုစိတ်ဝင်စားဖို့ကောင်းတယ်။

စောင့်ကြည့်ရေးစနစ် (Zabbix) မှရရှိလာသောဒေတာကိုအသုံးပြုခြင်း၊

tsp တွင် SNMP သို့မဟုတ် အလားတူ စက်ဖြင့်ဖတ်နိုင်သော API မရှိပါ။ CC မက်ဆေ့ဂျ်များကို အနည်းဆုံး 1 စက္ကန့်ကြာ စုစည်းထားရပါမည် (ပက်ကေ့ချ်ဆုံးရှုံးမှု ရာခိုင်နှုန်းများသဖြင့်၊ ဘစ်နှုန်းပေါ်မူတည်၍ တစ်စက္ကန့်လျှင် ရာနှင့်ချီ/ထောင်နှင့် သောင်းချီရှိနိုင်သည်)။

ထို့ကြောင့်၊ အချက်အလက်နှစ်ခုလုံးကို သိမ်းဆည်းရန်နှင့် CC အမှားများအတွက် ဂရပ်များဆွဲရန်နှင့် ဘစ်နှုန်းနှင့် မတော်တဆမှုမျိုးဖြစ်စေရန်အတွက်၊ အောက်ပါရွေးချယ်စရာများ ရှိနိုင်သည်-

  1. လက်ဖက်ရည်ဇွန်း၏အထွက်ကို စီစဥ်၍ စုစည်းပါ (ဥပမာ၊ လိုချင်သောပုံစံသို့ပြောင်းပါ။
  2. tsp ကိုယ်တိုင်နှင့်/သို့မဟုတ် ပရိုဆက်ဆာ ပလပ်အင်များ bitrate_monitor နှင့် အဆက်ပြတ်နေစေရန်အတွက် ရလဒ်အား စောင့်ကြည့်ရေးစနစ်အတွက် သင့်လျော်သော စက်ဖတ်နိုင်သော ပုံစံဖြင့် ပေးဆောင်ပါသည်။
  3. သင်၏လျှောက်လွှာကို tsduck စာကြည့်တိုက်၏ထိပ်တွင်ရေးပါ။

အထူးသဖြင့်၊ tsduck ကိုယ်တိုင်က အဆင့်နိမ့် (ခေတ်မီစံနှုန်းများ) ဘာသာစကား (C++) ဖြင့် ရေးသားထားသည်ကို ထည့်သွင်းစဉ်းစားရာတွင် ရွေးချယ်မှု 1 သည် အလွယ်ကူဆုံးဖြစ်သည်။

ရိုးရှင်းသော bash parser+aggregator ရှေ့ပြေးပုံစံသည် 10Mbps ထုတ်လွှင့်မှုနှင့် 50% ပက်ကတ်ဆုံးရှုံးမှု (အဆိုးဆုံးအခြေအနေတွင်) bash လုပ်ငန်းစဉ်သည် 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

လက်မခံနိုင်လောက်အောင် နှေးကွေးနေသည့်အပြင်၊ bash တွင် ပုံမှန်စာတွဲများမရှိပါ၊ bash အလုပ်များသည် သီးခြားလုပ်ငန်းစဉ်များဖြစ်ပြီး ဘေးထွက်ဆိုးကျိုးတွင် ပျောက်ဆုံးနေသောPackets ၏တန်ဖိုးကို တစ်စက္ကန့်လျှင်တစ်ကြိမ် ရေးသားခဲ့ရသည် (စက္ကန့်တိုင်းရောက်လာသော bitrate မက်ဆေ့ချ်များကို လက်ခံရရှိသည့်အခါ)။ ရလဒ်အနေဖြင့် bash သည် တစ်ဦးတည်းကျန်ရစ်ခဲ့ပြီး golang တွင် wrapper (parser + aggregator) ကိုရေးရန် ဆုံးဖြတ်ခဲ့သည်။ အလားတူ golang ကုဒ်၏ CPU သုံးစွဲမှုသည် tsp လုပ်ငန်းစဉ်ထက် 4-5 ဆ လျော့နည်းသည်။ bash နှင့် golang ကိုအစားထိုးခြင်းကြောင့် wrapper ၏အရှိန်မြှင့်မှုသည် 16 ဆခန့်ဖြစ်လာပြီးယေဘုယျအားဖြင့်ရလဒ်လက်ခံနိုင်သည် (အဆိုးဆုံးအခြေအနေတွင် CPU သည် 25% ) ။ golang အရင်းအမြစ်ဖိုင်တည်ရှိသည်။ ဒီမှာ.

ထုပ်ပိုးမှုကို ပြေးပါ။

wrapper စတင်ရန်၊ systemd အတွက် အရိုးရှင်းဆုံး ဝန်ဆောင်မှုပုံစံကို ပြုလုပ်ခဲ့သည် (ဒီမှာ) wrapper ကိုယ်တိုင်က /opt/tsduck-stat/ တွင်ရှိသော binary ဖိုင် (go build tsduck-stat.go) သို့ စုစည်းထားသင့်သည်။ monotonic နာရီ (>=1.9) အတွက် ပံ့ပိုးမှုဖြင့် golang ကို သင်အသုံးပြုနေသည်ဟု ယူဆပါသည်။

ဝန်ဆောင်မှု၏ဥပမာတစ်ခုဖန်တီးရန် systemctl enable command ကိုသင်လုပ်ဆောင်ရန်လိုအပ်သည်။ [အီးမေးလ်ကိုကာကွယ်ထားသည်]:1234 ထို့နောက် systemctl start ဖြင့် run ပါ။ [အီးမေးလ်ကိုကာကွယ်ထားသည်]: 1234 ။

Zabbix မှရှာဖွေတွေ့ရှိမှု

zabbix လည်ပတ်နေသောဝန်ဆောင်မှုများကိုရှာဖွေတွေ့ရှိနိုင်စေရန်အတွက်၊ ၎င်းကိုလုပ်ဆောင်ပြီးဖြစ်သည်။ အုပ်စုစာရင်းမီးစက် (discovery.sh)၊ Zabbix ရှာဖွေတွေ့ရှိမှုအတွက် လိုအပ်သော ဖော်မတ်ဖြင့် ၎င်းသည် တူညီသောနေရာတွင် တည်ရှိသည်ဟု ယူဆသည် - in /opt/tsduck-stat။ zabbix-agent မှတစ်ဆင့် ရှာဖွေတွေ့ရှိမှုကို လုပ်ဆောင်ရန်၊ သင်ထည့်သွင်းရန် လိုအပ်သည်။ .conf ဖိုင် အသုံးပြုသူပါရာမီတာကိုထည့်ရန် zabbix-agent configuration directory သို့။

Zabbix နမူနာပုံစံ

ပုံစံပုံစံကို ဖန်တီးခဲ့သည်။ (tsduck_stat_template.xml) တွင် အော်တိုရှာဖွေတွေ့ရှိမှု စည်းမျဉ်း၊ အမျိုးအမည် ရှေ့ပြေးပုံစံများ၊ ဂရပ်များနှင့် အစပျိုးမှုများ ပါရှိသည်။

အတိုချုံးစစ်ဆေးရန်စာရင်း (ကောင်းပြီ၊ တစ်စုံတစ်ဦးမှ ၎င်းကိုအသုံးပြုရန် ဆုံးဖြတ်ပါက မည်ကဲ့သို့)

  1. Tsp သည် "စံပြ" အခြေအနေများအောက်တွင် ပက်ကေ့ဂျ်များကို မချပါနှင့် (မီးစက်နှင့် ခွဲခြမ်းစိတ်ဖြာစက်ကို တိုက်ရိုက်ချိတ်ဆက်ထားသည်) ကျဆင်းသွားပါက၊ အပိုဒ် 2 သို့မဟုတ် ဤကိစ္စနှင့်ပတ်သက်သည့် ဆောင်းပါး၏စာသားကို ကြည့်ပါ။
  2. အများဆုံး socket ကြားခံကို ချိန်ညှိမှုပြုလုပ်ပါ (net.core.rmem_max=8388608)။
  3. tsduck-stat.go ကိုတည်ဆောက်ပါ (tsduck-stat.go) ကို စုစည်းပါ။
  4. ဝန်ဆောင်မှုပုံစံကို /lib/systemd/system တွင် ထည့်ပါ။
  5. systemctl ဖြင့်ဝန်ဆောင်မှုများကိုစတင်ပါ၊ ကောင်တာများစတင်ပေါ်လာကြောင်းစစ်ဆေးပါ (grep "" /dev/shm/tsduck-stat/*) ။ multicast streams အရေအတွက်အလိုက် ဝန်ဆောင်မှုအရေအတွက်။ ဤနေရာတွင် သင်သည် multicast အုပ်စုသို့ လမ်းကြောင်းတစ်ခု ဖန်တီးရန် လိုအပ်နိုင်သည်၊ ဖြစ်နိုင်သည်မှာ rp_filter ကို ပိတ်ရန် သို့မဟုတ် အရင်းအမြစ် ip သို့ လမ်းကြောင်းတစ်ခု ဖန်တီးရန် လိုအပ်နိုင်သည်။
  6. discovery.sh ကိုဖွင့်ပါ၊ json ကိုထုတ်ပေးကြောင်းသေချာပါစေ။
  7. zabbix အေးဂျင့် config ကိုထည့်ပါ၊ zabbix အေးဂျင့်ကို ပြန်လည်စတင်ပါ။
  8. ပုံစံပလိတ်ကို zabbix သို့ အပ်လုဒ်လုပ်ပါ၊ စောင့်ကြည့်နေသည့် အိမ်ရှင်ထံ လျှောက်ထားပြီး zabbix-agent ကို ထည့်သွင်းပြီး၊ 5 မိနစ်ခန့် စောင့်ပါ၊ ပစ္စည်းအသစ်များ၊ ဂရပ်များနှင့် အစပျိုးမှုများ ရှိမရှိ ကြည့်ရှုပါ။

ရလဒ်

IP(TS) စီးကြောင်းများကို စောင့်ကြည့်ရန် TSDuck ကို အသုံးပြုခြင်း။

packet ဆုံးရှုံးမှုကို ထောက်လှမ်းခြင်းလုပ်ငန်းအတွက်၊ ၎င်းသည် လုံလောက်လုနီးပါးဖြစ်သည်၊ အနည်းဆုံး ၎င်းသည် စောင့်ကြည့်ခြင်းမရှိခြင်းထက် ပိုကောင်းပါသည်။

အမှန်စင်စစ်၊ ဗီဒီယိုအပိုင်းအစများကို ပေါင်းစည်းသည့်အခါ CC "ဆုံးရှုံးမှု" ဖြစ်ပေါ်လာနိုင်သည် (ကျွန်တော်သိသလောက်၊ ရုရှားဖက်ဒရေးရှင်းရှိ ဒေသဆိုင်ရာ တီဗီစင်တာများတွင် ထည့်သွင်းမှုများ ပြုလုပ်ပုံ၊ ဥပမာ CC ကောင်တာကို ပြန်လည်တွက်ချက်ခြင်းမပြုဘဲ)၊ ဒါကို မှတ်သားထားရပါမည်။ တစ်ဦးတည်းပိုင်ဖြေရှင်းချက်များသည် SCTE-35 အညွှန်းများ (စီးကြောင်းမီးစက်ဖြင့်ထည့်ပါက) ကိုရှာဖွေခြင်းဖြင့် ဤပြဿနာကို တစ်စိတ်တစ်ပိုင်းအားဖြင့် ရှောင်တိမ်းပါ။

သယ်ယူပို့ဆောင်ရေး အရည်အသွေး စောင့်ကြည့်ခြင်း တွင် တုန်လှုပ်ခြောက်ခြားမှု စောင့်ကြည့်ခြင်း (IAT) မရှိခြင်း။ တီဗီစက်ပစ္စည်းများ (မော်ဂျူလာတာများ သို့မဟုတ် စက်ပစ္စည်းများဖြစ်ပါစေ) တွင် ဤကန့်သတ်သတ်မှတ်ချက်များအတွက် လိုအပ်ချက်များရှိပြီး jitbuffer ကို အဆုံးမရှိအထိ ချဲ့ထွင်ရန် အမြဲတမ်းမဖြစ်နိုင်ပါ။ အကူးအပြောင်းတွင် ကြီးမားသော ကြားခံကိရိယာများပါရှိသော ကိရိယာများကို အသုံးပြုပြီး QoS ကို ပြင်ဆင်သတ်မှတ်မထားပါက သို့မဟုတ် ယင်းကဲ့သို့ အချိန်နှင့်တပြေးညီ အသွားအလာများကို ထုတ်လွှင့်ရန် လုံလောက်သော ပြင်ဆင်သတ်မှတ်မှု မရှိသည့်အခါ တုန်လှုပ်သွားနိုင်သည်။

source: www.habr.com

မှတ်ချက် Add