このドキュメントでは、アプリケーションが失敗した場合や、アプリケーションのパフォーマンスが定義された基準を満たしていない場合に通知を受け取る方法について説明します。
アラートの仕組み
Cloud Monitoring のアラート プロセスは、次の 3 つの部分で構成されています。
アラート ポリシー、アラートを受け取る状況とインシデントの通知方法を記述します。アラート ポリシーでは、Monitoring で保存される時系列データや Cloud Logging で保存されるログをモニタリングできます。そのデータがアラート ポリシーの条件を満たすと、Monitoring によってインシデントが作成され、通知が送信されます。
各インシデントは、モニタリングされたデータの種類と、条件がいつ満たされたかの記録です。この情報は、インシデントの原因となった問題のトラブルシューティングに役立ちます。
通知チャンネルは、Monitoring がインシデントを作成したときに通知を受け取る方法を定義します。たとえば、通知チャンネルを構成して
my-support-team@example.comにメールを送信し、チャネル#my-support-teamに Slack メッセージを投稿できます。アラート ポリシーには、1 つ以上の通知チャネルを含めることができます。
アラート ポリシーでは、次の 2 種類のデータを評価できます。
時系列データ（指標データとも呼ばれます）。Monitoring によって保存されます。これらのタイプのポリシーは、指標ベースのアラート ポリシーと呼ばれます。
指標ベースのアラート ポリシーの設定方法については、Compute Engine のクイックスタートをご覧ください。
Cloud Logging によって保存されるログデータ。これらのタイプのポリシーは、ログベースのアラート ポリシーと呼ばれます。 ログベースのアラート ポリシーは、ログに特定のメッセージが表示されたときに通知します。
このドキュメントでは、指標ベースのアラート ポリシーに重点を置いて説明します。必要に応じて、ログベースのアラート ポリシーに関する一般的な情報も説明します。ログベースのアラート ポリシーの詳細については、ログをモニタリングするをご覧ください。
アラート プロセスは、アプリケーションのパフォーマンスが許容値を満たしていない場合に問題に対応するのに役立ちます。たとえば、ウェブ アプリケーションを 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 統合パッケージには、失敗したインスタンスと速度の遅いトランザクションに推奨されるアラート ポリシーが付属しています。
アラートの統合の詳細については、サードパーティ アプリケーションのモニタリングをご覧ください。
Cloud Monitoring を使用する
アラート ポリシーを作成し、指標タイプや時系列などの他のコンポーネントとともに条件タイプを選択する場合は、Monitoring を使用します。次の表に、アラート ポリシーの作成時に使用できるさまざまな条件のタイプを示します。
| Condition Type | 説明 | 例 |
|---|---|---|
| 指標しきい値条件 | 指標しきい値条件は、特定の再テスト ウィンドウで指標の値がしきい値を上回るか下回ると満たされます。 詳細については、指標しきい値のアラート ポリシーを作成すると API を使用してアラート ポリシーを作成するをご覧ください。 |
10 分を超える連続する 5 回の稼働時間チェックで、レスポンス レイテンシが 500 ミリ秒以上の場合に通知を送信するアラート ポリシーが必要です。 |
| 指標の不在条件 | 指標の不在条件は、モニタリング対象時系列に特定の再テスト ウィンドウのデータがない場合に満たされます。最大の再テスト ウィンドウは 23.5 時間です。 詳細については、指標不在のアラート ポリシーを作成すると API を使用してアラート ポリシーを作成するをご覧ください。 | リソースが 5 分間で HTTP リクエストに応答しない場合、サポートチームとのインシデントを開くアラート ポリシーが必要です。 |
| 予測指標値の条件 | 予測指標値の条件は、アラート ポリシーが今後の予測期間内にしきい値に違反すると予測した場合に満たされます。予測ウィンドウは 1 時間から 7 日の間で設定できます。 詳細については、予測指標値のアラート ポリシーを作成すると API を使用してアラート ポリシーを作成するをご覧ください。 |
リソースが 24 時間以内にディスク容量の 80% に達する可能性がある場合に、サポートチームとのインシデントを開くアラート ポリシーが必要です。 |
| ログベースの条件 |
ログベースのアラート ポリシーの条件は、アラート ポリシーがログベースの指標がアラート ポリシーの条件と一致していることを検出したときに満たされます。ログベースの指標は、ログエントリの内容から指標データを取得します。たとえば、ログベースの指標を使用して、特定のメッセージを含むログエントリの数をカウントできます。または、ログエントリに記録されたレイテンシ情報を抽出することもできます。 詳細については、ログベースのアラート ポリシーを構成すると Cloud Monitoring API を使用してログベースのアラート ポリシーを作成するをご覧ください。 |
プロジェクトに product_ids=['tier_1_support', 'tier_2_support'] を含む message があるログエントリが 50 個以上ある場合に、サポートチームとのインシデントを開くアラート ポリシーが必要です。 |
通知ポリシーのコンポーネント
各アラート ポリシーには次のコンポーネントがあります。
1 つのリソースまたはリソースのグループが、レスポンスを必要とする状態かどうかを表す条件。条件には、データソース、静的または動的しきい値、フィルタやグループ化などのデータ集計方法が含まれます。条件では、単一の指標、複数の指標、指標の比率をモニタリングできます。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 の料金の詳細については、次のドキュメントをご覧ください。
取り込まれるトレーススパンの数やログの数をモニタリングする方法、またはログエントリに特定のコンテンツが含まれている場合に通知する方法については、次のドキュメントをご覧ください。
次のステップ
通知レイテンシと、アラート ポリシーのパラメータの選択が通知送信のタイミングに及ぼす影響については、指標ベースのアラート ポリシーの動作をご覧ください。
指標ベースのポリシー サンプルの一覧については、アラート ポリシー サンプルの概要をご覧ください。