IP(TS) સ્ટ્રીમ્સને મોનિટર કરવા માટે TSDuck નો ઉપયોગ કરવો

આજે, IP(TS) સ્ટ્રીમનું નિરીક્ષણ કરવા માટે તૈયાર (માલિકીના) ઉકેલો છે, ઉદાહરણ તરીકે VB и iQ, તેમની પાસે કાર્યોનો એકદમ સમૃદ્ધ સમૂહ છે અને સામાન્ય રીતે ટીવી સેવાઓ સાથે કામ કરતા મોટા ઓપરેટરો પાસે આવા ઉકેલો હોય છે. આ લેખ ઓપન સોર્સ પ્રોજેક્ટ પર આધારિત ઉકેલનું વર્ણન કરે છે TSDuck, CC(કન્ટિન્યુટી કાઉન્ટર) કાઉન્ટર અને બિટરેટ દ્વારા IP(TS) સ્ટ્રીમના ન્યૂનતમ નિયંત્રણ માટે રચાયેલ છે. સંભવિત એપ્લિકેશન એ લીઝ્ડ L2 ચેનલ (જેનું સામાન્ય રીતે નિરીક્ષણ કરી શકાતું નથી, ઉદાહરણ તરીકે, કતારોમાં નુકસાન કાઉન્ટર્સ વાંચીને) દ્વારા પેકેટોના નુકસાન અથવા સમગ્ર પ્રવાહને નિયંત્રિત કરવા માટે છે.

TSDuck વિશે ખૂબ જ ટૂંકમાં

TSDuck એક ઓપન સોર્સ (2-ક્લોઝ BSD લાયસન્સ) સોફ્ટવેર છે (કન્સોલ યુટિલિટીઝનો સમૂહ અને કસ્ટમ યુટિલિટીઝ અથવા પ્લગઈન્સ વિકસાવવા માટેની લાઇબ્રેરી) TS સ્ટ્રીમ્સમાં હેરફેર કરવા માટે. ઇનપુટ તરીકે, તે IP (મલ્ટીકાસ્ટ/યુનિકાસ્ટ), http, hls, dvb ટ્યુનર્સ, dektec dvb-asi ડિમોડ્યુલેટર સાથે કામ કરી શકે છે, ત્યાં આંતરિક TS-સ્ટ્રીમ જનરેટર છે અને ફાઇલોમાંથી વાંચન છે. આઉટપુટ ફાઇલ, IP (મલ્ટીકાસ્ટ/યુનિકાસ્ટ), hls, dektec dvb-asi અને HiDes મોડ્યુલેટર્સ, પ્લેયર્સ (mplayer, vlc, xine) અને ડ્રોપ પર લખી શકાય છે. ઇનપુટ અને આઉટપુટ વચ્ચે વિવિધ ટ્રાફિક પ્રોસેસર્સનો સમાવેશ કરી શકાય છે, ઉદાહરણ તરીકે, પીઆઈડી રીમેપિંગ, સ્ક્રૅમ્બલિંગ/ડેસ્ક્રેમ્બલિંગ, સીસી કાઉન્ટર એનાલિસિસ, બિટરેટ કેલ્ક્યુલેશન અને ટીએસ સ્ટ્રીમ માટે અન્ય લાક્ષણિક કામગીરી.

આ લેખમાં, IP સ્ટ્રીમ્સ (મલ્ટીકાસ્ટ) નો ઇનપુટ તરીકે ઉપયોગ કરવામાં આવશે, પ્રોસેસર્સ bitrate_monitor (નામ પરથી તે સ્પષ્ટ છે કે તે શું છે) અને સાતત્ય (CC કાઉન્ટર્સનું વિશ્લેષણ) નો ઉપયોગ કરવામાં આવે છે. તમે TSDuck દ્વારા સમર્થિત અન્ય ઇનપુટ પ્રકાર સાથે સરળતાથી IP મલ્ટિકાસ્ટને બદલી શકો છો.

ઉપલબ્ધ છે સત્તાવાર બિલ્ડ/પેકેજ મોટા ભાગની વર્તમાન ઓપરેટિંગ સિસ્ટમો માટે TSDuck. તેઓ ડેબિયન માટે ઉપલબ્ધ નથી, પરંતુ અમે તેમને ડેબિયન 8 અને ડેબિયન 10 હેઠળ કોઈપણ સમસ્યા વિના બનાવવામાં વ્યવસ્થાપિત છીએ.

આગળ, સંસ્કરણ TSDuck 3.19-1520 નો ઉપયોગ થાય છે, Linux નો ઉપયોગ OS તરીકે થાય છે (ડેબિયન 10 નો ઉપયોગ સોલ્યુશન તૈયાર કરવા માટે કરવામાં આવ્યો હતો, CentOS 7 નો વાસ્તવિક ઉપયોગ માટે ઉપયોગ કરવામાં આવ્યો હતો)

TSDuck અને OS ની તૈયારી

વાસ્તવિક પ્રવાહનું નિરીક્ષણ કરતા પહેલા, તમારે ખાતરી કરવાની જરૂર છે કે TSDuck યોગ્ય રીતે કાર્ય કરે છે અને નેટવર્ક કાર્ડ અથવા OS (સોકેટ) સ્તર પર કોઈ ટીપાં નથી. નેટવર્ક પર અથવા "સર્વરની અંદર" - ટીપાં ક્યાં આવ્યા તે પછીથી અનુમાન ન કરવા માટે આ જરૂરી છે. તમે ethtool -S ethX કમાન્ડ વડે નેટવર્ક કાર્ડ લેવલ પર ડ્રોપ્સ ચેક કરી શકો છો, ટ્યુનિંગ એ જ એથટૂલ દ્વારા કરવામાં આવે છે (સામાન્ય રીતે, તમારે RX બફર (-G) વધારવાની જરૂર છે અને કેટલીક વખત કેટલાક ઑફલોડ્સ (-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" નો અર્થ છે કે તમારે દર સેકન્ડે બિટરેટની ગણતરી કરવાની અને દર સેકન્ડે બિટરેટ વિશેની માહિતી પ્રદર્શિત કરવાની જરૂર છે.
અમે 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 સુધી વધારવાનો પ્રયાસ કરો. વિશ્લેષક 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

જેમ તમે જોઈ શકો છો, બરાબર 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 ઇનપુટ (-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 એપ્લિકેશનના સીપીયુ વપરાશ મુજબ. એક કોર i5-4260U CPU @ 1.40GHz, 10Mbps ફ્લો એનાલિસિસ માટે 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%ની જરૂર પડશે. % પેકેટ લોસ સુયોજિત કરતી વખતે, CPU પરનો ભાર વ્યવહારીક રીતે વધતો નથી (પરંતુ ઘટી શકે છે).

વધુ ઉત્પાદક હાર્ડવેર પર, કોઈપણ સમસ્યા વિના 1Gb/s થી વધુની સ્ટ્રીમ્સ જનરેટ કરવી અને તેનું વિશ્લેષણ કરવું શક્ય હતું.

વાસ્તવિક નેટવર્ક કાર્ડ્સ પર પરીક્ષણ

વેથ જોડી પર પરીક્ષણ કર્યા પછી, તમારે એક યજમાનના બે હોસ્ટ અથવા બે પોર્ટ લેવાની જરૂર છે, બંદરોને એકબીજા સાથે જોડો, એક પર જનરેટર શરૂ કરો અને બીજા પર વિશ્લેષક. અહીં કોઈ આશ્ચર્ય નહોતા, પરંતુ વાસ્તવમાં તે બધા લોખંડ પર આધાર રાખે છે, નબળા, વધુ રસપ્રદ તે અહીં હશે.

મોનિટરિંગ સિસ્ટમ (ઝેબિક્સ) દ્વારા પ્રાપ્ત ડેટાનો ઉપયોગ કરવો

tsp પાસે SNMP અથવા તેના જેવું કોઈ મશીન વાંચી શકાય તેવું API નથી. CC સંદેશાઓ ઓછામાં ઓછા 1 સેકન્ડ માટે એકીકૃત હોવા જોઈએ (પૅકેટ નુકશાનની ઊંચી ટકાવારી સાથે, બિટરેટના આધારે સેંકડો/હજારો/દસ હજાર પ્રતિ સેકન્ડ હોઈ શકે છે).

આમ, બંને માહિતી સાચવવા અને CC ભૂલો અને બિટરેટ માટે ગ્રાફ દોરવા અને અમુક પ્રકારના અકસ્માતો કરવા માટે, નીચેના વિકલ્પો હોઈ શકે છે:

1. tsp ના આઉટપુટને પાર્સ અને એકંદર (CC દ્વારા) કરો, એટલે કે. તેને ઇચ્છિત સ્વરૂપમાં રૂપાંતરિત કરો.
2. tsp પોતે અને/અથવા પ્રોસેસર પ્લગિન્સ bitrate_monitor અને સાતત્ય સમાપ્ત કરો જેથી પરિણામ મોનિટરિંગ સિસ્ટમ માટે યોગ્ય મશીન-વાંચી શકાય તેવા સ્વરૂપમાં આપવામાં આવે.
3. તમારી અરજી tsduck લાઇબ્રેરીની ટોચ પર લખો.

દેખીતી રીતે, વિકલ્પ 1 એ પ્રયાસની દ્રષ્ટિએ સૌથી સહેલો છે, ખાસ કરીને તે ધ્યાનમાં લેવું કે tsduck પોતે નિમ્ન-સ્તરની (આધુનિક ધોરણો દ્વારા) ભાષા (C ++) માં લખાયેલ છે.

એક સરળ બેશ પાર્સર+એગ્રીગેટર પ્રોટોટાઇપ દર્શાવે છે કે 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

અસ્વીકાર્ય રીતે ધીમું હોવા ઉપરાંત, બેશમાં કોઈ સામાન્ય થ્રેડો નથી, બેશ જોબ્સ અલગ પ્રક્રિયાઓ છે, અને મારે આડઅસર પર એક સેકન્ડમાં એકવાર missingPackets નું મૂલ્ય લખવું પડ્યું (જ્યારે દર સેકન્ડે આવતા બિટરેટ સંદેશાઓ પ્રાપ્ત થાય છે). પરિણામે, બાશ એકલો રહી ગયો અને ગોલાંગમાં રેપર (પાર્સર + એગ્રીગેટર) લખવાનું નક્કી કરવામાં આવ્યું. સમાન ગોલાંગ કોડનો CPU વપરાશ tsp પ્રક્રિયા કરતાં 4-5 ગણો ઓછો છે. ગોલાંગ સાથે બેશને બદલવાને કારણે રેપરની ઝડપ લગભગ 16 ગણી થઈ અને સામાન્ય રીતે પરિણામ સ્વીકાર્ય છે (સૌથી ખરાબ કિસ્સામાં CPU ઓવરહેડ 25% દ્વારા). ગોલાંગ સ્ત્રોત ફાઇલ સ્થિત છે અહીં.

રેપર ચલાવો

રેપર શરૂ કરવા માટે, systemd માટે સૌથી સરળ સેવા નમૂનો બનાવવામાં આવ્યો હતો (અહીં). રેપર પોતે જ /opt/tsduck-stat/ માં સ્થિત દ્વિસંગી ફાઇલ (go build tsduck-stat.go) માં કમ્પાઇલ થયેલ હોવાનું માનવામાં આવે છે. એવું માનવામાં આવે છે કે તમે મોનોટોનિક ઘડિયાળ (>=1.9) માટે સપોર્ટ સાથે ગોલાંગનો ઉપયોગ કરી રહ્યાં છો.

સેવાનો દાખલો બનાવવા માટે, તમારે systemctl enable આદેશ ચલાવવાની જરૂર છે [ઇમેઇલ સુરક્ષિત]:1234 પછી systemctl start સાથે ચલાવો [ઇમેઇલ સુરક્ષિત]: 1234

Zabbix માંથી શોધ

zabbix માટે ચાલી રહેલ સેવાઓ શોધવામાં સક્ષમ થવા માટે, તે થઈ ગયું છે જૂથ સૂચિ જનરેટર (discovery.sh), Zabbix શોધ માટે જરૂરી ફોર્મેટમાં, એવું માનવામાં આવે છે કે તે તે જ જગ્યાએ સ્થિત છે - /opt/tsduck-stat માં. zabbix-એજન્ટ દ્વારા શોધ ચલાવવા માટે, તમારે ઉમેરવાની જરૂર છે .conf ફાઇલ વપરાશકર્તા પરિમાણ ઉમેરવા માટે zabbix-એજન્ટ રૂપરેખાંકન નિર્દેશિકામાં.

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 મિનિટ રાહ જુઓ, જુઓ કે ત્યાં નવી વસ્તુઓ, ગ્રાફ અને ટ્રિગર્સ છે કે નહીં.

પરિણામ

પેકેટ નુકશાન શોધવાના કાર્ય માટે, તે લગભગ પૂરતું છે, ઓછામાં ઓછું તે કોઈ દેખરેખ કરતાં વધુ સારું છે.

ખરેખર, CC "નુકસાન" જ્યારે વિડિઓ ટુકડાઓને મર્જ કરતી વખતે થઈ શકે છે (જ્યાં સુધી હું જાણું છું, આ રીતે રશિયન ફેડરેશનમાં સ્થાનિક ટીવી કેન્દ્રો પર દાખલ કરવામાં આવે છે, એટલે કે CC કાઉન્ટરની પુન: ગણતરી કર્યા વિના), આ યાદ રાખવું આવશ્યક છે. માલિકીના ઉકેલો SCTE-35 લેબલ્સ (જો સ્ટ્રીમ જનરેટર દ્વારા ઉમેરવામાં આવે તો) શોધીને આ સમસ્યાને આંશિક રીતે અટકાવે છે.

ટ્રાન્સપોર્ટ ક્વોલિટી મોનિટરિંગના સંદર્ભમાં, જિટર મોનિટરિંગ (IAT)નો અભાવ છે. ટીવી સાધનો (તે મોડ્યુલેટર હોય કે અંતિમ ઉપકરણો હોય) ને આ પરિમાણ માટેની આવશ્યકતાઓ હોય છે અને જિટબફરને અનંત સુધી વધારવું હંમેશા શક્ય નથી. અને જ્યારે મોટા બફર્સવાળા સાધનોનો ઉપયોગ ટ્રાન્ઝિટમાં કરવામાં આવે અને QoS રૂપરેખાંકિત ન હોય અથવા આવા રીયલટાઇમ ટ્રાફિકને ટ્રાન્સમિટ કરવા માટે પૂરતું ગોઠવેલું ન હોય ત્યારે જિટર તરતા હોય છે.

સોર્સ: www.habr.com