ログをモニタリングする

このドキュメントでは、Cloud Monitoring を使用してログデータのトレンドを確認し、記述した条件の発生時に通知する方法について説明します。Cloud Monitoring にログデータのデータを提供するため、Logging は次の機能をサポートしています。

• ログエントリからカスタム指標を生成できます。これらの指標は、ログベースの指標と呼ばれます。指標ベースのアラート ポリシーを作成して、ログベースの指標が条件を満たした場合に通知することもできます。詳細については、ログベースの指標を使用してログエントリ データを可視化するをご覧ください。

• アラート ポリシーを使用すると、ログエントリにメッセージが表示されたタイミングをほぼリアルタイムでモニタリングできます。このようなアラート ポリシーは、ログベースのアラート ポリシーと呼ばれます。詳細については、メッセージの個々のログエントリをモニタリングするをご覧ください。

• ログ分析で SQL クエリを作成し、クエリの結果をモニタリングするアラート ポリシーを作成できます。このようなアラート ポリシーは、SQL ベースのアラート ポリシーと呼ばれます。詳細については、SQL クエリ結果をモニタリングするをご覧ください。

  SQL ベースのアラート ポリシーは公開プレビュー版です。

このドキュメントの残りの部分では、これらの 3 つのアラート ポリシーの違いと、承認、費用、上限について説明します。

ログベースの指標を使用してログエントリ データを可視化する

一定期間内のログデータの繰り返しイベントをモニタリングする場合は、ログベースの指標を使用します。ログベースの指標は、ログデータから数値データを生成します。次のいずれかを行う場合に適しています。

• ログデータ内で警告やエラーなどのメッセージの発生回数をカウントし、しきい値を超えた場合に通知を受け取る。
• ログデータのレイテンシ値といったデータの傾向を監視し、許容できない値に変化した場合に通知を受け取る。
• 抽出した数値データをグラフにして表示する。

ログベースの指標はログデータから数値データを生成するため、アラート ポリシーでログベースの指標を使用して、グラフに表示できます。ログベースの指標のアラート ポリシーとグラフの作成については、ログベースの指標の通知の構成をご覧ください。

Cloud Monitoring には、事前定義された一連のログベースの指標が用意されており、それで独自の指標を定義できます。システム定義のログベースの指標のリストを表示するには、次の add_circle ボタンをクリックします。

システム定義のログベースの指標

次の表の指標タイプの文字列には、logging.googleapis.com/ という接頭辞を付ける必要があります。この接頭辞は表内で省略されています。 ラベルをクエリする場合は、metric.labels. 接頭辞を使用します（例: metric.labels.LABEL="VALUE"）。

指標タイプリリース ステージ （リソース階層レベル） 表示名
種類、タイプ、単位 モニタリング対象リソース	説明 ラベル
billing/bytes_ingested GA  （プロジェクト） ログバケットにストリーミングされたバイト数
DELTA, INT64, By グローバル	インデックス登録、クエリ、分析のためにログバケットにストリーミングされたバイト数。最大 30 日分の保存容量が含まれます。60 秒ごとにサンプリングされます。サンプリング後、データは最長 300 秒間表示されません。 resource_type: ログエントリのモニタリング対象リソースタイプ。
billing/bytes_stored ベータ版 （プロジェクト） ロギングの保持
GAUGE, INT64, By グローバル	デフォルトの 30 日を超えて保持されているログのボリューム。ログバケットの保持期間が 30 日を超えない場合、データは存在しません。ログバケットの保持期間が 30 日に短縮されている場合、この指標の値はゼロになることがあります。60 秒ごとにサンプリングされます。サンプリング後、データは最長 300 秒間表示されません。 data_type: このフィールドは、ここで報告されたログのボリュームが、デフォルトの 30 日をすぎた保持に対して課金されることを示します。報告されたすべての保持の data_type は「CHARGED」に設定されます。 log_bucket_location: ログバケットの配置場所。 log_bucket_id: ログバケットの ID。
billing/log_bucket_bytes_ingested ベータ版  （プロジェクト） ログバケットにストリーミングされたバイト数
DELTA, INT64, By グローバル	インデックス登録、クエリ、分析のためにログバケットにストリーミングされたバイト数。最大 30 日分の保存容量が含まれます。60 秒ごとにサンプリングされます。サンプリング後、データは最長 300 秒間表示されません。 log_source: ログの取得元となるリソース コンテナ。 resource_type: ログバケットにストリーミングされたログのモニタリング対象リソースタイプ。 log_bucket_location: ログバケットが存在するロケーション。 log_bucket_id: ログバケットの ID。
billing/log_bucket_monthly_bytes_ingested ベータ版  （プロジェクト） 毎月ログバケットにストリーミングされるバイト数
GAUGE, INT64, By グローバル	今月初来のインデックス登録、クエリ、分析のためにログバケットにストリーミングされたバイト数。最大 30 日分の保存容量が含まれます。1,800 秒ごとにサンプリングされます。サンプリング後、データが表示可能になるまで、最長で 6,000 秒かかります。 log_source: ログの取得元となるリソース コンテナ。 resource_type: ログバケットにストリーミングされたログのモニタリング対象リソースタイプ。 log_bucket_location: ログバケットが存在するロケーション。 log_bucket_id: ログバケットの ID。
billing/monthly_bytes_ingested GA  （プロジェクト） ログバケットにストリーミングされた 1 か月のバイト数
GAUGE, INT64, By グローバル	インデックス登録、クエリ、分析のためにログバケットにストリーミングされた 1 か月のバイト数。最大 30 日分の保存容量が含まれます。1,800 秒ごとにサンプリングされます。サンプリング後、データが表示可能になるまで、最長で 6,000 秒かかります。 resource_type: ログエントリのモニタリング対象リソースタイプ。
byte_count GA （プロジェクト） ログバイト
DELTA, INT64, By	少なくとも 1 つのログバケットに保存されているログエントリの合計バイト数（直接書き込まれたログエントリ、または project-sink を介してこのプロジェクトにルーティングされたログエントリ）。60 秒ごとにサンプリングされます。 log: ログの名前。 severity: ログエントリの重要度。
dropped_log_entry_count 非推奨  （プロジェクト） ログベースの指標のエラー数（非推奨）
DELTA, INT64, 1	代わりに「logging.googleapis.com/logs_based_metrics_error_count」を使用してください。60 秒ごとにサンプリングされます。 log: ログの名前。
exports/byte_count GA （プロジェクト） エクスポートされたログのバイト数
DELTA, INT64, By logging_sink	エクスポートされたログエントリのバイト数。60 秒ごとにサンプリングされます。サンプリング後、データは最長 420 秒間表示されません。
exports/error_count GA  （プロジェクト） エクスポートされたログエントリの失敗数
DELTA, INT64, 1 logging_sink	エクスポートできなかったログエントリの数。60 秒ごとにサンプリングされます。サンプリング後、データは最長 420 秒間表示されません。
exports/log_entry_count GA  （プロジェクト） エクスポートされたログエントリ
DELTA, INT64, 1 logging_sink	エクスポートされたログエントリの数。60 秒ごとにサンプリングされます。サンプリング後、データは最長 420 秒間表示されません。
log_entry_count GA （プロジェクト） ログエントリ
DELTA, INT64, 1	少なくとも 1 つのログバケットに保存されているログエントリの数（直接書き込まれたログエントリ、または project-sink を介してこのプロジェクトにルーティングされたログエントリ）。デフォルトでは、ログエントリは 30 日間保存されます。除外されたログはカウントされません。60 秒ごとにサンプリングされます。 log: ログの名前。 severity: ログエントリの重要度。
logs_based_metrics_error_count GA  （プロジェクト） ログベースの指標のエラー
DELTA, INT64, 1	ログバケットに保存されているものの、システム定義またはユーザー定義のログベースの指標から除外されるログエントリの数（直接書き込まれたログエントリ、または project-sink を介してこのプロジェクトにルーティングされたログエントリ）。この状況は、ログエントリのタイムスタンプが、実際の受信時刻より 24 時間以上前または 10 分後である場合に発生します。60 秒ごとにサンプリングされます。 log: ログの名前。
metric_label_cardinality ベータ版  （プロジェクト） ログベースの指標のアクティブなカーディナリティの数（ラベル別）
GAUGE, INT64, 1 指標	ログベースの指標の各指標ラベルのカーディナリティ見積もり。 見積りは約 25 時間にわたって計算されます。60 秒ごとにサンプリングされます。サンプリング後、データは最長 270 秒間表示されません。 label: 指標ラベルの名前。
metric_label_throttled ベータ版  （プロジェクト） ログベースの指標ラベルの絞り込みステータス
GAUGE, BOOL,  指標	カーディナリティの制限を超えたために、ログベースの指標で指標ラベルがドロップされていることを示します。60 秒ごとにサンプリングされます。サンプリング後、データは最長 270 秒間表示されません。 label: 指標ラベルの名前。
metric_throttled GA  （プロジェクト） ログベースの指標の絞り込みステータス
GAUGE, BOOL,  指標	アクティブな時系列（カーディナリティ）の上限を超えたために、ログベースの指標でラベルまたはポイントがドロップされていることを示します。60 秒ごとにサンプリングされます。サンプリング後、データは最長 270 秒間表示されません。
time_series_count ベータ版  （プロジェクト） ログベースの指標のアクティブな時系列（カーディナリティ）の数
GAUGE, INT64, 1 指標	ログベースの指標のアクティブな時系列（カーディナリティ）の推定。指標ラベルのみがカウントされ、推定は約 25 時間で計算されます。60 秒ごとにサンプリングされます。サンプリング後、データは最長 270 秒間表示されません。

表の生成日時: 2025-06-26 13:43:55 UTC

ユーザー定義のログベースの指標

ログデータから数値データを抽出するには、ログベースの指標を作成します。ユーザー定義のログベースの指標は、含まれるログエントリと除外されたログエントリの両方から値を計算します。

デフォルトでは、ユーザー定義のログベースの指標は、 Google Cloud プロジェクトのログルーターで受信したすべてのログエントリからデータを収集しますが、特定のログバケットにルーティングされたログエントリからデータを収集するログベースの指標を定義できます。

• プロジェクト レベルのログベースの指標を定義して使用する方法については、ログベースの指標の使用をご覧ください。
• バケットレベルのログベースの指標の定義と使用については、ログバケットのログベースの指標をご覧ください。

独自のログベースの指標を定義すると、料金が発生する可能性があります。指標の取り込みに関連する費用の詳細については、課金対象の指標をご覧ください。

メッセージの個々のログエントリをモニタリングする

ログエントリに特定のメッセージが発生するたびに通知を受け取るには、ログベースのアラート ポリシーを使用します。ログベースのアラート ポリシーは、次のようにセキュリティ関連のイベントをログエントリに記録するのに便利です。

• 人間のユーザーがサービス アカウントのセキュリティ キーにアクセスするようなイベントが監査ログに表示されたとき。
• アプリケーションがログにデプロイ メッセージを書き込み、デプロイの変更がログに記録されたとき。

ログベースのアラート ポリシーは、まれなイベントと重要なイベントの両方に役立ちます。トレンドやパターンではなく、何かが起こったことを知ることが大事です。

ログベースのアラート ポリシーはプロジェクトで定義され、次の条件に該当する場合にログエントリをスキャンします。

• 課金が有効になっている。
• ログエントリの発生元がプロジェクトである。

• ログエントリの発生元プロジェクトのシンク、またはログエントリのルーティング先プロジェクトのシンクにより、ログエントリがログバケットにルーティングされる。

  たとえば、プロジェクト A でログエントリが発生したとします。プロジェクト A のログシンクによってログエントリがログバケットにルーティングされると、プロジェクト A で定義されたログベースのアラート ポリシーでログエントリがスキャンされます。

  2 つ目の例として、プロジェクト X でログエントリが発生し、プロジェクト X のログシンクによってログエントリがプロジェクト Y にルーティングされたとします。プロジェクト Y のシンクによってログエントリがログバケットにルーティングされると、プロジェクト X とプロジェクト Y で定義されたログベースのアラート ポリシーでログエントリがスキャンされます。

ログベースのアラート ポリシーを使用して、フォルダ、請求先アカウント、組織で発生したログエントリをモニタリングしたり、ログバケットに保存されていないログエントリをモニタリングしたりすることはできません。集約シンクを作成すると、それらのシンクでログエントリがインターセプトされ、ログエントリの発生元プロジェクトのシンクによってログエントリがルーティングされなくなる可能性があります。

ログベースのアラート ポリシーの作成については、ログベースのアラート ポリシーを構成するをご覧ください。

SQL クエリ結果をモニタリングする

ログ分析を使用してログエントリ データに対して SQL クエリを実行するアラート ポリシーを構成できます。これらのタイプのアラート ポリシーは、ログベースのアラート ポリシーでは評価できないパターン（ログエントリの複雑なパターンやログデータの集計など）に基づいて通知を受け取る場合に効果的です。詳細については、アラート ポリシーを使用して SQL クエリ結果をモニタリングするをご覧ください。

アラート オプションの比較

このセクションでは、ログベースの指標に基づいて構築されたアラート ポリシー、ログベースのアラート ポリシー、SQL ベースのアラート ポリシーを比較します。

サマリー テーブル

次の表に、アラート手法の概要と、追加情報へのリンクを示します。

指標ベースのアラート ポリシー	ログベースのアラート ポリシー	SQL ベースのアラート ポリシー	詳細
ログエントリから派生した指標に基づく	個々のログエントリ内の文字列に基づく	ログエントリに対する SQL クエリによって返されたテーブルに基づく	ログベースの指標 ログベースのアラート SQL ベースのアラート
時系列でトレンドを通知するために使用される	ログに特定のメッセージがあるときに通知するために使用される	ログエントリのウィンドウ内のパターンを通知するために使用される	ログベースの指標 ログベースのアラート SQL ベースのアラート
次から計算 含まれるログエントリ（システム定義のログベースの指標） 含まれるログエントリと除外されたログエントリ（ユーザー定義のログベースの指標）	含まれるログエントリのみを照合する	スライディング ウィンドウ内のログエントリから計算される	使用可能なログエントリ SQL ベースのアラート
スコーピング プロジェクトの指標スコープ内のすべてのプロジェクトの指標に対して機能する	次の条件を満たすログエントリに対して機能する ポリシーが定義されているプロジェクトで発生したログエントリである。 ログエントリの発生元プロジェクトのシンク、またはログエントリのルーティング先プロジェクトのシンクにより、ログエントリがログバケットにルーティングされる。	リンクされたデータセットからアクセスできるログビューに対して機能する。リンクされたデータセットがどのプロジェクトにあるかは問わない。	指標スコープ リンクされたデータセット
指標の値が指定した期間に条件を満たすとインシデントが作成される	特定のログエントリがフィルタに一致するたびにインシデントが作成される	クエリ結果のテーブルが条件を満たすとインシデントが作成されます。	インシデントと通知
Monitoring で作成され、管理される	Logging で作成され、 Monitoring で管理される	ログ分析で作成され、Monitoring で管理される	アラート ポリシーの作成と管理 SQL ベースのアラート
Monitoring で表示される	Monitoring で表示される	Monitoring で表示される	アラート ポリシーの表示
Monitoring でサポートされている任意の通知チャンネルを使用できる	Monitoring でサポートされている任意の通知チャンネルを使用できる	Monitoring でサポートされている任意の通知チャンネルを使用できる	通知チャンネル

使用可能なログエントリ

ユーザー定義のログベースの指標は、 Google Cloud プロジェクトに適用されている包含フィルタまたは除外フィルタにかかわらず、 Google Cloud プロジェクトの Logging API によって受信されたすべてのログエントリから計算されます。ユーザー定義のログベースの指標に基づいてアラート ポリシーを作成すると、ポリシーはすべてのログエントリからデータをモニタリングします。

システム定義のログベースの指標は、Google Cloud プロジェクトのログバケットに保存されているログエントリからのみ計算されます。明示的に除外されているログは、これらの指標には含まれません。システム定義のログベースの指標に基づいてアラート ポリシーを作成すると、ポリシーは、含まれるログエントリからのデータのみをモニタリングします。

ログベースのアラート ポリシーはプロジェクトで定義され、次の条件に該当する場合にログエントリをスキャンします。

• 課金が有効になっている。
• ログエントリの発生元がプロジェクトである。

• ログエントリの発生元プロジェクトのシンク、またはログエントリのルーティング先プロジェクトのシンクにより、ログエントリがログバケットにルーティングされる。

  たとえば、プロジェクト A でログエントリが発生したとします。プロジェクト A のログシンクによってログエントリがログバケットにルーティングされると、プロジェクト A で定義されたログベースのアラート ポリシーでログエントリがスキャンされます。

  2 つ目の例として、プロジェクト X でログエントリが発生し、プロジェクト X のログシンクによってログエントリがプロジェクト Y にルーティングされたとします。プロジェクト Y のシンクによってログエントリがログバケットにルーティングされると、プロジェクト X とプロジェクト Y で定義されたログベースのアラート ポリシーでログエントリがスキャンされます。

ログベースのアラート ポリシーを使用して、フォルダ、請求先アカウント、組織で発生したログエントリをモニタリングしたり、ログバケットに保存されていないログエントリをモニタリングしたりすることはできません。集約シンクを作成すると、それらのシンクでログエントリがインターセプトされ、ログエントリの発生元プロジェクトのシンクによってログエントリがルーティングされなくなる可能性があります。

SQL ベースのアラート ポリシーは、ログバケットのログビューに対してクエリを実行します。これらのログバケットは、ログ分析を使用するようにアップグレードしてから、BigQuery データセットにリンクする必要があります。SQL ベースのアラート ポリシーの詳細については、アラート ポリシーを使用して SQL クエリの結果をモニタリングするをご覧ください。

複数のプロジェクトの指標をモニタリング

指標スコープを構成することで、複数のプロジェクトの指標をモニタリングできます。指標スコープは、モニタリングしているすべてのプロジェクトとアカウントを一覧表示します。スコーピング プロジェクトは、指標のスコープをホストします。スコーピング プロジェクトには、指標スコープ用に作成したアラート ポリシーとその他の構成が保存されます。指標スコープのスコーピング プロジェクトは、 Google Cloud コンソール プロジェクト選択ツールで選択したプロジェクトです。

ログベースの指標に基づくアラート ポリシー（他の指標に基づくアラート ポリシーなど）は、スコーピング プロジェクトの指標スコープ内のすべてのプロジェクトに対して機能します。

指標スコープは、ログエントリに基づくアラート ポリシー（ログベースや SQL ベースのポリシーなど）には関係ありません。

マルチ プロジェクト指標のスコープを含む指標のスコープとスコーピング プロジェクトの詳細については、以下をご覧ください。

• 指標スコープ
• 複数のプロジェクトの指標を表示

インシデントと通知

アラート ポリシーの条件が満たされると、Monitoring によってインシデントが開かれ、アラート ポリシーの通知チャンネルに通知が送信されます。インシデントの詳細を表示するには、通知メッセージの [インシデントを表示] をクリックするか、Monitoring の [インシデント] ページに直接移動します。

指標ベースのアラート ポリシーのインシデント

アラートの動作で説明しているように、ログベースの指標に基づくアラート ポリシーは、Monitoring の他のすべての指標ベースのアラート ポリシーと同様にインシデントと通知を作成します。指標ベースのアラート ポリシーのインシデント管理の詳細については、指標ベースのアラート ポリシーのインシデントをご覧ください。

ログベースのアラート ポリシーのインシデント

ログベースのアラート ポリシーは、指標ベースのアラート ポリシーではありません。ログエントリがログベースのアラート ポリシーの条件を満たすと、Monitoring は次のようにインシデントおよび通知を作成します。

• アラートクエリに一致するログエントリを初めて Cloud Logging がログバケットに書き込むと、インシデントが作成され、通知が送信されます。その後、一致する別のログエントリが書き込まれると、前のインシデントがクローズされている場合にのみ新しいインシデントが作成されます。ただし、クローズされたインシデントが完全に削除されるまで、最大 3 分かかることがあります。インシデントを閉じてから 3 分以内に一致するログエントリを受け取った場合、システムは新しいインシデントを作成せずに、そのインシデントを再開する可能性があります。

• ログベースのアラート ポリシーを作成するときに、通知間の最小時間を指定できます。たとえば、通知の間隔として 10 分を選択します。その期間内にログベースのアラート ポリシーの条件が 2 回満たされた場合、1 件の通知だけを受け取ります。

  ログベースのアラート ポリシーのインシデントの最大レートは、5 分あたり 1 件です。ログベースのアラート ポリシーのクエリでラベル値が抽出される場合は、抽出された値の組み合わせごとに独自のインシデント タイムラインが表されます。たとえば、ログベースのアラート ポリシーがラベルの値を抽出し、ラベルに 2 つの値が設定されているとします。この構成では、同じ 5 分間にラベル値ごとに 1 つずつ、2 つのインシデントを開くことが可能です。

• ログベースのアラート ポリシーごとに 1 日あたり 20 件のインシデントに制限されています。この上限に達した場合、その日の制限に達したというメッセージが通知に含まれます。

• 自動クローズ期間が終了すると、インシデントは自動的にクローズされます。デフォルトの自動クローズ期間は 7 日間です。

  自動クローズ期間には、インシデントの原因が再発しない状態で経過する必要がある時間を指定します。このため、インシデントが対応待ちで、その原因が再発した場合、インシデントは自動クローズ期間よりも長くオープン状態になることがあります。

ログベースのアラート ポリシーのインシデントの管理の詳細については、ログベースのアラート ポリシーのインシデントを管理するをご覧ください。

SQL ベースのアラート ポリシーのインシデント

SQL ベースのアラート ポリシーの場合、SQL クエリの結果がポリシーで指定された条件を初めて満たすと、Cloud Monitoring はインシデントを作成します。各アラート ポリシーには、対応待ちのインシデントが 1 つだけあります。インシデントが対応待ちの間に条件が再度満たされても、Monitoring が追加のインシデントを作成することも、追加の通知を送信することもありません。インシデントの終結期間を短く構成するか、インシデントを自分で終結しない限り、Monitoring は SQL ベースのインシデントを 7 日後に終結します。

SQL ベースのアラート ポリシーのインシデントの管理の詳細については、SQL ベースのアラート ポリシーのインシデントを管理するをご覧ください。

アラート ポリシーの作成と管理

Cloud Monitoring では、他の指標ベースのアラート ポリシーと同様に、ログベースの指標に基づいてアラート ポリシーの作成、変更、削除を行います。詳細については、ポリシーの管理をご覧ください。

ログベースのアラート ポリシーは、ログ エクスプローラまたは Cloud Monitoring API を使用して作成できます。ログベースのアラート ポリシーの変更と削除は、Monitoring または Cloud Monitoring API で行います。詳細については、ログベースのアラート ポリシーの管理をご覧ください。

SQL ベースのアラート ポリシーは、ログ分析または Cloud Monitoring API を使用して作成できます。SQL ベースのアラート ポリシーの変更と削除は、Monitoring または Cloud Monitoring API を使用して行います。詳細については、アラート ポリシーを使用して SQL クエリ結果をモニタリングするをご覧ください。

アラート ポリシーの表示

Monitoring の [ポリシー] ページには、 Google Cloud プロジェクトのすべてのアラート ポリシーが表示されます。このリストには、ログベースの指標とログベースのアラート ポリシーを使用するポリシーが含まれています。

1. Google Cloud コンソールで、notifications [アラート] ページに移動します。

   [アラート] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

2. [すべてのポリシーを見る] を選択します。

ログベースのアラート ポリシーは、[タイプ] 列の値が Logs であるリストに表示されます。指標によるアラート ポリシー（ログベースの指標を含む）は、[タイプ] 列の値が Metrics であるリストに表示されます。SQL ベースのアラート ポリシーは、[タイプ] 列の値が SQL であるリストに表示されます。次のスクリーンショットは、ポリシーリストの抜粋を示しています。

通知チャンネル

任意のタイプのアラート ポリシーから、Monitoring でサポートされている任意の通知チャンネルに通知を送信できます。アラート ポリシーで使用する前に、これらのチャンネルを構成する必要があります。

詳細については、通知チャンネルの管理をご覧ください。

承認の要件

ログベースの指標またはログベースのアラート ポリシーを使用するには、Cloud Logging と Cloud Monitoring の両方の承認が必要です。

• ユーザー定義のログベースの指標については、ログベースの指標の権限をご覧ください。

• ログベースのアラート ポリシーについては、ログベースのアラート ポリシーの権限をご覧ください。

• SQL ベースのアラート ポリシーについては、SQL ベースのアラート ポリシーの権限をご覧ください。

コストと制限

独自のログベースの指標を定義すると、以下が適用されます。

• ユーザー定義のログベースの指標の数と構造には上限があります。これらの上限の詳細については、ログベースの指標の制限をご覧ください。
• ユーザー定義のログベースの指標には料金が発生する場合があります。指標の取り込みに関連する費用の詳細については、課金対象の指標をご覧ください。
• SQL ベースのアラート ポリシーは、 Google Cloud プロジェクトの BigQuery 予約で実行されます。BigQuery の予約に対して料金が発生する場合があります。BigQuery 予約に関連する費用の詳細については、BigQuery の料金をご覧ください。

ログベースの指標に基づくアラート ポリシーの使用に伴う課金はありません。

アラート ポリシーに関連する次の Monitoring の上限が適用されます。

カテゴリ	値	ポリシータイプ1
指標スコープごとのアラート ポリシー（指標とログの合計）2	500	指標、ログ
指標ベースのアラート ポリシーあたりの条件数	6	指標
SQL ベースのアラート ポリシーごとの条件（公開プレビュー版）	1	SQL
SQL ベースのアラート ポリシーのクエリ実行時間の最大値（公開プレビュー版）	5 分	SQL
指標の不在条件が評価される 最大期間 3	1 日	指標
指標のしきい値条件が評価される 最大期間 3	23 時間 30 分	指標
指標しきい値の条件で 使用するフィルタの最大長	2,048 Unicode 文字	指標
予測条件でモニタリングされる 時系列の最大数	64	指標
最小予測ウィンドウ	1 時間（3,600 秒）	指標
最大予測期間	2.5 日（216,000 秒）	指標
1 アラート ポリシーあたりの通知チャンネル数	16	すべて
ログベースのアラートのインシデントの最大レート4	5 分ごとに 1 件のインシデント	ログ
ログベースのアラートのインシデントの最大数	ログベースのアラート ポリシーごとに 1 日あたり 20 件のインシデント	ログ
インシデントあたりの通知の最大数（ログベースのアラートの場合）5	インシデントごとに 1 日あたり 20 件の通知	ログ
プロジェクトあたりの同時にトリガーされるアラート ポリシーの最大数	80,000	すべて
1 アラート ポリシーあたりの 同時対応待ちインシデントの最大数	1,000	すべて
新規データのないインシデントが 自動的に終了するまでの期間	7 日間	指標、SQL
手動で終了していない場合のインシデントの最長時間	7 日間	ログ
終了したインシデントの保持	13 か月	該当なし
対応待ちのインシデントの保持	期限なし	該当なし
指標スコープごとの通知チャンネル	4,000	該当なし
スヌーズあたりのアラート ポリシーの最大数	16	すべて
スヌーズの保持	13 か月	該当なし

¹指標: 指標データに基づくアラート ポリシー。ログ: ログメッセージに基づくアラート ポリシー（ログベースのアラート）
²Apigee と Apigee ハイブリッドは Cloud Monitoring と緊密に統合されています。すべての Apigee サブスクリプション レベル（Standard、Enterprise、Enterprise Plus）のアラート数の上限は、Cloud Monitoring と同じで、1 指標スコープあたり 500 です。
³条件が評価する最大期間は、アライメント期間と期間時間枠の値の合計です。たとえば、アライメント期間が 15 時間、期間時間枠が 15 時間に設定されている場合、30 時間分のデータが条件を評価するために必要です。
⁴ログベースのアラート ポリシーのクエリでラベル値が抽出される場合は、抽出された値の組み合わせごとに独自のインシデント タイムラインが表されます。たとえば、ログベースのアラート ポリシーがラベルの値を抽出し、ラベルに 2 つの値が設定されているとします。この構成では、同じ 5 分間にラベル値ごとに 1 つずつ、2 つのインシデントを作成できます。
⁵ログベースのアラートの場合、フィルタに一致するログエントリが受信され、最新の通知から 5 分以上経過すると、Monitoring は対応待ちのインシデントに関する新しい通知を送信します。1 日に 1 件のインシデントに対して送信される通知は最大 20 件です。各通知は、アラート ポリシー用に構成されたすべての通知チャンネルに送信されます。