このドキュメントでは、アプリケーションが失敗した場合や、アプリケーションのパフォーマンスが定義された基準を満たさない場合に、通知を受け取る方法について説明します。
アラートの仕組み
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 秒を超える場合は、インシデントが作成され、サポートチームにメール通知が送信されます。
アラート ポリシーの作成方法
アラート ポリシーを作成するには、複数の方法があります。たとえば、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 ミリ秒以上の場合に通知を送信するアラート ポリシーが必要です。 |
| 指標の不在条件 | 「指標の不在」条件は、モニタリング対象時系列に特定の期間時間枠のデータがない場合に満たされます。期間時間枠は、Google Cloud コンソールまたは Cloud Monitoring API で条件を作成する場合、最大 24 時間です。 詳細については、指標の不在アラート ポリシーの作成と API を使用してアラート ポリシーを作成するをご覧ください。 | リソースが 5 分間で HTTP リクエストに応答しない場合、サポートチームとのインシデントを開くアラート ポリシーが必要です。 |
| 予測指標値の条件 | 予測指標値の条件は、アラート ポリシーにより、今後の予測期間内にしきい値をまたぐことが予測される場合に満たされます。 予測ウィンドウは 1 時間から 7 日間の間で設定できます。 詳細については、予測指標値のアラート ポリシーの作成と API を使用してアラート ポリシーを作成するをご覧ください。 |
リソースが 24 時間以内にディスク容量の使用率が 80% に達する可能性がある場合、サポートチームとのインシデントを開くアラート ポリシーが必要です。 |
| ログベースの条件 |
ログベースのアラート ポリシーの条件は、アラート ポリシーがアラート ポリシーの条件と一致するログベースの指標が検出されると満たされます。ログベースの指標は、ログエントリの内容から指標データを取得します。たとえば、ログベースの指標を使用して、特定のメッセージを含むログエントリの数をカウントできます。または、ログエントリに記録されたレイテンシ情報を抽出することもできます。 詳細については、ログベースのアラートの構成と Monitoring API を使用してログベースのアラートを作成するをご覧ください。 |
プロジェクトに product_ids=['tier_1_support', 'tier_2_support'] を含む message を持つログエントリが少なくとも 50 件ある場合、サポートチームとのインシデントを開くアラート ポリシーが必要です。 |
通知ポリシーのコンポーネント
各アラート ポリシーには次のコンポーネントがあります。
1 つのリソースまたはリソースのグループが、レスポンスを必要とする状態かどうかを表す条件。条件には、データソース、静的または動的しきい値、データ集計方法（ルックバック ウィンドウ、フィルタ、groupby など）が含まれます。条件では、単一の指標、複数の指標、または指標の比率をモニタリングできます。PromQL や Monitoring Query Language（MQL）などのクエリ言語を使用して、動的しきい値や条件ロジックなどの複雑な式を含めることもできます。
統合を使用して推奨アラート ポリシーを有効にする場合、アラート ポリシー条件は事前入力されます。
アクションが必要なユーザーを通知する通知チャネルのリスト。詳細については、通知チャンネルを作成して管理するをご覧ください。
通知とインシデントのページに表示されるドキュメント。通知の件名を構成し、通知の本文に有用な情報を追加できます。たとえば、内部ハンドブックやカスタム ダッシュボードなどの Google Cloud ページへのリンクを表示するように通知を構成できます。例を含むドキュメントの詳細については、ユーザー定義のドキュメントでアラートにアノテーションを付けるをご覧ください。
クエリ言語
アラート ポリシーでクエリ言語とフィルタを使用すると、指標の評価をより詳細に制御できます。Monitoring は、次のクエリタイプをサポートしています。
Prometheus Query Language（PromQL）は、時系列データをリアルタイムで評価するために使用される機能的なクエリ言語です。アラート ポリシーの条件を構成して、条件に PromQL クエリを含めることができます。PromQL クエリでは、指標の組み合わせ、比率、スケーリングしきい値などの有効な式を使用できます。Google Cloud の PromQL ベースの条件を使用してアラート ポリシーを構成することで、外部アラート インフラストラクチャへの依存関係を減らすことができます。詳細については、Cloud Monitoring の PromQL と PromQL によるアラート ポリシーをご覧ください。
Monitoring Query Language（MQL）は、表現力の高いテキストベースのインターフェースであり、時系列データの取得、フィルタリング、操作を行うことができます。Monitoring Query Language アラート オペレーションを含む条件でアラート ポリシーを作成できます。詳細については、Monitoring Query Language の概要と MQL のアラート ポリシーをご覧ください。
モニタリング フィルタを使用すると、フィルタベースの指標率を使用するようにアラート ポリシーを構成できます。フィルタベースのアラート ポリシーは、Google Cloud コンソールで表示または変更することはできません。モニタリング フィルタを使用するポリシーの例については、指標率をご覧ください。
アラート ポリシーとインシデントを管理する
アラート ポリシーの構成後、Monitoring はそのポリシーの条件を継続的にモニタリングします。特定の期間のみの条件をモニタリングするようにアラート ポリシーを構成することはできません。特定の期間にアラート ポリシーを無効にする場合は、スヌーズを作成します。
インシデントが未解決のまま残っていて、Monitoring で指標ベースのポリシーの条件が満たされなくなったと判断された場合、Monitoring は自動的にインシデントを終結させて、終結に関する通知を送信します。
料金
一般に、Cloud Monitoring システムの指標は無料であり、外部システム、エージェント、またはアプリケーションの指標はそうではありません。課金対象の指標は、取り込まれたバイト数とサンプル数のいずれかによって課金されます。
Cloud Monitoring の料金の詳細については、次のドキュメントをご覧ください。
取り込まれるトレーススパンまたはログの数をモニタリングする方法や、ログエントリに特定のコンテンツが含まれている場合に通知を受ける方法については、次のドキュメントをご覧ください。
次のステップ
通知レイテンシと、アラート ポリシーのパラメータの選択が通知送信のタイミングに及ぼす影響については、指標ベースのアラート ポリシーの動作をご覧ください。
指標ベースのポリシー サンプルの一覧については、アラート ポリシー サンプルの概要をご覧ください。