アラートの概要

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

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 秒を超えるようになりました。アラートポリシーでどのように対応するかを次に示します。

Monitoring は、HTTP レイテンシ測定値が 2 秒を超えるときに 5 分のタイマーを開始します。
次の 5 分間に受信した各レイテンシ測定値が 2 秒を超えたら、タイマーは期限切れになります。タイマーが期限切れになると、Monitoring によって条件が満たされたと判定され、インシデントが生成されて、サポートチームにメールが送信されます。
サポートチームがメールを受信し、Cloud Console にログインして、通知の受信を確認します。
通知メールのドキュメントに従って、サポートチームがレイテンシの原因に対応できます。数分以内に、HTTP レスポンスのレイテンシが 2 秒未満に減少します。
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 を使用してプロジェクトのロールを決定する手順は次のとおりです。

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

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

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

アラートポリシーに関連する費用

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

カテゴリ	値
指標スコープごとの稼働時間チェック¹	100
指標スコープごとのアラートポリシー²	500
1 アラートポリシーあたりの条件数	6
1 アラートポリシーあたりの通知チャンネル数	16
指標スコープごとの通知チャネル	4000
1 アラートポリシーあたりの同時対応待ちインシデント数	5,000
指標不在条件の最長時間	1 日
指標しきい値条件の最長時間	23 時間 30 分

¹この上限は稼働時間チェックの構成の数に適用されます。稼働時間チェックの各構成には、指定されたリソースのステータスを確認する時間間隔が含まれます。詳細については、稼働時間チェックの管理をご覧ください。

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

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

次のステップ

通知のレイテンシと、アラートポリシーのパラメータの選択が通知送信のタイミングに与える影響については、アラートの動作をご覧ください。
さまざまな種類のポリシーについては、各種のアラートポリシーをご覧ください。
アラートポリシーの例については、以下をご覧ください。