Azure Monitor サービスの制限

この記事では、Azure Monitor のさまざまな領域における制限の一覧を示します。

警告

リソース 既定の制限 上限
メトリック アラート (クラシック) サブスクリプションごとに 100 個のアクティブなアラート ルール。 サポートに問い合わせます
メトリック アラート Azure パブリック、Azure China 21Vianet、および Azure Government クラウド内でサブスクリプションごとに 5,000 個のアクティブな警告ルール。 この制限に達した場合は、同じ種類のマルチリソース アラートを使用できるかどうかを調べます。
アラート ルールあたり 5,000 個のメトリック時系列。
サポートに問い合わせます。
アクティビティ ログ アラート サブスクリプションごとに 100 個のアクティブなアラート ルール (増やすことはできません)。 既定値と同じ
ログ アラート サブスクリプションごとに 1000 個のアクティブなアラート ルール。 リソースごとに 1000 個のアクティブなアラート ルール。 サポートに問い合わせます
アラート ルールとアクション ルールの説明の長さ ログ検索アラートは 4096 文字
その他はすべて 2048 文字
既定値と同じ

Alerts API

Azure Monitor アラートには、ユーザーが過剰な数の呼び出しを実行するのを防ぐためのいくつかの調整制限があります。 このような動作によってシステムのバックエンド リソースが過負荷になり、サービスの応答性が損なわれる可能性があります。 次の制限は、顧客を中断から保護し、一貫したサービス レベルを確保するために設計されています。 ユーザーの調整と制限は、極端な使用シナリオにのみ影響するように設計されており、一般的な使用には関係ありません。

リソース 既定の制限 上限
GET alertsSummary サブスクリプションごとに毎分 50 回の呼び出し 既定値と同じ
GET alerts (アラート ID の指定なし) サブスクリプションごとに毎分 100 回の呼び出し 既定値と同じ
その他すべての呼び出し サブスクリプションごとに毎分 1000 回の呼び出し 既定値と同じ

アクション グループ

リソース 既定の制限 上限
Azure アプリのプッシュ アクション グループあたり 10 個のアプリ アクション。 既定値と同じ
Email アクション グループの 1,000 個のメール アクション。
1 時間で 100 件以下の電子メール。
レート制限情報 もご覧ください。
既定値と同じ
ITSM アクション グループの 10 個の ITSM アクション。 既定値と同じ
ロジック アプリ アクション グループの 10 個のロジック アプリ アクション。 既定値と同じ
Runbook アクション グループの 10 個の Runbook アクション。 既定値と同じ
sms アクション グループの 10 個の SMS アクション。
5 分ごとに SMS メッセージ 1 件以下。
レート制限情報 もご覧ください。
既定値と同じ
音声 アクション グループの 10 個の音声アクション。
5 分ごとに 1 件以下の音声通話。
レート制限情報 もご覧ください。
既定値と同じ
Webhook アクション グループの 10 個の Webhook アクション。 Webhook の最大呼び出し数は、サブスクリプションごとに毎分 1500 個です。 その他の制限はアクション固有の情報でご覧いただけます。 既定値と同じ

自動スケール

リソース 既定の制限 上限
自動スケールの設定 サブスクリプションあたりのリージョンごとに 100。 既定値と同じ
自動スケール プロファイル 自動スケーリング設定ごとに 20 プロファイル。 既定値と同じ

データ収集ルール

制限
データ ソースの最大数 10
パフォーマンス カウンターのカウンター指定子の最大数 100
SysLog 内のファシリティ名の最大数 20
イベントログ内の XPath クエリの最大数 100
データ フローの最大数 10
データ ストリームの最大数 10
拡張機能の最大数 10
拡張機能設定の最大サイズ 32 Kb
Log Analytics ワークスペースの最大数 10

ログ クエリと言語

一般的なクエリの制限

制限 説明
クエリ言語 Azure Monitor では、Azure Data Explorer と同じ Kusto クエリ言語が使用されます。 Azure Monitor でサポートされていない KQL 言語要素については、「Azure Monitor ログ クエリ言語の違い」を参照してください。
Azure Azure リージョン データが複数の Azure リージョンの Log Analytics ワークスペースにまたがっている場合、ログ クエリで過剰なオーバーヘッドが発生する可能性があります。 詳細については、「クエリの制限」をご覧ください。
リソース間のクエリ 1 回のクエリ内の Application Insights リソースと Log Analytics ワークスペースの数は 100 個に制限されています。
リソース間のクエリは、ビュー デザイナーでサポートされていません。
ログ アラートでのリソース間のクエリは、新しい scheduledQueryRules API でサポートされています。
詳細については、リソース間のクエリの制限に関する記事を参照してください。

ユーザー クエリの調整

Azure Monitor には、ユーザーが過剰な数のクエリを送信するのを防ぐためのいくつかの調整制限があります。 このような動作によってシステムのバックエンド リソースが過負荷になり、サービスの応答性が損なわれる可能性があります。 次の制限は、顧客を中断から保護し、一貫したサービス レベルを確保するために設計されています。 ユーザーの調整と制限は、極端な使用シナリオにのみ影響するように設計されており、一般的な使用には関係ありません。

Measure ユーザーあたりの制限 説明
同時クエリ 5 ユーザーのために既に 5 つのクエリが実行されている場合、新しいクエリはユーザーごとのコンカレンシー キューに配置されます。 実行中のクエリの 1 つが終了すると、次のクエリがキューから取り出されて開始されます。 これには、アラート ルールからのクエリは含まれません。
コンカレンシー キューの時間 3 分 クエリが開始されずにキューに 3 分以上留まると、クエリはコード 429 の HTTP エラー応答で終了します。
コンカレンシー キュー内の合計クエリ数 200 キュー内のクエリの数が 200 に達すると、追加のクエリは HTTP エラー コード 429 で拒否されます。 この数は、同時に実行できる 5 つのクエリとは別にカウントされます。
クエリ速度 30 秒あたり 200 クエリ これは、1 人のユーザーがすべてのワークスペースにクエリを送信できる全体的な速度です。 この制限は、プログラムによるクエリや、Azure ダッシュボードや Log Analytics ワークスペースの概要ページなどの視覚化パーツによって開始されるクエリに適用されます。
  • Azure Monitor でログ クエリを最適化する」の説明に従って、クエリを最適化します。
  • ダッシュボードとワークブックでは 1 つのビューに複数のクエリを含めることができるため、読み込みまたは更新のたびにクエリのバーストが生成されることがあります。 1 つのビューを複数のビューに分割し、必要に応じてそれらを読み込むことを検討してください。
  • Power BI では、未加工のログではなく、集計された結果のみを抽出することを検討してください。

Log Analytics ワークスペース

データの収集量と保持期間

レベル 1 日あたりの制限 データの保持 解説
現在の GB あたりの価格レベル
(2018 年 4 月に導入)
制限なし 30 日 - 730 日 31 日を超えるデータ保持期間は追加料金で使用できます。 Azure Monitor の価格を確認してください。
従来の Free レベル
(2016 年 4 月に導入)
500 MB 7 日 ワークスペースが 1 日あたり 500 MB の制限に達した場合、データ インジェストが停止し、翌日の始めに再開されます。 1 日は UTC に基づきます。 Azure Security Center によって収集されるデータは、この 1 日あたり 500 MB の制限には含まれず、この制限を超えても引き続き収集されます。
従来の GB あたりの Standalone レベル
(2016 年 4 月に導入)
制限なし 30 日 - 730 日 31 日を超えるデータ保持期間は追加料金で使用できます。 Azure Monitor の価格を確認してください。
従来のノードあたり (OMS)
(2016 年 4 月に導入)
制限なし 30 日 - 730 日 31 日を超えるデータ保持期間は追加料金で使用できます。 Azure Monitor の価格を確認してください。
従来の Standard レベル 制限なし 30 日 保持期間を調整することはできません。
従来の Premium レベル 制限なし 365 日 保持期間を調整することはできません。

サブスクリプションあたりのワークスペースの数。

Pricing tier ワークスペースの制限 説明
Free レベル 10 この制限を増やすことはできません。
その他のすべてのレベル 制限なし リソース グループ内のリソースの数とサブスクリプションあたりのリソース グループの数によって制限されます。

Azure Portal

カテゴリ 制限 説明
ログ クエリによって返されるレコードの最大数 30,000 クエリでクエリ スコープ、時間範囲、およびフィルターを使用して、結果を減らします。

データ コレクター API

カテゴリ 制限 説明
1 回の投稿の最大サイズ 30 MB 大量の場合は複数の投稿に分割します。
フィールド値の最大サイズ 32 KB 32 KB を超えるフィールドは切り詰められます。

クエリ API

カテゴリ 制限 説明
1 つのクエリで返されるレコードの最大数 500,000
返されるデータの最大サイズ 104 MB 以下 (100 MiB 以下)
クエリの最大実行時間 10 分 詳細については、タイムアウトに関するページをご覧ください。
最大要求レート Azure AD ユーザーまたはクライアントの IP アドレスごとに、30 秒あたり 200 件の要求 詳細については、レート制限に関するページをご覧ください。

Azure Monitor Logs コネクタ

カテゴリ 制限 説明
データの最大サイズ 16.7 MB 以下 (16 MiB 以下) コネクタ インフラストラクチャで、制限がクエリ API の制限よりも低く設定されている
レコードの最大数 500,000
クエリ タイムアウトの最大値 110 秒
グラフ [ログ] ページとコネクタの視覚化で使用されているグラフ ライブラリは異なり、現在、コネクタでは一部機能が使用できません。

一般的なワークスペースの制限

カテゴリ 制限 説明
テーブルの最大列数 500
列名の最大文字数 500

データ インジェストのボリューム レート

Azure Monitor とは、毎月増加するテラバイト単位のデータを送信する何千もの顧客にサービスを提供する高スケールのデータ サービスです。 ボリューム レート制限は、マルチテナント環境における突然のインジェスト スパイクから Azure Monitor の顧客を隔離するためのものです。 ワークスペースでは、既定のインジェスト ボリューム レートのしきい値である 500 MB (圧縮) が定義されており、これは約 6 GB/分 (非圧縮) に変換されます。実際のサイズは、ログの長さとその圧縮率に左右され、データの種類によって異なることがあります。 ボリューム レート制限は、診断設定を使用して、Azure リソースから取り込まれたデータに適用されます。 ボリューム レート制限に達すると、再試行メカニズムは 30 分間に 4 回データを取り込もうとし、操作が失敗した場合はそれを削除しようとします。 エージェントまたはデータ コレクター API から取り込まれたデータには適用されません。

ワークスペースに構成されているしきい値の 80% を超えるボリューム レートでワークスペースにデータが送信される場合、しきい値を超え続けている間、6 時間ごとにワークスペースの 操作 テーブルにイベントが送信されます。 インジェスト ボリューム レートがしきい値を超えると、一部のデータが削除され、しきい値を超え続けている間、6 時間ごとにワークスペースの "操作" テーブルにイベントが送信されます。 インジェスト ボリューム レートがしきい値を超え続けている場合、または間もなくそれに達すると予測される場合は、サポート リクエストを開いて、その引き上げをリクエストできます。

インジェストの制限に達するときに事前に通知されるようアラート ルールを作成するには、「Azure Monitor で Log Analytics ワークスペースの正常性を監視する」を参照してください。

注意

Log Analytics を使用してきた期間の長さによっては、レガシ価格レベルにアクセスできることがあります。 詳細については、Log Analytics のレガシ価格レベルに関するページを参照してください。

Application Insights

アプリケーションごと (インストルメンテーション キーごと) のメトリックとイベントの数には制限があります。 制限は、選択する料金プランによって異なります。

リソース 制限 Note
1 日あたりの合計データ量 100 GB 上限を設定することでデータを削減できます。 さらにデータが必要な場合は、ポータルで上限を最大 1,000 GB まで引き上げることができます。 1,000 GB を超える容量については、AIDataCap@microsoft.com までメールでご連絡ください。
Throttling 32,000 イベント/秒 制限は 1 分以上にわたって測定されます。
データの保持 30 日から 730 日 このリソースは、SearchAnalytics、およびメトリックス エクスプローラー用です。
可用性の複数手順のテストの詳細な結果の保持 90 日間 このリソースは、各手順の詳細な結果を提供します。
イベントの最大サイズ 64,000 バイト
プロパティとメトリック名の長さ 150 型スキーマに関するページを参照してください。
プロパティ値の文字列の長さ 8,192 型スキーマに関するページを参照してください。
トレースおよび例外のメッセージ長 32,768 型スキーマに関するページを参照してください。
アプリあたりの可用性テストの数 100
プロファイラーのデータ保持期間 5 日
プロファイラーの 1 日あたりの送信データ 10 GB

詳細については、Application Insights の価格とクォータに関するページを参照してください。

次の手順