Cloud Monitoring の割り当てと上限

このドキュメントでは、Cloud Monitoring に適用される割り当てとシステムの上限を示します。

  • 割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、Cloud Monitoring などの Google Cloud サービスによって定義されます。
  • システムの上限は固定値で、変更できません。

Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。

Cloud Quotas システムは次のことを行います。

  • Google Cloud のプロダクトとサービスの消費量をモニタリングする
  • これらのリソースの消費量を制限する
  • 割り当て値の変更をリクエストする方法を提供する

ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。

割り当ては通常、Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。

通常、割り当てを調整するには、Google Cloud コンソールを使用します。 詳細については、割り当ての調整をリクエストするをご覧ください。

Monitoring リソースにはシステムの上限もあります。システムの上限は変更できません。

ユーザー定義の指標

Cloud Monitoring の [指標の管理] ページでは、オブザーバビリティに影響を与えることなく、課金対象の指標に費やす金額を制御するために役立つ情報が提供されます。[指標の管理] ページには、次の情報が表示されます。

  • 指標ドメイン全体と個々の指標での、バイトベースとサンプルベースの両方の課金に対する取り込み量。
  • 指標のラベルとカーディナリティに関するデータ。
  • 各指標の読み取り回数。
  • アラート ポリシーとカスタム ダッシュボードでの指標の使用。
  • 指標書き込みエラーの割合。

また、指標の管理を使用して不要な指標を除外し、取り込みのコストを削減することもできます。[指標の管理] ページの詳細については、指標の使用状況の表示と管理をご覧ください。

カテゴリ 最大値
1 プロジェクトあたりのカスタム指標記述子1 10,000
1 指標記述子あたりのラベル 30
ラベルキーの文字列長 100
ラベル値の文字列長 1024
書き込みリクエストに含まれる時系列2 200
単一時系列へのデータ書き込み速度3 5 秒あたり 1 ポイント
1 カスタム分布指標あたりのヒストグラム バケット 200
1 プロジェクトあたりのワークロード、Prometheus、外部 4 指標記述子の数 25,000
1 モニタリング対象リソース 5 あたりの、カスタム指標からのアクティブな時系列 200,000
1 モニタリング対象リソース 5 あたりの、外部指標からのアクティブな時系列 200,000
1 モニタリング対象リソース 5 あたりの Prometheus からのアクティブな時系列 1,000,000
1 モニタリング対象リソース 5 あたりの、外部指標からのアクティブな時系列 200,000
指標記述子の作成レート プロジェクトあたり毎分 6,000 回

1 この上限は Cloud Monitoring によって課されます。他のサービスでは、より低い最大値が課されることもあります。カスタム指標とは、custom.googleapis.com に書き込まれる指標を指します。
2 リクエストの各時系列に書き込めるデータポイントは 1 つだけです。したがってこの制限はリクエストごとに書き込めるポイント数の上限としても機能します。
3 Cloud Monitoring API では、時系列に書き込まれるポイントの終了時間が少なくとも 5 秒離れている必要があります。データポイントが順番に書き込まれる場合は、ポイントを時系列にバッチ書き込みできます。
4 外部指標とは、external.googleapis.com に書き込まれる数を指します。
5 過去 24 時間以内に時系列にデータポイントが書き込まれた場合、その時系列はアクティブです。行に指定された上限は、すべてのユーザー定義指標(カスタム指標、ワークロード指標、Prometheus 指標、外部指標)の単一のモニタリング対象リソース(例: 単一の gce_instance VM または単一の k8s_container コンテナ)に対するアクティブな時系列の総数です。この例外となるのが global のモニタリング対象リソースです。このリソースには、各ユーザー定義指標ごとに上限が適用されます。これはシステム全体のセーフティ リミットであり、カスタマイズすることはできません。

Monitoring API の割り当てと上限

カテゴリ 最大値
API の使用上限

API の割り当てと上限を確認する手順は次のとおりです。

API ページトークンの存続時間 24 時間

Monitoring API の割り当てについて

Monitoring API には、時系列取り込みリクエストと時系列クエリのレートに対して割り当ての上限があります。取り込みリクエストは時系列データを書き込む呼び出しで、クエリは時系列データを取得する呼び出しです。他の Monitoring API エンドポイントにも内部上限があります。これらのエンドポイントは、大量のリクエストを処理するためのものではありません。

サービスが時系列データを書き込む際に発行する API リクエストの数を削減するには、1 つの API リクエストを使用して複数の時系列のデータを書き込みます。リクエストごとに少なくとも 10 個のオブジェクトを書き込むことをおすすめします。API リクエストのバッチ処理の詳細については、timeSeries.create をご覧ください。

API リクエストをバッチ処理しても、Monitoring API の割り当て上限の引き上げが必要な場合は、Google Cloud サポートにお問い合わせください。

このページでは、変更できないその他の上限について詳しく説明しています。

詳細については、割り当ての操作をご覧ください。

データの保持

保持期間を過ぎた指標データポイントは時系列から削除されます。

カテゴリ
カスタム、外部、エージェントの各指標タイプのデータポイントの保持期間
  • カスタム指標(接頭辞 custom.googleapis.com
  • Google Cloud Managed Service for Prometheus の指標、接頭辞 prometheus.googleapis.com2
  • エージェント指標(接頭辞 agent.googleapis.com
    processes/count_by_stateprocesses/fork_state を含む)。
    残りの processes 指標の保持期間は異なります。次のエントリをご覧ください。
  • 外部指標(接頭辞 external.googleapis.com
  • OpenTelemetry とその他のワークロード指標(接頭辞 workload.googleapis.com
24 か月 1
プロセスの状態の指標タイプ agent.googleapis.com/processes のデータポイントの保持期間
(前のエントリで説明したとおり、count_by_statefork_state は除く)。
24 時間
一部の Google Cloud サービスのデータポイントの保持期間。次のカテゴリ内のほとんどの指標が含まれます。
  • Compute Engine 指標(接頭辞 compute.googleapis.com
  • GKE と GKE Enterprise の指標(接頭辞 kubernetes.io
  • Cloud Storage 指標(接頭辞 storage.googleapis.com
  • BigQuery 指標、接頭辞 bigquery.googleapis.com
  • Cloud SQL の指標、接頭辞 cloudsql.googleapis.com
  • 内部、HTTPS、L7 ロードバランサの指標(接頭辞 loadbalancing.googleapis.com
24 か月1
以下を含む、その他すべての指標タイプのデータポイントの保持期間 6 週間
API ページトークンの存続時間 24 時間

1 指標データは、元のサンプリング頻度で 6 週間保存され、その後、長期保存用に 10 分間隔にダウンサンプリングされます。
2 Google Cloud Managed Service for Prometheus 指標データは、元のサンプリング頻度で 1 週間保存されます。その後の 5 週間は 1 分間隔にダウンサンプリングされ、その後、長期保存用に 10 分間隔にダウンサンプリングされます。

リソース グループ

カテゴリ
指標スコープごとのリソース グループの数 500
1 メールレポートに含まれるグループ数の上限1 10

1 Cloud Monitoring メールレポートを設定する際、リソース グループの使用率に関する情報をリクエストできます。メールレポート ツールの上限に従い、生成されたレポートには 10 グループのみの情報が含まれます。

モニタリング対象プロジェクトの上限

Cloud Monitoring では、指標スコープごとに最大 375 個の Google Cloud プロジェクトが正式にサポートされています。

指標スコープごとに最大 1,000 個の Google Cloud プロジェクトを追加できますが、特にカスタム指標や過去のデータに対してクエリを実行する場合は、パフォーマンスの問題が発生する可能性があります。Cloud Monitoring は、指標スコープごとに 375 の Google Cloud プロジェクトに対してのみ、高パフォーマンスのクエリとグラフを保証します。

指標スコープあたりの Google Cloud プロジェクトの割り当てを増やすには、「モニタリング対象プロジェクト / モニタリング指標スコープ」の割り当ての増加をリクエストします。詳細については、割り当ての管理に関するドキュメントをご覧ください。

指標記述子の作成と更新に関する制限

Cloud Monitoring では、新しい指標の作成、既存の指標への新しいラベル名の追加、指標の削除に 1 分あたりのレート制限が適用されます。このレート制限へは通常、Cloud Monitoring と最初に統合するときにのみ達します(たとえば、既存の成熟した Prometheus デプロイを Cloud Monitoring に移行する場合など)。これは、データポイントを取り込む場合のレート制限ではありません。このレート制限は、未知の指標を作成する場合、または既存の指標に新しいラベル名を追加する場合にのみ適用されます。

この割り当ては固定されていますが、新しい指標と指標ラベルを作成するときのレートが 1 分あたりの制限以下になると、問題は自動的に解決されます。

アラートの上限

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

合成モニターの上限

カテゴリ
指標スコープごとの稼働時間チェック* 100
公開稼働時間チェックごとの ICMP ping の最大数 3
指標スコープごとの合成モニタリング 100
*この上限は稼働時間チェックの構成の数に適用されます。稼働時間チェックの各構成には、指定されたリソースのステータスを確認する時間間隔が含まれます。
この上限を引き上げる方法については、Google Cloud コンソールを使用して割り当てを管理するをご覧ください。

グラフに関する上限

カテゴリ
指標スコープごとのダッシュボード 1000
1 つのダッシュボード上のグラフの数 40
1 つのグラフ上の線の数 50*
テーブル内の行 300
*この上限はパフォーマンス上の理由から適用されます。グラフに表示する時系列が 50 を超えると、赤いドット付きのアイコンがツールバーに追加されます。アイコンのツールチップに To improve performance, we've limited the time series displayed in this chart というメッセージが表示されます。すべての時系列を表示するには、ツールチップを展開して、[すべての時系列を表示] ボタンを選択します。

サービスレベル目標

カテゴリ
サービスあたりの SLO の数 500