IP(TS) ഫ്ലോകൾ നിരീക്ഷിക്കാൻ TSDuck ഉപയോഗിക്കുന്നു

ഇന്ന്, IP (TS) സ്ട്രീമുകൾ നിരീക്ഷിക്കുന്നതിന് റെഡിമെയ്ഡ് (പ്രൊപ്രൈറ്ററി) പരിഹാരങ്ങളുണ്ട്, ഉദാഹരണത്തിന് VB и iQ, അവർക്ക് സാമാന്യം സമ്പന്നമായ ഒരു കൂട്ടം ഫംഗ്ഷനുകൾ ഉണ്ട്, സാധാരണയായി ടിവി സേവനങ്ങൾ കൈകാര്യം ചെയ്യുന്ന വലിയ ഓപ്പറേറ്റർമാർക്ക് അത്തരം പരിഹാരങ്ങളുണ്ട്. ഈ ലേഖനം ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റിനെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു പരിഹാരത്തെ വിവരിക്കുന്നു TSDuck, CC(തുടർച്ച കൌണ്ടർ) കൗണ്ടറും ബിറ്റ്റേറ്റും വഴി IP(TS) സ്ട്രീമുകളുടെ ഏറ്റവും കുറഞ്ഞ നിയന്ത്രണത്തിനായി രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഒരു പാട്ടത്തിനെടുത്ത L2 ചാനലിലൂടെ പാക്കറ്റുകളുടെ നഷ്ടം അല്ലെങ്കിൽ മുഴുവൻ ഒഴുക്കും നിയന്ത്രിക്കുക എന്നതാണ് സാധ്യമായ ഒരു ആപ്ലിക്കേഷൻ (സാധാരണയായി നിരീക്ഷിക്കാൻ കഴിയില്ല, ഉദാഹരണത്തിന്, ക്യൂവിലെ നഷ്ട കൗണ്ടറുകൾ വായിക്കുന്നതിലൂടെ).

TSDuck-നെ കുറിച്ച് വളരെ ചുരുക്കമായി

ടിഎസ് സ്ട്രീമുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഒരു ഓപ്പൺ സോഴ്‌സ് (2-ക്ലോസ് ബിഎസ്ഡി ലൈസൻസ്) സോഫ്‌റ്റ്‌വെയർ (കൺസോൾ യൂട്ടിലിറ്റികളുടെ ഒരു കൂട്ടവും ഇഷ്‌ടാനുസൃത യൂട്ടിലിറ്റികൾ അല്ലെങ്കിൽ പ്ലഗിനുകൾ വികസിപ്പിക്കുന്നതിനുള്ള ഒരു ലൈബ്രറിയും) ആണ് TSDuck. ഒരു ഇൻപുട്ട് എന്ന നിലയിൽ, ഇതിന് 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 പതിപ്പ് ഉപയോഗിക്കുന്നു, ലിനക്സ് OS ആയി ഉപയോഗിക്കുന്നു (പരിഹാരം തയ്യാറാക്കാൻ debian 10 ഉപയോഗിച്ചു, യഥാർത്ഥ ഉപയോഗത്തിനായി CentOS 7 ഉപയോഗിച്ചു)

TSDuck, OS എന്നിവ തയ്യാറാക്കുന്നു

യഥാർത്ഥ ഫ്ലോകൾ നിരീക്ഷിക്കുന്നതിന് മുമ്പ്, TSDuck ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്നും നെറ്റ്‌വർക്ക് കാർഡ് അല്ലെങ്കിൽ OS (സോക്കറ്റ്) തലത്തിൽ ഡ്രോപ്പുകൾ ഇല്ലെന്നും നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്. നെറ്റ്‌വർക്കിൽ അല്ലെങ്കിൽ "സെർവറിനുള്ളിൽ" എവിടെയാണ് ഡ്രോപ്പുകൾ സംഭവിച്ചതെന്ന് പിന്നീട് ഊഹിക്കാതിരിക്കാൻ ഇത് ആവശ്യമാണ്. ethtool -S ethX കമാൻഡ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് നെറ്റ്‌വർക്ക് കാർഡ് തലത്തിൽ ഡ്രോപ്പുകൾ പരിശോധിക്കാൻ കഴിയും, ട്യൂണിംഗ് ചെയ്യുന്നത് അതേ ethtool ഉപയോഗിച്ചാണ് (സാധാരണയായി, നിങ്ങൾ RX ബഫർ (-G) വർദ്ധിപ്പിക്കുകയും ചിലപ്പോൾ ചില ഓഫ്‌ലോഡുകൾ (-K) പ്രവർത്തനരഹിതമാക്കുകയും വേണം). ഒരു പൊതു ശുപാർശ എന്ന നിലയിൽ, വിശകലനം ചെയ്ത ട്രാഫിക് സ്വീകരിക്കുന്നതിന് ഒരു പ്രത്യേക പോർട്ട് ഉപയോഗിക്കാൻ ഉപദേശിക്കാൻ കഴിയും, സാധ്യമെങ്കിൽ, മറ്റ് ട്രാഫിക്കിന്റെ സാന്നിധ്യം കാരണം അനലൈസർ പോർട്ടിൽ ഡ്രോപ്പ് കൃത്യമായി സംഭവിച്ചുവെന്നതുമായി ബന്ധപ്പെട്ട തെറ്റായ പോസിറ്റീവുകൾ ഇത് കുറയ്ക്കുന്നു. ഇത് സാധ്യമല്ലെങ്കിൽ (ഒരു പോർട്ടുള്ള ഒരു മിനി-കമ്പ്യൂട്ടർ/എൻ‌യു‌സി ഉപയോഗിക്കുന്നു), അനലൈസർ ബന്ധിപ്പിച്ചിരിക്കുന്ന ഉപകരണത്തിൽ ബാക്കിയുള്ളവയുമായി ബന്ധപ്പെട്ട് വിശകലനം ചെയ്ത ട്രാഫിക്കിന്റെ മുൻ‌ഗണന സജ്ജീകരിക്കുന്നത് വളരെ അഭികാമ്യമാണ്. വെർച്വൽ എൻവയോൺമെന്റുകളെ സംബന്ധിച്ച്, ഇവിടെ നിങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്, കൂടാതെ ഒരു ഫിസിക്കൽ പോർട്ടിൽ നിന്ന് ആരംഭിച്ച് ഒരു വെർച്വൽ മെഷീനിനുള്ളിലെ ഒരു ആപ്ലിക്കേഷനിൽ അവസാനിക്കുന്ന പാക്കറ്റ് ഡ്രോപ്പുകൾ കണ്ടെത്താൻ കഴിയണം.

ഹോസ്റ്റിനുള്ളിൽ ഒരു സ്ട്രീമിന്റെ ജനറേഷനും സ്വീകരണവും

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) പ്രവർത്തനരഹിതമാക്കുകയും ജനറേറ്റർ ബിറ്റ്റേറ്റ് 100 Mbit/s ആയി വർദ്ധിപ്പിക്കാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു. അനലൈസർ ഒരു കൂട്ടം CC പിശകുകളും 75-ന് പകരം ഏകദേശം 100 Mbit/s റിപ്പോർട്ട് ചെയ്യുന്നു. ആരെയാണ് കുറ്റപ്പെടുത്തേണ്ടതെന്ന് ഞങ്ങൾ മനസിലാക്കാൻ ശ്രമിക്കുകയാണ് - ജനറേറ്റർ നിലനിർത്തുന്നില്ല അല്ലെങ്കിൽ പ്രശ്‌നം അതിൽ ഇല്ല, ഇത് ചെയ്യുന്നതിന് ഞങ്ങൾ ഒരു സൃഷ്ടിക്കാൻ തുടങ്ങുന്നു നിശ്ചിത എണ്ണം പാക്കറ്റുകൾ (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 ഐപി പാക്കറ്റുകൾ സൃഷ്ടിച്ചു (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. ടിഎസ് പാക്കറ്റുകളിൽ, ഇത് 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 കെബിയുടെ ബഫർ ഉപയോഗിച്ചാണ് സോക്കറ്റുകൾ സൃഷ്ടിക്കുന്നത്, എന്നാൽ അവർ കൂടുതൽ അഭ്യർത്ഥിച്ചാൽ, അപ്പോഴും ആവശ്യപ്പെട്ടത് അവർക്ക് ലഭിക്കില്ല. 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% എന്നിവ ആവശ്യമാണ്. % പാക്കറ്റ് നഷ്ടം സജ്ജീകരിക്കുമ്പോൾ, സിപിയുവിലെ ലോഡ് പ്രായോഗികമായി വർദ്ധിക്കുന്നില്ല (പക്ഷേ കുറഞ്ഞേക്കാം).

കൂടുതൽ ഉൽപ്പാദനക്ഷമതയുള്ള ഹാർഡ്‌വെയറിൽ, പ്രശ്‌നങ്ങളൊന്നുമില്ലാതെ 1Gb / s-ൽ കൂടുതൽ സ്ട്രീമുകൾ സൃഷ്ടിക്കാനും വിശകലനം ചെയ്യാനും സാധിച്ചു.

യഥാർത്ഥ നെറ്റ്‌വർക്ക് കാർഡുകളിൽ പരിശോധന നടത്തുന്നു

ഒരു വെത്ത് ജോഡിയിൽ പരീക്ഷിച്ചതിന് ശേഷം, നിങ്ങൾ ഒരു ഹോസ്റ്റിന്റെ രണ്ട് ഹോസ്റ്റുകളോ രണ്ട് പോർട്ടുകളോ എടുക്കേണ്ടതുണ്ട്, പോർട്ടുകൾ പരസ്പരം ബന്ധിപ്പിക്കുക, ഒന്നിൽ ജനറേറ്റർ ആരംഭിക്കുക, രണ്ടാമത്തേതിൽ അനലൈസർ ആരംഭിക്കുക. ഇവിടെ ആശ്ചര്യങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല, പക്ഷേ വാസ്തവത്തിൽ ഇതെല്ലാം ഇരുമ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു, ദുർബലമാണ്, അത് ഇവിടെ കൂടുതൽ രസകരമാണ്.

മോണിറ്ററിംഗ് സിസ്റ്റം (Zabbix) വഴി ലഭിച്ച ഡാറ്റ ഉപയോഗിക്കുന്നു

tsp-ന് SNMP അല്ലെങ്കിൽ സമാനമായ മെഷീൻ-റീഡബിൾ API ഇല്ല. CC സന്ദേശങ്ങൾ ചുരുങ്ങിയത് 1 സെക്കന്റെങ്കിലും സമാഹരിച്ചിരിക്കണം (പാക്കറ്റ് നഷ്ടത്തിന്റെ ഉയർന്ന ശതമാനത്തിൽ, ബിറ്റ്റേറ്റ് അനുസരിച്ച് സെക്കൻഡിൽ നൂറുകണക്കിന്/ആയിരങ്ങൾ/പതിനായിരങ്ങൾ ഉണ്ടാകാം).

അതിനാൽ, രണ്ട് വിവരങ്ങളും സംരക്ഷിക്കുന്നതിനും സിസി പിശകുകൾക്കും ബിറ്റ്റേറ്റുകൾക്കുമായി ഗ്രാഫുകൾ വരയ്ക്കുന്നതിനും ചില തരത്തിലുള്ള അപകടങ്ങൾ ഉണ്ടാക്കുന്നതിനും, ഇനിപ്പറയുന്ന ഓപ്ഷനുകൾ ഉണ്ടാകാം:

1. ടീസ്‌പിയുടെ ഔട്ട്‌പുട്ട് പാഴ്‌സ് ചെയ്ത് സമാഹരിക്കുക (സിസി പ്രകാരം), അതായത്. അത് ആവശ്യമുള്ള ഫോമിലേക്ക് പരിവർത്തനം ചെയ്യുക.
2. tsp തന്നെ കൂടാതെ/അല്ലെങ്കിൽ പ്രോസസ്സർ പ്ലഗിനുകൾ bitrate_monitor ഉം Continueity ഉം പൂർത്തിയാക്കുക, അങ്ങനെ മോണിറ്ററിംഗ് സിസ്റ്റത്തിന് അനുയോജ്യമായ ഒരു മെഷീൻ-റീഡബിൾ രൂപത്തിൽ ഫലം ലഭിക്കും.
3. tsduck ലൈബ്രറിയുടെ മുകളിൽ നിങ്ങളുടെ അപേക്ഷ എഴുതുക.

വ്യക്തമായും, ശ്രമത്തിന്റെ കാര്യത്തിൽ ഏറ്റവും എളുപ്പമുള്ള ഓപ്ഷൻ 1 ആണ്, പ്രത്യേകിച്ചും tsduck തന്നെ താഴ്ന്ന നിലയിലുള്ള (ആധുനിക നിലവാരമനുസരിച്ച്) ഭാഷയിൽ (C ++) എഴുതിയിരിക്കുന്നതിനാൽ.

ബാഷിലെ ഒരു പാർസർ + അഗ്രഗേറ്ററിന്റെ ഒരു ലളിതമായ പ്രോട്ടോടൈപ്പ് കാണിക്കുന്നത് 10 Mbit/s ഒഴുക്കിലും 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 മടങ്ങായി മാറി, പൊതുവേ ഫലം സ്വീകാര്യമാണ് (ഏറ്റവും മോശമായ സാഹചര്യത്തിൽ സിപിയു ഓവർഹെഡ് 25%). golang ഉറവിട ഫയൽ സ്ഥിതിചെയ്യുന്നു ഇവിടെ.

റാപ്പർ പ്രവർത്തിപ്പിക്കുക

റാപ്പർ ആരംഭിക്കുന്നതിന്, systemd എന്നതിനായുള്ള ഏറ്റവും ലളിതമായ സേവന ടെംപ്ലേറ്റ് നിർമ്മിച്ചു (ഇവിടെ). റാപ്പർ തന്നെ /opt/tsduck-stat/-ൽ സ്ഥിതി ചെയ്യുന്ന ഒരു ബൈനറി ഫയലിലേക്ക് (go build tsduck-stat.go) കംപൈൽ ചെയ്യേണ്ടതാണ്. മോണോടോണിക് ക്ലോക്കിനുള്ള പിന്തുണയോടെയാണ് നിങ്ങൾ golang ഉപയോഗിക്കുന്നത് എന്ന് അനുമാനിക്കപ്പെടുന്നു (>=1.9).

സേവനത്തിന്റെ ഒരു ഉദാഹരണം സൃഷ്ടിക്കുന്നതിന്, നിങ്ങൾ systemctl enable കമാൻഡ് പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട് [ഇമെയിൽ പരിരക്ഷിച്ചിരിക്കുന്നു]:1234 തുടർന്ന് systemctl സ്റ്റാർട്ട് ഉപയോഗിച്ച് പ്രവർത്തിപ്പിക്കുക [ഇമെയിൽ പരിരക്ഷിച്ചിരിക്കുന്നു]: 1234.

Zabbix-ൽ നിന്നുള്ള കണ്ടെത്തൽ

അതിലൂടെ സബിക്സിന് പ്രവർത്തിക്കുന്ന സേവനങ്ങൾ കണ്ടെത്താനാകും, ഗ്രൂപ്പ് ലിസ്റ്റ് ജനറേറ്റർ (discovery.sh), Zabbix കണ്ടുപിടിത്തത്തിന് ആവശ്യമായ ഫോർമാറ്റിൽ, അത് ഒരേ സ്ഥലത്താണ് - /opt/tsduck-stat-ൽ സ്ഥിതി ചെയ്യുന്നതെന്ന് അനുമാനിക്കപ്പെടുന്നു. zabbix-agent വഴി കണ്ടെത്തൽ പ്രവർത്തിപ്പിക്കാൻ, നിങ്ങൾ ചേർക്കേണ്ടതുണ്ട് .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 മിനിറ്റ് കാത്തിരിക്കുക, പുതിയ ഡാറ്റ ഘടകങ്ങളും ഗ്രാഫുകളും ട്രിഗറുകളും പ്രത്യക്ഷപ്പെട്ടതായി കാണുക.

ഫലം

പാക്കറ്റ് നഷ്ടം തിരിച്ചറിയുന്നതിനുള്ള ചുമതലയ്ക്ക്, ഇത് ഏതാണ്ട് മതിയാകും, കുറഞ്ഞപക്ഷം ഇത് മോണിറ്ററിംഗ് ഇല്ലാത്തതിനേക്കാൾ നല്ലതാണ്.

വാസ്തവത്തിൽ, വീഡിയോ ശകലങ്ങൾ വിഭജിക്കുമ്പോൾ സിസി “നഷ്ടം” സംഭവിക്കാം (എനിക്കറിയാവുന്നിടത്തോളം, റഷ്യൻ ഫെഡറേഷനിലെ പ്രാദേശിക ടെലിവിഷൻ കേന്ദ്രങ്ങളിൽ ഉൾപ്പെടുത്തലുകൾ നടത്തുന്നത് ഇങ്ങനെയാണ്, അതായത് സിസി കൗണ്ടർ വീണ്ടും കണക്കാക്കാതെ), ഇത് ഓർമ്മിക്കേണ്ടതാണ്. കുത്തക പരിഹാരങ്ങളിൽ, SCTE-35 ടാഗുകൾ കണ്ടെത്തുന്നതിലൂടെ ഈ പ്രശ്നം ഭാഗികമായി മറികടക്കുന്നു (അവ സ്ട്രീം ജനറേറ്റർ ചേർത്തിട്ടുണ്ടെങ്കിൽ).

ഗതാഗത ഗുണനിലവാര നിരീക്ഷണത്തിന്റെ കാര്യത്തിൽ, ജിറ്റർ മോണിറ്ററിംഗിന്റെ (ഐഎടി) അഭാവമുണ്ട്. ടിവി ഉപകരണങ്ങൾക്ക് (അത് മോഡുലേറ്ററുകളോ അവസാന ഉപകരണങ്ങളോ ആകട്ടെ) ഈ പരാമീറ്ററിന് ആവശ്യകതകളുണ്ട്, കൂടാതെ ജിറ്റ്ബഫറിനെ അനന്തതയിലേക്ക് ഉയർത്തുന്നത് എല്ലായ്പ്പോഴും സാധ്യമല്ല. വലിയ ബഫറുകളുള്ള ഉപകരണങ്ങൾ ട്രാൻസിറ്റിൽ ഉപയോഗിക്കുകയും QoS കോൺഫിഗർ ചെയ്യാതിരിക്കുകയോ അല്ലെങ്കിൽ അത്തരം തത്സമയ ട്രാഫിക്കുകൾ കൈമാറാൻ വേണ്ടത്ര കോൺഫിഗർ ചെയ്യാതിരിക്കുകയോ ചെയ്യുമ്പോൾ വിറയൽ പൊങ്ങിക്കിടക്കും.

അവലംബം: www.habr.com