アラートの概要

アラートによって、クラウド アプリケーションの問題をタイムリーに認識し、問題をすばやく解決できます。

アラート ポリシーを作成するには、アラートを受け取る状況と通知方法を記述する必要があります。このページでは、アラート ポリシーの概要とそのコンセプトについて説明します。

アラートの実践的なに紹介ついては、次のクイックスタートをご覧ください。

使用状況をモニタリングし、料金のしきい値に近づいたらアラートを受け取るアラート ポリシーについては、月次ログ取り込み時のアラート発信と月次トレーススパン取り込み時のアラート発信をご覧ください。

アラートの仕組み

アラート ポリシーは、Google Cloud Console、Cloud Monitoring API、Cloud SDK を使用して作成と管理を行うことができます。

各アラート ポリシーで指定するものは、以下の通りです。

  • 1 つのリソースまたはリソースのグループが、操作が必要な状態かどうかを識別する条件。アラート ポリシーの条件は継続的にモニタリングされます。特定の期間のみにモニタリング対象となる条件を構成することはできません。

  • 条件が満たされたことをサポートチームに知らせるために送信される通知。既存の通知チャネルには、次のすべてが含まれます。

    通知の構成は省略可能です。利用可能な通知チャネルについては、通知オプションをご覧ください。

  • サポートチームによる問題の解決に役立つように、一部のタイプの通知に含めることができるドキュメント。ドキュメントの構成は省略可能です。

アラート ポリシーの条件が満たされると、Cloud Monitoring は Google Cloud Console にインシデントを作成して表示します。通知を設定した場合は、Cloud Monitoring によってユーザーやサードパーティの通知サービスにも通知が送信されます。 応答者は通知の受信を確認できますが、インシデントをトリガーした条件が true でなくなるまで、インシデントは開いたままになります。

Google Cloud Console を使用したインシデントの表示と管理については、インシデントをご覧ください。

例

LAMP スタックを実行している Compute Engine VM インスタンスにウェブ アプリケーションをデプロイします。通常の需要の増減に応じて HTTP レスポンスのレイテンシが変動する可能性はありますが、レイテンシが高い状態が長時間続く場合は、対応の必要があります。

ユーザーのレイテンシが長くなったときに通知を受けるには、次のアラート ポリシーを作成します。

HTTP レスポンスのレイテンシが 2 秒を超え、
かつこの状態が 5 分を超える場合、
インシデントを開き、サポートチームにメールを送信します。

ウェブアプリは予期したよりも人気が高く、レスポンスのレイテンシが 2 秒を超えるようになりました。アラート ポリシーでどのように対応するかを次に示します。

  1. 連続する 5 分間で 2 秒を超える HTTP レイテンシが発生した後、Cloud Monitoring によってインシデントが開かれ、メールが送信されます。

  2. サポートチームはメールを受信して Google Cloud Console にログインし、通知の受信を確認します。

  3. 通知メールのドキュメントに従って、チームはレイテンシの原因に対応できます。数分以内に、HTTP レスポンスが 2 秒未満に戻ります。

  4. Cloud Monitoring によって 2 秒未満の HTTP レイテンシが測定されると、すぐに、ポリシーの条件は真ではなくなります（短いレイテンシが 1 回でも測定されると、「連続 5 分」という要件に該当しなくなります）。

    Cloud Monitoring によってインシデントが閉じられ、5 分のタイマーはリセットされます。 次の連続する 5 分の間にレイテンシが 2 秒を超えると、ポリシーによって新しいインシデントが開かれます。

アラート ポリシーの種類

Cloud Monitoring を使用すると、さまざまなタイプのポリシーを作成できます。たとえば、指標が存在しない場合や指標の値がしきい値を超えた場合にトリガーするアラート ポリシーを作成できます。

Google Cloud Console では、API や Cloud SDK を使用して作成されたものも含め、Google Cloud プロジェクトに関連付けられているすべてのアラート ポリシーが一覧表示されます。ただし、比率ベースのアラート ポリシーを作成、表示、変更するには、Cloud Monitoring API または Cloud SDK を使用する必要があります。

さまざまなタイプのポリシーとサンプル ポリシーについては、アラート ポリシーのタイプをご覧ください。

アラートに影響する可能性のある変数については、アラートの動作をご覧ください。

承認

このセクションでは、アラート ポリシーの作成に必要なロールまたは権限について説明します。Cloud Monitoring の Identity and Access Management（IAM）の詳細については、アクセス制御をご覧ください。

各 IAM ロールには ID と名前があります。ロール ID は roles/monitoring.editor という形式で、アクセス制御を構成するときに gcloud コマンドライン ツールに引数として渡されます。詳細については、アクセス権の付与、変更、取り消しをご覧ください。モニタリング編集者などのロール名が Cloud Console に表示されます。

必要な Cloud Console のロール

アラート ポリシーを作成するには、Google Cloud プロジェクトの IAM ロール名が次のいずれかである必要があります。

  • モニタリング編集者
  • モニタリング管理者
  • プロジェクト所有者

ロールとそれに関連する権限のリストを表示するには、ロールをご覧ください。

必要な API 権限

Cloud Monitoring API を使用してアラート ポリシーを作成するには、Google Cloud プロジェクトの IAM のロール ID が次のいずれかである必要があります。

  • roles/monitoring.alertPolicyEditor: このロール ID は、アラート ポリシーの作成に必要な最小限の権限を付与します。このロールの詳細については、事前定義されたアラートのロールをご覧ください。
  • role/monitoring.editor
  • role/monitoring.admin
  • role/owner

特定の Cloud Monitoring API メソッドに必要な権限を特定するには、Cloud Monitoring API の権限をご覧ください。ロールとそれに関連する権限のリストを表示するには、ロールをご覧ください。

ロールの決定

Cloud Console を使用してプロジェクトのロールを決定する手順は次のとおりです。

  1. Cloud Console を開き、Google Cloud プロジェクトを選択します。

    Cloud Console に移動

  2. 役割を表示するには、[IAM と管理] をクリックします。ユーザー名と同じ行に役割が表示されます。

組織レベルの権限については、組織の管理者にお問い合わせください。

料金と上限

アラート ポリシーや稼働時間チェックの利用に伴う費用はありませんが、次の制限が適用されます。

カテゴリ 値
1 ワークスペースあたりの稼働時間チェック数1 100
1 ワークスペースあたりのアラート ポリシー数2 500
1 アラート ポリシーあたりの条件数 6
1 アラート ポリシーあたりの通知チャンネル数 16
1 ワークスペースあたりの通知チャンネル数 4,000
1 アラート ポリシーあたりの同時対応待ちインシデント数 5,000
指標不在条件の最長時間 1 日
指標しきい値条件の最長時間 23 時間 30 分
1この上限は稼働時間チェックの構成の数に適用されます。稼働時間チェックの各構成には、指定されたリソースのステータスを確認する時間間隔が含まれます。詳細については、稼働時間チェックの管理をご覧ください。

2Apigee と Apigee ハイブリッド は、Cloud Monitoring と緊密に連携しています。すべての Apigee サブスクリプション レベル（Standard、Enterprise、Enterprise Plus）のアラート数の上限は、Cloud Monitoring と同じで、1 ワークスペースあたり 500 です。

料金の詳細については、Google Cloud のオペレーション スイートの料金をご覧ください。

次のステップ