TSDuck을 사용하여 IP(TS) 스트림 모니터링

현재 IP(TS) 스트림 모니터링을 위한 기성품(독점) 솔루션이 있습니다. 예를 들어 VB и iQ, 그들은 상당히 풍부한 기능 세트를 가지고 있으며 일반적으로 TV 서비스를 다루는 대형 사업자는 그러한 솔루션을 가지고 있습니다. 이 문서에서는 오픈 소스 프로젝트를 기반으로 하는 솔루션에 대해 설명합니다. TSDuck, CC(연속 카운터) 카운터 및 비트레이트에 의한 IP(TS) 스트림의 최소 제어를 위해 설계되었습니다. 가능한 응용 프로그램은 임대된 L2 채널(예를 들어 대기열에서 손실 카운터를 읽어 정상적으로 모니터링할 수 없음)을 통해 패킷 손실 또는 전체 흐름을 제어하는 ​​것입니다.

TSDuck에 대해 아주 간단히

TSDuck은 TS 스트림 조작을 위한 오픈 소스(2-Clause BSD 라이선스) 소프트웨어(콘솔 유틸리티 세트 및 맞춤형 유틸리티 또는 플러그인 개발용 라이브러리)입니다. 입력으로 IP(멀티캐스트/유니캐스트), http, hls, dvb 튜너, dektec dvb-asi 복조기와 함께 작동할 수 있으며 내부 TS 스트림 생성기가 있고 파일에서 읽습니다. 출력은 파일, IP(멀티캐스트/유니캐스트), hls, dektec dvb-asi 및 HiDes 변조기, 플레이어(mplayer, vlc, xine) 및 드롭에 쓸 수 있습니다. 예를 들어, PID 리매핑, 스크램블링/디스크램블링, CC 카운터 분석, 비트레이트 계산 및 TS 스트림에 대한 기타 일반적인 작업과 같은 다양한 트래픽 프로세서가 입력과 출력 사이에 포함될 수 있습니다.

이 기사에서는 IP 스트림(멀티캐스트)이 입력으로 사용되고 bitrate_monitor 프로세서(이름에서 명확함) 및 연속성(CC 카운터 분석)이 사용됩니다. IP 멀티캐스트를 TSDuck에서 지원하는 다른 입력 유형으로 쉽게 대체할 수 있습니다.

있다 공식 빌드/패키지 대부분의 최신 운영 체제용 TSDuck. 데비안에서는 사용할 수 없지만 데비안 8과 데비안 10에서 아무 문제 없이 빌드할 수 있었습니다.

다음으로 TSDuck 3.19-1520 버전 사용, OS는 Linux 사용 (솔루션 준비는 debian 10 사용, 실사용은 CentOS 7 사용)

TSDuck 및 OS 준비

실제 흐름을 모니터링하기 전에 TSDuck이 올바르게 작동하고 네트워크 카드 또는 OS(소켓) 수준에서 드롭이 없는지 확인해야 합니다. 네트워크 또는 "서버 내부"에서 드롭이 발생한 위치를 나중에 추측하지 않으려면 필요합니다. ethtool -S ethX 명령을 사용하여 네트워크 카드 수준에서 드롭을 확인할 수 있습니다. 튜닝은 동일한 ethtool에서 수행됩니다(일반적으로 RX 버퍼(-G)를 늘리고 때로는 일부 오프로드(-K)를 비활성화해야 함). 일반적으로 분석된 트래픽을 수신하기 위해 별도의 포트를 사용하는 것이 좋습니다. 가능하면 다른 트래픽의 존재로 인해 분석기 포트에서 드롭이 정확히 발생했다는 사실과 관련된 오 탐지를 최소화합니다. 이것이 가능하지 않은 경우(XNUMX개의 포트가 있는 미니 컴퓨터/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 대신 약 100Mbps를 보고합니다. 우리는 누가 책임을 져야 하는지 파악하려고 노력하고 있습니다. 생성기에 시간이 없거나 문제가 없기 때문에 고정된 수의 생성을 시작합니다. 패킷(TS 패킷 700000개 = IP 패킷 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개의 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

따라서 응용 프로그램이 명시적으로 버퍼 크기를 요청하지 않으면 208KB의 버퍼로 소켓이 생성되지만 더 많이 요청해도 여전히 요청된 것을 받지 못합니다. IP 입력(-buffer-size)에 대해 tsp에서 버퍼 크기를 설정할 수 있으므로 기본 소켓 크기를 건드리지 않고 최대 소켓 버퍼 크기만 설정하고 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%가 필요합니다. % Packet Loss를 설정하면 CPU의 부하가 실질적으로 증가하지 않습니다(감소할 수 있음).

보다 생산적인 하드웨어에서는 문제 없이 1Gb/s 이상의 스트림을 생성하고 분석할 수 있었습니다.

실제 네트워크 카드에서 테스트

veth 쌍에서 테스트한 후 두 개의 호스트 또는 한 호스트의 두 포트를 가져와 포트를 서로 연결하고 하나에서 생성기를 시작하고 두 번째에서 분석기를 시작해야 합니다. 여기에는 놀라움이 없었지만 실제로 모든 것은 철에 달려 있으며 약할수록 여기에 더 흥미로울 것입니다.

모니터링 시스템(Zabbix)에서 수신한 데이터 사용

tsp에는 SNMP 또는 이와 유사한 기계 판독 가능 API가 없습니다. CC 메시지는 최소 1초 동안 집계되어야 합니다(패킷 손실 비율이 높으면 비트 전송률에 따라 초당 수백/수천/수만 개가 발생할 수 있음).

따라서 정보를 저장하고 CC 오류 및 비트 전송률에 대한 그래프를 그리고 어떤 종류의 사고를 일으키기 위해 다음 옵션이 있을 수 있습니다.

1. tsp의 출력을 구문 분석하고 집계합니다(CC에 의해). 원하는 형태로 변환합니다.
2. 결과가 모니터링 시스템에 적합한 기계 판독 가능 형식으로 제공되도록 tsp 자체 및/또는 프로세서 플러그인 bitrate_monitor 및 연속성을 완료합니다.
3. 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의 값을 4초에 한 번 작성해야 했습니다. 결과적으로 bash는 그대로 두고 golang에 wrapper(parser + aggregator)를 작성하기로 했습니다. 유사한 golang 코드의 CPU 소비는 tsp 프로세스 자체보다 5-16배 적습니다. bash를 golang으로 교체한 결과 wrapper의 속도 향상은 약 25배로 밝혀졌으며 일반적으로 결과는 수용 가능합니다(최악의 경우 CPU 오버헤드 XNUMX% 증가). golang 소스 파일이 있습니다. 여기에.

래퍼 실행

래퍼를 시작하기 위해 systemd에 대한 가장 간단한 서비스 템플릿을 만들었습니다(여기에). 래퍼 자체는 /opt/tsduck-stat/에 있는 바이너리 파일(go build tsduck-stat.go)로 컴파일되어야 합니다. 단조 시계(>=1.9)를 지원하는 golang을 사용하고 있다고 가정합니다.

서비스 인스턴스를 생성하려면 systemctl enable 명령을 실행해야 합니다. [이메일 보호]:1234 그런 다음 systemctl start로 실행 [이메일 보호]: 1234.

Zabbix에서 발견

zabbix가 실행 중인 서비스를 검색할 수 있도록 하기 위해 그룹 목록 생성기 (discovery.sh)는 Zabbix 검색에 필요한 형식으로 동일한 위치인 /opt/tsduck-stat에 있다고 가정합니다. zabbix-agent를 통해 검색을 실행하려면 다음을 추가해야 합니다. .conf 파일 zabbix-agent 구성 디렉토리에 사용자 매개변수를 추가합니다.

Zabbix 템플릿

생성된 템플릿 (tsduck_stat_template.xml)에는 자동 검색 규칙, 항목 프로토타입, 그래프 및 트리거가 포함되어 있습니다.

간략한 체크리스트(누군가 사용하기로 결정하면 어떻게 됩니까?)

1. tsp가 "이상적인" 조건(제너레이터와 분석기가 직접 연결됨)에서 패킷을 드롭하지 않는지 확인하십시오. 드롭이 있는 경우 단락 2 또는 이 문제에 대한 기사 텍스트를 참조하십시오.
2. 최대 소켓 버퍼를 조정합니다(net.core.rmem_max=8388608).
3. tsduck-stat.go를 컴파일합니다(tsduck-stat.go 빌드).
4. 서비스 템플릿을 /lib/systemd/system에 넣습니다.
5. systemctl로 서비스를 시작하고 카운터가 나타나기 시작했는지 확인합니다(grep "" /dev/shm/tsduck-stat/*). 멀티캐스트 스트림 수에 따른 서비스 수입니다. 여기에서 멀티캐스트 그룹에 대한 경로를 생성해야 할 수 있습니다. 아마도 rp_filter를 비활성화하거나 소스 IP에 대한 경로를 생성할 수 있습니다.
6. discovery.sh를 실행하고 json을 생성하는지 확인하십시오.
7. zabbix 에이전트 구성을 추가하고 zabbix 에이전트를 다시 시작하십시오.
8. 템플릿을 zabbix에 업로드하고 모니터링 중인 호스트와 zabbix-agent가 설치된 호스트에 적용하고 약 5분 정도 기다린 후 새 항목, 그래프 및 트리거가 있는지 확인합니다.

결과

패킷 손실을 감지하는 작업에는 거의 충분하며 적어도 모니터링하지 않는 것보다 낫습니다.

실제로 비디오 조각을 병합할 때 CC "손실"이 발생할 수 있습니다. 독점 솔루션은 SCTE-35 레이블(스트림 생성기에 의해 추가된 경우)을 감지하여 이 문제를 부분적으로 우회합니다.

전송 품질 모니터링 측면에서 지터 모니터링(IAT)이 부족합니다. TV 장비(변조기 또는 최종 장치)에는 이 매개변수에 대한 요구 사항이 있으며 jitbuffer를 무한대로 확장하는 것이 항상 가능한 것은 아닙니다. 그리고 큰 버퍼가 있는 장비가 전송 중에 사용되고 QoS가 구성되지 않았거나 이러한 실시간 트래픽을 전송할 수 있을 만큼 충분히 구성되지 않은 경우 지터가 떠오를 수 있습니다.

출처 : habr.com