MediaLiveをCloudWatchで監視する

August 21, 2018

背景

MediaLive ですが、いろいろなエラーを通知してくれます。

やれ「RTMP 接続が切れたよ」とか「オーディオ入力 or ビデオ入力が無いよ」とかですね。通常、ライブ配信が始まる前は当然、MediaLive への入力は無いはずなので、通知は構わないのですが、ライブ配信中に出ると、それはもうトラブルシューティングの情報の一つとして重要なものになります。 ( というか当初、エラーは出てるっぽいし、挙動はおかしいんだけど、どんなエラーが出てるか分からないケースがあって窮地な時がありました )

今は管理画面の[ channels ]->[ 目的のチャンネル ]->[ Alerts ]から確認できます。が、ログとして残しておくのは良い事だと思います。このエラー出力のフォーマットは決まっている訳ではなく、たまに変わります。ので『あー、エラー出力が変わったからアラートが上がらなくなったのね』、という事がログを残しておくと分かります。

手順

WebUI

SNS のページ( https://ap-northeast-1.console.aws.amazon.com/sns/ )を開く
[ トピック ]->[ 新しいトピックの作成 ]->トピック名の入力、私は[ MediaLiveEvent ]、表示名[ MediaLiveEvent ]と入れてみた
作成したトピックの ARN をコピペ arn:aws:sns:ap-northeast-1:1111111111111:MediaLiveEvent
( 同じ SNS 内の左側メニュー )[ サブスクリプション ]->[ サブスクリプションの作成 ]
[ トピック ARN ]に先程作成した MediaLive のトピックの ARN を入力
プロトコルメール(ほかにも lambda とかから Slack に送信できたりする)
エンドポイント : 自分のメールアドレス

はじめてのアラートメール設定の場合、AWS から確認のメールが飛ぶ

[ AWS Notification - Subscription Confirmation ]という件名のメールがあったらメール本文内のリンクをクリック

CloudWatch

cloudwatch のページに移動*
[ イベント ]->[ ルールの作成 ]
[ イベントパターン ]になってること
[ カスタムイベントパターン ]に変更カスタムイベントパターンの内容としては下記を入力

{
  "source": [
    "aws.medialive"
  ]
}

右側の[ ターゲットの追加 ]->[ SNS トピック ]に変更->[ トピック ]はプルダウンメニューから先程、作成した SNS のトピックを選択
[ 設定の詳細 ]
ルールの定義
名前: 任意
説明: 任意
[ ルールの作成 ]
メールボックスを確認

CLI

参考: SNS をコマンドラインから設定する : 電子の密林を開拓する

CLI での SNS トピックの作成は

$ sns create-topic --name mediaLiveEvent

SNSでのサブスクリプションの作成

$ aws sns subscribe --topic-arn "arn:aws:sns:ap-northeast-1:11111111111111111:mediaLiveEvent" --protocol email --notification-endpoint "hoge@example.com"

—notification-endpoint に登録したメールアドレスに飛んだメールのリンクをクリックする

CloudWatch eventsの設定

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/RunLambdaSchedule.html#schedule-create-rule

ルール作成

$ aws events put-rule --name "mediaLiveEvent" --event-pattern (jo source=(jo -a aws.medialive))

CloudWatch ルールのターゲットを指定

aws events put-targets --rule my-scheduled-rule --targets file://targets.json
aws events put-targets --rule mediaLiveEvent --targets (jo -a (jo -- -s Id=1 -s Arn=arn:aws:sns:ap-northeast-1:139332511982:mediaLiveEvent))

ポーリングかイベントドリブンか

よく監視だと「5分ごとのポーリング」などの形が多いじゃないですか、負荷監視とか。私もそういう認識だったんですが、 MediaLiveの監視って、ポーリングみたいな考え方だと、どうにもならなくね?(CloudWatchのEventでcron式書く? 監視方法検討、lambdaで実装?と考えてみて) CloudWatchの仕組みにのった方がシンプルになりそう、という訳で、やってみました。最初はアラート通知とかだったんですが、 5分単位のポーリングよりイベント・ドリブンでアラートが通知されるので、こちらの方が好きになりました。

更にいうとRTMPの再接続があった場合、念の為、CloudFrontのキャッシュを削除するようにしています。 (これは前のライブのキャッシュがCloudFrontに残っており、万が一ですが、ライブのチャンクデータで「昔のチャンクを参照してしまう」みたいなトラブルを避けたいための運用です。 MediaLive + MediaStore構成ならMediaStoreが非常に高速なので不要かもしれません) この自動化ができました。CloudFrontからチャンクの削除を自動ででき、漏れなくできる。

Cloudwatch カスタムイベントパターンバリエーション

その1 RTMP接続が無くなった場合

ライブ中にRTMP接続がなくなるとやばいよ、何かしないとマズいよね、lambdaで関数つくって呼び出そう

{
  "source": [
    "aws.medialive"
  ],
  "detail": {
    "alarm_state": [
      "SET"
    ],
    "message": [
      "Waiting for RTMP input"
    ]
  }
}

その2 RTMP接続が来たよ

何かRTMP接続された時にする処理をlambdaで作って呼び出せるよ

{
  "source": [
    "aws.medialive"
  ],
  "detail": {
    "alarm_state": [
      "CLEARED"
    ],
    "message": [
      "Waiting for RTMP input"
    ]
  }
}

背景

手順