このドキュメントでは、Cloud Monitoring に適用される割り当てと上限を示します。
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 サポートにお問い合わせください。
このページでは、変更できないその他の上限について詳しく説明しています。
詳細については、割り当ての操作をご覧ください。
データの保持
保持期間を過ぎた指標データポイントは時系列から削除されます。
| カテゴリ | 値 | ||
|---|---|---|---|
カスタム、外部、エージェントの各指標タイプのデータポイントの保持期間
|
24 か月 1 | ||
プロセスの状態の指標タイプ agent.googleapis.com/processes のデータポイントの保持期間（前のエントリで説明したとおり、 count_by_state と fork_state は除く）。 |
24 時間 | ||
| 以下を含む、その他すべての指標タイプのデータポイントの保持期間 | 6 週間 | Google Cloud 指標の保持 | 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 | 指標、ログ |
| 1 アラート ポリシーあたりの条件数 | 6 | 指標 |
| 指標の不在条件が評価される 最大期間 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 | 該当なし |
| 1 回のスヌーズあたりのアラート ポリシーの最大数 | 16 | 指標、ログ |
| スヌーズの保持 | 13 か月 | 該当なし |
2Apigee と Apigee ハイブリッドは Cloud Monitoring と緊密に統合されています。すべての Apigee サブスクリプション レベル（Standard、Enterprise、Enterprise Plus）のアラート数の上限は、Cloud Monitoring と同じで、1 指標スコープあたり 500 です。
3条件が評価する最大期間は、アライメント期間と期間時間枠の値の合計です。たとえば、アライメント期間が 15 時間、期間時間枠が 15 時間に設定されている場合、30 時間分のデータが条件を評価するために必要です。
合成モニターの上限
| カテゴリ | 値 |
|---|---|
| 指標スコープごとの稼働時間チェック* | 100 |
| 公開稼働時間チェックごとの ICMP ping の最大数 | 3 |
| 指標スコープごとの合成モニタリング | 100† |
†この上限を増やす方法については、Google Cloud コンソールを使用して割り当てを管理するをご覧ください。
グラフに関する上限
| カテゴリ | 値 |
|---|---|
| 指標スコープごとのダッシュボード | 1000 |
| 1 つのダッシュボード上のグラフの数 | 40 |
| 1 つのグラフ上の線の数 | 50 |
サービスレベル目標
| カテゴリ | 値 |
|---|---|
| サービスあたりの SLO の数 | 500 |