Azure Monitor サービスの制限
この記事では、Azure Monitor のさまざまな領域における制限の一覧を示します。
警告
リソース | 既定の制限 | 上限 |
---|---|---|
メトリック アラート (クラシック) | サブスクリプションごとに 100 個のアクティブなアラート ルール。 パブリック クラウド ユーザー向けの従来のアラートは廃止されています。 Azure Government クラウドおよび 21Vianet によって運営される Microsoft Azure での従来型のアラートは、2024 年 2 月 29 日に廃止されます。 |
サポートに問い合わせます。 |
メトリック アラート | Azure パブリック、21Vianet によって運営される Microsoft Azure、および Azure Government クラウド内でサブスクリプションごとに 5,000 個のアクティブな警告ルール。 この制限に達した場合は、同じ種類のマルチリソース アラートを使用できるかどうかを確認します。 アラート ルールあたり 5,000 個のメトリック時系列。 |
サポートに問い合わせます。 |
アクティビティ ログ アラート | サブスクリプションごとに 100 個のアクティブなアラート ルール (増やすことはできません)。 この制限を増やすことができないので、サブスクリプションごとにより多くのルールが必要な場合は、 アクティビティ ログを Log Analytics ワークスペースに送信し、代わりにログ検索アラートを作成することを検討してください。 |
既定値と同じ。 |
ログ アラート | サブスクリプションごとに 5,000 個のアクティブなアラート ルール。 そのうち、1 分あたりのアクティブな警告ルールは 100 個です。 リソースごとに 1,000 個のアクティブなアラート ルール。 ステートレスな各警告ルールでは、評価ごとに最大 6,000 件のアラートをトリガーできます。 ステートフルな各警告ルールでは、評価ごとに最大 300 件のアラートをトリガーできます。 一度に発するステートフル アラートは最大 5,000 件。 ログ警告ルールのプロパティ内のすべてのデータの合計サイズは、64 KB を超えることはできません。 Kusto クエリの結果は、20 MB を超えることはできません。 |
サポートに問い合わせます。 |
アラート処理ルール | サブスクリプションごとに 1,000 個のアクティブなルール。 | サポートに問い合わせます。 |
アラート ルールとアラート処理ルールの説明の長さ | ログ検索アラートは 4,096 文字。 それ以外はすべて 2,048 文字。 |
既定値と同じ。 |
Alerts API
Azure Monitor アラートには、ユーザーが過剰な数の呼び出しを実行するのを防ぐためのいくつかの調整制限があります。 このような動作によってシステムのバックエンド リソースが過負荷になり、サービスの応答性が損なわれる可能性があります。 次の制限は、顧客の中断を防ぎ、一貫したサービス レベルを確保するために設計されています。 ユーザーの調整と制限は、過剰な使用シナリオにのみ影響するように設計されています。 一般的な使用には関係しません。
Note
インスタンスあたりの API 呼び出しには制限があります。 正確な制限の数はインスタンスによって異なります。
リソース | 既定の制限 | 上限 |
---|---|---|
アラート - 概要の取得 | サブスクリプションごとに毎分 50 回の呼び出し | 既定値と同じ |
アラート - すべてを取得 ("ID による取得" でなく) | サブスクリプションごとに毎分 100 回の呼び出し | 既定値と同じ |
その他すべてのアラートの呼び出し | サブスクリプションごとに毎分 1,000 回の呼び出し | 既定値と同じ |
アクション グループ
サブスクリプションに含めることができるアクション グループの数には制限はありません。
リソース | 既定の制限 | 上限 |
---|---|---|
Azure アプリのプッシュ | アクション グループあたり 10 個のアプリ アクション。 | 既定値と同じ |
アクション グループの 1,000 個のメール アクション。 リージョンごと、メールアドレスごと、1 時間ごとに 100 件以下のメール メール アドレスの文字数制限は 64 文字です。 電子メールの文字数制限は 55296 です。 レート制限情報 もご覧ください。 |
既定値と同じ | |
電子メールの Azure Resource Manager のロール | アクショングループごとに 10 種類の電子メール ARM ロール アクション。 運用環境: リージョンごとに 1 時間に 100 件以下の電子メール。 テスト アクション グループ内: 1 分ごとに 2 件以下の電子メール。 |
既定値と同じ |
Event Hubs | アクション グループごとに 10 種類の Event Hubs アクション。 | 既定値と同じ |
ITSM | アクション グループの 10 個の ITSM アクション。 | 既定値と同じ |
ロジック アプリ | アクション グループの 10 個のロジック アプリ アクション。 | 既定値と同じ |
Runbook | アクション グループの 10 個の Runbook アクション。 | 既定値と同じ |
Secure Webhook | アクション グループの 10 種類の安全な Webhook アクション。 Webhook の最大呼び出し数は、サブスクリプションごとに毎分 1500 個です。 | 既定値と同じ |
sms | アクション グループの 10 個の SMS アクション。 運用環境: 5 分ごとに 1 件以下の SMS メッセージ。 テスト アクション グループ内: 1 分ごとに 1 件以下の SMS。 |
既定値と同じ |
音声 | アクション グループの 10 個の音声アクション。 運用環境: 5 分ごとに 1 件以下の音声通話。 テスト アクション グループ内: 1 分ごとに 1 件以下の音声通話。 |
既定値と同じ |
Webhook | アクション グループの 10 個の Webhook アクション。 Webhook の最大呼び出し数は、サブスクリプションごとに毎分 1500 個です。 | 既定値と同じ |
自動スケール
リソース | 既定の制限 | 上限 |
---|---|---|
自動スケールの設定 | サブスクリプションあたりのリージョンごとに 100。 | 既定値と同じ |
自動スケール プロファイル | 自動スケーリング設定ごとに 20 プロファイル。 | 既定値と同じ |
Prometheus メトリック
データの取り込み
Azure マネージド Prometheus は、大文字と小文字を区別しないシステムです。 メトリック名、ラベル名、ラベル値などの文字列が、文字列の大文字と小文字が異なるだけで別の時系列と異なる場合、それらの文字列は同じ時系列として扱われます。 詳細については、Prometheus のメトリックの概要に関する記事を参照してください。
Prometheus のメトリックを取り込む Azure Monitor ワークスペースには、次の制限が適用されます。
制限 | 値 |
---|---|
過去 12 時間以内に報告されたメトリックを含むアクティブな時系列。 | 1,000,000 引き上げを要求できます。 |
1 分間に取り込まれるイベント数。 | 1,000,000 引き上げを要求できます。 |
Azure Monitor ワークスペースに Prometheus のメトリック データを送信するデータ収集規則 (DCR) とデータ収集エンドポイント (DCE) には、次の制限が適用されます。
制限 | 値 |
---|---|
データ収集エンドポイントへの 1 分あたりのインジェスト要求数 | 15,000 この制限を増やすことはできません。 |
データ収集エンドポイントへの 1 分あたりのデータ インジェスト | 50 GB この制限を増やすことはできません。 |
クエリ
Prometheus のクエリは PromQL を使って作成され、Azure Managed Grafana またはセルフマネージド Grafana で作成できます。
制限 | 値 |
---|---|
データの保持 | 18 か月間。 この制限を増やすことはできません。 |
クエリの時間範囲 | PromQL クエリの開始日時から終了日時まで 32 日間。 この制限を増やすことはできません。 |
メトリックごとのクエリ時系列 | 500,000 個の時系列。 |
返されるクエリ サンプル数 | クエリあたり 50,000,000 個のサンプル。 |
クエリ ステップの最小サイズ 48 時間以上の時間範囲 |
60 秒。 |
クエリ データの制限
クライアント トラフィックの場合:
制限 | 値 |
---|---|
調整期間の検索の長さ | 30 秒 |
Azure Monitor ワークスペースごとに返されるデータ | 0.5 GB |
レコーディング ルール トラフィックの場合:
制限 | 値 |
---|---|
調整期間の検索の長さ | 3 分 |
Azure Monitor ワークスペースごとに返されるデータ | 1 GB |
クエリの事前解析の制限
30 秒間のクエリの時間範囲と要求の種類に基づきます (クライアント トラフィックの場合)。
制限 | 値 |
---|---|
ユーザーあたりのクエリ時間 (Microsoft Entra ID、マネージド ID、Azure Managed Grafana ワークスペース) | 30,000 |
Azure Monitor ワークスペースごとのクエリ時間 | 60,000 |
Azure テナントごとのクエリ時間 | 600,000 |
3 分間のクエリの時間範囲と要求の種類に基づきます (レコーディング ルール トラフィックの場合)。
制限 | 値 |
---|---|
Azure Monitor ワークスペースごとのクエリ時間 | 60,000 |
Azure テナントごとのクエリ時間 | 600,000 |
クエリの解析後の制限
クエリの時間範囲と 30 秒間の範囲ベクトルに基づきます (クライアント トラフィックの場合)。
制限 | 値 |
---|---|
ユーザーあたりのクエリ時間 (Microsoft Entra ID、マネージド ID、Azure Managed Grafana ワークスペース) | 2,000,000 |
Azure Monitor ワークスペースごとのクエリ時間 | 2,000,000 |
Azure テナントごとのクエリ時間 | 20,000,000 |
クエリの時間範囲と 3 分間の範囲ベクトルに基づきます (レコーディング ルール トラフィックの場合)。
制限 | 値 |
---|---|
Azure Monitor ワークスペースごとのクエリ時間 | 2,000,000 |
Azure テナントごとのクエリ時間 | 20,000,000 |
クエリ のコスト調整の制限
制限 | 値 |
---|---|
クエリあたりの最大クエリ コスト | 15000 |
ルール クエリを記録するための最大クエリ コスト | 3000 |
クエリ コストの計算は次のように行われます:
Query Cost = (要求された時系列の数 * (クエリされた時間 (秒) / "クエリされたデータの推定時間解決")) / 5000
クエリ対象データの推定時間解決 = クエリ対象 のメトリック / クエリされた時間の期間のランダムに選択された 1 つの時系列キーに格納されているデータ ポイントの数 (秒単位)
アラート ルールとレコーディング ルール
Prometheus アラート ルールとレコーディング ルールは PromQL で定義されます。 Prometheus 用 Azure Monitor マネージド サービスの一部としてマネージド ルーラー サービスで実行します。
制限 | 値 |
---|---|
Azure サブスクリプション内の Azure Monitor ワークスペースごとのルール グループ | 500 引き上げを要求できます。 |
規則グループごとのルール数 | 20 この制限を増やすことはできません。 |
規則グループの評価間隔 | 1 分から 24 時間の間。 既定値は 1 分です。 |
アクティブなアラート | 現時点で制限はありません。 |
リモート書き込み
計算は、既定値であるリモート バッチ サイズ 500 を使って決定されています。
制限 | 値 |
---|---|
CPU 使用率 | 0.25 x (メトリック数) + 1.25 x (メトリックあたりの平均系列数) |
CPU 要求 | 0.75 x (CPU 使用率) |
CPU 制限 | 2 x (CPU 要求) |
メモリ要求 | 150 MB |
メモリ制限 | 200 MB |
最大スループット | リモート書き込みコンテナーは、最大 150,000 個の一意の時系列を処理できます。 コンテナーは、要求が 150,000 を超えると、コンカレント接続の数が多いため、エラーをスローする場合があります。 この問題は、リモート バッチ サイズを 500 から 1,000 に増やすことで軽減できます。 この変更により、開かれる接続の数が減ります。 |
ログ インジェスト API
制限 | 値 | 説明 |
---|---|---|
API 呼び出しの最大サイズ | 1 MB | 圧縮されたデータと圧縮されていないデータの両方。 |
フィールド値の最大サイズ | 64 KB | 64 KB を超えるフィールドは切り詰められます。 |
DCR あたりの最大データ/分数 | 2 GB | 圧縮されたデータと圧縮されていないデータの両方。 応答の Retry-After ヘッダーに示されている期間の後に再試行します。 |
DCR あたりの最大要求数/分 | 12,000 | 応答の Retry-After ヘッダーに示されている期間の後に再試行します。 |
データ収集ルール
制限 | 値 |
---|---|
データ ソースの最大数 | 10 |
パフォーマンス カウンターのカウンター指定子の最大数 | 100 |
SysLog 内のファシリティ名の最大数 | 20 |
イベントログ内の XPath クエリの最大数 | 100 |
データ フローの最大数 | 10 |
データ ストリームの最大数 | 10 |
拡張機能の最大数 | 10 |
拡張機能設定の最大サイズ | 32 Kb |
Log Analytics ワークスペースの最大数 | 10 |
変換での最大文字数 | 15,360 |
診断設定
リソース | 既定の制限 | 上限 |
---|---|---|
リソースごとの診断設定の最大数 | 5 | 既定値と同じ。 |
ログ クエリと言語
一般的なクエリの制限
制限 | 説明 |
---|---|
クエリ言語 | Azure Monitor では、Azure Data Explorer と同じ Kusto 照会言語 (KQL) が使用されます。 Azure Monitor でサポートされていない KQL 言語要素については、「Azure Monitor ログ クエリ言語の違い」を参照してください。 |
Azure Azure リージョン | データが複数の Azure リージョンの Log Analytics ワークスペースにまたがっている場合、ログ クエリで過剰なオーバーヘッドが発生する可能性があります。 詳細については、「クエリの制限」をご覧ください。 |
リソース間のクエリ | 1 回のクエリ内の Application Insights リソースと Log Analytics ワークスペースの数は 100 個に制限されています。 リソース間のクエリは、ビュー デザイナーでサポートされていません。 ログ アラートでのリソース間のクエリは、新しい scheduledQueryRules API でサポートされています。 詳細については、リソース間のクエリの制限に関する記事を参照してください。 |
Log Analytics ダッシュボード クエリ | 1 つの Log Analytics ダッシュボード クエリで返されるレコードの最大数は 2,000 です。 |
ユーザー クエリの調整
Azure Monitor には、ユーザーが過剰な数のクエリを送信するのを防ぐためのいくつかの調整制限があります。 このような動作によってシステムのバックエンド リソースが過負荷になり、サービスの応答性が損なわれる可能性があります。 次の制限は、顧客を中断から保護し、一貫したサービス レベルを確保するために設計されています。 ユーザーの調整と制限は、極端な使用シナリオにのみ影響するように設計されており、一般的な使用には関係ありません。
Measure | ユーザーあたりの制限 | 説明 |
---|---|---|
同時クエリ | 5 | ユーザーは最大 5 つの同時クエリを実行できます。 その他のクエリはキューに追加されます。 実行中のクエリのいずれかが完了すると、キューの最初のクエリがキューから引き出され、実行が開始されます。 アラート クエリはこの制限に含まれません。 |
コンカレンシー キューの時間 | 3 分 | クエリが開始されずにキューに 3 分以上留まっている場合、コード 429 の HTTP エラー応答で終了されます。 |
コンカレンシー キュー内の合計クエリ数 | 200 | キュー内のクエリの数が 200 に達すると、次のクエリは HTTP エラー コード 429 で拒否されます。 この数は、同時に実行できる 5 つのクエリとは別にカウントされます。 |
クエリ速度 | 30 秒あたり 200 クエリ | 1 人のユーザーがすべてのワークスペースに送信できるクエリの全体的な速度。 この制限は、プログラムによるクエリや、Azure ダッシュボードや Log Analytics ワークスペースの概要 (非推奨) ページなどの視覚化パーツによって開始されるクエリに適用されます。 |
- 「Azure Monitor でログ クエリを最適化する」の説明に従って、クエリを最適化します。
- ダッシュボードとワークブックでは 1 つのビューに複数のクエリを含めることができるため、読み込みまたは更新のたびにクエリのバーストが生成されることがあります。 1 つのビューを複数のビューに分割し、必要に応じてそれらを読み込むことを検討してください。
- Power BI では、生ログではなく、集計された結果のみを抽出することを検討してください。
Log Analytics ワークスペース
データの収集量と保持期間
Pricing tier | 1 日あたりの制限 | データの保持 | 解説 |
---|---|---|---|
従量課金制 (2018 年 4 月に導入) |
制限なし | 最大 730 日間の対話型の保持期間 / 最大 12 年間のデータ アーカイブ |
31 日を超えるデータ保持期間は追加料金で使用できます。 Azure Monitor の価格を確認する。 |
コミットメント レベル (2019 年 11 月に導入) |
制限なし | 最大 730 日間の対話型の保持期間 / 最大 12 年間のデータ アーカイブ |
31 日を超えるデータ保持期間は追加料金で使用できます。 Azure Monitor の価格を確認する。 |
従来のノードあたり (OMS) (2016 年 4 月に導入) |
制限なし | 30 日 - 730 日 | 31 日を超えるデータ保持期間は追加料金で使用できます。 Azure Monitor の価格を確認する。 レベルを使用するためのアクセスは、2018 年 4 月 2 日に Log Analytics ワークスペースまたは Application Insights リソースが含まれていたサブスクリプション、または 2019 年 2 月 1 日より前に開始され、まだアクティブな Enterprise Agreement にリンクされているサブスクリプションに制限されます。 |
従来の Standalone レベル (2016 年 4 月に導入) |
制限なし | 30 日 - 730 日 | 31 日を超えるデータ保持期間は追加料金で使用できます。 Azure Monitor の価格を確認する。 レベルを使用するためのアクセスは、2018 年 4 月 2 日に Log Analytics ワークスペースまたは Application Insights リソースが含まれていたサブスクリプション、または 2019 年 2 月 1 日より前に開始され、まだアクティブな Enterprise Agreement にリンクされているサブスクリプションに制限されます。 |
従来の Free レベル (2016 年 4 月に導入) |
500 MB | 7 日 | ワークスペースが 1 日あたり 500 MB の制限に達した場合、データ インジェストが停止し、翌日の始めに再開されます。 1 日は UTC に基づきます。 Microsoft Defender for Cloud によって収集されるデータは 1 日あたり 500 MB の制限には含まれず、この制限を超えても引き続き収集されます。 2022 年 7 月 1 日までは、レガシの無料試用版の価格レベルで新しいワークスペースを作成する (または既存のワークスペースを移動してくる) ことができます。 |
従来の Standard レベル | 制限なし | 30 日 | 保持期間は調整できません。 このレベルは、2016 年 10 月 1 日以降、新しいワークスペースでは使用できません。 |
従来の Premium レベル | 制限なし | 365 日 | 保持期間は調整できません。 このレベルは、2016 年 10 月 1 日以降、新しいワークスペースでは使用できません。 |
サブスクリプションあたりのワークスペースの数
Pricing tier | ワークスペースの制限 | 説明 |
---|---|---|
従来の Free レベル | 10 | この制限を増やすことはできません。 2022 年 7 月 1 日までは、レガシの無料試用版の価格レベルで新しいワークスペースを作成する (または既存のワークスペースを移動してくる) ことができます。 |
その他のすべてのレベル | 制限なし | リソース グループ内のリソースの数とサブスクリプションあたりのリソース グループの数によって制限されます。 |
Azure Portal
カテゴリ | 制限 | 説明 |
---|---|---|
ログ クエリによって返されるレコードの最大数 | 30,000 | クエリでクエリ スコープ、時間の範囲、およびフィルターを使用して、結果を減らします。 |
データ コレクター API
カテゴリ | 制限 | 説明 |
---|---|---|
1 回の投稿の最大サイズ | 30 MB | 大量の場合は複数の投稿に分割します。 |
フィールド値の最大サイズ | 32 KB | 32 KB を超えるフィールドは切り詰められます。 |
クエリ API
カテゴリ | 制限 | 説明 |
---|---|---|
1 つのクエリで返されるレコードの最大数 | 500,000 | |
返されるデータの最大サイズ | 104 MB 以下 (100 MiB 以下) | この API では、最大 64 MB の圧縮データが返されます。これは最大 100 MB のテキストに相当します。 |
クエリの最大実行時間 | 10 分 | 詳細については、タイムアウトに関するページをご覧ください。 |
最大要求レート | Microsoft Entra ユーザーまたはクライアントの IP アドレスごとに、30 秒あたり 200 件の要求 | 「ログ クエリと言語」を参照してください。 |
Azure Monitor Logs コネクタ
カテゴリ | 制限 | 説明 |
---|---|---|
データの最大サイズ | 16.7 MB 以下 (16 MiB 以下) | コネクタ インフラストラクチャでは、クエリ API の制限よりも低い制限が設定されています。 |
レコードの最大数 | 500,000 | |
コネクタ タイムアウトの最大値 | 110 秒 | |
クエリ タイムアウトの最大値 | 100 秒 | |
グラフ | [ログ] ページとコネクタでは、視覚化に異なるグラフ ライブラリが使用されます。 現在、コネクタでは一部の機能を使用できません。 |
集計ルール
カテゴリ | なし |
---|---|
ワークスペース内のアクティブなルールの最大数 | 30 |
ビンあたりの結果の最大数 | 500,000 |
結果セットの最大ボリューム | 100 MB |
ビン処理のクエリ タイムアウト | 10 分 |
一般的なワークスペースの制限
カテゴリ | 制限 | 説明 |
---|---|---|
テーブルの最大列数 | 500 | AzureDiagnostics -- 制限を超える列は、動的な 'AdditionalFields' 列に追加されます Data Collector API によって作成されたカスタム ログ -- 制限を超える列は、動的な 'AdditionalFields' 列に追加されます カスタム ログ -- 詳しくは、サポートにお問い合わせください |
カスタム ログ テーブルの最大数 | 500 | 詳細については、サポートにお問い合わせください。 |
列名の最大文字数 | 45 |
データ インジェストのボリューム レート
Azure Monitor とは、増加し続けるテラバイト単位のデータを毎日送信する何千もの顧客にサービスを提供する高スケールのデータ サービスです。 ボリューム レートのソフト制限は、マルチテナント環境における突然のインジェスト スパイクから Azure Monitor の顧客を隔離するためのものです。 ワークスペースのデフォルトのインジェスト ボリューム レートのしきい値は 500 MB (圧縮) であり、圧縮されていない場合の約 6 GB/分に相当します。
ボリューム レート制限は、診断設定と Data Collector API を使用して、Azure リソースから取り込まれたデータに適用されます。 ボリューム レート制限に達すると、再試行メカニズムが 12 時間に 4 回データを取り込もうとし、操作が失敗した場合はそれを削除しようとします。 エージェントから、または DCR 経由で取り込まれたデータには適用されません。
ワークスペースに構成されているしきい値の 80% を超えるボリューム レートでワークスペースにデータが送信される場合、しきい値を超え続けている間、6 時間ごとにワークスペースの Operation
テーブルにイベントが送信されます。 インジェスト ボリューム レートがしきい値を超えると、一部のデータが削除され、しきい値を超え続けている間、6 時間ごとにワークスペースの Operation
テーブルにイベントが送信されます。
インジェスト ボリューム レートがしきい値を超え続けている場合、または間もなく達すると予測される場合は、サポート リクエストを開いて、この制限の引き上げを要求できます。
また、インジェストの制限に達したときに事前に通知するアラート ルールを作成することもお勧めします。 「Azure Monitor で Log Analytics ワークスペースの正常性を監視する」を参照してください。
Note
Log Analytics を使用してきた期間によっては、レガシ価格レベルにアクセスできることがあります。 詳細については、Log Analytics のレガシ価格レベルに関するページを参照してください。
Application Insights
アプリケーションごと (インストルメンテーション キーごと) のメトリックとイベントの数には制限があります。 制限は、選択する料金プランによって異なります。
リソース | 既定の制限 | 上限 | Notes |
---|---|---|---|
1 日あたりの合計データ量 | 100 GB | サポートにお問い合わせください。 | 上限を設定してデータを減らすことができます。 さらにデータが必要な場合は、ポータルで上限を最大 1,000 GB まで引き上げることができます。 1,000 GB を超える容量については、AIDataCap@microsoft.com までメールでご連絡ください。 |
Throttling | 32,000 イベント/秒 | サポートにお問い合わせください。 | 制限は 1 分間にわたって測定されます。 |
データ保持ログ | 30 日 - 730 日 | 730 日 | このリソースはログ用です。 |
データ保持メトリック | 90 日間 | 90 日間 | このリソースはメトリックス エクスプローラー用です。 |
可用性の複数手順のテストの詳細な結果の保持 | 90 日間 | 90 日間 | このリソースは、各手順の詳細な結果を提供します。 |
テレメトリ項目の最大サイズ | 64 KB | 64 KB | |
バッチあたりの最大テレメトリ項目数 | 64,000 | 64,000 | |
プロパティとメトリック名の長さ | 150 | 150 | 型スキーマに関するページを参照してください。 |
プロパティ値の文字列の長さ | 8,192 | 8,192 | 型スキーマに関するページを参照してください。 |
トレースおよび例外のメッセージ長 | 32,768 | 32,768 | 型スキーマに関するページを参照してください。 |
Application Insights リソースあたりの可用性テスト数 | 100 | 100 | |
リソース グループあたりの可用性テスト数 | 800 | 800 | Azure Resource Manager を参照してください |
可用性テストのテストあたりの最大リダイレクト数 | 10 | 10 | |
可用性テストの最小テスト頻度 | 300 秒 | 5 分未満のカスタム テスト周波数または周波数には、カスタム TrackAvailability 実装が必要です。 | |
プロファイラーとスナップショットのデータ保有期間 | 2 週間 | サポートにお問い合せください。 保持の最大限度は 6 か月です。 | |
プロファイラーの 1 日あたりの送信データ | 制限なし | 制限なし。 | |
スナップショットの 1 日あたりの送信データ | 監視対象アプリごとに 1 日あたり 30 のスナップショット | 制限なし。 | アプリケーションあたりに収集されるスナップショットの数は、構成することで変更できます。 |
価格とクォータの詳細については、「Application Insights の課金」を参照してください。
Azure Monitor プライベート リンク スコープ (AMPLS)
AMPLS オブジェクトには、次の制限があります。
- 仮想ネットワークは、"1 つ" の AMPLS オブジェクトにのみ接続できます。 これは、その AMPLS オブジェクトで、仮想ネットワークでアクセスできる必要のあるすべての Azure Monitor リソースへのアクセスを提供する必要があることを意味します。
- AMPLS オブジェクトは、最大 300 の Log Analytics ワークスペースと最大 1,000 の Application Insights コンポーネントに接続できます。
- Azure Monitor リソースは、最大 5 つの AMPLS に接続できます。
- 1 つの AMPLS オブジェクトは、最大 10 個のプライベート エンドポイントに接続できます。