監視のためにFlussonicのイベントを操作する
ユーザーからよく聞かれます：ストリームがドロップしたときにFlussonicがメッセージを送信する方法。
ボアをオンにすると、転倒が何であるかが明確でないことをつぶやくことができます ストリームのビットレートがゼロ以外であり、フレームがオンであり、ホワイトノイズまたは黒い画面があるため、多くの質問があります。 ストリームは機能しているようですが、本質的には機能していません。 ただし、新しいイベントシステムを使用して、元の問題の解決策を検討してください。
最も簡単なオプションは単純ですが、動作します。 ストリーマー構成で、以下を追加します。
notify no_video { sink /etc/flussonic/no_video.lua; }
/etc/flussonic/no_video.luaファイルに
/etc/flussonic/no_video.luaように記述します。
for k,event in pairs(events) do -- , if event.event == "source_lost" or event.event == "stream_stopped" then -- , mail.send({from = "flussonic@streamer1.mycdn", to = "marketing@team.mycdn", subject = "Source lost", body = "source lost on "..event.media}) -- end end
予備ろ過
本番環境でこのようなコードを実行すると、多くの文字を消去する必要があるため、ここに個人的なメールを入れないことが重要です。
ビデオストリーマの内部では、膨大な数のイベントが常に生成されます。各オープン/クローズセッション、アーカイブに記録された各フラグメントなどに対して、configで事前フィルタリングを使用してこのコードの最適化を始めましょう。
notify no_video { sink /etc/flussonic/no_video.lua; only event=source_lost,source_ready,stream_stopped; }
ハンドラーではなくイベントを送信するコードでフィルター処理が行われるため、これは重要です。その結果、マルチコアマシンでは非常に重要な、1つのコアをロードせずにコードを冷却できます。
構成
書かれたばかりのluaスクリプトは確かに人気があります。さらに、あるグループでは1つのグループのスレッドに、他のスレッドでは別のグループに手紙を送信することができます。 スクリプトを1回作成すると、fluxonic configでその設定を保持できます。
notify no_video { sink /etc/flussonic/no_video.lua; only event=source_lost,source_ready,stream_stopped; to marketing@team.mycdn; from flussonic@streamer1.mycdn; }
スクリプトでは、
argsパラメーターを使用します。
for k,event in pairs(events) do if event.event == "source_lost" or event.event == "stream_stopped" then mail.send({from = args.from, to = args.to, subject = "Source lost", body = "source lost on "..event.media}) end end
このスクリプトを少し調整して、大量に送信するのではなく、1通の手紙を送信します。問題が次の場合にのみ：
local body = "" local count = 0 for k,event in pairs(events) do if event.event == "source_lost" or event.event == "stream_stopped" then count = count + 1 body = body.." "..event.media.."\n" end end if count > 0 then mail.send({from = args.from, to = args.to, subject = "Source lost", body = "source lost on: \n"..body}) end
デバウンス
私たちが持っているスクリプトは完璧とはほど遠いものであり、ユーザーカメラの束など、ライブの少ないプロダクションですぐに明らかになります。
電子メールのトラフィックを減らし、電子メールをより便利にする方法を見つけましょう。 ストリームの落下に関するメッセージを受信した後、すぐに手紙を送信するのではなく、30秒待って他の誰が落ちたかを収集します。
これを行うには、Flussonicのイベントハンドラーに組み込みのタイマーメカニズムを使用します。 実際、Flussonicはリクエスト間でハンドラーの状態を保存し、1つのスレッドでこの状態でハンドラーを順番に起動します。
これに注意してください：バッファにすべてすべてのイベントを蓄積すると、サーバーをドロップできます。
秋の最初のイベントが到着するとすぐに、タイマーを設定し、期限が切れるまで何も送信しません。 この時間の間に、落ちたフローに関する情報を蓄積してから、すべてを一度に送信します。
if not new_dead_streams then new_dead_streams = {} end local some_stream_died = false for k,evt in pairs(events) do if evt.event == "stream_stopped" or evt.event == "source_lost" then new_dead_streams[evt.media] = true some_stream_died = true end end if not notify_timer and some_stream_died then notify_timer = flussonic.timer(30000, "handle_timer", "go") end function handle_timer(arg) local body = "Local time "..flussonic.now().."\n" for name,flag in pairs(new_dead_streams) do body = body.." "..name.."\n" end new_dead_streams = {} mail.send({from = args.from, to = args.to, subject = "Source lost", body = body}) end
最初のパラメーターである
flussonic.timer関数
flussonic.timer関数がミリ秒単位で呼び出された時間、関数名、引数の順にかかります。
ローカルで宣言されたテーブルの受け渡しは失敗するため、これに注意してください：数値または文字列を送信するか、グローバル変数を使用します。
メールで地獄に行こう
スラックのチャンネルにプッシュするようにメーリングリストを変更しましょう。
https://YOURTEAM.slack.com/apps/manage/custom-integrationsする必要があり
https://YOURTEAM.slack.com/apps/manage/custom-integrations 。そこから着信Webhookに移動します
そこで、フォームのURLを取得します。
https://hooks.slack.com/services/NB8hv62/ERBAdLVT/VW9teYkRPMp2NMbU
mail.sendを次のように変更します。
message = {text= body, username= "flussonic" } http.post(args.slack_url, {["content-type"] = "application/json"}, json.encode(message))
構成を変更します。
notify no_video { sink /etc/flussonic/no_video.lua; only event=source_lost,source_ready,stream_stopped; slack_url https://hooks.slack.com/services/NB8hv62/ERBAdLVT/VW9teYkRPMp2NMbU; }
なぜ引数が必要なのですか？
スクリプトを修正できるのに、なぜいくつかのパラメータをスクリプトに渡すのでしょうか？
まず、Linuxを初めて見たユーザーでも、定期的にヘルプを参照してくれるユーザーがいるため、luaスクリプトを編集するのは考えられないタスクです。 。
次に、同じスクリプトを異なるストリームの異なるパラメーターで使用できます。 ここでは、経験豊富なユーザーが、スクリプト自体の派手な条件ではなく、構成を介して引数を渡すのが既にはるかに簡単です。
ボンネットの下には何がありますか？
Flussonicでは、イベントシステムはほぼ2012年以来長い間使用されてきましたが、以前の実装は公然と柔軟でした。 stdlibのモジュール名に基づいて、
gen_eventモジュールがこのメカニズムを実装するために選択されました。
gen_event 、決して
gen_event使用しないで
gen_event 。それはどこにも必要ありません。 最も重要な理由の1つ：何らかの理由でハンドラーがgen_eventでクラッシュした場合、サイレントに（またはログにわずかな呪いを伴って）サイレントに削除され、再起動は行われません。
イベント処理の内部構造を変更しました。 configに記述されている各ハンドラーは個別の
gen_serverで起動され、クラッシュした場合に再起動されます。 そのような各プロセスでは、ハンドラーは各メッセージを試行して、パック内で既に完了したイベントの最大数（制限を超えない、約1000）を収集し、それらをまとめてハンドラーに渡します。 このアプローチにより、HTTPを介した送信またはファイルへの書き込みのオーバーヘッドが削減されます。
この変更により、イベントのフィルタリングを送信プロセスに転送できるようになりました。したがって、サーバーに1000のストリームがあり、3つだけを監視する必要がある場合、1つのコアではなく、48かすべてのコアがフィルタリングされます。 これは、システムのスケーラビリティにとって不可欠なポイントです。
微妙ですが重要なニュアンスは、イベントハンドラーが過負荷を監視し、原則としてイベントをリセットすることさえできることです。 事態が非常に悪い場合、fluxonikはイベントをキューに無限に蓄積するのではなく、それらを破棄し始めます。 このような場合、受信プロセスのメッセージキューの長さを埋めることができないため、輻輳のチェックは非常に簡単です。したがって、独自の活性のイベントを送信するプロセスによる独立したチェックによってこれを行います。
おわりに
この記事では、次の方法について少し話しました。
＃LuaのFlussonicでイベントハンドラーを作成する
mail.sendからメールを送信：
mail.send ＃json本文でHTTPリクエストを作成：
http.postおよび
json.encode ＃タイマーを使用：
flussonic.timer