このドキュメントでは、アプリケーションが失敗した場合や、アプリケーションのパフォーマンスが定義された基準を満たさない場合に、通知を受け取る方法について説明します。
アラートの仕組み
Cloud Monitoring アラート プロセスは、次の 3 つの部分で構成されています。
アラート ポリシー、アラートを受け取る状況とインシデントの通知方法を記述します。アラート ポリシーは、Cloud Monitoring によって保存された時系列データまたは Cloud Logging によって保存されたログをモニタリングできます。データがアラート ポリシーの条件を満たすと、Cloud Monitoring はインシデントを作成し、通知を送信します。
各インシデントは、モニタリングされたデータのタイプと条件が満たされた時点の記録です。この情報は、インシデントの原因となった問題のトラブルシューティングに役立ちます。
通知チャネルは、Cloud 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を使用して新しいアラート ポリシーを構成することもできます。
統合と推奨アラートの使用
Cloud Monitoring には、Google Cloud サービスとサードパーティ統合のアラート ポリシーを作成できるビルド済みパッケージが用意されています。パッケージには、推奨されるアラート ポリシー、サンプル ダッシュボード、サービスの主な指標が含まれます。これらのパッケージは、Google Kubernetes Engine、Compute Engine、Cloud SQL などの Google Cloud サービスと、MongoDB、Kafka、Elasticsearch などの一般的なサードパーティ統合で使用できます。
パッケージをインストールすると、パッケージの推奨アラートを有効にできます。アラートを有効にする場合は、通知チャネルを指定して、アラートのデフォルト構成を使用するか、必要に応じて構成を調整します。アラート ポリシーは、すぐにターゲットのモニタリングを開始します。追加のユーザー入力は必要ありません。
推奨アラート ポリシーは、新しいサービスをデプロイし、重要な指標に関するアラートを送信する場合に役立ちます。たとえば、Cloud SQL 統合パッケージには、失敗したインスタンスと遅いトランザクションに関する推奨アラートが付属しています。
アラートの統合の詳細については、サードパーティ アプリケーションのモニタリングをご覧ください。
Cloud Monitoring を使用する
アラート ポリシーを作成して、その条件タイプを、指標タイプや時系列などの他のコンポーネントとともに選択する場合は、Cloud Monitoring を使用します。次の表に、アラート ポリシーの作成時に使用できるさまざまなタイプの条件を示します。
| Condition Type | 説明 | 例 |
|---|---|---|
| 指標しきい値条件 | 指標しきい値条件は、指標の値が特定の期間時間枠のしきい値を上回る、または下回るときにトリガーされます。 詳細については、指標しきい値のアラート ポリシーの作成と API を使用してアラート ポリシーを作成するをご覧ください。 |
10 分を超える連続する 5 回の稼働時間チェックで、リソース レイテンシが 500 ミリ秒以上の場合にアラートを送信するアラート ポリシーが必要です。 |
| 指標の不在条件 | 指標の不在条件は、モニタリング対象の時系列に特定の期間時間枠のデータがない場合にトリガーされます。期間時間枠は、Google Cloud コンソールで条件を作成する場合には最大 24 時間、Cloud Monitoring API では 24.5 時間です。 詳細については、指標の不在アラート ポリシーの作成と 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 ページへのリンクを表示するように通知を構成できます。例を含むドキュメントの詳細については、ユーザー定義のドキュメントでアラートにアノテーションを付けるをご覧ください。
クエリ言語
アラート ポリシーでクエリ言語とフィルタを使用すると、指標の評価をより詳細に制御できます。Cloud Monitoring では、次のクエリタイプがサポートされています。
PromQL アラートを使用すると、Prometheus クエリ言語を使用するようにアラート ポリシーを構成できます。PromQL クエリでは、指標の組み合わせ、比率、スケーリングしきい値など、あらゆる種類の有効な Prometheus Query Language 式を使用できます。PromQL アラートでは、完全に Google Cloud CLI ベースのアラートを実行でき、外部アラート インフラストラクチャへの依存がなくなります。詳細については、Cloud Monitoring の PromQL と PromQL のアラート ポリシーをご覧ください。
Monitoring Query Language（MQL）は、表現力の高いテキストベースのインターフェースであり、時系列データの取得、フィルタリング、操作を行うことができます。Monitoring Query Language アラート オペレーションを含む条件でアラート ポリシーを作成できます。詳細については、Monitoring Query Language の概要と MQL のアラート ポリシーをご覧ください。
モニタリング フィルタを使用すると、フィルタベースの指標率を使用するようにアラート ポリシーを構成できます。フィルタベースのアラート ポリシーは、Google Cloud コンソールで表示または変更することはできません。モニタリング フィルタを使用するポリシーの例については、指標率をご覧ください。
アラート ポリシーとインシデントを管理する
アラート ポリシーが有効になると、Cloud Monitoring はそのポリシーの条件を継続的にモニタリングします。特定の期間のみ条件をモニタリングするようにアラート ポリシーを構成することはできません。特定の期間にアラート ポリシーを無効にする場合は、スヌーズを作成します。
インシデントが未解決のまま残っていて、Monitoring で指標ベースのポリシーの条件が満たされなくなったと判断された場合、Monitoring は自動的にインシデントを終結させて、終結に関する通知を送信します。
アラート ポリシーに関連する費用
料金の詳細については、Google Cloud のオペレーション スイートの料金をご覧ください。
次のステップ
通知レイテンシと、アラート ポリシーのパラメータの選択が通知送信のタイミングに及ぼす影響については、指標ベースのアラート ポリシーの動作をご覧ください。
指標ベースのポリシーの例の一覧については、アラート ポリシーの例の概要をご覧ください。
取り込まれたトレーススパンまたはログの数をモニタリングする方法、または特定のコンテンツがログエントリに含まれるときに通知する方法については、以下をご覧ください。