අද, උදාහරණයක් ලෙස, IP(TS) ප්‍රවාහයන් නිරීක්ෂණය කිරීම සඳහා සූදානම් කළ (හිමිකාර) විසඳුම් තිබේ. и , ඔවුන්ට තරමක් පොහොසත් කාර්යයන් සමූහයක් ඇති අතර සාමාන්‍යයෙන් රූපවාහිනී සේවා සමඟ කටයුතු කරන විශාල ක්‍රියාකරුවන්ට සමාන විසඳුම් ඇත. මෙම ලිපිය විවෘත මූලාශ්‍ර ව්‍යාපෘතියක් මත පදනම් වූ විසඳුමක් විස්තර කරයි , CC (අඛණ්ඩ කවුන්ටරය) කවුන්ටරය සහ බිට්රේට් භාවිතයෙන් IP(TS) ප්‍රවාහ අවම පාලනය සඳහා නිර්මාණය කර ඇත. විය හැකි යෙදුමක් වන්නේ බදු දී ඇති L2 නාලිකාවක් හරහා පැකට් නැතිවීම හෝ සම්පූර්ණ ප්‍රවාහය නිරීක්ෂණය කිරීමයි (එය සාමාන්‍යයෙන් නිරීක්ෂණය කළ නොහැක, උදාහරණයක් ලෙස, පෝලිම්වල පාඩු කවුන්ටර කියවීමෙන්).
TSDuck ගැන ඉතා කෙටියෙන්
TSDuck යනු TS ප්‍රවාහයන් හැසිරවීම සඳහා විවෘත මූලාශ්‍ර (2- වගන්ති BSD බලපත්‍රය) මෘදුකාංගයකි (කොන්සෝල උපයෝගිතා කට්ටලයක් සහ ඔබේම උපයෝගිතා හෝ ප්ලගීන සංවර්ධනය කිරීම සඳහා පුස්තකාලයකි). ආදානයක් ලෙස, එය IP (multicast/unicast), http, hls, dvb tuners, dektec dvb-asi demodulator සමඟ ක්‍රියා කළ හැකිය, අභ්‍යන්තර TS ප්‍රවාහ උත්පාදකයක් සහ ගොනු වලින් කියවීමක් ඇත. ප්‍රතිදානය ගොනුවකට පටිගත කිරීම, IP (multicast/unicast), hls, dektec dvb-asi සහ HiDes modulators, players (mplayer, vlc, xine) සහ drop විය හැක. ආදානය සහ ප්‍රතිදානය අතර, ඔබට විවිධ රථවාහන ප්‍රොසෙසර සක්‍රීය කළ හැක, උදාහරණයක් ලෙස, PID නැවත සකස් කිරීම, ස්ක්‍රැම්බල් කිරීම/ඩිස්ක්‍රම්බ් කිරීම, CC කවුන්ටර විශ්ලේෂණය කිරීම, බිට්රේට් ගණනය කිරීම සහ TS ප්‍රවාහ සඳහා සාමාන්‍ය වෙනත් මෙහෙයුම්.
මෙම ලිපියේදී, IP ප්‍රවාහ (multicast) ආදාන, bitrate_monitor ප්‍රොසෙසර (නමයෙන් පැහැදිලි වන්නේ මෙය කුමක්ද යන්නයි) සහ අඛණ්ඩතාව (CC කවුන්ටර විශ්ලේෂණය) ප්‍රොසෙසර ලෙස භාවිතා කරනු ඇත. කිසිදු ගැටළුවක් නොමැතිව, ඔබට TSDuck විසින් සහාය දක්වන වෙනත් ආදාන වර්ගයක් සමඟ IP බහු විකාශනය ප්‍රතිස්ථාපනය කළ හැකිය.
පවතින බොහෝ වත්මන් OS සඳහා TSDuck. Debian සඳහා කිසිවක් නැත, නමුත් අපි ඒවා කිසිදු ගැටළුවක් නොමැතිව Debian 8 සහ Debian 10 සඳහා සම්පාදනය කළෙමු.
ඊළඟට, TSDuck අනුවාදය 3.19-1520 භාවිතා වේ, ලිනක්ස් මෙහෙයුම් පද්ධතිය ලෙස භාවිතා කරයි (විසඳුම සකස් කිරීමට debian 10 භාවිතා කරන ලදී, සත්‍ය භාවිතය සඳහා CentOS 7 භාවිතා කරන ලදී)
TSDuck සහ OS සූදානම් කිරීම
සැබෑ ප්‍රවාහයන් නිරීක්ෂණය කිරීමට පෙර, TSDuck නිවැරදිව ක්‍රියා කරන බවටත් ජාල කාඩ්පතේ හෝ OS (සොකට්) මට්ටමින් පහත වැටීම් සිදු නොවන බවටත් ඔබ සහතික විය යුතුය. ජාලයේ හෝ "සේවාදායකය තුළ" බිංදු සිදු වූ ස්ථානය ඔබට පසුව අනුමාන කිරීමට අවශ්‍ය නොවන පරිදි මෙය අවශ්‍ය වේ. ඔබට ethtool -S ethX විධානය සමඟ ජාල කාඩ්පත් මට්ටමින් පහත වැටීම් පරීක්ෂා කළ හැකිය, සුසර කිරීම එකම ethtool මගින් සිදු කෙරේ (සාමාන්‍යයෙන් ඔබට RX බෆරය (-G) වැඩි කිරීමට සහ සමහර විට සමහර offloads (-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” යන්නෙන් අදහස් කරන්නේ ඔබ සෑම තත්පරයකම බිට්රේට් ගණනය කළ යුතු අතර සෑම තත්පරයකම බිට්රේට් පිළිබඳ තොරතුරු ප්‍රදර්ශනය කළ යුතු බවයි.
අපි 10 Mbit/s වේගයකින් රථවාහන උත්පාදක යන්ත්රයක් දියත් කරමු:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234එහිදී “-p 7 -e” යන්නෙන් අදහස් වන්නේ ඔබට TS පැකට් 7ක් IP පැකට් 1කට අසුරා එය අමාරුවෙන් (-e), i.e. IP පැකට්ටුවක් සෑදීමට පෙර අවසාන ප්‍රොසෙසරයෙන් TS පැකට් 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) අක්‍රීය කර උත්පාදක බිටු අනුපාතය 100 Mbit/s දක්වා වැඩි කිරීමට උත්සාහ කරමු. විශ්ලේෂකය CC දෝෂ සමූහයක් සහ 75 වෙනුවට Mbit/s 100 ක් පමණ වාර්තා කරයි. අපි දොස් පැවරිය යුත්තේ කාටද යන්න සොයා ගැනීමට උත්සාහ කරන්නෙමු - උත්පාදක යන්ත්රය ක්‍රියාත්මක නොවේ හෝ ගැටලුව එහි නොමැත, මෙය සිදු කිරීම සඳහා අපි උත්පාදනය ආරම්භ කරමු. ස්ථාවර පැකට් ගණන (TS පැකට් 700000 = IP පැකට් 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 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 බෆරයකින් සාදනු ලැබේ, නමුත් ඔවුන් වැඩිපුර ඉල්ලන්නේ නම්, ඔවුන් ඉල්ලූ දේ තවමත් ඔවුන්ට නොලැබෙනු ඇත. tsp හි ඔබට IP ආදානය (--බෆර-ප්‍රමාණය) සඳහා බෆර ප්‍රමාණය සැකසිය හැකි බැවින්, අපි පෙරනිමි සොකට් ප්‍රමාණය ස්පර්ශ නොකරමු, නමුත් උපරිම සොකට් බෆර ප්‍රමාණය පමණක් සකසා 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 පරිභෝජනය මත පදනම්ව. එක් core i5-4260U CPU @ 1.40GHz සම්බන්ධයෙන්, 10Mbit/s ප්‍රවාහයක් විශ්ලේෂණය කිරීමට, CPU වලින් 3-4%ක් අවශ්‍ය වේ, 100Mbit/s - 25%, 200Mbit/s - 46%. % පැකට් පාඩුව සැකසීමේදී, CPU භාරය ප්‍රායෝගිකව වැඩි නොවේ (නමුත් අඩු විය හැක).
වඩා ඵලදායී දෘඪාංග මත, කිසිදු ගැටළුවක් නොමැතිව 1Gb/s ට වැඩි ප්‍රවාහයන් උත්පාදනය කිරීමට සහ විශ්ලේෂණය කිරීමට හැකි විය.
සැබෑ ජාල කාඩ්පත් මත පරීක්ෂා කිරීම
Veth pair එකක් මත පරීක්ෂා කිරීමෙන් පසු, ඔබ එක් ධාරකයක ධාරක දෙකක් හෝ වරායන් දෙකක් ගත යුතුය, වරායන් එකිනෙක සම්බන්ධ කර, උත්පාදක යන්ත්රය එකකින් ද, විශ්ලේෂකය දෙවනුව ද ධාවනය කළ යුතුය. මෙහි විස්මයන් කිසිවක් නොතිබුණි, නමුත් ඇත්ත වශයෙන්ම ඒ සියල්ල දෘඩාංග මත රඳා පවතී, එය දුර්වල වේ, එය මෙහි වඩාත් රසවත් වනු ඇත.
අධීක්ෂණ පද්ධතිය (Zabbix) මගින් ලැබුණු දත්ත භාවිතා කිරීම
tsp සතුව SNMP හෝ ඊට සමාන යන්ත්‍ර කියවිය හැකි API කිසිවක් නොමැත. CC පණිවිඩ එක් වරකට අවම වශයෙන් තත්පර 1ක් වත් එකතු කළ යුතුය (පැකට් අලාභයේ ඉහළ ප්‍රතිශතයක් සමඟ, බිටු අනුපාතය අනුව තත්පරයට සිය ගණනක්/දහසක්/දස දහස් ගණනක් තිබිය හැක).
මේ අනුව, තොරතුරු සුරැකීමට සහ CC දෝෂ සහ bitrate සඳහා ප්‍රස්ථාර ඇඳීමට සහ යම් ආකාරයක අනතුරු තවදුරටත් සිදු කිරීමට, පහත විකල්ප තිබිය හැකිය:
- tsp ප්‍රතිදානය (CC මගින්) විග්‍රහ කර එකතු කරන්න, i.e. එය අපේක්ෂිත ආකෘතියට පරිවර්තනය කරන්න.
- tsp ම සහ/හෝ bitrate_monitor සහ අඛණ්ඩ ප්‍රොසෙසර ප්ලගීන එක් කරන්න එවිට ප්රතිඵලය අධීක්ෂණ පද්ධතියට සුදුසු යන්ත්‍ර කියවිය හැකි ආකාරයෙන් ප්‍රතිදානය වේ.
- tsduck පුස්තකාලය මත ඔබේ අයදුම්පත ලියන්න.
පැහැදිලිවම, ශ්‍රම පිරිවැය අනුව, විකල්පය 1 සරලම වේ, විශේෂයෙන් tsduck පහත මට්ටමේ (නූතන ප්‍රමිතීන්ට අනුව) භාෂාවෙන් (C++) ලියා ඇති බව සලකයි.
bash හි parser + aggregator හි සරල මූලාකෘතියක් පෙන්නුම් කළේ 10 Mbit/s ප්‍රවාහයක් සහ 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 jobs යනු ස්වාධීන ක්‍රියාවලි වන අතර අතුරු ප්රතිඵලය මත (තත්පරයකට වරක් එන bitrate පණිවිඩ ලැබෙන විට) missingPackets අගය තත්පරයකට වරක් ලිවීමට සිදු විය. එහි ප්‍රතිඵලයක් ලෙස, bash තනිව ඉතිරි වූ අතර golang වලින් දවටනයක් (parser + aggregator) ලිවීමට තීරණය විය. golang හි සමාන කේතයක CPU පරිභෝජනය tsp ක්‍රියාවලියට වඩා 4-5 ගුණයකින් අඩුය. bash වෙනුවට golang මගින් එතුමෙහි ත්වරණය දළ වශයෙන් 16 ගුණයක් වූ අතර සමස්ත ප්රතිඵලය පිළිගත හැකි ය (නරකම අවස්ථාවෙහිදී CPU පොදු කාර්ය 25% කින්). golang මූලාශ්‍ර ගොනුව පිහිටා ඇත .
එතුම දියත් කිරීම
දවටනය දියත් කිරීම සඳහා, systemd සඳහා සරල සේවා අච්චුවක් සාදන ලදී () එය /opt/tsduck-stat/ හි පිහිටා ඇති ද්වීතික ගොනුවකට (go build tsduck-stat.go) සම්පාදනය කර ඇති බව උපකල්පනය කෙරේ. golang monotonic clock support (>=1.9) සමඟ භාවිතා වන බව උපකල්පනය කෙරේ.
සේවා අවස්ථාවක් නිර්මාණය කිරීම සඳහා ඔබ systemctl enable විධානය ක්‍රියාත්මක කළ යුතුය [විද්‍යුත් ආරක්‍ෂිත]:1234, පසුව systemctl start සමඟ ධාවනය කරන්න [විද්‍යුත් ආරක්‍ෂිත]: 1234.
Zabbix වෙතින් සොයා ගැනීම
එවිට zabbix හට ධාවන සේවා සොයා ගැනීමට හැකි වේ, (discovery.sh), Zabbix සොයාගැනීම සඳහා අවශ්‍ය ආකෘතියෙන්, එය එම ස්ථානයේම පිහිටා ඇතැයි උපකල්පනය කෙරේ - /opt/tsduck-stat. zabbix-agent හරහා සොයාගැනීම් ධාවනය කිරීමට, ඔබ එකතු කළ යුතුය පරිශීලක පරාමිතියක් එක් කිරීමට zabbix-agent වින්‍යාසයන් සහිත නාමාවලිය වෙත.
Zabbix සැකිල්ල
(tsduck_stat_template.xml) ස්වයං සොයාගැනීමේ රීතිය, මූලද්‍රව්‍ය, ප්‍රස්ථාරය සහ ප්‍රේරක මූලාකෘති අඩංගු වේ.
කෙටි පිරික්සුම් ලැයිස්තුවක් (යමෙකු එය භාවිතා කිරීමට තීරණය කරන්නේ නම්)
- "පරමාදර්ශී" තත්වයන් යටතේ tsp පැකට් අත් නොහරින බවට වග බලා ගන්න (උත්පාදක යන්ත්රය සහ විශ්ලේෂකය සෘජුවම සම්බන්ධ වේ), බිංදු තිබේ නම්, 2 වන කරුණ හෝ මෙම කාරණය පිළිබඳ ලිපියේ පෙළ බලන්න.
- උපරිම සොකට් බෆරය සුසර කරන්න (net.core.rmem_max=8388608).
- tsduck-stat.go සම්පාදනය කරන්න (යන්න tsduck-stat.go ගොඩනැගීමට යන්න).
- සේවා අච්චුව /lib/systemd/system හි තබන්න.
- systemctl භාවිතයෙන් සේවා ආරම්භ කරන්න, කවුන්ටර දිස් වීමට පටන් ගෙන තිබේදැයි පරීක්ෂා කරන්න (grep "" /dev/shm/tsduck-stat/*). බහු විකාශන ප්‍රවාහ ගණන අනුව සේවා ගණන. මෙහිදී ඔබට බහු විකාශන කණ්ඩායමට මාර්ගයක් නිර්මාණය කිරීමට අවශ්‍ය විය හැක, සමහරවිට rp_filter අක්‍රිය කිරීමට හෝ මූලාශ්‍ර ip වෙත මාර්ගයක් තැනීමට.
- Discovery.sh ධාවනය කරන්න, එය json ජනනය කරන බවට වග බලා ගන්න.
- Zabbix නියෝජිත වින්‍යාසය තබන්න, zabbix නියෝජිතයා නැවත ආරම්භ කරන්න.
- අච්චුව zabbix වෙත උඩුගත කරන්න, අධීක්ෂණය සිදු කරන සහ zabbix-agent ස්ථාපනය කර ඇති ධාරකයට එය යොදන්න, මිනිත්තු 5ක් පමණ රැඳී සිටින්න, නව දත්ත මූලද්‍රව්‍ය, ප්‍රස්ථාර සහ ප්‍රේරක දිස්වන බව බලන්න.
ප්රතිඵලය
පැකට් අලාභය හඳුනාගැනීමේ කාර්යය සඳහා, එය පාහේ ප්රමාණවත් වේ, අවම වශයෙන් එය කිසිදු අධීක්ෂණයකට වඩා හොඳය.
ඇත්ත වශයෙන්ම, වීඩියෝ කොටස් බෙදීමේදී CC “පාඩු” සිදුවිය හැකිය (මා දන්නා පරිදි, රුසියානු සමූහාණ්ඩුවේ දේශීය රූපවාහිනී මධ්‍යස්ථානවල ඇතුළු කිරීම් සිදු කරන්නේ එලෙස ය, එනම් CC කවුන්ටරය නැවත ගණනය නොකර), මෙය මතක තබා ගත යුතුය. හිමිකාර විසඳුම් වලදී, SCTE-35 ටැග් හඳුනා ගැනීමෙන් මෙම ගැටළුව අර්ධ වශයෙන් මග හරිනු ලැබේ (ඒවා ප්‍රවාහ උත්පාදක යන්ත්රය මගින් එකතු කරන්නේ නම්).
ප්‍රවාහන තත්ත්ව අධීක්‍ෂණයේ දෘෂ්ටි කෝණයෙන්, jitter Monitoring (IAT) ප්රමාණවත් නොවේ, මන්ද රූපවාහිනී උපකරණ (මොඩියුලේටර් හෝ අවසාන උපාංග වේවා) මෙම පරාමිතිය සඳහා අවශ්‍යතා ඇති අතර ජිට්බෆරය දින නියමයක් නොමැතිව පුම්බා ගැනීමට සැමවිටම නොහැකි වේ. සංක්‍රාන්තිය විශාල බෆර සහිත උපකරණ භාවිතා කරන විට සහ QoS වින්‍යාස කර නොමැති හෝ එවැනි තත්‍ය කාලීන ගමනාගමනය සම්ප්‍රේෂණය කිරීමට ප්රමාණවත් ලෙස වින්‍යාස කර නොමැති විට කම්පනය පාවී යා හැක.
මූලාශ්රය: www.habr.com