TSDuck を使用して IP(TS) ストリームを監視する

現在、IP(TS) ストリームを監視するための既製の (独自の) ソリューションが存在します。 VB и iQ、かなり豊富な機能セットがあり、通常、テレビサービスを扱う大手事業者がそのようなソリューションを持っています。 この記事では、オープンソース プロジェクトに基づくソリューションについて説明します TSDアヒル、CC(continuity counter)カウンターとビットレートによるIP(TS)ストリームの最小限の制御のために設計されています。 考えられるアプリケーションは、専用の L2 チャネル (キュー内の損失カウンタを読み取るなど、通常は監視できません) を介してパケットまたはフロー全体の損失を制御することです。

TSDuck について簡単に説明します。

TSDuck は、TS ストリームを操作するためのオープン ソース (2 条項 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。 これらは Debian では利用できませんが、debian 8 および debian 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 Mbps ではなく約 100 Mbps を報告します。私たちは、誰のせいなのかを解明しようとしています。ジェネレーターに時間がないか、問題がそこにないため、固定数の CC エラーの生成を開始します。パケット (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 KB のバッファで作成されますが、それ以上のバッファを要求しても、要求されたものは受信されません。 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 消費量に応じて。 5 コア i4260-1.40U CPU @ 10GHz と比較して、3Mbps フロー解析には 4 ～ 100%、25Mbps - 200%、46Mbps - XNUMX% の CPU が必要です。 % パケット ロスを設定すると、CPU の負荷は実質的に増加しません (ただし、減少する場合があります)。

より生産性の高いハードウェアでは、1Gb/秒を超えるストリームを問題なく生成および分析することができました。

実際のネットワークカードでのテスト

veth ペアでテストした後、XNUMX つのホストまたは XNUMX つのホストの XNUMX つのポートを取得し、ポートを相互に接続し、XNUMX つでジェネレーターを開始し、XNUMX つ目でアナライザーを開始する必要があります。 ここには驚きはありませんでしたが、実際にはすべてが鉄に依存し、弱ければ弱いほど、ここではより興味深いものになります。

受信データを監視システム（Zabbix）で利用する

tsp には、SNMP などの機械可読 API がありません。 CC メッセージは少なくとも 1 秒間集約する必要があります (パケット損失の割合が高い場合、ビットレートに応じて XNUMX 秒あたり数百、数千、数万になる可能性があります)。

したがって、両方の情報を保存し、CC エラーとビットレートのグラフを描画して何らかの事故を起こすには、次のオプションがあります。

1. tsp の出力を解析して (CC によって) 集約します。 それを目的の形式に変換します。
2. 結果が監視システムに適した機械可読形式で与えられるように、tsp 自体および/またはプロセッサ プラグイン bitrate_monitor と継続性を終了します。
3. tsduck ライブラリの上にアプリケーションを作成します。

明らかに、特に tsduck 自体が (最新の標準による) 低レベル言語 (C ++) で書かれていることを考慮すると、オプション 1 が労力の点で最も簡単です。

シンプルな 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 ジョブは別個のプロセスであり、副作用 (毎秒届くビットレート メッセージを受信するとき) に 4 秒に 5 回 missingPackets の値を書き込む必要がありました。 その結果、bash はそのまま残され、golang でラッパー (パーサー + アグリゲーター) を書くことになりました。 同様の golang コードの CPU 消費量は、tsp プロセス自体の 16 ～ 25 分の XNUMX です。 bash を golang に置き換えたことによるラッパーの高速化は約 XNUMX 倍であることが判明し、一般的には許容可能な結果でした (最悪の場合、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 の「損失」が発生する可能性があります (私の知る限り、これはロシア連邦のローカル TV センターで挿入が行われる方法です。つまり、CC カウンタを再計算せずに行われます)。これは覚えておく必要があります。 独自のソリューションは、SCTE-35 ラベル (ストリーム ジェネレーターによって追加された場合) を検出することで、この問題を部分的に回避します。

トランスポート品質のモニタリングに関しては、ジッター モニタリング (IAT) が不足しています。 TV 機器 (変調器またはエンドデバイス) にはこのパラメータの要件があり、ジットバッファを無限に拡張できるとは限りません。 また、大きなバッファを備えた機器が転送中に使用され、QoS が設定されていない、またはそのようなリアルタイム トラフィックを送信するのに十分な設定がされていない場合、ジッタが浮遊する可能性があります。

出所： habr.com