ログをモニタリングする

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

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

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

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

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

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

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

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

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

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

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

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

次の表の指標タイプの文字列には、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 日に短縮されている場合、この指標の値は 0 になることがあります。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 日分の保存容量が含まれます。1800 秒ごとにサンプリングされます。サンプリング後、データは最長 6000 秒間表示されません。 log_source: ログの取得元となるリソース コンテナ。 resource_type: ログバケットにストリーミングされたログのモニタリング対象リソースタイプ。 log_bucket_location: ログバケットが存在するロケーション。 log_bucket_id: ログバケットの ID。
billing/monthly_bytes_ingested ^GA  （プロジェクト） ログバケットにストリーミングされた 1 か月のバイト数
GAUGE、INT64、By グローバル	インデックス登録、クエリ、分析のためにログバケットにストリーミングされた 1 か月のバイト数。最大 30 日分の保存容量が含まれます。1800 秒ごとにサンプリングされます。サンプリング後、データは最長 6000 秒間表示されません。 resource_type: ログエントリのモニタリング対象リソースタイプ。
byte_count ^一般提供  （プロジェクト） ログバイト
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 ^一般提供  （プロジェクト） エクスポートされたログのバイト数
DELTA、INT64、By logging_sink	エクスポートされたログエントリのバイト数。60 秒ごとにサンプリングされます。サンプリング後、データは最長 420 秒間表示されません。
exports/error_count ^一般提供  （プロジェクト） エクスポートされたログエントリの失敗数
DELTA、INT64、1 logging_sink	エクスポートできなかったログエントリの数。60 秒ごとにサンプリングされます。サンプリング後、データは最長 420 秒間表示されません。
exports/log_entry_count ^一般提供  （プロジェクト） エクスポートされたログエントリ
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 ^一般提供  （プロジェクト） ログベースの指標のエラー
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 秒間表示されません。

表の生成日時: 2024-12-05 22:01:39 UTC

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

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

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

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

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

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

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

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

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

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

指標ベースのアラート ポリシーを構成して、ログベースのアラート ポリシーをシミュレートできます。これを行うには、ログベースの指標を定義し、しきい値が 1 の指標ベースのアラート ポリシーでその指標を使用します。ログベース アラート ポリシーは、ログを作成しなくてもその動作を提供し、指標に基づくアラート ポリシーを構成します。

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

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

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

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

サマリー テーブル

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

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

使用可能なログ

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

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

ログベースのアラート ポリシーは、プロジェクトで生成された含まれるログに対してのみ機能します。ログベースのアラート ポリシーを使用して、除外されたログ内のメッセージや、フォルダや組織などの他のリソースからのログについて通知することはできません。

ログベースの指標とログベースのアラート ポリシーは、個々のバケットではなく、Google Cloud プロジェクトのスコープで動作します。

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

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

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

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

ログベースのアラート ポリシーは、指標スコープでは機能しません。プロジェクトのログは指標スコープに含まれません。ログベースのアラート ポリシーは、現在の Google Cloud プロジェクトで生成されたログエントリ、または現在のプロジェクトに転送されたログエントリを評価し、ログバケットに保存します。

SQL ベースのアラート ポリシーは、指標スコープでは機能しません。

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

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

インシデントと通知

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

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

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

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

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

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

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

  ログベースのアラート ポリシーの通知の最大レートは、ログベースのアラート ポリシーごとに 5 分あたり 1 件の通知です。ただし、ログベースのアラート ポリシーのクエリでラベル値が抽出される場合は、抽出された値の組み合わせごとに独自の通知タイムラインが表されます。たとえば、ログベースのアラート ポリシーがラベルの値を抽出するとします。ラベルに 2 つの値を指定できるとします。この構成では、同じ 5 分間にラベル値ごとに 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 ベースのアラート ポリシーは、Log Analytics または Cloud Monitoring API を使用して作成できます。SQL ベースのアラート ポリシーの変更と削除は、Monitoring または Cloud Monitoring API を使用して行います。詳細については、アラート ポリシーを使用して SQL クエリ結果をモニタリングするをご覧ください。

アラート ポリシーの表示

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

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

   [アラート] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [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
指標の不在条件が評価される 最大期間 ^3	1 日	指標
指標のしきい値条件が評価される 最大期間 ^3	23 時間 30 分	指標
指標しきい値の条件で 使用するフィルタの最大長	2,048 Unicode 文字	指標
予測条件でモニタリングされる 時系列の最大数	64	指標
最小予測ウィンドウ	1 時間（3,600 秒）	指標
最大予測期間	2.5 日（216,000 秒）	指標
1 アラート ポリシーあたりの通知チャンネル数	16	指標、ログ
通知の最大レート^４	ログベースのアラート ポリシーごとに 5 分あたり 1 件の通知	ログ
通知の最大数	ログベースのアラート ポリシーごとに 1 日あたり 20 件の通知	ログ
1 アラート ポリシーあたりの 同時対応待ちインシデントの最大数	1,000	指標
新規データのないインシデントが 自動的に終了するまでの期間	7 日	指標
手動で終了していない場合のインシデントの最長時間	7 日	ログ
終了したインシデントの保持	13 か月	該当なし
対応待ちのインシデント	期限なし	該当なし
指標スコープごとの通知チャネル	4,000	該当なし
スヌーズあたりのアラート ポリシーの最大数	16	指標、ログ
スヌーズの保持	13 か月	該当なし

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