🥇Истифодаи TSDuck барои назорати ҷараёнҳои IP(TS)

Имрӯз барои мониторинги ҷараёни IP(TS) қарорҳои тайёр (хусусӣ) мавҷуданд, масалан VB и iQ, онҳо маҷмӯи хеле бойи вазифаҳо доранд ва одатан операторони калоне, ки бо хидматҳои телевизионӣ сарукор доранд, ҳалли шабеҳ доранд. Ин мақола ҳалли асоси лоиҳаи кушодаасосро тавсиф мекунад TSDuck, ки барои назорати ҳадди ақали ҷараёнҳои IP(TS) бо истифода аз ҳисобкунаки CC (ҳисобкунаки давомнокӣ) ва суръати бит пешбинӣ шудааст. Барномаи эҳтимолӣ ин мониторинги талафоти бастаҳо ё тамоми ҷараёни тавассути канали ба иҷора гирифташудаи L2 мебошад (ки онро ба таври муқаррарӣ назорат кардан мумкин нест, масалан, бо хондани ҳисобкунакҳои талафот дар навбат).

Хеле мухтасар дар бораи TSDuck

TSDuck нармафзори кушодаасос аст (литсензияи 2-банди BSD) (маҷмӯи утилитаҳои консол ва китобхона барои таҳияи утилитаҳо ё плагинҳои шахсии шумо) барои коркарди ҷараёнҳои TS. Ҳамчун вуруд, он метавонад бо IP (мултиcast/unicast), http, hls, dvb tuner, dektec dvb-asi demodulator кор кунад, генератори дохилии ҷараёни TS ва хондани файлҳо мавҷуд аст. Натиҷа метавонад сабти файл, IP (мултиcast/unicast), hls, dektec dvb-asi ва модуляторҳои HiDes, плеерҳо (mplayer, vlc, xine) ва тарки бошад. Байни вуруд ва баромад, шумо метавонед протсессорҳои гуногуни трафикро фаъол созед, масалан, аз нав харитаи PIDҳо, анҷом додани scrambling/descrambling, таҳлили ҳисобкунакҳои CC, ҳисоб кардани суръати бит ва дигар амалиётҳои барои ҷараёнҳои TS хос.

Дар ин мақола ҷараёнҳои IP (мултиcast) ҳамчун вуруд истифода хоҳанд шуд, протсессори bitrate_monitor (аз номаш маълум аст, ки ин чист) ва муттасилӣ (CC counter analysis) истифода мешаванд. Бе ягон мушкилот, шумо метавонед IP multicast бо навъи дигари вуруди аз ҷониби TSDuck дастгирӣшаванда иваз кунед.

дастрас сохтмонҳо / бастаҳои расмӣ TSDuck барои аксари ОС-и ҷорӣ. Ҳеҷ чиз барои Debian вуҷуд надорад, аммо мо тавонистем онҳоро барои Debian 8 ва Debian 10 бидуни мушкилот тартиб диҳем.

Баъдан, версияи TSDuck 3.19-1520 истифода мешавад, Linux ҳамчун OS истифода мешавад (барои омода кардани ҳалли debian 10 истифода шудааст, CentOS 7 барои истифодаи воқеӣ истифода шудааст)

Омода кардани TSDuck ва OS

Пеш аз мониторинги ҷараёнҳои воқеӣ, шумо бояд боварӣ ҳосил кунед, ки TSDuck дуруст кор мекунад ва пастшавӣ дар корти шабакавӣ ё сатҳи OS (розетка) рух намедиҳад. Ин барои он талаб карда мешавад, ки ба шумо лозим нест, ки баъдтар фаҳмед, ки қатраҳо дар куҷо рух додаанд - дар шабака ё "дар дохили сервер". Шумо метавонед қатраҳоро дар сатҳи корти шабака бо фармони ethtool -S ethX тафтиш кунед, танзим тавассути ҳамон ethtool анҷом дода мешавад (одатан ба шумо лозим аст, ки буфери 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" маънои онро дорад, ки шумо бояд суръати битро ҳар сония ҳисоб кунед ва ҳар сония маълумотро дар бораи суръати бит нишон диҳед
Мо генератори трафикро бо суръати 10 Мбит/с ба кор меандозем:

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 Мбит/с зиёд кунем. Анализатор як қатор хатогиҳои CC ва ба ҷои 75 тақрибан 100 Мбит/с хабар медиҳад. Мо кӯшиш мекунем фаҳмем, ки кӣ гунаҳкор аст - генератор ба кор намеояд ё мушкилот дар он нест, барои ин мо тавлиди як шумораи собит бастаҳо (700000 100000 пакети TS = XNUMX XNUMX пакети 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 IP-пакетҳо тавлид шудаанд (151825460-1). Ҳамин тавр, мо мефаҳмем, ки бо анализатор чӣ рӯй дода истодааст, барои ин мо бо ҳисобкунаки RX дар veth0 тафтиш мекунем, он ба таври қатъӣ ба ҳисобкунаки TX дар vethXNUMX баробар аст, пас мо ба он чизе ки дар сатҳи розетка рух дода истодааст, мебинем:

# 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 КБ сохта мешаванд, аммо агар онҳо бештар дархост кунанд, онҳо то ҳол он чизеро, ки дархост карда буданд, қабул намекунанд. Азбаски дар tsp шумо метавонед андозаи буферро барои вуруди IP (--buffer-size) таъин кунед, мо ба андозаи пешфарз васл намекунем, балки танҳо андозаи ҳадди ниҳоии буфери розеткаро муқаррар мекунем ва андозаи буферро ба таври возеҳ тавассути аргументҳои 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

Бо ин танзими буфери розетка, суръати гузоришшуда ҳоло тақрибан 100 Мбит / с аст, хатогиҳои CC вуҷуд надоранд.

Дар асоси истеъмоли CPU аз ҷониби худи барномаи tsp. Дар мавриди як CPU-и асосии i5-4260U @ 1.40 ГГц, барои таҳлили ҷараёни 10Мбит/с, 3-4% аз CPU лозим мешавад, 100Мбит/с - 25%, 200Мбит/с - 46%. Ҳангоми муқаррар кардани % талафи баста, сарбории CPU амалан зиёд намешавад (вале метавонад кам шавад).

Дар сахтафзорҳои пурмаҳсул бе ягон мушкилот ҷараёнҳои зиёда аз 1 Гб/с тавлид ва таҳлил кардан мумкин буд.

Санҷиш дар кортҳои шабакавии воқеӣ

Пас аз санҷиш дар як ҷуфти veth, шумо бояд ду ҳост ё ду порти як ҳост гиред, портҳоро ба ҳамдигар пайваст кунед, генераторро дар як ва анализаторро дар дуюм кор кунед. Дар ин ҷо тааҷҷубовар набуд, аммо дар асл ҳамааш аз сахтафзор вобаста аст, ҳар қадар заифтар бошад, дар ин ҷо ҷолибтар хоҳад буд.

Истифодаи маълумоти гирифташуда аз ҷониби системаи мониторинг (Zabbix)

tsp ягон API-и бо мошин хондашаванда ба монанди SNMP ё шабеҳ надорад. Паёмҳои CC бояд дар як вақт ҳадди аққал 1 сония ҷамъ карда шаванд (бо фоизи баланди талафоти бастаҳо, вобаста ба суръати бит метавонад садҳо/ҳазорҳо/даҳҳо ҳазор дар як сония бошад).

Ҳамин тариқ, барои захира кардани маълумот ва кашидани графикҳо барои хатогиҳои CC ва суръати бит ва минбаъдаи баъзе садамаҳо, имконоти зерин вуҷуд доранд:

Таҳлил ва ҷамъоварӣ (аз рӯи CC) баромади tsp, яъне. онро ба шакли дилхох табдил дихед.
Худи tsp ва/ё плагинҳои bitrate_monitor ва протсессори давомдорро илова кунед, то натиҷа дар шакли бо мошин хондашаванда барои системаи мониторинг бароварда шавад.
Аризаи худро дар болои китобхонаи tsduck нависед.

Аён аст, ки аз нуқтаи назари хароҷоти меҳнат, варианти 1 соддатарин аст, хусусан бо назардошти он, ки худи tsduck бо забони сатҳи паст (аз рӯи стандартҳои муосир) навишта шудааст (C++)

Прототипи оддии парсер + агрегатор дар bash нишон дод, ки дар ҷараёни 10 Мбит/с ва 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

Илова бар он, ки ин ба таври қобили қабул суст кор мекунад, дар bash риштаҳои муқаррарӣ вуҷуд надоранд, корҳои bash равандҳои мустақиланд ва ман маҷбур будам, ки арзиши missingPackets-ро дар як сония як маротиба дар таъсири тараф нависам (ҳангоми гирифтани паёмҳои бит, ки ҳар сония меоянд). Дар натиҷа, bash танҳо монданд ва тасмим гирифта шуд, ки бо забони голанг печанда (парсер + агрегатор) нависад. Истеъмоли CPU барои рамзи шабеҳ дар голанг 4-5 маротиба камтар аз худи раванди tsp аст. Шитоби парпеч бо иваз кардани bash бо голанг тақрибан 16 маротиба буд ва дар маҷмӯъ натиҷа қобили қабул аст (сарфи CPU 25% дар бадтарин ҳолат). Файли сарчашмаи golang ҷойгир аст дар ин ҷо.

Оғози бастабандӣ

Барои оғоз кардани бастабандӣ, як қолаби оддии хидматрасонӣ барои systemd сохта шуд (дар ин ҷо). Тахмин меравад, ки худи бастабандӣ ба файли дуӣ тартиб дода шудааст (go build tsduck-stat.go), воқеъ дар /opt/tsduck-stat/. Тахмин меравад, ки голанг бо дастгирии соати монотонӣ истифода мешавад (>=1.9).

Барои сохтани мисоли хидматӣ шумо бояд фармони systemctl enable -ро иҷро кунед [почтаи электронӣ ҳифз карда шудааст]:1234, пас бо systemctl start иҷро кунед [почтаи электронӣ ҳифз карда шудааст]: 1234.

Кашф аз Zabbix

Барои он ки zabbix метавонад хидматҳои иҷрошавандаро кашф кунад, генератори рӯйхати гурӯҳ (discovery.sh), дар формате, ки барои кашфи Zabbix лозим аст, тахмин карда мешавад, ки он дар ҳамон ҷо ҷойгир аст - дар /opt/tsduck-stat. Барои иҷро кардани кашф тавассути zabbix-agent, шумо бояд илова кунед файли .conf ба директория бо конфигуратсияҳои zabbix-агент барои илова кардани параметри корбар.

Шаблон 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 бартараф карда мешавад (агар онҳо аз ҷониби генератори ҷараён илова карда шаванд).

Аз нуктаи назари мониторинги сифати наклиёт, мониторинги jitter (IAT) кифоя нест, зеро Таҷҳизоти телевизионӣ (хоҳ модуляторҳо ва хоҳ дастгоҳҳои ниҳоӣ) ба ин параметр талабот доранд ва на ҳама вақт имкон дорад, ки ҷитбуферро ба таври номуайян пур кунед. Ва ҷиттер метавонад шино кунад, вақте ки транзит таҷҳизоти дорои буферҳои калонро истифода мебарад ва QoS барои интиқоли чунин трафики вақти воқеӣ ба қадри кофӣ танзим карда нашудааст ё танзим нашудааст.

Манбаъ: will.com

Истифодаи TSDuck барои мониторинги ҷараёни IP(TS).