ໃຊ້ TSDuck ເພື່ອຕິດຕາມ IP(TS) Stream

ມື້ນີ້, ມີວິທີແກ້ໄຂທີ່ກຽມພ້ອມ (ເປັນເຈົ້າຂອງ) ສໍາລັບການຕິດຕາມ IP (TS) streams, ສໍາລັບການຍົກຕົວຢ່າງ. VB и iQ, ພວກເຂົາເຈົ້າມີຫນ້າທີ່ອຸດົມສົມບູນພໍສົມຄວນແລະປົກກະຕິແລ້ວຜູ້ປະກອບການຂະຫນາດໃຫຍ່ທີ່ກ່ຽວຂ້ອງກັບການບໍລິການໂທລະພາບມີວິທີແກ້ໄຂທີ່ຄ້າຍຄືກັນ. ບົດຄວາມນີ້ອະທິບາຍການແກ້ໄຂໂດຍອີງໃສ່ໂຄງການແຫຼ່ງເປີດ TSDuck, ອອກແບບມາເພື່ອຄວບຄຸມ IP(TS) streams ໜ້ອຍທີ່ສຸດໂດຍ CC(continuity counter) counter ແລະ bitrate. ຄໍາຮ້ອງສະຫມັກທີ່ເປັນໄປໄດ້ແມ່ນການຄວບຄຸມການສູນເສຍແພັກເກັດຫຼືການໄຫຼເຂົ້າທັງຫມົດໂດຍຜ່ານຊ່ອງທາງ L2 ທີ່ເຊົ່າ (ເຊິ່ງບໍ່ສາມາດຕິດຕາມໄດ້ຕາມປົກກະຕິ, ສໍາລັບການຍົກຕົວຢ່າງ, ໂດຍການອ່ານຕົວນັບການສູນເສຍໃນຄິວ).

ສັ້ນໆກ່ຽວກັບ TSDuck

TSDuck ເປັນຊອຟແວ open source (ໃບອະນຸຍາດ 2-Clause BSD) (ຊຸດຂອງ console utilities ແລະຫ້ອງສະຫມຸດສໍາລັບການພັດທະນາ custom utilities ຫຼື plugins) ສໍາລັບ manipulating TS streams. ເປັນວັດສະດຸປ້ອນ, ມັນສາມາດເຮັດວຽກກັບ IP (multicast/unicast), http, hls, dvb tuners, dektec dvb-asi demodulator, ມີເຄື່ອງກໍາເນີດ TS-stream ພາຍໃນແລະການອ່ານຈາກໄຟລ໌. ຜົນຜະລິດສາມາດຂຽນເປັນໄຟລ໌, IP (multicast/unicast), hls, dektec dvb-asi ແລະ HiDes modulators, ເຄື່ອງຫຼິ້ນ (mplayer, vlc, xine) ແລະຫຼຸດລົງ. ໂປເຊດເຊີການຈາລະຈອນຕ່າງໆສາມາດຖືກລວມເຂົ້າລະຫວ່າງການປ້ອນຂໍ້ມູນແລະຜົນຜະລິດ, ສໍາລັບການຍົກຕົວຢ່າງ, PID remapping, scrambling / descrambling, ການວິເຄາະຕ້ານ CC, ການຄິດໄລ່ອັດຕາບິດ, ແລະການປະຕິບັດປົກກະຕິອື່ນໆສໍາລັບນ້ໍາ TS.

ໃນບົດຄວາມນີ້, IP streams (multicast) ຈະຖືກນໍາໃຊ້ເປັນ input, bitrate_monitor processors (ຈາກຊື່ມັນຈະແຈ້ງວ່ານີ້ແມ່ນຫຍັງ) ແລະການຕໍ່ເນື່ອງ (CC counter analysis) processors ຈະຖືກນໍາໃຊ້. ໂດຍບໍ່ມີບັນຫາໃດໆ, ທ່ານສາມາດທົດແທນ IP multicast ດ້ວຍປະເພດວັດສະດຸປ້ອນອື່ນທີ່ສະຫນັບສະຫນູນໂດຍ TSDuck.

ມີໃຫ້ ການ​ກໍ່​ສ້າງ / ການ​ຫຸ້ມ​ຫໍ່​ຢ່າງ​ເປັນ​ທາງ​ການ​ TSDuck ສໍາລັບລະບົບປະຕິບັດການໃນປະຈຸບັນສ່ວນໃຫຍ່. ພວກມັນບໍ່ສາມາດໃຊ້ໄດ້ສໍາລັບ Debian, ແຕ່ພວກເຮົາໄດ້ຈັດການສ້າງພວກມັນພາຍໃຕ້ debian 8 ແລະ debian 10 ໂດຍບໍ່ມີບັນຫາໃດໆ.

ຕໍ່ໄປ, ຮຸ່ນ TSDuck 3.19-1520 ຖືກນໍາໃຊ້, Linux ຖືກນໍາໃຊ້ເປັນ OS (debian 10 ຖືກນໍາໃຊ້ເພື່ອກະກຽມການແກ້ໄຂ, CentOS 7 ຖືກນໍາໃຊ້ສໍາລັບການນໍາໃຊ້ຕົວຈິງ)

ການກະກຽມ TSDuck ແລະ OS

ກ່ອນທີ່ຈະຕິດຕາມການໄຫຼທີ່ແທ້ຈິງ, ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າ TSDuck ເຮັດວຽກຢ່າງຖືກຕ້ອງແລະການຫຼຸດລົງນັ້ນບໍ່ໄດ້ເກີດຂື້ນໃນລະດັບບັດເຄືອຂ່າຍຫຼື OS (socket). ນີ້ແມ່ນຈໍາເປັນເພື່ອວ່າທ່ານຈະບໍ່ຕ້ອງເດົາພາຍຫຼັງທີ່ການຫຼຸດລົງເກີດຂຶ້ນ - ໃນເຄືອຂ່າຍຫຼື "ພາຍໃນເຄື່ອງແມ່ຂ່າຍ." ທ່ານສາມາດກວດເບິ່ງການຫຼຸດລົງໃນລະດັບບັດເຄືອຂ່າຍດ້ວຍຄໍາສັ່ງ ethtool -S ethX, ການປັບແມ່ນເຮັດໄດ້ໂດຍ ethtool ດຽວກັນ (ໂດຍປົກກະຕິທ່ານຕ້ອງການເພີ່ມ RX buffer (-G) ແລະບາງຄັ້ງປິດການໂຫຼດບາງຢ່າງ (-K)). ຕາມຄໍາແນະນໍາທົ່ວໄປ, ຄວນໃຊ້ພອດແຍກຕ່າງຫາກເພື່ອຮັບການຈະລາຈອນທີ່ວິເຄາະ, ຖ້າເປັນໄປໄດ້, ນີ້ຈະຫຼຸດຜ່ອນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງເນື່ອງຈາກຄວາມຈິງທີ່ວ່າການຫຼຸດລົງໄດ້ເກີດຂື້ນພ້ອມໆກັນຢູ່ໃນພອດການວິເຄາະເນື່ອງຈາກມີການຈະລາຈອນອື່ນໆ. ຖ້າອັນນີ້ເປັນໄປບໍ່ໄດ້ (ທ່ານກຳລັງໃຊ້ຄອມພິວເຕີຂະໜາດນ້ອຍ/ NUC ທີ່ມີພອດອັນດຽວ), ມັນສົມຄວນທີ່ຈະກຳນົດຄ່າບູລິມະສິດຂອງການຈະລາຈອນທີ່ວິເຄາະແລ້ວກ່ຽວກັບສ່ວນທີ່ເຫຼືອໃນອຸປະກອນທີ່ເຄື່ອງວິເຄາະເຊື່ອມຕໍ່. ກ່ຽວກັບສະພາບແວດລ້ອມ virtual, ໃນທີ່ນີ້ທ່ານຈໍາເປັນຕ້ອງລະມັດລະວັງແລະສາມາດຊອກຫາການຫຼຸດລົງຂອງແພັກເກັດເລີ່ມຕົ້ນຈາກພອດທາງດ້ານຮ່າງກາຍແລະສິ້ນສຸດດ້ວຍຄໍາຮ້ອງສະຫມັກພາຍໃນເຄື່ອງ virtual.

ການຜະລິດແລະການຕ້ອນຮັບຂອງນ້ໍາພາຍໃນເຈົ້າພາບ

ເປັນຂັ້ນຕອນທໍາອິດໃນການກະກຽມ 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" ຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງໄດ້ຫຸ້ມຫໍ່ 7 TS ເຂົ້າໄປໃນ 1 ຊຸດ IP ແລະເຮັດມັນຍາກ (-e), i.e. ລໍຖ້າ 7 ຊຸດ TS ຈາກໂປເຊດເຊີສຸດທ້າຍກ່ອນທີ່ຈະສົ່ງຊຸດ IP.

ຕົວວິເຄາະເລີ່ມສົ່ງຂໍ້ຄວາມທີ່ຄາດໄວ້:

* 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. ພວກເຮົາພະຍາຍາມຊອກຫາຜູ້ທີ່ຕ້ອງຕໍານິ - ເຄື່ອງກໍາເນີດໄຟຟ້າບໍ່ໄດ້ຮັກສາຫຼືບັນຫາບໍ່ໄດ້ຢູ່ໃນມັນ, ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາເລີ່ມຕົ້ນສ້າງ. ຈໍານວນແພັກເກັດຄົງທີ່ (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). ດັ່ງນັ້ນ, ໃຫ້ພວກເຮົາຄິດອອກສິ່ງທີ່ເກີດຂຶ້ນກັບເຄື່ອງວິເຄາະ, ສໍາລັບນີ້ພວກເຮົາກວດເບິ່ງກັບຕົວນັບ RX ໃນ veth1, ມັນເທົ່າທຽມກັນຢ່າງເຂັ້ມງວດກັບເຄນ TX ໃນ veth0, ຫຼັງຈາກນັ້ນພວກເຮົາເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນໃນລະດັບເຕົ້າຮັບ:

# 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% ດຽວກັນຂອງ bitrate ທີ່ສູນເສຍແມ່ນການຫຼຸດລົງໃນເຕົ້າຮັບ UDP. ການຫຼຸດລົງໃນຊັອກເກັດ UDP ມັກຈະເກີດຂື້ນເນື່ອງຈາກການຂາດບັບເຟີ, ເບິ່ງຂະຫນາດ socket buffer ເລີ່ມຕົ້ນແລະຂະຫນາດ socket buffer ສູງສຸດ:

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

ດັ່ງນັ້ນ, ຖ້າແອັບພລິເຄຊັນບໍ່ຮ້ອງຂໍຂະຫນາດ buffer ຢ່າງຊັດເຈນ, ເຕົ້າສຽບຖືກສ້າງຂື້ນດ້ວຍ buffer 208 KB, ແຕ່ຖ້າພວກເຂົາຮ້ອງຂໍເພີ່ມເຕີມ, ພວກເຂົາຍັງບໍ່ໄດ້ຮັບສິ່ງທີ່ຮ້ອງຂໍ. ເນື່ອງຈາກວ່າທ່ານສາມາດກໍານົດຂະຫນາດ buffer ໃນ tsp ສໍາລັບການປ້ອນຂໍ້ມູນ IP (-buffer-size), ພວກເຮົາຈະບໍ່ແຕະຂະຫນາດ socket ເລີ່ມຕົ້ນ, ແຕ່ພຽງແຕ່ກໍານົດຂະຫນາດ buffer ເຕົ້າຮັບສູງສຸດແລະລະບຸຂະຫນາດ buffer ຢ່າງຊັດເຈນໂດຍຜ່ານການ arguments 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.

ອີງຕາມການບໍລິໂພກ CPU ຂອງຄໍາຮ້ອງສະຫມັກ tsp ຕົວຂອງມັນເອງ. ກ່ຽວຂ້ອງກັບຫນຶ່ງ core i5-4260U CPU @ 1.40GHz, ການວິເຄາະການໄຫຼ 10Mbps ຈະຕ້ອງການ CPU 3-4%, 100Mbps - 25%, 200Mbps - 46%. ເມື່ອຕັ້ງ % Packet Loss, ການໂຫຼດໃນ CPU ບໍ່ໄດ້ເພີ່ມຂຶ້ນ (ແຕ່ອາດຈະຫຼຸດລົງ).

ໃນຮາດແວທີ່ມີຜົນຜະລິດຫຼາຍ, ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງແລະວິເຄາະສາຍນ້ໍາຫຼາຍກ່ວາ 1Gb / s ໂດຍບໍ່ມີບັນຫາໃດໆ.

ການທົດສອບໃນບັດເຄືອຂ່າຍທີ່ແທ້ຈິງ

ຫຼັງຈາກການທົດສອບຄູ່ veth, ທ່ານຈໍາເປັນຕ້ອງເອົາສອງໂຮດຫຼືສອງພອດຂອງຫນຶ່ງໂຮດ, ເຊື່ອມຕໍ່ພອດກັບກັນແລະກັນ, ແລ່ນເຄື່ອງກໍາເນີດໄຟຟ້າໃນຫນຶ່ງ, ແລະເຄື່ອງວິເຄາະທີສອງ. ບໍ່ມີຄວາມແປກໃຈຢູ່ທີ່ນີ້, ແຕ່ຄວາມຈິງແລ້ວມັນທັງຫມົດແມ່ນຂຶ້ນກັບຮາດແວ, ມັນອ່ອນກວ່າ, ມັນຈະມີຄວາມຫນ້າສົນໃຈຫຼາຍຢູ່ທີ່ນີ້.

ການນໍາໃຊ້ຂໍ້ມູນທີ່ໄດ້ຮັບໂດຍລະບົບການຕິດຕາມ (Zabbix)

tsp ບໍ່ມີ API ທີ່ເຄື່ອງສາມາດອ່ານໄດ້ເຊັ່ນ SNMP ຫຼືຄ້າຍຄືກັນ. ຂໍ້ຄວາມ CC ຕ້ອງໄດ້ຮັບການລວບລວມຢ່າງຫນ້ອຍ 1 ວິນາທີຕໍ່ຄັ້ງ (ໂດຍມີອັດຕາສ່ວນສູງຂອງການສູນເສຍແພັກເກັດ, ສາມາດມີຫຼາຍຮ້ອຍ / ພັນ / ສິບພັນຕໍ່ວິນາທີ, ຂຶ້ນກັບອັດຕາບິດ).

ດັ່ງນັ້ນ, ເພື່ອບັນທຶກທັງສອງຂໍ້ມູນແລະແຕ້ມກາຟສໍາລັບຄວາມຜິດພາດ CC ແລະອັດຕາບິດແລະເຮັດໃຫ້ບາງປະເພດຂອງອຸປະຕິເຫດ, ອາດຈະມີທາງເລືອກດັ່ງຕໍ່ໄປນີ້:

1. parse ແລະລວບລວມ (ໂດຍ CC) ຜົນຜະລິດ tsp, i.e. ປ່ຽນມັນເຂົ້າໄປໃນຮູບແບບທີ່ຕ້ອງການ.
2. ເພີ່ມ tsp ຕົວມັນເອງແລະ / ຫຼື plugins ໂປເຊດເຊີ bitrate_monitor ແລະຢ່າງຕໍ່ເນື່ອງເພື່ອໃຫ້ຜົນໄດ້ຮັບແມ່ນຜົນຜະລິດໃນຮູບແບບທີ່ເຄື່ອງສາມາດອ່ານໄດ້ທີ່ເຫມາະສົມກັບລະບົບການຕິດຕາມ.
3. ຂຽນຄໍາຮ້ອງສະຫມັກຂອງທ່ານຢູ່ເທິງສຸດຂອງຫ້ອງສະຫມຸດ tsduck.

ແນ່ນອນ, ທາງເລືອກ 1 ແມ່ນງ່າຍທີ່ສຸດກ່ຽວກັບຄວາມພະຍາຍາມ, ໂດຍສະເພາະແມ່ນການພິຈາລະນາວ່າ tsduck ຕົວຂອງມັນເອງຖືກຂຽນໃນລະດັບຕ່ໍາ (ໂດຍມາດຕະຖານທີ່ທັນສະໄຫມ) ພາສາ (C ++)

A ງ່າຍດາຍ bash parser + aggregator prototype ສະແດງໃຫ້ເຫັນວ່າໃນ 10Mbps stream ແລະ 50% packet ສູນເສຍ (ກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ), ຂະບວນການ bash ໃຊ້ CPU 3-4 ເທົ່າຫຼາຍກ່ວາຂະບວນການ tsp ຕົວມັນເອງ. ສະຖານະການນີ້ບໍ່ສາມາດຍອມຮັບໄດ້. ແທ້ຈິງແລ້ວ, ຊິ້ນສ່ວນຂອງຕົ້ນແບບນີ້ແມ່ນຢູ່ຂ້າງລຸ່ມນີ້

Noodles ສຸດ basha

#!/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 ທີ່ຂາດຫາຍໄປຫນຶ່ງຄັ້ງຕໍ່ວິນາທີກ່ຽວກັບຜົນກະທົບຂ້າງຄຽງ (ເມື່ອໄດ້ຮັບຂໍ້ຄວາມອັດຕາບິດທີ່ເຂົ້າມາທຸກໆວິນາທີ). ດັ່ງນັ້ນ, bash ໄດ້ຖືກປະໄວ້ຢ່າງດຽວແລະມັນຖືກຕັດສິນໃຈຂຽນ wrapper (parser + aggregator) ໃນ golang. ການບໍລິໂພກ CPU ຂອງລະຫັດທີ່ຄ້າຍຄືກັນໃນ golang ແມ່ນ 4-5 ເທື່ອຫນ້ອຍກ່ວາຂະບວນການ tsp ຕົວຂອງມັນເອງ. ການເລັ່ງຂອງ wrapper ໂດຍການປ່ຽນແທນ bash ກັບ golang ແມ່ນປະມານ 16 ເທື່ອແລະຜົນໄດ້ຮັບໂດຍລວມແມ່ນຍອມຮັບ (CPU overhead 25% ໃນກໍລະນີຮ້າຍແຮງທີ່ສຸດ). ໄຟລ໌ແຫຼ່ງ golang ຕັ້ງຢູ່ ທີ່ນີ້.

ການເປີດຕົວຫໍ່

ເພື່ອເລີ່ມຕົ້ນການຫໍ່, ແມ່ແບບການບໍລິການທີ່ງ່າຍດາຍທີ່ສຸດສໍາລັບ systemd ໄດ້ຖືກສ້າງຂື້ນ (ທີ່ນີ້). wrapper ຕົວຂອງມັນເອງຄວນຈະຖືກລວບລວມເຂົ້າໄປໃນໄຟລ໌ຄູ່ (ໄປສ້າງ tsduck-stat.go) ທີ່ຕັ້ງຢູ່ໃນ /opt/tsduck-stat/. ມັນສົມມຸດວ່າທ່ານກໍາລັງໃຊ້ golang ໂດຍສະຫນັບສະຫນູນໂມງ monotonic (>= 1.9).

ເພື່ອສ້າງຕົວຢ່າງຂອງການບໍລິການ, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການຄໍາສັ່ງເປີດໃຊ້ systemctl [email protected]: 1234 ຫຼັງຈາກນັ້ນດໍາເນີນການດ້ວຍການເລີ່ມຕົ້ນ systemctl [email protected]: 1234

ການຄົ້ນພົບຈາກ Zabbix

ດັ່ງນັ້ນ zabbix ສາມາດເຮັດໃຫ້ການຄົ້ນພົບການບໍລິການແລ່ນ, ຜູ້ຜະລິດລາຍຊື່ກຸ່ມ (discovery.sh), ໃນຮູບແບບທີ່ຕ້ອງການສໍາລັບການຄົ້ນພົບ Zabbix, ມັນສົມມຸດວ່າມັນຢູ່ໃນສະຖານທີ່ດຽວກັນ - in /opt/tsduck-stat . ເພື່ອດໍາເນີນການຄົ້ນພົບຜ່ານ zabbix-agent, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມ ໄຟລ໌ .conf ໄປຫາໄດເລກະທໍລີທີ່ມີການຕັ້ງຄ່າ zabbix-agent ເພື່ອເພີ່ມພາລາມິເຕີຜູ້ໃຊ້.

ແມ່ແບບ Zabbix

ສ້າງແມ່ແບບ (tsduck_stat_template.xml) ປະກອບມີກົດລະບຽບ autodiscover, prototypes ລາຍການ, ກຣາບ ແລະ triggers.

ບັນຊີລາຍການກວດກາສັ້ນໆ (ດີ, ຈະເປັນແນວໃດຖ້າຜູ້ໃດຜູ້ນຶ່ງຕັດສິນໃຈໃຊ້ມັນ)

1. ໃຫ້ແນ່ໃຈວ່າ tsp ບໍ່ໄດ້ຫຼຸດລົງຊອງພາຍໃຕ້ເງື່ອນໄຂ "ທີ່ເຫມາະສົມ" (ເຄື່ອງກໍາເນີດແລະເຄື່ອງວິເຄາະແມ່ນເຊື່ອມຕໍ່ໂດຍກົງ), ຖ້າມີການຫຼຸດລົງ, ເບິ່ງຈຸດ 2 ຫຼືຂໍ້ຄວາມຂອງບົດຄວາມກ່ຽວກັບເລື່ອງນີ້.
2. ເຮັດໃຫ້ການປັບແຕ່ງຂອງ socket buffer ສູງສຸດ (net.core.rmem_max=8388608).
3. ລວບລວມ tsduck-stat.go (ໄປສ້າງ tsduck-stat.go).
4. ໃສ່ແມ່ແບບການບໍລິການໃນ /lib/systemd/system.
5. ເລີ່ມການບໍລິການດ້ວຍ systemctl, ກວດເບິ່ງວ່າຕົວນັບເລີ່ມປາກົດ (grep "" /dev/shm/tsduck-stat/*). ຈໍານວນການບໍລິການໂດຍຈໍານວນຂອງການຖ່າຍທອດ multicast. ໃນທີ່ນີ້ທ່ານອາດຈະຕ້ອງສ້າງເສັ້ນທາງໄປຫາກຸ່ມ multicast, ບາງທີອາດປິດການໃຊ້ງານ rp_filter ຫຼືສ້າງເສັ້ນທາງໄປຫາ ip ແຫຼ່ງ.
6. ດໍາເນີນການ discovery.sh, ໃຫ້ແນ່ໃຈວ່າມັນສ້າງ json.
7. ເພີ່ມການຕັ້ງຄ່າຕົວແທນ zabbix, ຣີສະຕາດຕົວແທນ zabbix.
8. ອັບໂຫລດແມ່ແບບໃສ່ zabbix, ນໍາໃຊ້ມັນກັບເຈົ້າພາບທີ່ກໍາລັງຕິດຕາມແລະຕິດຕັ້ງ zabbix-agent, ລໍຖ້າປະມານ 5 ນາທີ, ເບິ່ງວ່າມີລາຍການໃຫມ່, ເສັ້ນສະແດງແລະ triggers.

ຜົນ

ສໍາລັບວຽກງານການກໍານົດການສູນເສຍແພັກເກັດ, ມັນເກືອບພຽງພໍ, ຢ່າງຫນ້ອຍມັນກໍ່ດີກວ່າບໍ່ມີການຕິດຕາມ.

ແທ້ຈິງແລ້ວ, CC "ການສູນເສຍ" ສາມາດເກີດຂື້ນໄດ້ໃນເວລາທີ່ການລວມເອົາຊິ້ນວິດີໂອ (ເທົ່າທີ່ຂ້ອຍຮູ້, ນີ້ແມ່ນວິທີການໃສ່ໃນສູນໂທລະພາບທ້ອງຖິ່ນໃນສະຫະພັນລັດເຊຍ, ເຊັ່ນ: ໂດຍບໍ່ມີການຄິດໄລ່ຄືນ CC), ນີ້ຕ້ອງໄດ້ຮັບການຈົດຈໍາ. ວິທີແກ້ໄຂທີ່ເປັນເຈົ້າຂອງບາງສ່ວນຫລີກລ້ຽງບັນຫານີ້ໂດຍການກວດສອບປ້າຍ SCTE-35 (ຖ້າເພີ່ມໂດຍເຄື່ອງກໍາເນີດນ້ໍາ).

ຈາກຈຸດຂອງການກວດສອບຄຸນນະພາບການຂົນສົ່ງ, ການກວດສອບ jitter (IAT) ແມ່ນບໍ່ພຽງພໍ, ເນື່ອງຈາກວ່າ ອຸປະກອນໂທລະທັດ (ບໍ່ວ່າຈະເປັນ modulators ຫຼືອຸປະກອນສິ້ນສຸດ) ມີຂໍ້ກໍານົດສໍາລັບພາລາມິເຕີນີ້ແລະມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະ inflate jitbuffer ຕະຫຼອດໄປ. ແລະການສັ່ນສະເທືອນສາມາດລອຍໄດ້ໃນເວລາທີ່ການຂົນສົ່ງນໍາໃຊ້ອຸປະກອນທີ່ມີ buffers ຂະຫນາດໃຫຍ່ແລະ QoS ບໍ່ໄດ້ຖືກຕັ້ງຄ່າຫຼືບໍ່ໄດ້ຕັ້ງຄ່າດີພໍທີ່ຈະສົ່ງການຈະລາຈອນໃນເວລາທີ່ແທ້ຈິງດັ່ງກ່າວ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com