Өнөөдөр жишээ нь IP(TS) урсгалыг хянах бэлэн (өмчийн) шийдлүүд байдаг и , тэдгээр нь нэлээд баялаг функцтэй бөгөөд ихэвчлэн телевизийн үйлчилгээ эрхэлдэг томоохон операторууд ийм шийдлүүдтэй байдаг. Энэ нийтлэлд нээлттэй эхийн төсөл дээр суурилсан шийдлийг тайлбарласан болно , CC(тасралтгүй байдлын тоолуур) тоолуур болон битийн хурдаар IP(TS) урсгалыг хамгийн бага хянах зориулалттай. Боломжит хэрэглээ бол түрээсийн L2 сувгаар пакетуудын алдагдлыг эсвэл бүхэлд нь урсгалыг хянах явдал юм (жишээлбэл, дараалал дахь алдагдлыг тоологч унших замаар үүнийг хянах боломжгүй).
TSDuck-ийн талаар маш товчхон
TSDuck нь TS урсгалыг удирдахад зориулагдсан нээлттэй эхийн (2-р бүлэг BSD лиценз) програм хангамж юм (консолын хэрэгслүүдийн багц ба тусгай хэрэгсэл эсвэл залгаасуудыг хөгжүүлэх номын сан). Оролтын хувьд IP (multicast/unicast), http, hls, dvb тааруулагч, dektec dvb-asi демодулятортой ажиллах боломжтой, дотоод TS урсгал үүсгэгч, файлаас унших боломжтой. Гаралт нь файл, IP (multicast/unicast), hls, dektec dvb-asi болон HiDes модулятор, тоглуулагч (mplayer, vlc, xine) болон уналтад бичих боломжтой. Оролт ба гаралтын хооронд янз бүрийн траффик процессоруудыг оруулж болно, жишээлбэл, PID дахин зураглал, скрамлинг / задлах, CC тоолуурын шинжилгээ, битийн хурдыг тооцоолох болон TS урсгалын бусад ердийн үйлдлүүд.
Энэ нийтлэлд IP урсгалыг (олон дамжуулалт) оролт болгон ашиглах бөгөөд bitrate_monitor процессорууд (нэрнээс нь харахад энэ нь юу болох нь тодорхой) болон тасралтгүй байдал (CC тоолуурын дүн шинжилгээ) ашиглагддаг. Та IP multicast-ыг TSDuck-ийн дэмждэг өөр оролтын төрлөөр хялбархан сольж болно.
Боломжтой Одоогийн ихэнх үйлдлийн системд зориулсан TSDuck. Тэдгээрийг Debian-д ашиглах боломжгүй, гэхдээ бид тэдгээрийг debian 8 болон debian 10-ийн доор ямар ч асуудалгүйгээр бүтээж чадсан.
Дараа нь TSDuck 3.19-1520 хувилбарыг ашиглаж, үйлдлийн систем болгон Linux ашигладаг (шийдэл бэлтгэхэд debian 10, бодит хэрэглээнд CentOS 7 ашигласан)
TSDuck болон үйлдлийн системийг бэлтгэж байна
Бодит урсгалыг хянахын өмнө та TSDuck зөв ажиллаж, сүлжээний карт эсвэл үйлдлийн систем (сокет) түвшинд уналт байхгүй эсэхийг шалгах хэрэгтэй. Сүлжээнд эсвэл "сервер дотор" уналт хаана болсныг тааварлахгүйн тулд үүнийг хийх шаардлагатай. Та 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" нь секунд тутамд битийн хурдыг тооцоолж, секунд тутамд битийн хурдны мэдээллийг харуулах шаардлагатай гэсэн үг юм.
Бид 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) генераторын битийн хурдыг 100Mbps хүртэл нэмэгдүүлэхийг оролдоно уу. Анализатор нь олон тооны CC алдааг мэдээлдэг бөгөөд 75-ийн оронд 100 Mbps-ийн хурдтай байдаг. Бид хэн буруутайг олохыг оролдож байна - генератор цаг байхгүй эсвэл асуудал үүнд ороогүй байна, үүний тулд бид тогтмол тоо үүсгэж эхэлдэг. пакетууд (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). Ингээд анализаторт юу болж байгааг олж мэдье, үүний тулд 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. 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 КБ буфер бүхий сокетууд үүсгэгддэг боловч хэрэв тэд илүү ихийг хүсэх юм бол тэд хүссэн зүйлийг хүлээж авахгүй хэвээр байх болно. Та IP оролтод зориулж буферийн хэмжээг tsp-д тохируулах боломжтой тул (-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Сокет буферийн тохиргоог хийснээр одоо мэдээлэгдсэн битийн хурд ойролцоогоор 100Mbps байна, CC алдаа байхгүй.
tsp програмын CPU-ийн хэрэглээний дагуу. Нэг цөмт i5-4260U CPU @ 1.40GHz-тэй харьцуулахад 10Mbps урсгалын шинжилгээ хийхэд 3-4% CPU, 100Mbps - 25%, 200Mbps - 46% шаардагдана. Пакет алдагдлыг% тохируулах үед CPU-ийн ачаалал бараг нэмэгддэггүй (гэхдээ буурч магадгүй).
Илүү бүтээмжтэй техник хангамж дээр 1 Гб / с-ээс дээш урсгалыг ямар ч асуудалгүйгээр үүсгэж, дүн шинжилгээ хийх боломжтой болсон.
Бодит сүлжээний картууд дээр туршилт хийж байна
Veth pair дээр туршилт хийсний дараа та хоёр хост эсвэл нэг хостын хоёр портыг авч, портуудыг хооронд нь холбож, генераторыг нэг дээр, анализаторыг хоёр дахь дээр нь эхлүүлэх хэрэгтэй. Энд гэнэтийн зүйл тохиолдсонгүй, гэхдээ үнэндээ бүх зүйл төмрөөс хамаарна, сул дорой байх тусмаа энд илүү сонирхолтой байх болно.
Хяналтын системээр хүлээн авсан өгөгдлийг ашиглах (Zabbix)
tsp-д SNMP эсвэл үүнтэй төстэй ямар ч машин уншдаг API байхгүй. CC мессежийг дор хаяж 1 секундын турш нэгтгэх ёстой (пакет алдагдлын өндөр хувьтай, битийн хурдаас хамааран секундэд хэдэн зуу/мянган/ арван мянга байж болно).
Тиймээс мэдээллийг хоёуланг нь хадгалах, CC алдаа, битийн хурдыг график зурах, зарим төрлийн осол гаргахын тулд дараах сонголтууд байж болно.
- tsp-ийн гаралтыг задлан шинжилж, нэгтгэх (CC-ээр), i.e. үүнийг хүссэн хэлбэрт шилжүүлнэ.
- tsp өөрөө болон/эсвэл процессорын залгаасууд bitrate_monitor болон тасралтгүй байдлыг дуусгаснаар үр дүнг хяналтын системд тохирох машинд уншигдахуйц хэлбэрээр өгөх болно.
- Өргөдлөө tsduck номын сангийн дээд талд бичээрэй.
Мэдээжийн хэрэг, 1-р сонголт нь хүчин чармайлтын хувьд хамгийн хялбар бөгөөд ялангуяа tsduck нь өөрөө бага түвшний (орчин үеийн стандартаар) хэлээр (C ++) бичигдсэн байдаг.
Энгийн bash задлагч+агрегаторын прототип нь 10Mbps урсгал болон 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 ганцаараа үлдэж, голанг хэл дээр боодол (parser + агрегатор) бичихээр шийдсэн. Үүнтэй төстэй голанг кодын CPU-ийн хэрэглээ нь tsp процессоос 4-5 дахин бага байдаг. Bash-ийг голангаар сольсны улмаас боодлын хурд 16 дахин их болсон бөгөөд ерөнхийдөө үр дүн нь хүлээн зөвшөөрөгдөхүйц байна (хамгийн муу тохиолдолд CPU-ийн ачаалал 25%). Голанг эх файл байрладаг .
Боодол ажиллуулна уу
Боодлыг эхлүүлэхийн тулд systemd-д зориулсан хамгийн энгийн үйлчилгээний загварыг хийсэн (). Боодол нь өөрөө /opt/tsduck-stat/ дотор байрлах хоёртын файлд (go build tsduck-stat.go) эмхэтгэгдэх ёстой. Та монотон цагийг дэмждэг голанг ашиглаж байна гэж таамаглаж байна (>=1.9).
Үйлчилгээний жишээг үүсгэхийн тулд та systemctl enable командыг ажиллуулах хэрэгтэй [имэйлээр хамгаалагдсан]:1234 дараа нь systemctl start-оор ажиллуулна [имэйлээр хамгаалагдсан]: 1234.
Zabbix-ийн нээлт
Zabbix ажиллаж байгаа үйлчилгээг олж мэдэхийн тулд үүнийг хийсэн (discovery.sh), Zabbix-ийн нээлтэд шаардлагатай форматаар энэ нь нэг газар байрладаг гэж үздэг - /opt/tsduck-stat. zabbix-agent-ээр дамжуулан нээлтийг ажиллуулахын тулд та нэмэх хэрэгтэй zabbix-agent тохиргооны лавлах руу хэрэглэгчийн параметрийг нэмнэ үү.
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-агент суулгасан хост дээр хэрэглэж, 5 минут хүлээгээд шинэ зүйл, график, триггер байгаа эсэхийг харна уу.
үр дүн
Пакет алдагдлыг илрүүлэх даалгаврын хувьд энэ нь бараг л хангалттай, ядаж хяналтгүй байснаас дээр юм.
Үнэн хэрэгтээ, видеоны хэсгүүдийг нэгтгэх үед CC "алдагдал" гарч болзошгүй (миний мэдэж байгаагаар ОХУ-ын орон нутгийн телевизийн төвүүдэд оруулга ийм байдлаар хийгддэг, өөрөөр хэлбэл CC тоолуурыг дахин тооцоолохгүйгээр) үүнийг санах хэрэгтэй. Өмчлөлийн шийдлүүд нь SCTE-35 шошгыг (хэрэв урсгал үүсгэгч нэмсэн бол) илрүүлэх замаар энэ асуудлыг хэсэгчлэн тойрон гардаг.
Тээврийн чанарын мониторингийн хувьд jitter monitoring (IAT) дутагдалтай байна. Телевизийн төхөөрөмж (модулятор эсвэл төгсгөлийн төхөөрөмж ч бай) энэ параметрт тавигдах шаардлагуудтай бөгөөд jitbuffer-ийг хязгааргүй хүртэл шахах нь үргэлж боломжгүй байдаг. Том буфер бүхий тоног төхөөрөмжийг дамжин өнгөрөхөд ашиглаж, QoS нь ийм бодит цагийн урсгалыг дамжуулахад хангалттай тохируулагдаагүй эсвэл сайн тохируулагдаагүй үед чичиргээ хөвж болно.
Эх сурвалж: www.habr.com