アラートによって、クラウド アプリケーションの問題をタイムリーに認識し、問題をすばやく解決できます。 Cloud Monitoring では、アラート ポリシーで、アラートを受け取る状況と通知方法を記述します。このページでは、通知ポリシーの概要について説明します。
Cloud Monitoring によって収集された指標データの追跡に使用されるアラート ポリシーは、指標ベースのアラート ポリシーと呼ばれます。アラート ポリシーに関する Cloud Monitoring のドキュメントの多くは、指標ベースのアラート ポリシーを使用していることを前提としています。指標ベースのアラート ポリシーの設定方法については、Compute Engine のクイックスタートをご覧ください。
ログにアラート ポリシーを作成して、ログに特定のメッセージがある場合に通知することもできます。これらのポリシーは指標に基づいていません。このコンテンツは、ログベースのアラート ポリシーには適用されません。ログベースのアラート ポリシーの詳細については、ログのモニタリングをご覧ください。
アラートの仕組み
各アラート ポリシーで指定するものは、以下の通りです。
1 つのリソースまたはリソースのグループが、レスポンスを必要とする状態かどうかを表す条件。たとえば、条件を次のように構成できます。
The HTTP response latency is higher than two seconds for at least five minutes.
この例では、条件によって指標「HTTP レスポンスのレイテンシ」がモニタリングされ、5 分間のすべてのレイテンシ測定値が 2 秒を超えるとトリガーされます。
条件には次の 3 種類があります。
- 指標しきい値条件は、指標の値が特定の期間時間枠のしきい値を上回る、または下回るときにトリガーされます。
- 指標の不在条件は、期間時間枠に測定値が存在しない場合にトリガーされます。
- 予測条件では、以前のデータを使用して測定の将来の動作を予測します。これらの条件は、時系列が予測ウィンドウ内でしきい値に違反すると予測されたときにトリガーされます。
アラート ポリシーには少なくとも 1 つの条件を設定する必要がありますが、複数の条件を設定したポリシーを構成できます。
アクションが必要なユーザーを通知する通知チャネルです。アラート ポリシーには、複数の通知チャネルを含めることができます。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 によってインシデントが開き、サポートチームにメールが送信されます。
サポートチームがメールを受信し、Google Cloud コンソールにログインして、通知の受信を確認します。
通知メールのドキュメントに従って、サポートチームがレイテンシの原因に対応できます。数分以内に、HTTP レスポンスのレイテンシが 2 秒未満に低下します。
Monitoring が 2 秒未満の HTTP レイテンシ測定を受信すると、インシデントを終了し、インシデントが終結されたという通知をサポートチームに送信します。
レイテンシが 2 秒を超え、5 分間にわたってそのしきい値を超えた場合、新しいインシデントが開かれ、通知が送信されます。
アラート ポリシーの追加方法
指標ベースのアラート ポリシーは、Google Cloud コンソール、Cloud Monitoring API、または Google Cloud CLI を使用して Google Cloud プロジェクトに追加できます。
Google Cloud コンソールを使用する場合は、推奨アラートを有効にするか、Cloud Monitoring の [アラート] ページからアラートを作成できます。
推奨アラートは一部の Google Cloud プロダクトでご利用いただけます。これらのアラートには、通知チャネルの追加など、最小限の構成が必要です。たとえば、Pub/Sub Lite の [トピック] ページは、割り当て上限に達したときに通知するように構成されているアラートにリンクします。同様に、Monitoring の [VM インスタンス] ページは、インスタンスのメモリ使用率とネットワーク レイテンシをモニタリングするように構成されたアラート ポリシーにリンクします。
アラート ポリシーを作成する方法については、次のドキュメントをご覧ください。
Google Cloud コンソールを使用して作成したポリシーは、Google Cloud コンソールか Cloud Monitoring API を使用して変更および表示できます。Cloud Monitoring API を使用すると、指標の比率をモニタリングするアラート ポリシーを作成できます。これらのポリシーで Monitoring フィルタが使用されている場合は、Google Cloud コンソールでフィルタを表示することも変更することもできません。
Cloud Monitoring API を直接使用する場合、または Google Cloud CLI を使用すると、アラート ポリシーを作成、表示、変更できます。
詳細については、Cloud Monitoring API または Google Cloud CLI を使用してアラート ポリシーを作成するをご覧ください。
1 つの指標、複数の指標、または指標の比率をモニタリングする条件を作成できます。Cloud Monitoring API を使用する場合は、Monitoring Query Language（MQL）または Monitoring フィルタを使用して比率を指定できます。モニタリング フィルタを使用するポリシーの例については、指標率をご覧ください。
Cloud Monitoring は、Google Cloud コンソールと Cloud Monitoring API で使用できる表現力に優れたテキストベースの言語をサポートしています。この言語をアラートで使用する方法については、Monitoring Query Language（MQL）を使用したアラート ポリシーの作成をご覧ください。
ログベースのアラート ポリシーを Google Cloud プロジェクトに追加するには、Cloud Logging のログ エクスプローラまたは Monitoring API を使用します。このコンテンツは、ログベースのアラート ポリシーには適用されません。ログベースのアラート ポリシーの詳細については、ログのモニタリングをご覧ください。
アラート ポリシーに関連する費用
アラート ポリシーの使用に伴う費用は発生しません。稼働時間チェックの料金については、Cloud Monitoring の料金概要をご覧ください。
アラート ポリシーと稼働時間チェックの使用には、次の上限が適用されます。
| Category | 値 | ポリシータイプ 1 |
|---|---|---|
| 指標スコープごとのアラート ポリシー（指標とログの合計）2 | 500 | 指標、ログ |
| 1 アラート ポリシーあたりの条件数 | 6 | 指標 |
| 指標の不在条件が評価される 最大期間 3 |
1 日 | 指標 |
| 指標のしきい値条件が評価される 最大期間 3 |
23 時間 30 分 | 指標 |
| 指標しきい値条件で使用される フィルタの最大長 |
2,048 Unicode 文字 | 指標 |
| 予測条件によってモニタリングされる時系列の最大数 |
64 | 指標 |
| 最小予測ウィンドウ | 1 時間（3,600 秒） | 指標 |
| 最大予測ウィンドウ | 7 日（604,800 秒） | 指標 |
| 1 アラート ポリシーあたりの通知チャンネル数 | 16 | 指標、ログ |
| 通知の最大レート | ログベースのアラートごとに 5 分あたり 1 件の通知 | ログ |
| 通知の最大数 | ログベースのアラートごとに 1 日あたり 20 件の通知 | ログ |
| 1 アラート ポリシーあたりの 同時対応待ちインシデントの最大数 |
1,000 | 指標 |
| 新規データのないインシデントが 自動的に終了するまでの期間 |
7 日 | 指標 |
| 手動で終了していない場合のインシデントの最長時間 | 7 日 | ログ |
| 終了したインシデントの保持 | 13 か月 | 該当なし |
| 対応待ちのインシデント | 期限なし | 該当なし |
| 指標スコープごとの通知チャネル | 4,000 | 該当なし |
| スヌーズごとのアラート ポリシーの最大数 | 16 | 指標、ログ |
| スヌーズの保持 | 13 か月 | 該当なし |
| 指標スコープごとの稼働時間チェック 4 | 100 | 該当なし |
| 公開稼働時間チェックごとの ICMP ping の最大数 | 3 | 該当なし |
2Apigee と Apigee ハイブリッドは Cloud Monitoring と緊密に統合されています。すべての Apigee サブスクリプション レベル（Standard、Enterprise、Enterprise Plus）のアラート数の上限は、Cloud Monitoring と同じで、1 指標スコープあたり 500 です。
3条件が評価する最大期間は、アライメント期間と期間時間枠の値の合計です。たとえば、アライメント期間が 15 時間、期間時間枠が 15 時間に設定されている場合、30 時間分のデータが条件を評価するために必要です。
4この上限は稼働時間チェックの構成の数に適用されます。稼働時間チェックの各構成には、指定されたリソースのステータスを確認する時間間隔が含まれます。詳細については、稼働時間チェックの管理をご覧ください。
料金の詳細については、Google Cloud のオペレーション スイートの料金をご覧ください。
次のステップ
通知レイテンシと、アラート ポリシーのパラメータの選択が通知送信のタイミングに及ぼす影響については、指標ベースのアラート ポリシーの動作をご覧ください。
指標ベースのポリシーの例の一覧については、アラート ポリシーの例の概要をご覧ください。
取り込まれたトレーススパンまたはログの数をモニタリングする方法、または特定のコンテンツがログエントリに含まれるときに通知する方法については、以下をご覧ください。