アラートの概要

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

Cloud Monitoring では、アラート ポリシーで、アラートを受け取る状況と通知方法を記述します。このページでは、通知ポリシーの概要について説明します。

アラート ポリシーを設定する方法については、Compute Engine のクイックスタートをお試しください。

アラートの仕組み

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

  • 1 つのリソースまたはリソースのグループが、操作が必要な状態かどうかを識別する条件。アラート ポリシーには少なくとも 1 つの条件を設定する必要がありますが、複数の条件を設定したポリシーを構成できます。

    たとえば、条件を次のように構成できます。

    The HTTP response latency is higher than two seconds for at least five minutes.
    

    この例では、条件によって指標「HTTP レスポンスのレイテンシ」がモニタリングされ、指標の値に対してアクションを実行する必要があるタイミングが指定されます。

  • アクションが必要なユーザーを通知する通知チャネルです。アラート ポリシーには、複数の通知チャネルを含めることができます。Cloud Monitoring は、一般的な通知チャネルだけでなく、Cloud Mobile App と Pub/Sub にも対応しています。サポートされているチャネルのリストと、これらのチャネルを構成する方法については、通知オプションをご覧ください。

    たとえば、アラート ポリシーを構成して my-support-team@example.com にメールを送信し、チャネル #my-support-team に Slack メッセージを投稿できます。

  • 通知に含めるドキュメント。ドキュメント フィールドでは、書式なしテキスト、マークダウン、変数がサポートされています。

    たとえば、次のポリシーをアラート ポリシーに組み込むことができます。

    ## HTTP latency responses
    
    This alert originated from the project ${project}, using
    the variable $${project}.
    

アラート ポリシーの構成後、Monitoring はそのポリシーの条件を継続的にモニタリングします。特定の期間のみをモニタリングする条件を構成することはできません。ポリシーの条件が満たされた場合、つまり、リソースの状態によりアクションを実行する必要がある場合、Monitoring はインシデントを作成し、インシデントに関する通知を送信します。この通知には、インシデントの概要情報、インシデントを調査できる [ポリシーの詳細] ページのリンク、および指定したドキュメントが記載されています。

インシデントが未解決のまま残っていて、Monitoring でポリシーの条件が満たされなくなったと判断された場合、Monitoring は自動的にインシデントを終結させて、終結に関する通知を送信します。

ウェブ アプリケーションを実行している Compute Engine 仮想マシン(VM)インスタンスにウェブ アプリケーションをデプロイします。HTTP レスポンスのレイテンシは通常の需要の増減に応じて変動する場合があることはわかっていますが、ユーザーが長時間にわたって長いレイテンシを感じるようになった場合は、サポートチームがアクションを起こせるよう、通知を受けることをおすすめします。

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

  If the HTTP response latency is higher than two seconds for at least five minutes,
  then open an incident and send an email to your support team.

このアラート ポリシーでは、設定条件により HTTP レスポンスのレイテンシがモニタリングされています。このレイテンシが 5 分間で継続して 2 秒を超える場合は、条件が満たされ、インシデントが生成されます。レイテンシの一時的な急上昇によって条件が満たされたり、インシデントが生成されたりすることはありません。

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

  1. Monitoring は、HTTP レイテンシ測定値が 2 秒を超えるときに 5 分のタイマーを開始します。

  2. 次の 5 分間に受信した各レイテンシ測定値が 2 秒を超えたら、タイマーは期限切れになります。タイマーが期限切れになると、Monitoring によって条件が満たされたと判定され、インシデントが生成されて、サポートチームにメールが送信されます。

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

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

  5. Monitoring が 2 秒未満の HTTP レイテンシ測定を受信すると、インシデントを終了し、インシデントが終結されたという通知をサポートチームに送信します。

インシデントが終結された後、HTTP レスポンスのレイテンシが 2 秒を超え、そのしきい値を超える状態が 5 分間続くと、Monitoring によって新しいインシデントが開かれ、通知メールが送信されます。

アラート ポリシーの追加方法

アラート ポリシーは、Google Cloud Console、Cloud Monitoring API、または Cloud SDK を使用して Google Cloud プロジェクトに追加できます。

  • Cloud Console を使用する場合は、推奨アラートを有効にするか、Cloud Monitoring の [アラート] ページからアラートを作成できます。

    推奨アラートは一部の Google Cloud プロダクトでご利用いただけます。これらのアラートには、通知チャネルの追加など、最小限の構成が必要です。たとえば、Pub/Sub Lite の [トピック] ページを表示している場合、割り当ての上限に達すると、通知するアラートを有効化できます。同様に、Monitoring から [VM インスタンス] ページを表示している場合は、そのインスタンスのメモリ使用量とネットワーク レイテンシをモニタリングする推奨のアラート ポリシーを有効化できます。

    Cloud Monitoring の [アラート] ページに表示されるアラート ポリシーの作成方法については、Cloud Console を使用したアラート ポリシーの作成をご覧ください。

  • Cloud Monitoring API を直接使用する場合、または Cloud SDK を使用する場合は、アラート ポリシーを作成、表示、変更できます。アラート ポリシーの条件で 2 つの指標の比率を計算し、その比率をしきい値と比較する場合は、Cloud Monitoring API または Cloud SDK を使用してポリシーを作成する必要があります。この種のポリシーの例については、指標率をご覧ください。

    Cloud Monitoring API と Cloud SDK の使用に関する詳細については、Cloud Monitoring API または Cloud SDK を使用したアラート ポリシーの作成をご覧ください。

Cloud Monitoring は、Google Cloud Console と Cloud Monitoring API で使用できる表現力に優れたテキストベースの言語をサポートしています。この言語をアラートで使用する方法については、Monitoring Query Language(MQL)を使用したアラート ポリシーの作成をご覧ください。

アラート ポリシーの管理方法

プロジェクトのアラート ポリシーのリストを表示する方法と、それらのポリシーを変更する方法については、以下をご覧ください。

アラート ポリシーの作成に必要な承認

このセクションでは、アラート ポリシーの作成に必要なロールまたは権限について説明します。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 100
指標スコープごとのアラート ポリシー2 500
1 アラート ポリシーあたりの条件数 6
1 アラート ポリシーあたりの通知チャンネル数 16
指標スコープごとの通知チャネル 4000
1 アラート ポリシーあたりの同時対応待ちインシデント数 5,000
指標不在条件の最長時間 1 日
指標しきい値条件の最長時間 23 時間 30 分
1この上限は稼働時間チェックの構成の数に適用されます。稼働時間チェックの各構成には、指定されたリソースのステータスを確認する時間間隔が含まれます。詳細については、稼働時間チェックの管理をご覧ください。

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

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

次のステップ