నేడు, IP(TS) స్ట్రీమ్‌లను పర్యవేక్షించడానికి సిద్ధంగా ఉన్న (యాజమాన్య) పరిష్కారాలు ఉన్నాయి, ఉదాహరణకు и , వారు చాలా గొప్ప ఫంక్షన్‌లను కలిగి ఉంటారు మరియు సాధారణంగా టీవీ సేవలతో వ్యవహరించే పెద్ద ఆపరేటర్‌లు అలాంటి పరిష్కారాలను కలిగి ఉంటారు. ఈ వ్యాసం ఓపెన్ సోర్స్ ప్రాజెక్ట్ ఆధారంగా ఒక పరిష్కారాన్ని వివరిస్తుంది , CC(కంటిన్యూటీ కౌంటర్) కౌంటర్ మరియు బిట్‌రేట్ ద్వారా IP(TS) స్ట్రీమ్‌ల కనీస నియంత్రణ కోసం రూపొందించబడింది. లీజుకు తీసుకున్న L2 ఛానెల్ ద్వారా ప్యాకెట్ల నష్టాన్ని లేదా మొత్తం ప్రవాహాన్ని నియంత్రించడం సాధ్యమయ్యే అప్లికేషన్ (ఇది సాధారణంగా పర్యవేక్షించబడదు, ఉదాహరణకు, క్యూలలో నష్టాల కౌంటర్‌లను చదవడం ద్వారా).
TSDuck గురించి చాలా క్లుప్తంగా
TSDuck అనేది TS స్ట్రీమ్‌లను మానిప్యులేట్ చేయడానికి ఓపెన్ సోర్స్ (2-క్లాజ్ BSD లైసెన్స్) సాఫ్ట్‌వేర్ (కన్సోల్ యుటిలిటీల సమితి మరియు కస్టమ్ యుటిలిటీస్ లేదా ప్లగిన్‌లను అభివృద్ధి చేయడానికి ఒక లైబ్రరీ). ఇన్‌పుట్‌గా, ఇది IP (మల్టీకాస్ట్/యూనికాస్ట్), http, hls, dvb ట్యూనర్‌లు, dektec dvb-asi demodulatorతో పని చేయగలదు, అంతర్గత TS-స్ట్రీమ్ జనరేటర్ మరియు ఫైల్‌ల నుండి రీడింగ్ ఉంది. అవుట్‌పుట్ ఫైల్, IP (మల్టీకాస్ట్/యూనికాస్ట్), hls, dektec dvb-asi మరియు HiDes మాడ్యులేటర్లు, ప్లేయర్‌లు (mplayer, vlc, xine) మరియు డ్రాప్‌కు వ్రాయవచ్చు. ఇన్‌పుట్ మరియు అవుట్‌పుట్ మధ్య వివిధ ట్రాఫిక్ ప్రాసెసర్‌లను చేర్చవచ్చు, ఉదాహరణకు, PID రీమ్యాపింగ్, స్క్రాంబ్లింగ్ / డీస్క్రాంబ్లింగ్, CC కౌంటర్ విశ్లేషణ, బిట్‌రేట్ లెక్కింపు మరియు TS స్ట్రీమ్‌ల కోసం ఇతర సాధారణ కార్యకలాపాలు.
ఈ కథనంలో, IP స్ట్రీమ్‌లు (మల్టీకాస్ట్) ఇన్‌పుట్‌గా ఉపయోగించబడుతుంది, ప్రాసెసర్‌లు bitrate_monitor (పేరు నుండి అది ఏమిటో స్పష్టంగా ఉంది) మరియు కొనసాగింపు (CC కౌంటర్ల విశ్లేషణ) ఉపయోగించబడతాయి. మీరు TSDuck మద్దతు ఉన్న మరొక ఇన్‌పుట్ రకంతో IP మల్టీకాస్ట్‌ని సులభంగా భర్తీ చేయవచ్చు.
అందుబాటులో ఉంది చాలా ప్రస్తుత ఆపరేటింగ్ సిస్టమ్‌ల కోసం TSDuck. డెబియన్ కోసం అవి అందుబాటులో లేవు, కానీ మేము వాటిని డెబియన్ 8 మరియు డెబియన్ 10 కింద ఎలాంటి సమస్యలు లేకుండా నిర్మించగలిగాము.
తరువాత, సంస్కరణ TSDuck 3.19-1520 ఉపయోగించబడుతుంది, Linux OS గా ఉపయోగించబడుతుంది (పరిష్కారాన్ని సిద్ధం చేయడానికి debian 10 ఉపయోగించబడింది, CentOS 7 నిజమైన ఉపయోగం కోసం ఉపయోగించబడింది)
TSDuck మరియు OSని సిద్ధం చేస్తోంది
నిజమైన ప్రవాహాలను పర్యవేక్షించే ముందు, మీరు TSDuck సరిగ్గా పని చేస్తుందని మరియు నెట్‌వర్క్ కార్డ్ లేదా OS (సాకెట్) స్థాయిలో ఎటువంటి చుక్కలు లేవని నిర్ధారించుకోవాలి. నెట్‌వర్క్‌లో లేదా “సర్వర్ లోపల” ఎక్కడ చుక్కలు సంభవించాయో తర్వాత ఊహించకుండా ఉండటానికి ఇది అవసరం. మీరు ethtool -S ethX కమాండ్‌తో నెట్‌వర్క్ కార్డ్ స్థాయిలో డ్రాప్‌లను తనిఖీ చేయవచ్చు, ట్యూనింగ్ అదే ethtool ద్వారా చేయబడుతుంది (సాధారణంగా, మీరు RX బఫర్ (-G)ని పెంచాలి మరియు కొన్నిసార్లు కొన్ని ఆఫ్‌లోడ్‌లను (-K) నిలిపివేయాలి). సాధారణ సిఫార్సుగా, విశ్లేషించబడిన ట్రాఫిక్‌ను స్వీకరించడానికి ప్రత్యేక పోర్ట్‌ను ఉపయోగించమని సలహా ఇవ్వవచ్చు, వీలైతే, ఇతర ట్రాఫిక్ ఉన్నందున ఎనలైజర్ పోర్ట్‌లో డ్రాప్ సరిగ్గా జరిగిందనే వాస్తవంతో సంబంధం ఉన్న తప్పుడు పాజిటివ్‌లను ఇది తగ్గిస్తుంది. ఇది సాధ్యం కాకపోతే (ఒక పోర్ట్‌తో ఒక మినీ-కంప్యూటర్/NUC ఉపయోగించబడుతుంది), అప్పుడు ఎనలైజర్ కనెక్ట్ చేయబడిన పరికరంలో మిగిలిన వాటికి సంబంధించి విశ్లేషించబడిన ట్రాఫిక్ యొక్క ప్రాధాన్యతను సెటప్ చేయడం చాలా అవసరం. వర్చువల్ పరిసరాలకు సంబంధించి, ఇక్కడ మీరు జాగ్రత్తగా ఉండాలి మరియు ఫిజికల్ పోర్ట్ నుండి ప్రారంభించి వర్చువల్ మెషీన్‌లోని అప్లికేషన్‌తో ముగిసే ప్యాకెట్ డ్రాప్‌లను కనుగొనగలరు.
హోస్ట్ లోపల స్ట్రీమ్ యొక్క జనరేషన్ మరియు రిసెప్షన్
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), అనగా. 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 CC ఎర్రర్‌ల సమూహాన్ని నివేదిస్తుంది. మేము ఎవరిని నిందించాలో గుర్తించడానికి ప్రయత్నిస్తున్నాము - జనరేటర్‌కు సమయం లేదు లేదా సమస్య దానిలో లేదు, దీని కోసం మేము నిర్ణీత సంఖ్యలో ఉత్పత్తి చేయడం ప్రారంభిస్తాము. ప్యాకెట్లు (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 ఇన్‌పుట్ (-బఫర్-సైజ్) కోసం బఫర్ పరిమాణాన్ని 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 సెకను పాటు సమగ్రపరచబడాలి (అధిక శాతం ప్యాకెట్ నష్టంతో, బిట్‌రేట్‌పై ఆధారపడి సెకనుకు వందలు/వేలు/పదివేలు ఉండవచ్చు).
అందువల్ల, సమాచారాన్ని రెండింటినీ సేవ్ చేయడానికి మరియు CC లోపాలు మరియు బిట్‌రేట్ కోసం గ్రాఫ్‌లను గీయడానికి మరియు కొన్ని రకాల ప్రమాదాలు చేయడానికి, ఈ క్రింది ఎంపికలు ఉండవచ్చు:
- tsp యొక్క అవుట్‌పుట్‌ని అన్వయించి, సమగ్రపరచండి (CC ద్వారా), అనగా. దానిని కావలసిన రూపంలోకి మార్చండి.
- tsp దానంతట అదే మరియు/లేదా ప్రాసెసర్ ప్లగిన్‌లు bitrate_monitor మరియు కంటిన్యూటీని పూర్తి చేయండి, తద్వారా ఫలితం పర్యవేక్షణ సిస్టమ్‌కు తగిన మెషీన్-రీడబుల్ రూపంలో ఇవ్వబడుతుంది.
- 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/లో ఉన్న బైనరీ ఫైల్ (గో బిల్డ్ tsduck-stat.go)లోకి కంపైల్ చేయబడాలి. మీరు మోనోటోనిక్ గడియారానికి (>=1.9) మద్దతుతో గోలాంగ్‌ని ఉపయోగిస్తున్నారని భావించబడుతుంది.
సేవ యొక్క ఉదాహరణను సృష్టించడానికి, మీరు systemctl ఎనేబుల్ ఆదేశాన్ని అమలు చేయాలి [ఇమెయిల్ రక్షించబడింది]:1234 ఆపై systemctl ప్రారంభంతో రన్ చేయండి [ఇమెయిల్ రక్షించబడింది]: 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 లేబుల్‌లను గుర్తించడం ద్వారా ఈ సమస్యను పాక్షికంగా తప్పించుకుంటాయి (స్ట్రీమ్ జనరేటర్ ద్వారా జోడించబడితే).
రవాణా నాణ్యత పర్యవేక్షణ పరంగా, జిట్టర్ మానిటరింగ్ (IAT) లోపించింది. TV పరికరాలు (అది మాడ్యులేటర్లు లేదా ముగింపు పరికరాలు కావచ్చు) ఈ పరామితి కోసం అవసరాలను కలిగి ఉంటాయి మరియు జిట్‌బఫర్‌ను అనంతంగా పెంచడం ఎల్లప్పుడూ సాధ్యం కాదు. రవాణాలో పెద్ద బఫర్‌లు ఉన్న పరికరాలను ఉపయోగించినప్పుడు మరియు QoS కాన్ఫిగర్ చేయబడనప్పుడు లేదా అటువంటి రియల్ టైమ్ ట్రాఫిక్‌ను ప్రసారం చేయడానికి తగినంతగా కాన్ఫిగర్ చేయబడనప్పుడు మరియు జిట్టర్ తేలుతుంది.
మూలం: www.habr.com