🥇Ang paggamit sa TSDuck aron ma-monitor ang IP(TS) nga mga sapa

Karon, adunay mga andam na (proprietary) nga mga solusyon alang sa pag-monitor sa mga sapa sa IP (TS), pananglitan VB и iQ, sila adunay usa ka medyo adunahan nga hugpong sa mga gimbuhaton ug kasagaran ang dagkong mga operator nga nag-atubang sa mga serbisyo sa TV adunay ingon nga mga solusyon. Kini nga artikulo naghulagway sa usa ka solusyon base sa usa ka open source nga proyekto TSDuck, gidisenyo alang sa gamay nga pagkontrol sa IP(TS) nga mga sapa pinaagi sa CC(continuity counter) counter ug bitrate. Ang usa ka posible nga aplikasyon mao ang pagkontrolar sa pagkawala sa mga pakete o sa tibuok nga agos pinaagi sa usa ka giabangan nga L2 channel (nga dili normal nga mabantayan, pananglitan, pinaagi sa pagbasa sa pagkawala sa mga counter sa mga pila).

Sa mubo kaayo bahin sa TSDuck

Ang TSDuck usa ka open source (2-Clause BSD license) software (usa ka set sa console utilities ug library para sa pagpalambo sa custom utilities o plugins) para sa pagmaniobra sa TS streams. Ingon sa usa ka input, kini mahimo sa pagtrabaho uban sa IP (multicast/unicast), http, hls, dvb tuners, dektec dvb-asi demodulator, adunay internal TS-stream generator ug pagbasa gikan sa mga file. Ang output mahimong pagsulat sa usa ka file, IP (multicast/unicast), hls, dektec dvb-asi ug HiDes modulators, mga magdudula (mplayer, vlc, xine) ug drop. Ang lain-laing mga tigproseso sa trapiko mahimong maapil tali sa input ug output, pananglitan, PID remapping, scrambling/descrambling, CC counter analysis, bitrate kalkulasyon, ug uban pang tipikal nga operasyon para sa TS streams.

Niini nga artikulo, ang mga IP stream (multicast) gamiton isip usa ka input, ang mga processor bitrate_monitor (gikan sa ngalan nga klaro kung unsa kini) ug ang pagpadayon (analysis sa CC counters) gigamit. Dali nimo mapulihan ang IP multicast sa lain nga tipo sa input nga gisuportahan sa TSDuck.

Anaa opisyal nga pagtukod/pakete TSDuck para sa pinakabag-o nga operating system. Dili sila magamit alang sa Debian, apan nakahimo kami sa pagtukod niini sa ilawom sa debian 8 ug debian 10 nga wala’y mga problema.

Sunod, gigamit ang bersyon TSDuck 3.19-1520, gigamit ang Linux ingon OS (gigamit ang debian 10 aron maandam ang solusyon, gigamit ang CentOS 7 alang sa tinuud nga paggamit)

Pag-andam sa TSDuck ug OS

Sa wala pa ma-monitor ang tinuod nga mga agos, kinahanglan nimo nga siguruha nga ang TSDuck nagtrabaho sa husto ug wala’y mga pagtulo sa lebel sa network card o OS (socket). Gikinahanglan kini aron dili makatag-an sa ulahi kung diin nahitabo ang mga pagtulo - sa network o "sa sulod sa server". Mahimo nimong susihon ang mga pagtulo sa lebel sa network card gamit ang ethtool -S ethX command, ang pag-tune gihimo sa parehas nga ethtool (kasagaran, kinahanglan nimo nga dugangan ang RX buffer (-G) ug usahay i-disable ang pipila nga mga offloads (-K)). Ingon sa usa ka kinatibuk-ang rekomendasyon, kini mahimong gitambagan sa paggamit sa usa ka bulag nga pantalan alang sa pagdawat sa analisar sa trapiko, kon mahimo, kini mamenosan sayop nga mga positibo nga nalangkit sa kamatuoran nga ang drop nahitabo sa tukma sa analyzer pantalan tungod sa presensya sa ubang mga trapiko. Kung dili kini mahimo (usa ka mini-computer / NUC nga adunay usa ka pantalan ang gigamit), nan labi nga gitinguha nga i-set up ang prioritization sa na-analisar nga trapiko nga may kalabotan sa nahabilin sa aparato diin konektado ang analisador. Mahitungod sa mga virtual nga palibot, dinhi kinahanglan ka mag-amping ug makit-an ang mga packet drop sugod sa usa ka pisikal nga pantalan ug matapos sa usa ka aplikasyon sa sulod sa usa ka virtual machine.

Pagmugna ug pagdawat sa usa ka sapa sa sulod sa host

Isip usa ka unang lakang sa pag-andam sa TSDuck, makamugna kami ug makadawat og trapiko sulod sa usa ka host gamit ang netns.

Pag-andam sa palibot:

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

Andam na ang palibot. Atong sugdan ang traffic analyzer:

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

diin ang "-p 1 -t 1" nagpasabot nga kinahanglan nimong kuwentahon ang bitrate matag segundo ug ipakita ang impormasyon bahin sa bitrate matag segundo
Gisugdan namon ang generator sa trapiko nga adunay katulin nga 10Mbps:

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

diin ang "-p 7 -e" nagpasabot nga kinahanglan nimo nga i-pack ang 7 TS packets ngadto sa 1 IP packet ug buhaton kini nga lisud (-e), i.e. kanunay maghulat 7 TS packets gikan sa katapusang processor sa dili pa magpadala ug IP packet.

Ang analista magsugod sa pag-output sa gipaabot nga mga mensahe:

* 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

Karon pagdugang pipila ka tulo:

ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROP

ug ang mga mensahe nga sama niini makita:

* 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

nga gipaabot. I-disable ang packet loss (ip netns exec P iptables -F) ug sulayi nga dugangan ang bitrate sa generator ngadto sa 100Mbps. Ang analisador nagtaho sa usa ka hugpong sa mga kasaypanan sa CC ug mga 75 Mbps imbes sa 100. Gisulayan namon nga mahibal-an kung kinsa ang mabasol - ang generator wala’y oras o ang problema wala sa sulod niini, tungod niini nagsugod kami sa pagmugna og usa ka piho nga gidaghanon sa packets (700000 TS packets = 100000 IP packets):

# 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

Sama sa imong nakita, eksakto nga 100000 nga mga pakete sa IP ang nahimo (151925460-151825460). Mao nga atong mahibal-an kung unsa ang nahitabo sa analisador, alang niini atong susihon ang RX counter sa veth1, kini hugot nga katumbas sa TX counter sa veth0, unya atong tan-awon kung unsa ang mahitabo sa lebel sa socket:

# 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

Dinhi imong makita ang gidaghanon sa mga tulo = 24355. Sa TS packets, kini mao ang 170485 o 24.36% sa 700000, mao nga atong makita nga ang mga sama nga 25% sa nawala nga bitrate mga tulo sa udp socket. Ang mga pagtulo sa usa ka UDP socket kasagaran mahitabo tungod sa kakulang sa buffer, tan-awa ang default nga socket buffer size ug ang maximum socket buffer size:

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

Busa, kung ang mga aplikasyon dili tin-aw nga mangayo og buffer nga gidak-on, ang mga socket gihimo nga adunay buffer nga 208 KB, apan kung mangayo pa sila, dili gihapon nila madawat ang gihangyo. Tungod kay mahimo nimong itakda ang gidak-on sa buffer sa tsp alang sa input sa IP (-buffer-size), dili namon hikapon ang default nga gidak-on sa socket, apan itakda lamang ang labing kadaghan nga gidak-on sa buffer ug ipiho ang gidak-on sa buffer nga tin-aw pinaagi sa mga argumento sa 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

Sa kini nga pag-tune sa socket buffer, karon ang gitaho nga bitrate mga 100Mbps, wala’y mga sayup sa CC.

Sumala sa konsumo sa CPU sa tsp application mismo. Relatibo sa usa ka core i5-4260U CPU @ 1.40GHz, 10Mbps flow analysis magkinahanglan og 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%. Kung gitakda ang % Packet Loss, ang load sa CPU halos dili motaas (apan mahimong mokunhod).

Sa labi ka produktibo nga hardware, posible nga makamugna ug mag-analisar sa mga sapa nga labaw sa 1Gb / s nga wala’y mga problema.

Pagsulay sa tinuod nga network card

Human sa pagsulay sa usa ka pares sa veth, kinahanglan nimo nga magkuha og duha ka mga host o duha ka mga pantalan sa usa ka host, ikonektar ang mga pantalan sa usag usa, sugdi ang generator sa usa, ug ang analyzer sa ikaduha. Wala'y mga sorpresa dinhi, apan sa pagkatinuod kini tanan nagdepende sa puthaw, ang mas huyang, mas makapaikag kini dinhi.

Gigamit ang nadawat nga datos sa sistema sa pagmonitor (Zabbix)

tsp walay bisan unsa nga machine-readable API sama sa SNMP o susama. Ang mga mensahe sa CC kinahanglan nga matipon sa labing menos 1 ka segundo (nga adunay taas nga porsyento sa pagkawala sa pakete, mahimo’g adunay gatusan / libo / napulo ka libo matag segundo, depende sa bitrate).

Busa, aron matipigan ang duha ka impormasyon ug magdrowing og mga graph alang sa mga error sa CC ug bitrate ug makahimo og pipila ka matang sa mga aksidente, mahimong adunay mosunod nga mga kapilian:

Parse ug aggregate (sa CC) ang output sa tsp, i.e. i-convert kini sa gusto nga porma.
Tapuson ang tsp mismo ug/o processor plugins bitrate_monitor ug continuity aron ang resulta mahatag sa usa ka machine-readable nga porma nga haum sa monitoring system.
Isulat ang imong aplikasyon sa ibabaw sa tsduck library.

Dayag nga, ang kapilian 1 mao ang labing kadali sa mga termino sa paningkamot, labi na kung gikonsiderar nga ang tsduck mismo gisulat sa usa ka ubos nga lebel (sa modernong mga sumbanan) nga lengguwahe (C ++)

Ang usa ka yano nga bash parser + aggregator prototype nagpakita nga sa usa ka 10Mbps nga sapa ug 50% nga pagkawala sa pakete (labing daotan nga kaso), ang proseso sa bash mikonsumo sa 3-4 ka beses nga labi ka CPU kaysa sa proseso sa tsp mismo. Kini nga senaryo dili madawat. Sa tinuud usa ka piraso sa kini nga prototype sa ubos

Noodles sa ibabaw

#!/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

Gawas pa sa dili madawat nga hinay, wala’y normal nga mga hilo sa bash, ang mga trabaho sa bash lahi nga mga proseso, ug kinahanglan nako isulat ang kantidad sa nawala ngaPackets kausa sa usa ka segundo sa side effect (kung makadawat mga bitrate nga mensahe nga moabut matag segundo). Ingon usa ka sangputanan, gibiyaan nga nag-inusara ang bash ug nakahukom nga magsulat usa ka wrapper (parser + aggregator) sa golang. Ang pagkonsumo sa CPU sa parehas nga golang code 4-5 ka beses nga mas gamay kaysa sa proseso sa tsp mismo. Ang pagpadali sa wrapper tungod sa pag-ilis sa bash sa golang nahimo nga mga 16 ka beses ug sa kinatibuk-an ang resulta madawat (CPU overhead sa 25% sa pinakagrabe nga kaso). Ang golang source file nahimutang dinhi.

Dagan wrapper

Aron masugdan ang wrapper, gihimo ang pinakasimple nga template sa serbisyo para sa systemd (dinhi). Ang wrapper mismo kinahanglan nga i-compile sa binary file (go build tsduck-stat.go) nga nahimutang sa /opt/tsduck-stat/. Gituohan nga naggamit ka og golang nga adunay suporta sa monotonic nga orasan (>=1.9).

Aron makahimo usa ka pananglitan sa serbisyo, kinahanglan nimo nga ipadagan ang systemctl enable command [protektado sa email]: 1234 unya pagdagan uban ang systemctl pagsugod [protektado sa email]: 1234.

Pagdiskobre gikan sa Zabbix

Aron ang zabbix makadiskubre sa mga serbisyo nga nagdagan, nahimo kini generator sa listahan sa grupo (discovery.sh), sa pormat nga gikinahanglan alang sa pagdiskobre sa Zabbix, gituohan nga kini nahimutang sa samang dapit - sa /opt/tsduck-stat. Aron makadagan ang pagkadiskobre pinaagi sa zabbix-agent, kinahanglan nimo nga idugang .conf file sa zabbix-agent configuration directory aron idugang ang user parameter.

Zabbix nga template

Gibuhat nga template (tsduck_stat_template.xml) naglangkob sa lagda sa autodiscover, mga prototype sa butang, mga graph, ug mga trigger.

Mubo nga checklist (maayo, unsa man kung adunay modesisyon sa paggamit niini)

Siguruha nga ang tsp dili maghulog sa mga pakete sa ilawom sa "ideal" nga mga kondisyon (ang generator ug analista direkta nga konektado), kung adunay mga pagtulo, tan-awa ang parapo 2 o ang teksto sa artikulo bahin niini nga butang.
Himoa nga tuning ang pinakataas nga socket buffer (net.core.rmem_max=8388608).
Pag-compile sa tsduck-stat.go (pagtukod og tsduck-stat.go).
Ibutang ang template sa serbisyo sa /lib/systemd/system.
Sugdi ang mga serbisyo gamit ang systemctl, susiha nga ang mga counter nagsugod na sa pagpakita (grep "" /dev/shm/tsduck-stat/*). Ang gidaghanon sa mga serbisyo pinaagi sa gidaghanon sa multicast sapa. Dinhi kinahanglan nimo nga maghimo usa ka ruta sa grupo nga multicast, tingali dili pag-disable ang rp_filter o maghimo usa ka ruta sa gigikanan nga ip.
Pagdalagan ang discovery.sh, siguroha nga kini makamugna og json.
Idugang ang zabbix agent config, i-restart ang zabbix agent.
I-upload ang template sa zabbix, i-apply kini sa host nga gimonitor ug ang zabbix-agent gi-install, paghulat mga 5 minuto, tan-awa kung adunay bag-ong mga butang, graph ug trigger.

resulta

Alang sa tahas sa pag-ila sa pagkawala sa packet, hapit na kini igo, labing menos kini mas maayo kaysa walay pag-monitor.

Sa tinuud, ang "pagkawala" sa CC mahimong mahitabo kung ang paghiusa sa mga tipik sa video (sa akong nahibal-an, kini ang paagi nga gihimo ang mga pagsal-ot sa mga lokal nga sentro sa TV sa Russian Federation, i.e. nga wala’y pagkalkula sa CC counter), kinahanglan kini hinumdoman. Ang proprietary solutions partially circumvent this problem by detecting SCTE-35 labels (kon idugang sa stream generator).

Sa termino sa pagmonitor sa kalidad sa transportasyon, adunay kakuwang sa jitter monitoring (IAT). Ang mga ekipo sa TV (bisan modulators o end device) adunay mga kinahanglanon alang niini nga parameter ug dili kanunay posible nga mapataas ang jitbuffer hangtod sa walay katapusan. Ug ang jitter mahimong molutaw kung ang mga kagamitan nga adunay daghang mga buffer gigamit sa pagbiyahe ug ang QoS wala ma-configure o dili maayo nga na-configure aron mapadala ang ingon nga trapiko sa oras.

Source: www.habr.com

Paggamit sa TSDuck sa Pag-monitor sa IP(TS) Streams