Azure Monitorコストは、Log Analytics ワークスペースで収集されたデータの量によって大きく異なる場合があります。 ワークスペースを使用する一連のソリューションと、各ソリューションが収集するデータの量は、このボリュームに影響します。
この記事では、収集したデータを分析してデータ インジェスト コストを制御するためのガイダンスを提供します。 これは以下のことに役立ちます。
- 予想を超える使用量の原因を特定します。
- より多くのリソースを監視し、さまざまな Azure Monitor 機能を構成するときにコストを予測します。
ヒント
Azure Monitor のコストを削減するための戦略については、「コストの最適化と Azure Monitor」を参照してください。
予想を超える使用量の原因
各 Log Analytics ワークスペースは個々のサービスとして課金され、Azure サブスクリプションの課金内容に加えられます。 データインジェストの量は次の要因によってかなり大きくなる可能性があります。
- 有効になっている一連の分析情報とサービス ( Application Insights、 Container Insights、 VM Insights など) とその構成。
- 監視対象のリソースの数と種類。
- 各監視対象リソースから収集されたデータの量。
これらの要因のいずれかが予期せず増加すると、データ保持に対する料金が増加する可能性があります。 この記事の残りの部分では、このような状況を検出し、収集したデータを分析して、増加した使用量のソースを特定して軽減する方法について説明します。
収集したデータの量が多い場合にアラートを送信する
予期しない請求を回避するには、過剰な使用に対する事前通知を設定します。 通知を受け取ることで、請求期間が終了する前に発生する可能性のある異常に対処するように設定されます。
次の例は、過去 24 時間に取り込まれた課金対象データ ボリュームが 50 GB を超える場合にアラートを送信する ログ検索アラート ルール です。 アラート ロジック設定を変更し、実際の環境内で予想される使用量に基づいて別のしきい値を使用してください。 また、毎日複数回使用状況を確認する頻度を増やすこともできますが、このオプションではアラート ルールの料金が高くなります。
| 設定 | 価値 |
|---|---|
| スコープ | |
| ターゲット スコープ | Log Analytics ワークスペースを選択します。 |
| 条件 | |
| クエリ | Usage \| where IsBillable \| summarize DataGB = sum(Quantity / 1000) |
| 測定 | 測定: DataGB 集計の種類: 合計 集計単位: 1 日 |
| アラート ロジック | 演算子: より大きい しきい値: 50 評価の頻度: 1 日 |
| アクション | しきい値を超えたときに通知するアクション グループを選択または追加します。 |
| 詳細 | |
| 重大度 | 警告 |
| アラート ルール名 | 24 時間でデータ量が 50 GB を超える課金対象データ。 |
組み込みのツールを使用して使用状況を分析する
Azure Monitor の既存のツールを使用して分析を開始します。 これらのツールは構成を必要とせず、多くの場合、最小限の労力で必要な情報を提供できます。 収集したデータを既存の Azure Monitor 機能よりも詳細に分析する必要がある場合は、Log Analytics で次のいずれかのログ クエリを使用します。
Log Analytics ワークスペースインサイト
Log Analytics Workspace Insights を使用すると、ワークスペース内のデータをすばやく理解できます。 たとえば、次のような分析情報が得られます。
- メイン テーブル内の最も多くのデータ ボリュームを取り込むデータ テーブル。
- データを提供する上位のリソース。
- データ インジェストの傾向。
[ 使用状況 ] タブには、ソリューションとテーブルごとのインジェストの内訳が表示されます。 この情報は、データ ボリュームの大部分に影響を与えるテーブルをすばやく識別するのに役立ちます。 タブには、時間の経過に伴うデータ収集の傾向も表示されます。 データ収集が時間の経過と同時に着実に増加したか、構成の変更に応じて突然増加したかを確認します。
データ パターンの理解を深めるのに役立つ事前構築済みクエリの [追加クエリ] を選択します。
使用量と推定コスト
各ワークスペースの [使用量と推定コスト] ページの [ソリューションごとのデータ インジェスト] グラフには、送信されたデータの合計量と、各ソリューションが過去 31 日間に送信した量が表示されます。 この情報は、データの全体的な使用状況や特定のソリューションによる使用状況の増加など、傾向を判断するのに役立ちます。
Usage テーブルから課金対象データ ボリュームを照会する
特定のサービスまたはソリューションによって収集された課金対象データの量を分析します。 これらのクエリでは、ワークスペース内の各テーブルの使用状況データを収集するUsageテーブルが使用されます。
注意
TimeGenerated を含む句は、Azure portal のクエリ機能が既定の 24 時間を超えてさかのぼって参照するようにするためだけのものです。
Usage データ型を使用する場合、StartTime と EndTime は、結果が表示される時間バケットを表します。
過去 1 か月間の種類別の課金対象データ ボリューム
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), DataType
| render columnchart
過去 1 か月間のテーブル プラン別の課金対象データ 量
各テーブル プランに取り込まれたデータの量 (分析ログ、基本ログ、または補助ログ) を表示します。 この Plan 列は、2026 年 5 月中旬に Usage テーブルに追加されました。 それより前に取り込まれたデータには、この列は設定されません。
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), Plan
| render columnchart
過去 1 か月間のソリューションと種類別の課金対象データ量
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000 by Solution, DataType
| sort by Solution asc, DataType asc
クエリの例については、「 Usage テーブルのクエリ」を参照してください。
イベント レコードから課金対象データ ボリュームを照会する
ログ クエリをLog Analyticsで使用します。収集したデータの詳細な分析が必要な場合は、 Log Analytics ワークスペースの各テーブルには、課金対象データの分析に役立つ次の標準列があります。
- _IsBillable は、インジェスト料金が発生するレコードを識別します。 課金対象でないデータを除外するには、この列を使用します。
- _BilledSizeは、レコードのサイズをバイト単位で提供します。
特定のイベントの課金対象データ ボリューム
特定のデータ型が過剰なデータを収集している場合は、そのテーブル内のデータを分析して、増加している特定のレコードを識別できます。 次の使用例は、Event テーブル内の特定のイベント ID をフィルター処理し、各 ID にカウントを提供します。 このクエリは、他のテーブルの列を使用して変更できます。
Event
| where TimeGenerated > startofday(ago(31d)) and TimeGenerated < startofday(now())
| where EventID == 5145 or EventID == 5156
| where _IsBillable == true
| summarize count(), Bytes=sum(_BilledSize) by EventID, bin(TimeGenerated, 1d)
クエリの例については、「 イベント テーブルのクエリ」を参照してください。
Azure リソース、リソース グループ、またはサブスクリプションごとのデータ ボリューム
特定のリソースまたはリソースのセットから収集された課金対象データの量を分析できます。 これらのクエリ では、Azureでホストされているリソースからのデータに対して_ResourceId列と_SubscriptionId列が使用されます。
警告
複数の種類のデータにわたるスキャンは、実行に多量のリソースを使うため、検索クエリは多用しないようにします。 サブスクリプション、リソース グループ、またはリソース名ごとに結果が必要ない場合は、 Usage テーブル の課金対象データ ボリュームのクエリで Usage テーブル クエリを使用します。
過去 1 日のリソース ID 別の課金対象データ量
find where TimeGenerated between(startofday(ago(1d))..startofday(now())) project _ResourceId, _BilledSize, _IsBillable
| where _IsBillable == true
| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId
| sort by BillableDataBytes nulls last
過去 1 日のリソース グループ別の課金対象データ ボリューム
find where TimeGenerated between(startofday(ago(1d))..startofday(now())) project _ResourceId, _BilledSize, _IsBillable
| where _IsBillable == true
| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId
| extend resourceGroup = tostring(split(_ResourceId, "/")[4] )
| summarize BillableDataBytes = sum(BillableDataBytes) by resourceGroup
| sort by BillableDataBytes nulls last
_ResourceId を解析すると役立つ場合があります。
| parse tolower(_ResourceId) with "/subscriptions/" subscriptionId "/resourcegroups/"
resourceGroup "/providers/" provider "/" resourceType "/" resourceName
過去 1 日のサブスクリプション別の課金対象データ 量
find where TimeGenerated between(startofday(ago(1d))..startofday(now())) project _BilledSize, _IsBillable, _SubscriptionId
| where _IsBillable == true
| summarize BillableDataBytes = sum(_BilledSize) by _SubscriptionId
| sort by BillableDataBytes nulls last
ヒント
データ量が多いワークスペースの場合、このセクションに示すような大量の生データを対象とするクエリの実行は、1 日に制限する必要がある場合があります。 経時的な傾向を追跡するには、Power BI レポートを設定し、増分更新を使用してリソースごとに 1 日 1 回データ ボリュームを収集することを検討してください。
コンピューターごとのデータ ボリューム
仮想マシンまたは一連の仮想マシンから収集される課金対象データ量を分析できます。 Usage テーブルには特定の仮想マシンについてのデータ ボリュームを示す細分性がないため、これらのクエリでは検索演算子を使用して、コンピューター名を含むすべてのテーブルを検索します。 このクエリは、データの傾向分析にのみ使用されるため、Usage 型は、省略されています。
警告
複数の種類のデータにわたるスキャンは、実行に多量のリソースを使うため、検索クエリは多用しないようにします。 サブスクリプション、リソース グループ、またはリソース名ごとに結果が必要ない場合は、 Usage テーブル の課金対象データ ボリュームのクエリで Usage テーブル クエリを使用します。
直近の1日のコンピューターごとの課金対象データ量
find where TimeGenerated between(startofday(ago(1d))..startofday(now())) project _BilledSize, _IsBillable, Computer, Type
| where _IsBillable == true and Type != "Usage"
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| summarize BillableDataBytes = sum(_BilledSize) by computerName
| sort by BillableDataBytes desc nulls last
最後の 1 日のコンピューターごとの課金対象イベントの数
find where TimeGenerated between(startofday(ago(1d))..startofday(now())) project _IsBillable, Computer, Type
| where _IsBillable == true and Type != "Usage"
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| summarize eventCount = count() by computerName
| sort by eventCount desc nulls last
一般的なデータ型のクエリ データ ボリューム
特定のデータ型に対して過剰な課金対象データがあることが判明した場合は、そのテーブル内のデータ分析をするため、クエリの実行が必要かもしれません。 次のクエリでは、一般的なデータ型のサンプルを提供します。
セキュリティ ソリューション
SecurityEvent
| summarize AggregatedValue = count() by EventID
| order by AggregatedValue desc nulls last
クエリの例については、 SecurityEvent テーブル のクエリを参照してください。
ログ管理ソリューション
Usage
| where Solution == "LogManagement" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true
| summarize AggregatedValue = count() by DataType
| order by AggregatedValue desc nulls last
クエリの例については、「 Usage テーブルのクエリ」を参照してください。
Perf データ型
Perf
| summarize AggregatedValue = count() by CounterPath
Perf
| summarize AggregatedValue = count() by CounterName
クエリの例については 、Perf テーブル のクエリを参照してください。
イベント データ型
Event
| summarize AggregatedValue = count() by EventID
Event
| summarize AggregatedValue = count() by EventLog, EventLevelName
クエリの例については、「 イベント テーブルのクエリ」を参照してください。
Syslog データ型
Syslog
| summarize AggregatedValue = count() by Facility, SeverityLevel
Syslog
| summarize AggregatedValue = count() by ProcessName
クエリの例については、 Syslog テーブルの クエリを参照してください。
AzureDiagnostics データ型
AzureDiagnostics
| summarize AggregatedValue = count() by ResourceProvider, ResourceId
クエリの例については、 AzureDiagnostics テーブル のクエリを参照してください。
Application Insights データ ボリュームのクエリ
次のクエリは、Log Analytics ワークスペースの外部にデータを格納するクラシック リソースなど、Application Insights リソースに適用されます。 ワークスペースベースのリソースとクラシック リソースの両方に対して取り込まれた各イベントで使用できる _BilledSize プロパティを使用します。 クラシック リソースの場合は、 systemEvents テーブルで集計情報を使用することもできます。
注意
SystemEventsを除く Application Insights テーブルに対するクエリは、ワークスペース ベースの Application Insights リソースと従来の Application Insights リソースの両方で機能します。
後方互換対応により、従来のテーブル名を引き続き使用できます。 ワークスペースベースのリソースの場合は、[Log Analytics ワークスペース] メニューから [ログ] を開きます。 クラシック リソースの場合は、[Application Insights] メニューから [ログ] を開きます。
依存関係操作では、過去 30 日間で最も多くのデータ ボリュームが生成されます (ワークスペースベースまたはクラシック)
dependencies
| where timestamp >= startofday(ago(30d))
| summarize sum(_BilledSize) by operation_Name
| render barchart
この Application Insights リソースの過去 7 日間の種類別の日次データ量 (クラシックのみ)
systemEvents
| where timestamp >= startofday(ago(7d)) and timestamp < startofday(now())
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes) by BillingTelemetryType, bin(timestamp, 1d)
ワークスペースベースのリソースのデータボリュームの傾向
ワークスペースベースの Application Insights リソースのデータ ボリュームの傾向を確認するには、すべての Application Insights テーブルを含むクエリを使用します。 次のクエリでは、ワークスペースベースのリソースに固有のテーブル名を使用します。
ワークスペース内のすべての Application Insights リソースの過去 7 日間の種類別の日次データ量
union AppAvailabilityResults,
AppBrowserTimings,
AppDependencies,
AppExceptions,
AppEvents,
AppMetrics,
AppPageViews,
AppPerformanceCounters,
AppRequests,
AppSystemEvents,
AppTraces
| where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now())
| summarize sum(_BilledSize) by _ResourceId, bin(TimeGenerated, 1d)
1 つの Application Insights リソースのみのデータ量の傾向を確認するには、上記のクエリの summarize の前に次の行を追加します。
| where _ResourceId contains "<myAppInsightsResourceName>"
ヒント
データ量が多いワークスペースの場合は、前のクエリ (大量の生データに対してクエリを実行する) などのクエリを 1 日に制限します。 経時的な傾向を追跡するには、Power BI レポートを設定し、増分更新を使用してリソースごとに 1 日 1 回データ ボリュームを収集することを検討してください。
データを送信するノードについて理解する
特定のソースからの過剰なデータが表示されない場合は、データを送信するエージェントの数が多すぎる可能性があります。
過去 1 か月間において、毎日ハートビートを送信しているエージェント ノードの数
Heartbeat
| where TimeGenerated > startofday(ago(31d))
| summarize nodes = dcount(Computer) by bin(TimeGenerated, 1d)
| render timechart
クエリの例については、「 ハートビート テーブルのクエリ」を参照してください。
警告
複数の種類のデータにわたるスキャンは、実行に多量のリソースを使うため、検索クエリは多用しないようにします。 サブスクリプション、リソース グループ、またはリソース名ごとに結果が必要ない場合は、 Usage テーブル の課金対象データ ボリュームのクエリで Usage テーブル クエリを使用します。
過去 24 時間以内にデータを送信したノードの数
find where TimeGenerated > ago(24h) project Computer
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize nodes = dcount(computerName)
過去 24 時間以内に各ノードによって送信されたデータ ボリューム
find where TimeGenerated > ago(24h) project _BilledSize, Computer
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize TotalVolumeBytes=sum(_BilledSize) by computerName
従来のノード単位の価格体系で課金されるノード
従来のノードごとの価格レベルでは、ノードごとに時間単位で課金されます。 また、一連のセキュリティ データ型のみを送信するノードもカウントされません。 ワークスペースが従来のノードごとの価格レベルにある場合にノードとして課金されるコンピューターの一覧を取得するには、一部のデータ型が無料であるため、課金対象のデータ型を送信するノードを探します。 この場合、完全修飾ドメイン名の左端のフィールドを使用します。
次のクエリは、1時間あたりの課金データを含むコンピューターの数を返します。 請求書の単位数はノードの月単位で、クエリは billableNodeMonthsPerDayとして表します。 ワークスペースにUpdate Managementソリューションがインストールされている場合は、句の一覧にUpdateおよびwhereデータの種類を追加します。
find where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now()) project Computer, _IsBillable, Type, TimeGenerated
| where Type !in ("SecurityAlert", "SecurityBaseline", "SecurityBaselineSummary", "SecurityDetection", "SecurityEvent", "WindowsFirewall", "LinuxAuditLog", "ProtectionStatus", "WindowsEvent", "MDCFileIntegrityMonitoringEvents")
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| where _IsBillable == true
| summarize billableNodesPerHour=dcount(computerName) by bin(TimeGenerated, 1h)
| summarize billableNodesPerDay = sum(billableNodesPerHour)/24., billableNodeMonthsPerDay = sum(billableNodesPerHour)/24./31. by day=bin(TimeGenerated, 1d)
| sort by day asc
注意
ソリューションのターゲット設定を使用した場合の実際の課金アルゴリズムの複雑さは、上記のクエリでは表されていません。
到着遅延データを診断する
Usage レコードを使用して高いデータ インジェストが報告されているのに、データ型で直接_BilledSize合計しても同じ結果が表示されない場合は、到着遅延データが原因である可能性があります。 この状況は、データが古いタイムスタンプで取り込まれる場合に発生します。
たとえば、エージェントに接続の問題があり、再接続後に蓄積されたデータが送信される場合があります。 または、ホストの時刻が正しくない可能性があります。 どちらの例でも、Usage データ型によって報告される取り込まれたデータと、イベントが生成されたタイムスタンプである TimeGenerated によって指定された特定の日の生データの _BilledSize を合計するクエリとの間の明らかな不一致が起こる可能性があります。
到着遅延データの問題を診断するには、 _TimeReceived 列と TimeGenerated 列を使用します。
_TimeReceived プロパティは、Azure Monitorがレコードを受信する時刻です。
次の例では、2021 年 5 月 2 日に取り込まれた W3CIISLog データの大量のデータに応答して、この取り込まれたデータのタイムスタンプを識別します。
where TimeGenerated > datetime(1970-01-01)ステートメントは、すべてのデータを調べる手掛かりをLog Analyticsユーザーインターフェイスに提供する目的で含まれます。
W3CIISLog
| where TimeGenerated > datetime(1970-01-01)
| where _TimeReceived >= datetime(2021-05-02) and _TimeReceived < datetime(2021-05-03)
| where _IsBillable == true
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated, 1d)
| sort by TimeGenerated asc
次のステップ
- Log Analytics ワークスペース内のデータに対する料金の計算方法と、料金を削減するためのさまざまな構成オプションについては、「Azure Monitor Logs の価格の詳細」を参照してください。
- さまざまな種類のAzure Monitor料金の説明と、Azureの請求書でそれらを分析する方法については、「Azure Monitorコストと使用量を参照してください。
- 料金を最小限に抑えるためのAzure Monitorの構成と管理に関するベスト プラクティスについては、「Azure Monitor ベスト プラクティス - コスト管理を参照してください。
- 不要なレコードと列をフィルター処理して、Log Analytics ワークスペースで収集するデータの量を減らす変換の使用方法については、「Azure Monitor (プレビュー) の
Data コレクション変換」を参照してください。