Данас постоје готова (власничка) решења за праћење ИП(ТС) токова, нпр. и , имају прилично богат скуп функција и обично велики оператери који се баве ТВ услугама имају таква решења. Овај чланак описује решење засновано на пројекту отвореног кода , дизајниран за минималну контролу ИП(ТС) токова помоћу ЦЦ (континуитет бројача) бројача и брзине преноса. Могућа примена је контрола губитка пакета или целог тока кроз закупљени Л2 канал (који се не може нормално надгледати, на пример, читањем бројача губитака у редовима).
Врло кратко о ТСДуцку
ТСДуцк је софтвер отвореног кода (2-Цлаусе БСД лиценца) (скуп конзолних услужних програма и библиотека за развој прилагођених услужних програма или додатака) за манипулисање ТС токовима. Као улаз може да ради са ИП (мултицаст/уницаст), хттп, хлс, двб тјунерима, дектец двб-аси демодулатором, постоји интерни ТС стреам генератор и читање из фајлова. Излаз може бити уписивање у датотеку, ИП (мултицаст/уницаст), хлс, дектец двб-аси и ХиДес модулатори, плејери (мплаиер, влц, кине) и дроп. Можете да омогућите различите процесоре саобраћаја између улаза и излаза, на пример, ПИД ремаппинг, шифровање / дешифровање, анализу ЦЦ бројача, израчунавање брзине преноса и друге типичне операције за ТС токове.
У овом чланку ће се као улаз користити ИП токови (мултицаст), користе се процесори битрате_монитор (из назива је јасно шта је то) и континуитет (анализа ЦЦ бројача). Можете лако да замените ИП мултицаст другим типом улаза који подржава ТСдуцк.
Постоје ТСДуцк за већину актуелних оперативних система. Нису доступни за Дебиан, али смо успели да их направимо под дебиан 8 и дебиан 10 без икаквих проблема.
Затим се користи верзија ТСДуцк 3.19-1520, Линук се користи као ОС (дебиан 10 је коришћен за припрему решења, ЦентОС 7 је коришћен за стварну употребу)
Припрема ТСДуцк и ОС
Пре надгледања стварних токова, морате се уверити да ТСДуцк ради исправно и да нема падова на нивоу мрежне картице или ОС (соцкет). Ово је потребно да касније не бисте погодили где су се десили падови - на мрежи или „унутар сервера“. Можете проверити падове на нивоу мрежне картице помоћу етхтоол -С етхКс команде, подешавање се врши помоћу истог етхтоол-а (обично је потребно да повећате РКС бафер (-Г) и понекад онемогућите неке истоваре (-К)). Као општа препорука, може се саветовати да се користи посебан порт за пријем анализираног саобраћаја, ако је могуће, то минимизира лажне позитивне резултате повезане са чињеницом да се пад догодио управо на порту анализатора због присуства другог саобраћаја. Уколико то није могуће (користи се мини-рачунар/НУЦ са једним портом), онда је веома пожељно поставити приоритет анализираног саобраћаја у односу на остатак на уређају на који је анализатор повезан. Што се тиче виртуелних окружења, овде морате бити пажљиви и бити у могућности да пронађете испуштање пакета почевши од физичког порта до апликације унутар виртуелне машине.
Генерисање и пријем тока унутар хоста
Као први корак у припреми ТСДуцк-а, генерисаћемо и примати саобраћај унутар једног хоста користећи нетнс.
Припрема околине:
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где "-п 1 -т 1" значи да треба да израчунате брзину преноса сваке секунде и да прикажете информације о брзини у битовима сваке секунде
Покрећемо генератор саобраћаја брзином од 10Мбпс:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234где "-п 7 -е" значи да треба да спакујете 7 ТС пакета у 1 ИП пакет и то тешко (-е), тј. увек сачекајте 7 ТС пакета од последњег процесора пре него што пошаљете ИП пакет.
Анализатор почиње да емитује очекиване поруке:
* 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 што се очекује. Онемогућите губитак пакета (ип нетнс екец П иптаблес -Ф) и покушајте да повећате брзину протока генератора на 100 Мбпс. Анализатор пријављује гомилу ЦЦ грешака и око 75 Мбпс уместо 100. Покушавамо да откријемо ко је крив - генератор нема времена или проблем није у њему, за то почињемо да генеришемо фиксни број пакети (700000 ТС пакета = 100000 ИП пакета):
# 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). Дакле, хајде да схватимо шта се дешава са анализатором, за ово проверавамо са РКС бројачем на ветх1, он је стриктно једнак ТКС бројачу на ветх0, затим гледамо шта се дешава на нивоу утичнице:
# 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% изгубљеног битрате-а падови у удп сокету. Падови у УДП сокету се обично дешавају због недостатка бафера, погледајте подразумевану величину бафера утичнице и максималну величину бафера утичнице:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Дакле, ако апликације експлицитно не захтевају величину бафера, сокети се креирају са бафером од 208 КБ, али ако захтевају више, и даље неће добити оно што је тражено. Пошто можете да подесите величину бафера у тсп за ИП улаз (-буффер-сизе), нећемо дирати подразумевану величину сокета, већ само поставити максималну величину бафера утичнице и експлицитно навести величину бафера преко тсп аргумената:
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Мбпс, нема ЦЦ грешака.
Према потрошњи ЦПУ-а саме тсп апликације. У односу на ЦПУ са једним језгром и5-4260У на 1.40 ГХз, анализа протока од 10 Мбпс ће захтевати 3-4% ЦПУ, 100 Мбпс - 25%, 200 Мбпс - 46%. Приликом подешавања % губитка пакета, оптерећење ЦПУ-а се практично не повећава (али се може смањити).
На продуктивнијем хардверу било је могуће генерисати и анализирати стреамове веће од 1Гб/с без икаквих проблема.
Тестирање на стварним мрежним картицама
Након тестирања на ветх пару, потребно је да узмете два хоста или два порта једног хоста, повежете портове један са другим, покренете генератор на једном, а анализатор на другом. Овде није било изненађења, али у ствари све зависи од гвожђа, што слабије, то ће овде бити занимљивије.
Коришћење примљених података од стране система за праћење (Заббик)
тсп нема никакав машински читљив АПИ као што је СНМП или слично. ЦЦ поруке морају бити агрегиране најмање 1 секунду (са високим процентом губитка пакета, може бити стотине/хиљаде/десетине хиљада у секунди, у зависности од брзине преноса).
Дакле, да бисте сачували и информације и нацртали графиконе за ЦЦ грешке и брзину преноса и направили неку врсту незгода, могу постојати следеће опције:
- Парсирајте и агрегирајте (по ЦЦ) излаз тсп, тј. претворите га у жељени облик.
- Завршите сам тсп и/или додатке за процесор битрате_монитор и континуитет тако да се резултат даје у машински читљивом облику погодном за систем за праћење.
- Напишите своју апликацију на врху тсдуцк библиотеке.
Очигледно, опција 1 је најлакша у смислу напора, посебно имајући у виду да је сам тсдуцк написан на ниском нивоу (по савременим стандардима) језику (Ц ++)
Једноставан басх парсер+агрегатор прототип је показао да је на 10Мбпс стреаму и 50% губитка пакета (у најгорем случају), басх процес трошио 3-4 пута више ЦПУ-а него сам тсп процес. Овај сценарио је неприхватљив. У ствари, део овог прототипа испод
Резанци на врху
#!/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Поред тога што је неприхватљиво спор, нема нормалних нити у басх-у, басх послови су одвојени процеси и морао сам да напишем вредност недостајућих пакета једном у секунди на споредном ефекту (приликом примања порука брзине преноса које долазе сваке секунде). Као резултат тога, басх је остао сам и одлучено је да се напише омот (парсер + агрегатор) у голанг. Потрошња ЦПУ-а сличног голанг кода је 4-5 пута мања од самог тсп процеса. Испоставило се да је убрзање омотача услед замене басх-а голангом око 16 пута и генерално резултат је прихватљив (претеривање ЦПУ-а за 25% у најгорем случају). Голанг изворна датотека се налази .
Покрени омотач
Да би се покренуо омотач, направљен је најједноставнији сервисни шаблон за системд (). Сам омотач би требало да буде преведен у бинарну датотеку (иди буилд тсдуцк-стат.го) која се налази у /опт/тсдуцк-стат/. Претпоставља се да користите голанг са подршком за монотони сат (>=1.9).
Да бисте креирали инстанцу услуге, потребно је да покренете наредбу системцтл енабле [емаил заштићен]:1234 затим покрените са системцтл старт [емаил заштићен]: КСНУМКС.
Откриће из Заббика
Да би заббик могао да открије покренуте сервисе, то је учињено (дисцовери.сх), у формату потребном за откривање Заббика, претпоставља се да се налази на истом месту - у /опт/тсдуцк-стат. Да бисте покренули откривање преко заббик-агента, потребно је да додате у директоријум конфигурације заббик-агента да бисте додали кориснички параметар.
Заббик шаблон
(тсдуцк_стат_темплате.кмл) садржи правило аутоматског откривања, прототипове ставки, графиконе и покретаче.
Кратка контролна листа (па, шта ако неко одлучи да је користи)
- Уверите се да тсп не испушта пакете под "идеалним" условима (генератор и анализатор су директно повезани), ако има падова, погледајте параграф 2 или текст чланка о овом питању.
- Направите подешавање максималног бафера утичнице (нет.цоре.рмем_мак=8388608).
- Компилирајте тсдуцк-стат.го (идите буилд тсдуцк-стат.го).
- Ставите шаблон услуге у /либ/системд/систем.
- Покрените сервисе са системцтл, проверите да ли су бројачи почели да се појављују (греп "" /дев/схм/тсдуцк-стат/*). Број услуга према броју мултицаст стримова. Овде ћете можда морати да креирате руту до групе за вишеструке преносе, можда онемогућите рп_филтер или креирате руту до изворног ИП-а.
- Покрените дисцовери.сх, уверите се да генерише јсон.
- Додајте конфигурацију заббик агента, поново покрените заббик агент.
- Отпремите шаблон на заббик, примените га на хост који се надгледа и заббик-агент је инсталиран, сачекајте око 5 минута, погледајте да ли има нових ставки, графикона и покретача.
Резултат
За задатак откривања губитка пакета, то је скоро довољно, барем је боље него без праћења.
Заиста, ЦЦ „губици“ могу да настану приликом спајања видео фрагмената (колико ја знам, овако се раде уметци у локалним ТВ центрима у Руској Федерацији, односно без поновног израчунавања ЦЦ бројача), ово се мора запамтити. Власничка решења делимично заобилазе овај проблем откривањем СЦТЕ-35 ознака (ако их дода генератор тока).
У погледу праћења квалитета транспорта, постоји недостатак праћења џитера (ИАТ). ТВ опрема (било да се ради о модулаторима или крајњим уређајима) има захтеве за овај параметар и није увек могуће надувати јитбуффер до бесконачности. И подрхтавање може да плута када се опрема са великим баферима користи у транзиту, а КоС није конфигурисан или није довољно добро конфигурисан за пренос таквог саобраћаја у реалном времену.
Извор: ввв.хабр.цом