Azure Monitor を使用して Azure Cosmos DB のアラートを作成する
適用対象: NoSQL
MongoDB
Cassandra
Gremlin
Table
アラートは、Azure Cosmos DB リソースの可用性と応答性を監視するための定期的なテストを設定するために使用されます。 アラートでは、いずれかのメトリックがしきい値に達したとき、またはアクティビティ ログに特定のイベントが記録されたときに、電子メールの形式で通知を送信したり、Azure 関数を実行したりすることができます。
Azure Cosmos DB アカウントのメトリック、アクティビティ ログ イベント、Log Analytics のログに基づいて、アラートを受け取ることができます。
メトリック - このアラートは、指定したメトリックの値が、割り当てたしきい値を超えたときにトリガーされます。 たとえば、使用された要求ユニットの合計が 1000 RU/秒を超えた場合などです。 このアラートは条件を最初に満たしたときと、後でその条件を満たさなくなったときの両方でトリガーされます。 Azure Cosmos DB で使用できるさまざまなメトリックについては、監視データのリファレンスに関する記事を参照してください。
アクティビティ ログ イベント – このアラートは、特定のイベントが発生したときにトリガーされます。 たとえば、Azure Cosmos DB アカウントのキーへのアクセスがあったとき、または更新されたときです。
Log Analytics – このアラートは、Log Analytics クエリの結果で指定されたプロパティの値が、割り当てたしきい値を超えたときにトリガーされます。 たとえば、Log Analytics のクエリを記述して、Azure Cosmos DB で論理パーティション キーのストレージが 20GB の上限に達しているかどうかを監視することができます。
アラートは、[Azure Cosmos DB] ペインまたは Azure portal の Azure Monitor サービスから設定できます。 両方のインターフェイスに同じオプションが用意されています。 この記事では、Azure Monitor を使用して Azure Cosmos DB のアラートを設定する方法について説明します。
アラート ルールを作成する
この項では、HTTP 状態コード 429 を受信したときのアラートを作成する方法について説明します。この状態コードは、要求がレート制限されている場合に受け取ります。 たとえば、レート制限された要求が 100 以上になったらアラートを受け取るようにすることができます。 この記事では、HTTP 状態コードを使用して、このようなシナリオのアラートを構成する方法について説明します。 同様の手順を使用して、他の種類のアラートを構成することもできます。この場合は、要件に基づいて別の条件を選択する必要があるだけです。
ヒント
ここでは、しきい値を超えた場合の 429 に基づくアラートのシナリオを説明のために使用します。 これは、データベースまたはコンテナーに 429 が表示されるとことが本質的に問題であるという意味ではありません。 一般に、運用環境のワークロードで 429 の要求が 1 から 5% 表示され、アプリケーション全体の待機時間が要件内であれば、これはプロビジョニングしたスループット(RU/s)を十分に使用していることを示す正常な兆候です。 429 例外を解釈してデバッグする方法について参照してください。
Azure portal にサインインします。
左側のナビゲーション バーから [監視] を選択し、 [アラート] を選択します。
[新しいアラート ルール] ボタンを選択して [アラート ルールの作成] ペインを開きます。
[スコープ] セクションの項目に入力します。
[リソースの選択] ペインを開き、次のように構成します。
サブスクリプション名を選択します。
[リソースの種類] に [Azure Cosmos DB アカウント] を選択します。
Azure Cosmos DB アカウントの [場所]。
詳細を入力すると、選んだスコープの Azure Cosmos DB アカウントの一覧が表示されます。 アラートを構成するアカウントを選択して、 [完了] を選択します。
[条件] セクションの項目に入力します。
[条件の選択] ペインを開いて、[シグナル ページの設定] ページを開き、次のように構成します。
シグナルを選択します。 [シグナルの種類] には、[メトリック]、[アクティビティ ログ]、または [ログ (ログ分析)]を指定できます。 合計要求単位数メトリックに対してレート制限が発生した場合にアラートを受け取るために、このシナリオでは [メトリック] を選択します。
[モニター サービス] に [すべて] を選択します
[シグナル名] を選択します。 HTTP 状態コードに関するアラートを取得するには、 [要求ユニットの合計] シグナルを選択します。
これで、アラートをトリガーするロジックを定義し、グラフを使用して Azure Cosmos DB アカウントの傾向を表示することができます。 [合計要求ユニット数] メトリックではディメンションがサポートされます。 これらのディメンションを使用すると、メトリックに基づいてフィルター処理を行うことができます。 たとえば、ディメンションを使用して、監視する特定のデータベースまたはコンテナーにフィルター処理できます。 ディメンションを選択していない場合、この値は無視されます。
[ディメンション名]として[StatusCode] を選択します。 [カスタム値を追加] を選択し、状態コードを 429 に設定します。
[アラート ロジック] で、 [しきい値] を [静的] に設定します。 静的しきい値では、ユーザー定義のしきい値を使用してルールを評価します。一方、動的しきい値では、組み込みの機械学習アルゴリズムを使用して、メトリックの動作パターンを継続的に学習し、しきい値を自動的に計算します。
[演算子] に [次の値より大きい] 、 [集計の種類] に [合計] 、および [しきい値] に [100] を設定します。 このロジックでは、ステータス コード 429 の要求が 100 を超えてクライアントに表示された場合に、アラートがトリガーされます。 また、要件に基づいて、集計の種類、集計の粒度、および評価の頻度を構成することもできます。
フォームへの入力が終わったら、 [完了] を選択します。 次のスクリーンショットは、アラート ロジックの詳細を示しています。
[アクション グループ] セクションの項目に入力します。
[ルールの作成] ペインで、既存のアクション グループを選択するか、新しいグループを作成します。 アクション グループを使用して、アラート条件が発生したときに実行するアクションを定義できます。 この例では、新しいアクション グループを作成して、アラートがトリガーされたときに電子メール通知を受信するようにします。 [アクション グループの追加] ペインを開き、次の詳細を入力します。
アクション グループ名 - アクション グループ名は、リソース グループ内で一意である必要があります。
短い名前 - アクション グループの短い名前。この値は、通知の送信元であるアクション グループを識別するために、電子メールおよび SMS 通知に含められます。
このアクション グループを作成するサブスクリプションとリソース グループを選択します。
アクションの名前を指定し、 [アクションの種類] として [電子メール/SMS メッセージ/プッシュ/音声] を選択します。 次のスクリーンショットは、アクションの種類の詳細を示しています。
[アラート ルールの詳細] セクションの項目に入力します。
- ルールの名前を定義し、必要に応じて説明とアラートの重大度レベルを入力し、ルールの作成時にルールを有効にするかどうかを選択した後、 [ルールのアラートの作成] を選択してメトリック ルールのアラートを作成します。
アラートを作成すると、10 分以内にアクティブになります。
一般的なアラートのシナリオ
アラートを使用できるいくつかのシナリオを次に示します。
- Azure Cosmos DB アカウントのキーが更新されたとき。
- コンテナー、データベース、またはリージョンのデータまたはインデックスの使用量が特定のバイト数を超えたとき。
- 論理パーティション キーのストレージが Azure Cosmos DBの 20GB の論理パーティション ストレージの上限に達している場合。
- 正規化された RU/秒の消費量が特定の割合を超えたとき。 正規化された RU 消費量メトリックは、レプリカ セット内の最大スループット利用率を示します。 詳細については、正規化された RU/秒を監視する方法に関する記事を参照してください。
- リージョンが追加、削除されたとき、またはオフラインになったとき。
- データベースまたはコンテナーが作成、削除、または更新されたとき。
- データベースまたはコンテナーのスループットが変化したとき。
次のステップ
- Azure Cosmos DB コンテナーの正規化された RU/秒メトリックを監視する方法。
- Azure Cosmos DB で操作のスループットまたは要求ユニットの使用状況を監視する方法。