このドキュメントでは、アプリケーションが失敗した場合や、アプリケーションのパフォーマンスが定義された基準を満たしていない場合に通知を受け取る方法について説明します。
アラートの仕組み
Cloud Monitoring のアラート プロセスは、次の 3 つの部分で構成されています。
アラート ポリシーを作成して、アラートを受け取る状況とインシデントの通知方法を記述します。アラート ポリシーでは、Monitoring で保存される時系列データや Cloud Logging で保存されるログをモニタリングできます。そのデータがアラート ポリシーの条件を満たすと、Monitoring によってインシデントが作成され、通知が送信されます。
各インシデントは、モニタリングされたデータの種類と、条件がいつ満たされたかの記録です。この情報は、インシデントの原因となった問題のトラブルシューティングに役立ちます。
通知チャンネルは、Monitoring がインシデントを作成したときに通知を受け取る方法を定義します。たとえば、アラート ポリシーを構成して
my-support-team@example.comにメールを送信し、チャネル#my-support-teamに Slack メッセージを投稿できます。アラート ポリシーには 1 つ以上の通知チャンネルを含めることができます。
アラート ポリシーでは、次の 3 種類のデータを評価できます。
時系列データ（指標データとも呼ばれます）。これは Monitoring によって保存されます。これらのタイプのポリシーは、指標ベースのアラート ポリシーと呼ばれます。
指標ベースのアラート ポリシーの設定方法については、Compute Engine のクイックスタートをご覧ください。
Cloud Logging によって保存されるログエントリ データ。個々のログエントリを評価するアラート ポリシーは、ログベースのアラート ポリシーと呼ばれます。ログベースのアラート ポリシーは、ログに特定のメッセージが表示されたときに通知します。詳細については、ログのモニタリングをご覧ください。
Logging に保存されているログエントリ データに対してログ分析で実行された SQL クエリの結果。SQL クエリの結果をモニタリングするアラート ポリシーは、SQL ベースのアラート ポリシーと呼ばれます。詳細については、アラート ポリシーを使用して SQL クエリ結果をモニタリングするをご覧ください。
SQL ベースのアラート ポリシーは公開プレビュー版です。
アラート プロセスは、アプリケーションのパフォーマンスが許容値に達していないときに、問題に対応する際に役立ちます。たとえば、ウェブ アプリケーションを Compute Engine 仮想マシン（VM）インスタンスにデプロイします。HTTP レスポンスのレイテンシは変動することが予想されますが、アプリケーションのレイテンシが長期間高いときには、サポートチームに対応を依頼する必要があります。アプリケーションの HTTP レスポンス レイテンシ指標をモニタリングする指標ベースのアラート ポリシーを作成できます。レスポンスのレイテンシが少なくとも 5 分間に 2 秒を超えると、Monitoring はインシデントを作成し、サポートチームにメール通知を送信します。
アラート ポリシーを作成する方法
アラート ポリシーの作成方法は複数あります。たとえば、 Google Cloud コンソールのインテグレーション ページまたは特定のページから推奨アラートを有効にすることで、事前構成済みのアラート ポリシーを使用できます。Google Cloud コンソール、Cloud Monitoring API、Google Cloud CLI および Terraform を使用して新しいアラート ポリシーを構成することもできます。
インテグレーションと推奨のアラート ポリシーを使用する
Monitoring には、Google Cloud サービスとサードパーティ統合のアラート ポリシーを作成するための事前構築済みパッケージが用意されています。パッケージには、推奨されるアラート ポリシー、サンプル ダッシュボード、サービスの主要指標が含まれています。これらのパッケージは、Google Kubernetes Engine、Compute Engine、Cloud SQL などのGoogle Cloud サービスと、MongoDB、Kafka、Elasticsearch などの一般的なサードパーティ統合で使用できます。
パッケージをインストールするときに、パッケージの推奨アラート ポリシーを有効にできます。推奨アラート ポリシーを有効にするときに、通知チャンネルを構成し、必要に応じて他の値を変更します。構成後、アラート ポリシーはターゲットのモニタリングをすぐに開始します。ユーザーによる追加の入力は必要ありません。
推奨アラート ポリシーは、新しいサービスをデプロイし、重要な指標に関するアラートを設定する場合に役立ちます。たとえば、Cloud SQL 統合パッケージには、失敗したインスタンスと速度の遅いトランザクションに推奨されるアラート ポリシーが付属しています。
アラート統合の詳細については、サードパーティ アプリケーションのモニタリングをご覧ください。
新しいアラート ポリシーを作成する
アラートのニーズに応じて、さまざまな種類のデータをモニタリングするアラート ポリシーを作成できます。以降のセクションでは、アラート ポリシーでモニタリングできるさまざまな種類のデータについて説明します。
時系列データをモニタリングする
| 条件タイプ | 説明 | 例 |
|---|---|---|
| 指標しきい値条件 | 指標しきい値条件は、特定の再テスト ウィンドウで指標の値がしきい値を上回るか下回ると満たされます。 詳細については、指標しきい値のアラート ポリシーを作成すると API を使用してアラート ポリシーを作成するをご覧ください。 |
10 分を超える連続 5 回の稼働時間チェックで、レスポンス レイテンシが 500 ミリ秒以上の場合に通知を送信するアラート ポリシーが必要です。 |
| 指標の不在条件 | 指標の不在条件は、モニタリング対象時系列に特定の再テスト ウィンドウのデータがない場合に満たされます。最大の再テスト ウィンドウは 23.5 時間です。 詳細については、指標不在のアラート ポリシーを作成すると API を使用してアラート ポリシーを作成するをご覧ください。 | リソースが 5 分間で HTTP リクエストに応答しない場合、サポートチームと一緒にインシデントを開くためのアラート ポリシーが必要です。 |
| 予測指標値の条件 | 予測指標値の条件は、今後の予測期間内にしきい値違反が発生するとアラート ポリシーが予測した場合に満たされます。予測ウィンドウは、1 時間から 7 日間の範囲で設定できます。 詳細については、予測指標値のアラート ポリシーを作成すると API を使用してアラート ポリシーを作成するをご覧ください。 |
リソースが 24 時間以内にディスク容量の 80% に達する可能性がある場合に、サポートチームと一緒にインシデントを開くアラート ポリシーが必要です。 |
ログエントリ データをモニタリングする
個々のログエントリをモニタリングするには、ログベースのアラート ポリシーを使用します。ログベースのアラート ポリシーの条件は、ログエントリのフレーズがアラート ポリシーの条件に一致することをアラート ポリシーが検出したときに満たされます。たとえば、ログエントリの message に product_ids=['tier_1_support', 'tier_2_support'] が含まれている場合に、サポートチームと一緒にインシデントを開くアラート ポリシーが必要です。
詳細については、ロギングのドキュメントのログベースのアラート ポリシーを構成するをご覧ください。
SQL クエリ結果をモニタリングする
SQL クエリの結果をモニタリングするには、SQL ベースのアラート ポリシーを使用します。SQL ベースのアラート ポリシーの条件は、ログエントリ データを定期的に分析し、クエリ結果のテーブルが特定の条件を満たした場合にインシデントを作成します。このタイプのアラート ポリシーは、複数のログエントリにわたるデータの集計や複雑なパターンをモニタリングするアラート ポリシーが必要な場合に役立ちます。たとえば、過去 60 分間に 50 件を超えるログエントリの重大度が WARNING の場合に通知を受け取るとします。
詳細については、Logging ドキュメントのアラート ポリシーを使用して SQL クエリの結果をモニタリングするをご覧ください。
通知ポリシーのコンポーネント
各アラート ポリシーには次のコンポーネントがあります。
1 つのリソースまたはリソースのグループが、レスポンスを必要とする状態かどうかを表す条件。条件には、データソース、静的または動的しきい値、フィルタや groupby などのデータ集計方法が含まれます。条件では、単一の指標、複数の指標、指標の比率をモニタリングできます。Prometheus Query Language（PromQL）を使用して、動的しきい値や条件付きロジックなどの複雑な式を含めることもできます。
インテグレーションを使用して推奨アラート ポリシーを有効にすると、アラート ポリシーの条件が事前入力されます。
アクションが必要なユーザーを通知する通知チャンネルのリスト。詳細については、通知チャンネルを作成して管理するをご覧ください。
通知とインシデント ページに表示されるドキュメント。通知の件名を構成したり、通知の本文に役立つ情報を追加できます。たとえば、内部ハンドブックやカスタム ダッシュボードなどの Google Cloud ページへのリンクを表示するように通知を構成できます。例を含むドキュメントの詳細については、ユーザー定義のドキュメントでインシデントにアノテーションを付けるをご覧ください。
クエリ言語
アラート ポリシーでクエリ言語とフィルタを使用すると、指標の評価をより詳細に制御できます。Monitoring は次のクエリタイプをサポートしています。
Prometheus Query Language（PromQL）は、時系列データをリアルタイムで評価するために使用される関数クエリ言語です。アラート ポリシーの条件に PromQL クエリを含めるようにアラート ポリシーを構成できます。PromQL クエリでは、指標の組み合わせ、比率、スケーリングしきい値などの有効な式を使用できます。 Google Cloudで PromQL ベースのアラート ポリシーを構成すると、外部アラート インフラストラクチャへの依存関係を軽減できます。詳細については、Cloud Monitoring の PromQL と PromQL アラートの概要をご覧ください
モニタリング フィルタを使用すると、フィルタベースの指標比率を使用するようにアラート ポリシーを構成できます。フィルタベースのアラート ポリシーは、 Google Cloud コンソールで表示または変更できません。モニタリング フィルタを使用するポリシーの例については、指標率をご覧ください。
Monitoring Query Language（MQL）は、時系列データの取得、フィルタ、操作を可能にする、表現力の高いテキストベースのインターフェースです。Monitoring Query Language アラート オペレーションを含む条件でアラート ポリシーを作成できます。詳細については、Monitoring Query Language の概要と MQL のアラート ポリシーをご覧ください。
アラート ポリシーとインシデントを管理する
アラート ポリシーの構成後、Monitoring はそのポリシーの条件を継続的にモニタリングします。特定の期間のみをモニタリングするアラート ポリシーを構成することはできません。一定期間アラート ポリシーを無効にする場合は、スヌーズを作成します。
インシデントが未解決のまま残っていて、Monitoring で指標ベースのポリシーの条件が満たされなくなったと判断された場合、Monitoring は自動的にインシデントをクローズし、それに関する通知を送信します。
料金
一般に、Cloud Monitoring システムの指標は無料であり、外部システム、エージェント、またはアプリケーションの指標はそうではありません。課金対象の指標は、取り込まれたバイト数とサンプル数のいずれかによって課金されます。
Cloud Monitoring の料金の詳細については、次のドキュメントをご覧ください。
取り込まれたトレーススパンまたはログの数をモニタリングする方法、または特定のコンテンツがログエントリに含まれている場合に通知を受け取る方法については、次のドキュメントをご覧ください。
次のステップ
通知レイテンシと、アラート ポリシーのパラメータの選択が通知送信のタイミングに及ぼす影響については、指標ベースのアラート ポリシーの動作をご覧ください。
指標ベースのポリシー サンプルの一覧については、アラート ポリシー サンプルの概要をご覧ください。