CloudWatchアラームでAmazon Connectを監視・通知する

📅 2020-04-18

先日Amazon ConnectのCloudWatchメトリクスの記事を書きましたが、今回はそのメトリクス+CloudWatchアラームを利用して監視・通知の設定をしていきたいと思います。

AWS上で運用を行う場合、CloudWatchでの監視は必須項目です。同時通話数が設定値を超えてしまった場合や、問い合わせフロー内でエラーが起きてしまった場合にすぐに対応できるというメリットもありますし、不在着信（missed call）や長時間キューで待機が発生した際にすぐに現場のパフォーマンス改善指示を出せるといった現場レベルのパフォーマンス監視もすることができます。

コンソール上でのCloudWatchアラームの注意点

CloudWatchアラームは前述したように必ず設定すべきなのですが、ちょっとした罠があります。それは、AWSコンソール上からはメトリクスデータがあるものしか登録できないというこです。

どういうことかというと、CloudWatchメトリクスはAWSがメトリクスデータを送信をした時に初めてコンソール画面にメトリクスデータ一覧に表示されます。コンソール画面からCloudWatchアラームを設定をする場合、すべてのメトリクスから選択できるわけではなく、表示されているメトリクスからしか選択できません。

何が問題かというと、問い合わせフローエラーのメトリクスなどの発生を通知しなければいけないメトリクスを、一度発生するまでアラームに登録できないという点です。

ただしこれはコンソール画面から設定を行う場合の話で、AWS CLIからは登録を行うことができます。以下ではCLIを利用した登録方法を紹介します。

AWS CLIを使ってCloudWatchアラームを登録する

AWS CLIの導入

CLIのバージョンは、2020年2月にリリースしたバージョン2の使用をおすすめします。元々はpythonで動作するCLIツールでしたが、新しいバージョンではインストーラーから簡単にインストールを行うことができます。

AWS CLI バージョン 2 のインストール

使用するCLIコマンド

CloudWatchアラームを設定するコマンドは、put-metric-alarmというコマンドです。

AWS CLI Command Reference put-metric-alarm

アラーム名、メトリクス、条件、アラーム時のアクションなどをパラメーターで指定して登録をします。以下のサンプルコードを使用してみてください。

サンプルコード

CallsBreachingConcurrencyQuota
ConcurrentCalls
ConcurrentCallsPercentage
ThrottledCalls
ContactFlowErrors
ContactFlowFatalErrors

をアラーム登録するスクリプトです。

PROFILEは一つしかない場合は「default」を指定してください。また、SNSのトピックは別途作成をしてARNを指定してください。

#!/bin/bash

PROFILE="AWS CLIのプロファイルを指定"
INSTANCE_ID="Amazon ConnectのインスタンスIDを指定"
TOPIC_ARN="SNSトピックのARNを指定"

# CallsBreachingConcurrencyQuota
# インスタンスの同時通話のクォータを超えた音声通話の総数
aws --profile $PROFILE cloudwatch put-metric-alarm --alarm-name CallsBreachingConcurrencyQuota-Alarm \
    --namespace AWS/Connect \
    --metric-name CallsBreachingConcurrencyQuota \
    --dimensions Name=InstanceId,Value=$INSTANCE_ID \
    --period 300 --statistic Maximum --threshold 0 --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 --alarm-actions $TOPIC_ARN --ok-actions $TOPIC_ARN \
    --treat-missing-data notBreaching

# ConcurrentCalls
# ダッシュボードにデータが表示された時点でのデータが表示された時点でのインスタンス内の同時アクティブ音声通話数
# このメトリクスとして表示される値はダッシュボード表示時点での同時アクティブ通話数で、
# 設定された更新間隔の間隔全体の合計値ではありません。
# エージェントへ接続されたアクティブな通話だけではなく、アクティブな音声通話すべてを含みます。
aws --profile $PROFILE cloudwatch put-metric-alarm --alarm-name ConcurrentCalls-Alarm \
    --namespace AWS/Connect \
    --metric-name ConcurrentCalls \
    --dimensions Name=InstanceId,Value=$INSTANCE_ID Name=MetricGroup,Value=VoiceCalls \
    --period 300 --statistic Maximum --threshold 10 --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 --alarm-actions $TOPIC_ARN --ok-actions $TOPIC_ARN \
    --treat-missing-data notBreaching

# ConcurrentCallsPercentage
# インスタンス内で使用された、同時アクティブ音声通話のサービスのクォータの割合 (%) です。
# ConcurrentCalls/ConfiguredConcurrentCallsLimit * 100
aws --profile $PROFILE cloudwatch put-metric-alarm --alarm-name ConcurrentCallsPercentage-Alarm \
    --namespace AWS/Connect \
    --metric-name ConcurrentCallsPercentage \
    --dimensions Name=InstanceId,Value=$INSTANCE_ID Name=MetricGroup,Value=VoiceCalls \
    --period 300 --statistic Maximum --threshold 100 --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 --alarm-actions $TOPIC_ARN --ok-actions $TOPIC_ARN \
    --treat-missing-data notBreaching

# ThrottledCalls
# 1 秒あたりの呼び出しレートが、サポートされるクォータを超えたためにために拒否された音声呼び出しの数。
aws --profile $PROFILE cloudwatch put-metric-alarm --alarm-name ThrottledCalls-Alarm \
    --namespace AWS/Connect \
    --metric-name ThrottledCalls \
    --dimensions Name=InstanceId,Value=$INSTANCE_ID Name=MetricGroup,Value=VoiceCalls \
    --period 300 --statistic Sum --threshold 0 --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 --alarm-actions $TOPIC_ARN --ok-actions $TOPIC_ARN \
    --treat-missing-data notBreaching

# ContactFlowErrors
# 問い合わせフローに対するエラー分岐が実行された回数です。
# 対象問い合わせフロー: example
aws --profile $PROFILE cloudwatch put-metric-alarm --alarm-name ContactFlowErrors-example-Alarm \
    --namespace AWS/Connect \
    --metric-name ContactFlowErrors \
    --dimensions Name=InstanceId,Value=$INSTANCE_ID Name=MetricGroup,Value=ContactFlow \
    Name=ContactFlowName,Value=example \
    --period 300 --statistic Sum --threshold 0 --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 --alarm-actions $TOPIC_ARN --ok-actions $TOPIC_ARN \
    --treat-missing-data notBreaching

# ContactFlowFatalErrors
# システムエラーが原因で問い合わせフローが実行に失敗した回数です。
# 対象問い合わせフロー: example
aws --profile $PROFILE cloudwatch put-metric-alarm --alarm-name ContactFlowFatalErrors-example-Alarm \
    --namespace AWS/Connect \
    --metric-name ContactFlowFatalErrors \
    --dimensions Name=InstanceId,Value=$INSTANCE_ID Name=MetricGroup,Value=ContactFlow \
    Name=ContactFlowName,Value=example \
    --period 300 --statistic Sum --threshold 0 --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 --alarm-actions $TOPIC_ARN --ok-actions $TOPIC_ARN \
    --treat-missing-data notBreaching

登録してみる

ippeinoMacBook:cloudWatch ippei$ ./put_metrics_alarm.sh
ippeinoMacBook:cloudWatch ippei$

shellが何も表示されずに返ってきたら成功です。CloudWatchアラームの一覧を見てみると以下のように登録されています。

cloudwatch-alarm-list

アラームの条件について

各メトリクスのアラーム条件について解説してきます。

CallsBreachingConcurrencyQuota

このメトリクスは同時通話数のクォータを超えた際に記録されるので、0より大きい値が記録されるとアラームを実行します。アラームが発生した場合は同時通話数のクォータを上限緩和申請しましょう。

ConcurrentCallsとConcurrentCallsPercentage

このメトリクスは上記の同時通話数と関連するもので、運用としてどうするかがポイントになります。同時通話数クォータを余裕を持って設定しているのであればあまり問題はないですが、ギリギリにしている場合は、同時通通話数設定値の8割~9割になった際にアラーム登録をしておくと、上限緩和申請を事前に行う目安になるかと思います。

サンプルコード上ではConcurrentCallsはデフォルトのクォータである10に、ConcurrentCallsPercentageは100%に設定しています。

ThrottledCalls

こちらもCallsBreachingConcurrencyQuotaと同様に、より大きい値記録されるとアラームを実行します。アラームが発生した場合は同時通話数のクォータを上限緩和申請しましょう。

ContactFlowErrorsとContactFlowFatalErrors

これまでこのアラームが発生したことを見たことがないのですが、発生した際にはカスタマーエクスペリエンスに影響を与えているということになるので、原因を探る必要があるでしょう。アラームが発生した時刻の問い合わせフローログを解析するといった流れになるかと思います。

このアラームは問い合わせフローごとにそれぞれアラーム設定を行う必要があります。ディメンションで問い合わせフロー名を指定します。

その他のメトリクスのアラーム設定について

必要に応じてアラームを設定しましょう。Amazon Connect以外のAWSサービスを利用している場合、そちらも合わせてアラーム登録をしましょう！

まとめ

Amazon ConnectのCloudWatchメトリクスのアラーム設定をする方法を紹介しました。画面から登録できないので少し分かりづらいですが、一度スクリプトを作ってしまえば以降は簡単に登録をすることができます。

また、CLIから一度アラームの登録を行えばコンソール画面から条件の編集や削除ができるので、細かい条件は無視して登録だけスクリプトでやってしまうというのもアリだと思います。

アラームの条件設定や発生時のオペレーションに関しては、運用や保守の体制によって変わる部分だと思いますので、あらかじめルールを決めておくと良いでしょう。

← Prev Next →