Application Insights の使用量とコストを管理するManage usage and costs for Application Insights

注意

この記事では、Application Insights のコストを理解し、それを制御する方法について説明します。This article describes how to understand and control your costs for Application Insights. 関連記事の「使用量と推定コストの監視」では、さまざまな価格モデルに対する複数の Azure 監視機能全体の使用量と推定コストを表示する方法について説明します。A related article, Monitoring usage and estimated costs describes how to view usage and estimated costs across multiple Azure monitoring features for different pricing models.

Application Insights の課金のしくみについてご質問がある場合は、フォーラムに投稿してください。If you have questions about how pricing works for Application Insights, you can post a question in our forum.

価格モデルPricing model

Azure Application Insights の価格は従量課金制モデルであり、取り込まれたデータの量に基づき、データを長期保有してもかかる場合があります。The pricing for Azure Application Insights is a Pay-As-You-Go model, based on data volume ingested and optionally for longer data retention. Application Insights の各リソースは個々のサービスとして課金され、Azure サブスクリプションの課金内容に加えられます。Each Application Insights resource is charged as a separate service and contributes to the bill for your Azure subscription.

データ ボリュームの詳細Data volume details

  • データ ボリュームとは、Application Insights で受信したテレメトリのバイト数です。Data volume is the number of bytes of telemetry received by Application Insights. データ ボリュームは、Application Insights がアプリケーションから受信した圧縮されていない JSON データ パッケージのサイズとして測定されます。Data volume is measured as the size of the uncompressed JSON data package that's received by Application Insights from your application. Analytics にインポートされた表形式データでは、データ ボリュームは、Application Insights に送信されたファイルの非圧縮サイズとして測定されます。For tabular data imported to Analytics, data volume is measured as the uncompressed size of files that are sent to Application Insights.
  • アプリケーションのデータ ボリューム料金は、2018 年 4 月からデータ インジェストという新しい課金メーターで報告されるようになりました。Your application's data volume charges are now reported on a new billing meter named Data Ingestion as of April 2018. この新しいメーターは Applications Insights や Log Analytics などの監視テクノロジで共有され、現在は Log Analytics というサービス名の下に表示されます。This new meter is shared across monitoring technologies such as Applications Insights and Log Analytics and is currently under the service name Log Analytics.
  • ライブ メトリック ストリーム データは、課金対象としてカウントされません。Live Metrics Stream data isn't counted for pricing purposes.

注意

この記事のスクリーンショットに表示されているすべての価格は、例を示す目的でのみ使用されています。All prices displayed in screenshots in this article are for example purposes only. お客様の通貨およびリージョンでの現在の価格については、「Application Insights の価格」をご覧ください。For current prices in your currency and region, see Application Insights pricing.

複数手順の Web テストMulti-step web tests

複数ステップ Web テストに対しては、追加料金が発生します。Multi-step web tests incur an additional charge. 複数ステップ Web テストは、一連のアクションを実行する Web テストです。Multi-step web tests are web tests that perform a sequence of actions.

単一ページの "ping テスト" については、個別の料金はかかりません。There's no separate charge for ping tests of a single page. Ping テストと複数ステップ テストからのテレメトリについては、アプリの他のテレメトリと同じ料金が請求されます。Telemetry from ping tests and multi-step tests is charged the same as other telemetry from your app.

アプリケーションを管理するためのコストの見積もりEstimating the costs to manage your application

Application Insights をまだ使用していない場合は、Azure Monitor 料金計算ツールを使用して、Application Insights の使用コストを見積もることができます。If you're not yet using Application Insights, you can use the Azure Monitor pricing calculator to estimate the cost of using Application Insights. まず、[検索] ボックスに「Azure Monitor」と入力し、結果として表示される Azure Monitor タイルをクリックします。Start by entering "Azure Monitor" in the Search box, and clicking on the resulting Azure Monitor tile. ページを下にスクロールして Azure Monitor に移動し、[種類] ドロップダウンから [Application Insights] を選択します。Scroll down the page to Azure Monitor, and select Application Insights from the Type dropdown. 知りたいことは Application Insights によるアプリケーションの監視で収集されるデータの量なので、ここでは 1 か月間に収集することが予想されるデータの GB 数を入力できます。Here you can enter the number of GB of data you expect to collect per month, so they question is how much data will Application Insights collect monitoring your application.

これに対応する方法は 2 つあり、ASP.NET SDK で利用できる既定の監視とアダプティブ サンプリングを使用するか、または他の似た顧客の実績に基づいてデータ インジェストを推定します。There are two approaches to address this: use of default monitoring and adaptive sampling which is available in the ASP.NET SDK, or estimtate you likley data ingestion based on what other similar customers have seen.

サンプリングを使用する場合のデータ収集Data collection when using sampling

ASP.NET SDK のアダプティブ サンプリングを使用すると、データ ボリュームが自動的に調整されて、既定の Application Insights 監視に対して指定されている最大トラフィック レート内に維持されます。With the ASP.NET SDK's adaptive sampling, the data volume is adjusted automatically to keep within a specified maximum rate of traffic for default Application Insights monitoring. アプリケーションが少量のテレメトリを生成している場合 (デバッグ時や使用量が少ない場合など)、量が構成されている秒あたりイベント数レベルを下回っている限り、サンプリング プロセッサによって項目がドロップされることはありません。If the application produces a low amount of telemetry, such as when debugging or due to low usage, items won't be dropped by the sampling processor as long as volume is below the configured events per second level. 量の多いアプリケーションの場合、既定のしきい値である 5 イベント/秒では、アダプティブ サンプリングによって 1 日あたりのイベント数は 432,000 に制限されます。For a high volume application, with the default threshold of 5 events per second, adaptive sampling will limit the number of daily events to 432,000. 標準的な平均イベント サイズである 1 KB を使用すると、アプリケーションがホストされているノードごとに、1 か月 (31 日) あたり 13.4 GB のテレメトリに対応します (サンプリングは各ノードに対してローカルに行われるため)。Using a typical average event size of 1 KB, this corresponds to 13.4 GB of telemetry per 31-day month per node hosting your application (since the sampling is done local to each node.)

アダプティブ サンプリングがサポートされていない SDK の場合は、インジェスト サンプリング を使用できます。この機能では、保持するデータの割合に基づいて、または Web サーバーと Web ブラウザーから送信されるトラフィックを減らすために ASP.NET、ASP.NET Core、および Java の Web サイトでは固定レートのサンプリングで、Application Insights によってデータが受信されたときにサンプリングされますFor SDKs which don't support adaptive sampling, you can employ [ingestion sampling)[https://docs.microsoft.com/azure/azure-monitor/app/sampling#ingestion-sampling] which samples when the data is receved by Application Insights based on a percentage of data to retain, or fixed-rate sampling for ASP.NET, ASP.NET Core, and Java websites to reduce the traffic sent from your web server and web browsers

似た顧客の収集を参考にするLearn from what similar customers collect

Application Insights 用の Azure Monitoring 料金計算ツールでは、"アプリケーションのアクティビティに基づいてデータ量を見積もる" 機能を有効にした場合、アプリケーションに関する情報を (クライアント側テレメトリを収集する場合、1 か月あたりの要求数とページ ビュー数) を入力すると、類似アプリケーションによって収集されたデータ量の中央値と 90 パーパーセンタイル量が表示されます。In the Azure Monitoring Pricing calculator for Application Insights, if you enable the "Estimate data volume based on application activity" functionality, you can provide inputs about your application (requests per month and page views per month, in case you will collect client side telemetry), and then the calculator will tell you the median and 90th percentile amount of data collected by similar applications. もちろん、これらのアプリケーションでの Application Insights の構成は範囲が広いので (たとえば、既定のサンプリングを使用しているものや、サンプルを使用していないものなど)、サンプリングを使用して、取り込まれるデータの量が中央値のレベルよりはるかに少なくなるように制御できます。Of course these applicatons span the range of Application Insights configuration (e.g some have default sampling, some have no sampling etc.), so you still have the control to reduce the volume of data you ingest far below the median level using sampling. しかし、これは、他の似た顧客が行っていることを理解するための出発点となります。But this is a starting point to understand what other, similar customers are seeing.

ご自分の使用量を理解してコストを見積もるUnderstand your usage and estimate costs

Application Insights では、最近の使用パターンに基づいてコストがどのようになるかを簡単に理解できるようになっています。Application Insights makes it easy to understand what your costs are likely to be based on recent usage patterns. 作業を開始するには、Azure portal で Application Insights リソースの [使用量と推定コスト] ページに移動します。To get started, in the Azure portal, for the Application Insights resource, go to the Usage and estimated costs page:

価格の選択

A.A. 該当の月のデータ量を確認します。Review your data volume for the month. これには、サーバーおよびクライアント アプリから、また可用性テストから (サンプリングの後に) 受信され保持されたすべてのデータが含まれます。This includes all the data that's received and retained (after any sampling) from your server and client apps, and from availability tests.
B.B. 複数ステップ Web テストで別料金が発生しています。A separate charge is made for multi-step web tests. (これには、データ ボリューム料金に含まれるシンプルな可用性テストは含まれません。)(This doesn't include simple availability tests, which are included in the data volume charge.)
C.C. 過去 1 か月のデータ ボリュームの傾向を表示します。View data volume trends for the past month.
D.D. データ インジェストのサンプリングを有効にします。Enable data ingestion sampling.
E.E. 1 日のデータ ボリュームの上限を設定します。Set the daily data volume cap.

Application Insights の使用量をさらに詳しく調査するには、 [メトリック] ページを開き、"データ ポイントの量" という名前のメトリックを追加してから、 [Apply splitting](分割の適用) オプションを選択して、"テレメトリ項目の種類" でデータを分割します。To investigate your Application Insights usage more deeply, open the Metrics page, add the metric named "Data point volume", and then select the Apply splitting option to split the data by "Telemetry item type".

Application Insights の課金は Azure の課金内容に加えられます。Application Insights charges are added to your Azure bill. Azure Portal の [課金] セクションか Azure Billing Portal で、Azure の課金内容の詳細を確認できます。You can see details of your Azure bill in the Billing section of the Azure portal, or in the Azure billing portal.

左側のメニューで [課金] を選択します

Azure の請求書での Application Insights の使用状況の表示Viewing Application Insights usage on your Azure bill

Azure では、Azure Cost Management と課金ハブに便利な機能が多数用意されています。Azure provides a great deal of useful functionality in the Azure Cost Management + Billing hub. たとえば、"コスト分析" 機能を使用すると、Azure リソースに対するご自分の支出を表示できます。For instance, the "Cost analysis" functionality enables you to view your spends for Azure resources. リソースの種類 (Application Insights の場合は microsoft.insights/components) でフィルターを追加すると、支出を追跡することができます。Adding a filter by resource type (to microsoft.insights/components for Application Insights) will allow you see track your spend.

Azure portal から使用状況をダウンロードすることで、ご自分の使用状況をさらに詳しく理解できます。More understanding of your usage can be gained by downloading your usage from the Azure Portal. ダウンロードしたスプレッドシートでは、Azure リソースごとに、1 日あたりの使用量を確認できます。In the downloaded spreadsheet you can see usage per Azure resource per day. この Excel スプレッドシートでは、Application Insights のリソースからの使用量を検索することができます。それには、まず、[測定カテゴリ] 列でフィルター処理を行って "Application Insights" と "Log Analytics" を表示し、次に [インスタンス ID] 列に対するフィルター ("contains microsoft.insights/components") を追加します。In this Excel spreadsheet, usage from your Application Insights resources can be found by first filtering on the "Meter Category" column to show "Application Insights" and "Log Analytics", and then adding a filter on the "Instance ID" column which is "contains microsoft.insights/components". すべての Azure Monitor コンポーネントに対して 1 つのログ バックエンドがあるため、ほとんどの Application Insights の使用量は、メーターでは Log Analytics の測定カテゴリで報告されます。Most Application Insights usage is reported on meters with the Meter Category of Log Analytics, since there is a single logs backend for all Azure Monitor components. Application Insights の測定カテゴリで報告されるのは、従来の価格レベルおよび複数ステップ Web テストでの Application Insights リソースのみです。Only Application Insights resources on legacy pricing tiers and multi-step web tests are reported with a Meter Category of Application Insights. 使用量は "消費量" 列に表示され、各エントリの単位は "測定単位" 列に表示されます。The usage is shown in the "Consumed Quantity" column and the unit for each entry is shown in the "Unit of Measure" column. 詳細については、「Microsoft Azure の課金内容を確認する」を参照してください。More details are available to help you understand your Microsoft Azure bill.

データ ボリュームの管理Managing your data volume

アプリから送信されるデータの量を把握するには、次の操作を行います。To understand how much data your app is sending, you can:

  • [使用量と推定コスト] ウィンドウに移動し、毎日のデータ ボリュームのグラフを確認します。Go to the Usage and estimated cost pane to see the daily data volume chart.
  • メトリックス エクスプローラーで、新しいグラフを追加します。In Metrics Explorer, add a new chart. グラフ メトリックについては、 [データ ポイントの量] を選択します。For the chart metric, select Data point volume. [グループ化] を有効にし、 [データの種類] を選択してグループ化します。Turn on Grouping, and then group by Data type.
  • systemEvents データ型を使用します。Use the systemEvents data type. たとえば、過去 1 日に取り込まれたデータ ボリュームを表示するためのクエリは、次のようになります。For instance, to see the data volume ingested in the last day, the query would be:
systemEvents 
| where timestamp >= ago(1d)
| where type == "Billing" 
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes)

このクエリは、データ ボリュームに対するアラートを設定するために、Azure ログ アラートで使用できます。This query can be used in an Azure Log Alert to set up alerting on data volumes.

送信するデータの量は、次の 3 つの方法で管理できます。The volume of data you send can be managed in three ways:

  • サンプリング:サンプリングを使用すると、メトリックのひずみを最小に抑えて、サーバーおよびクライアント アプリから送信されるテレメトリの量を減らすことができます。Sampling: You can use sampling to reduce the amount of telemetry that's sent from your server and client apps, with minimal distortion of metrics. サンプリングは、送信するデータの量を調整するために使用できる主要なツールです。Sampling is the primary tool you can use to tune the amount of data you send. サンプリング機能の詳細については、こちらを参照してくださいLearn more about sampling features.

  • 日次上限:Azure portal で Application Insights リソースを作成する場合、日次上限は 100 GB/日に設定されます。Daily cap: When you create an Application Insights resource in the Azure portal, the daily cap is set to 100 GB/day. Visual Studio から Application Insights リソースを作成する場合の既定値は小 (32.3 MB/日) です。When you create an Application Insights resource in Visual Studio, the default is small (only 32.3 MB/day). 日次上限の既定値は、テストを容易にするために設定されます。The daily cap default is set to facilitate testing. アプリを実稼働環境にデプロイする前に、ユーザーが日次上限を上げることになります。It's intended that the user will raise the daily cap before deploying the app into production.

    高トラフィック アプリケーション用に最大値の引き上げを要求する場合を除き、最大の上限は 1,000 GB/日です。The maximum cap is 1,000 GB/day unless you request a higher maximum for a high-traffic application.

    日次上限に関する警告メールは、Application Insights リソースの次のロールのメンバーであるアカウントに送信されます: "ServiceAdmin"、"AccountAdmin"、"CoAdmin"、"Owner"。Warning emails about the daily cap are sent to account that are members of these roles for your Application Insights resource: "ServiceAdmin", "AccountAdmin", "CoAdmin", "Owner".

    日次上限を設定する場合はご注意ください。Use care when you set the daily cap. 意図は、"日次上限に達しない" ようにすることです。Your intent should be to never hit the daily cap. 日次上限に達した場合、その日の残りの時間についてデータが失われ、アプリケーションを監視することはできません。If you hit the daily cap, you lose data for the remainder of the day, and you can't monitor your application. 日次上限を変更するには、 [日次ボリューム上限] オプションを使用します。To change the daily cap, use the Daily volume cap option. このオプションには、 [使用量と推定コスト] ウィンドウでアクセスできます (これについてはこの記事で後ほど詳しく説明します)。You can access this option in the Usage and estimated costs pane (this is described in more detail later in the article).

    Application Insights には使用できなかったクレジットがある一部のサブスクリプションの種類の制限を除去しました。We've removed the restriction on some subscription types that have credit that couldn't be used for Application Insights. これまでは、サブスクリプションに使用制限がある場合は、[日次上限] ダイアログに、使用制限を解除して日次上限を 32.3 MB/日から引き上げる方法が表示されました。Previously, if the subscription has a spending limit, the daily cap dialog has instructions to remove the spending limit and enable the daily cap to be raised beyond 32.3 MB/day.

  • スロットル:スロットルにより、データ速度は、インストルメンテーション キーごとに 1 分間で平均して 1 秒あたり 32,000 イベントに制限されます。Throttling: Throttling limits the data rate to 32,000 events per second, averaged over 1 minute per instrumentation key. アプリから送信されるデータ量は分単位で評価されます。The volume of data that your app sends is assessed every minute. 1 分間で平均して 1 秒あたりのレートを超える場合、一部の要求がサーバーから拒否されます。If it exceeds the per-second rate averaged over the minute, the server refuses some requests. SDK はデータをバッファー処理し、その再送信を試みます。The SDK buffers the data and then tries to resend it. 急激な増加を数分間に分散させます。It spreads out a surge over several minutes. アプリが常にスロットル レートを超えてデータを送信した場合、一部のデータが破棄されますIf your app consistently sends data at more than the throttling rate, some data will be dropped. (ASP.NET、Java、JavaScript SDK はこの方法でデータの再送信を試みますが、その他の SDK は調整されたデータを単に破棄します)。スロットルが発生した場合、この状況が発生したことを通知する警告が表示されます。(The ASP.NET, Java, and JavaScript SDKs try to resend data this way; other SDKs might simply drop throttled data.) If throttling occurs, a notification warning alerts you that this has occurred.

データ ボリュームの削減Reduce your data volume

データ ボリュームを減らすために、以下のことを実行できます。Here are some things you can do to reduce your data volume:

  • サンプリングの使用。Use Sampling. このテクノロジは、メトリックがゆがめずにデータ速度を低下させます。This technology reduces your data rate without skewing your metrics. Search では、関連項目間を移動する機能は失われません。You don't lose the ability to navigate between related items in Search. サーバー アプリケーションでは、サンプリングは自動的に動作します。In server apps, sampling operates automatically.
  • 報告できる AJAX 呼び出しの数を制限する か、AJAX レポートを無効にします。Limit the number of Ajax calls that can be reported in every page view, or switch off Ajax reporting.
  • ApplicationInsights.config を編集し、不要なコレクション モジュールを無効にします。Edit ApplicationInsights.config to turn off collection modules that you don't need. たとえば、パフォーマンス カウンターや依存関係のデータが重要ではないと判断した場合などに検討します。For example, you might decide that performance counters or dependency data are inessential.
  • 異なるインストルメンテーション キー間でテレメトリを分割します。Split your telemetry among separate instrumentation keys.
  • 事前集計メトリック。Pre-aggregate metrics. TrackMetric への呼び出しをアプリに配置した場合、平均計算と測定のバッチの標準偏差を受け入れるオーバーロードを使用して、トラフィックを減らすことができます。If you put calls to TrackMetric in your app, you can reduce traffic by using the overload that accepts your calculation of the average and standard deviation of a batch of measurements. または、事前集計パッケージを使用することもできます。Or, you can use a pre-aggregating package.

ご自分のデータの 1 日の最大ボリュームを管理するManage your maximum daily data volume

日次ボリューム上限を使用すると、収集されるデータを制限できます。You can use the daily volume cap to limit the data collected. ただし、上限に達した場合は、その日の残りの時間についてアプリケーションから送信されたすべてのテレメトリが失われます。However, if the cap is met, a loss of all telemetry sent from your application for the remainder of the day occurs. アプリケーションが日次上限に達することは "望ましくありません"。It is not advisable to have your application hit the daily cap. 日次上限に達した後は、アプリケーションの正常性とパフォーマンスを追跡できません。You can't track the health and performance of your application after it reaches the daily cap.

日次ボリューム上限を使用する代わりに、サンプリングを使用して、データ ボリュームを目的のレベルに調整してください。Instead of using the daily volume cap, use sampling to tune the data volume to the level you want. その後、アプリケーションが予期せず大量のテレメトリの送信を開始した場合に、"最後の手段" としてのみ日次上限を使用します。Then, use the daily cap only as a "last resort" in case your application unexpectedly begins to send much higher volumes of telemetry.

定義する日次データ制限を明らかにするIdentify what daily data limit to define

Application Insights の使用量と推定コストを確認し、データ インジェストの傾向および日次のデータ ボリュームの上限をどう定義するか理解します。Review Application Insights Usage and estimated costs to understand the data ingestion trend and what is the daily volume cap to define. 上限に達した後はリソースを監視できなくなるので、慎重に検討してください。It should be considered with care, since you won’t be able to monitor your resources after the limit is reached.

1 日の上限を設定するSet the Daily Cap

日次上限を変更するには、Application Insights リソースの [構成] セクションで、 [使用量と推定コスト] ページから [日次上限] を選択します。To change the daily cap, in the Configure section of your Application Insights resource, in the Usage and estimated costs page, select Daily Cap.

テレメトリの日次ボリューム上限の調整

日次上限を変更するために Azure Resource Manager で変更するプロパティは dailyQuota です。To change the daily cap via Azure Resource Manager, the property to change is the dailyQuota. Azure Resource Manager を使用して、dailyQuotaResetTime と日次上限の warningThreshold を設定することもできます。Via Azure Resource Manager you can also set the dailyQuotaResetTime and the daily cap's warningThreshold.

サンプリングSampling

サンプリングは、テレメトリがアプリに送信される速度を低下させる一方で、診断検索中に関連イベントを見つける機能を保持する方法です。Sampling is a method of reducing the rate at which telemetry is sent to your app, while retaining the ability to find related events during diagnostic searches. 適切なイベント カウントも保持されます。You also retain correct event counts.

サンプリングは、料金を削減し、月間クォータ内で維持する効果的な方法です。Sampling is an effective way to reduce charges and stay within your monthly quota. サンプリング アルゴリズムはテレメトリの関連項目を保持するので、たとえば、Search を使用する場合は、特定の例外に関連する要求を検出できます。The sampling algorithm retains related items of telemetry so, for example, when you use Search, you can find the request related to a particular exception. アルゴリズムは、要求レート、例外レート、およびその他のカウントについてメトリックス エクスプローラーに正しい値が表示されるように正しいカウントも保持します。The algorithm also retains correct counts so you see the correct values in Metric Explorer for request rates, exception rates, and other counts.

サンプリングの形式にはいくつかあります。There are several forms of sampling.

  • アダプティブ サンプリングは、ASP.NET SDK の既定値です。Adaptive sampling is the default for the ASP.NET SDK. アダプティブ サンプリング は、アプリが送信するテレメトリの量を自動的に調整します。Adaptive sampling automatically adjusts to the volume of telemetry that your app sends. Web アプリの SDK で自動的に動作して、ネットワーク上のテレメトリのトラフィックを削減します。It operates automatically in the SDK in your web app so that telemetry traffic on the network is reduced.
  • インジェスト サンプリング " は、アプリからのテレメトリが Application Insights サービスに入る時点で動作します。Ingestion sampling is an alternative that operates at the point where telemetry from your app enters the Application Insights service. インジェスト サンプリングは、アプリから送信されるテレメトリの量には影響しませんが、サービスによって保持される量が削減されます。Ingestion sampling doesn't affect the volume of telemetry sent from your app, but it reduces the volume that's retained by the service. インジェスト サンプリングを使用すると、ブラウザーや他の SDK からのテレメトリによって使用されるクォータを削減できます。You can use ingestion sampling to reduce the quota that's used up by telemetry from browsers and other SDKs.

インジェスト サンプリングを設定するには、 [価格] ウィンドウに移動します。To set ingestion sampling, go to the Pricing pane:

クォータと価格のウィンドウで、[サンプル] タイルを選択して、サンプリングの割合を選択する

警告

[データのサンプリング] ウィンドウでは、インジェスト サンプリングの値だけを制御します。The Data sampling pane controls only the value of ingestion sampling. アプリで Application Insights SDK によって適用されているサンプリング レートは反映されません。It doesn't reflect the sampling rate that's applied by the Application Insights SDK in your app. 受信テレメトリが既に SDK でサンプリングされている場合、インジェスト サンプリングは適用されません。If the incoming telemetry has already been sampled in the SDK, ingestion sampling isn't applied.

適用されている場所に関係なく、実際のサンプリング レートを検出するには、Analytics クエリ を使用します。To discover the actual sampling rate, no matter where it's been applied, use an Analytics query. クエリは次のようになります。The query looks like this:

requests | where timestamp > ago(1d)
| summarize 100/avg(itemCount) by bin(timestamp, 1h)
| render areachart

保持されている各レコードで、itemCount は、それが表す元のレコードの数を示します。In each retained record, itemCount indicates the number of original records that it represents. これは、1 + 以前に破棄されたレコードの数と同じです。It's equal to 1 + the number of previous discarded records.

データ保持期間の変更Change the data retention period

Application Insights リソースの既定の保持期間は 90 日です。The default retention for Application Insights resources is 90 days. Application Insights リソースごとに異なる保持期間を選択できます。Different retention periods can be selected for each Application Insights resource. 使用可能な保持期間の完全なセットは、30 日、60 日、90 日、120 日、180 日、270 日、365 日、550 日、または 730 日です。The full set of available retention periods is 30, 60, 90, 120, 180, 270, 365, 550 or 730 days.

保持期間を変更するには、ご利用の Application Insights リソースから [使用量と推定コスト] ページに移動し、 [データ保持期間] オプションを選択します。To change the retention, from your Application Insights resource, go to the Usage and Estimated Costs page and select the Data Retention option:

テレメトリの日次ボリューム上限の調整

この保持期間は retentionInDays パラメーターを使用して ARM 経由で設定することもできます。The retention can also be set via ARM using the retentionInDays parameter. さらに、データ保持を 30 日間に設定すると、immediatePurgeDataOn30Days パラメーターを使用してより古いデータの即時の消去をトリガーできます。これは、コンプライアンス関連のシナリオに役立つ可能性があります。Additionally, if you set the data retention to 30 days, you can trigger an immediate purge of older data using the immediatePurgeDataOn30Days parameter, which may be useful for compliance-related scenarios. この機能は ARM 経由でのみ公開されます。This functionality is only exposed via ARM.

2019 年 12 月の初めに長期の保持期間に対する課金が開始する場合、90 日を超えて保持されているデータには、Azure Log Analytics のデータ保持期間に対して現在請求されているのと同じ料金で課金されます。When billing begins for longer retention in early December 2019, data kept longer than 90 days will be billed as the same rate as is currently billed for Azure Log Analytics data retention. 詳細については、「Azure Monitor の価格」ページを参照してください。Learn more at the Azure Monitor Pricing page. この提案に投票することによって、可変の保持期間の進捗に関する最新情報を把握してください。Stay up-to-date on variable retention progress by voting for this suggestion.

Application Insights の使用でのデータ転送料金Data transfer charges using Application Insights

Application Insights にデータを転送する場合、データ帯域幅の料金が発生する場合があります。Sending data to Application Insights might incur data bandwidth charges. Azure 帯域幅の価格ページで説明されているように、2 つのリージョンに存在する Azure サービス間のデータ転送は、通常の料金で送信データ転送として課金されます。As described in the Azure Bandwidth pricing page, data transfer between Azure services located in two regions charged as outbound data transfer at the normal rate. 受信データ転送は無料です。Inbound data transfer is free. ただし、この料金は、Application Insights のデータ インジェストのコストと比へると非常に小さい (数パーセント) ものです。However, this charge is very small (few %) compared to the costs for Application Insights log data ingestion. そのため、Log Analytics のコスト管理では、ご自分で取り込まれたデータ ボリュームに注目する必要があり、それについて理解するためのガイダンスがこちらに用意されています。Consequently controlling costs for Log Analytics needs to focus on your ingested data volume, and we have guidance to help understand that here.

制限の概要Limits summary

アプリケーションごと (インストルメンテーション キーごと) のメトリックとイベントの数には制限があります。There are some limits on the number of metrics and events per application, that is, per instrumentation key. 制限は、選択する料金プランによって異なります。Limits depend on the pricing plan that you choose.

ResourceResource 既定の制限Default limit NoteNote
1 日あたりの合計データ量Total data per day 100 GB100 GB 上限を設定することでデータを削減できます。You can reduce data by setting a cap. さらにデータが必要な場合は、ポータルで上限を最大 1,000 GB まで引き上げることができます。If you need more data, you can increase the limit in the portal, up to 1,000 GB. 1,000 GB を超える容量については、AIDataCap@microsoft.com までメールでご連絡ください。For capacities greater than 1,000 GB, send email to AIDataCap@microsoft.com.
ThrottlingThrottling 32,000 イベント/秒32,000 events/second 制限は 1 分以上にわたって測定されます。The limit is measured over a minute.
データの保持Data retention 30 日から 730 日30 - 730 days このリソースは、SearchAnalytics、およびメトリックス エクスプローラー用です。This resource is for Search, Analytics, and Metrics Explorer.
可用性の複数手順のテストの詳細な結果の保持Availability multi-step test detailed results retention 90 日間90 days このリソースは、各手順の詳細な結果を提供します。This resource provides detailed results of each step.
テレメトリ項目の最大サイズMaximum telemetry item size 64 KB64 kB
バッチあたりの最大テレメトリ項目数Maximum telemetry items per batch 64 K64 K
プロパティとメトリック名の長さProperty and metric name length 150150 型スキーマに関するページを参照してください。See type schemas.
プロパティ値の文字列の長さProperty value string length 8,1928,192 型スキーマに関するページを参照してください。See type schemas.
トレースおよび例外のメッセージ長Trace and exception message length 32,76832,768 型スキーマに関するページを参照してください。See type schemas.
アプリあたりの可用性テストの数Availability tests count per app 100100
プロファイラーのデータ保持期間Profiler data retention 5 日5 days
プロファイラーの 1 日あたりの送信データProfiler data sent per day 10 GB10 GB

詳細については、Application Insights の価格とクォータに関するページを参照してください。For more information, see About pricing and quotas in Application Insights.

日次上限メールを無効にするDisable daily cap e-mails

日次ボリューム上限メールを無効にするには、Application Insights リソースの [構成] セクションで、 [使用量と推定コスト] ウィンドウから [日次上限] を選択します。To disable the daily volume cap e-mails, under the Configure section of your Application Insights resource, in the Usage and estimated costs pane, select Daily Cap. 上限に達したとき、および調整可能な警告レベルに達したときに、メールを送信する設定があります。There are settings to send e-mail when the cap is reached, as well as when an adjustable warning level has been reached. すべての日次上限ボリューム関連メールを無効にする場合は、両方のボックスをオフにします。If you wish to disable all daily cap volume-related emails uncheck both boxes.

従来の Enterprise (Per Node) 価格レベルLegacy Enterprise (Per Node) pricing tier

Azure Application Insights の早期導入者は、引き続き次の 2 つの価格レベルをご利用いただけます。Basic と Enterprise。For early adopters of Azure Application Insights, there are still two possible pricing tiers: Basic and Enterprise. Basic 価格レベルは前述のとおりで、既定のレベルです。The Basic pricing tier is the same as described above and is the default tier. これには、Enterprise レベルのすべての機能が追加コストなしで含まれます。It includes all Enterprise tier features, at no additional cost. Basic レベルでは基本的に、取り込まれるデータの量に基づいて請求されます。The Basic tier bills primarily on the volume of data that's ingested.

注意

レガシ価格レベルの名前が変更されました。These legacy pricing tiers have been renamed. Enterprise 価格レベルの新しい名前は Per Node に、Basic 価格レベルの新しい名前は Per GB となります。The Enterprise pricing tier is now called Per Node and the Basic pricing tier is now called Per GB. Azure portal も含め、以下、これらの新しい名前を使用します。These new names are used below and in the Azure portal.

Per Node (旧 Enterprise) レベルは、料金がノード単位となっており、日単位のデータ利用分が各ノードに割り当てられます。The Per Node (formerly Enterprise) tier has a per-node charge, and each node receives a daily data allowance. Per Node 価格レベルでは、含まれる利用分を超えて取り込まれたデータに対して課金されます。In the Per Node pricing tier, you are charged for data ingested above the included allowance. Operations Management Suite を使用している場合は、Per Node レベルを選択する必要があります。If you are using Operations Management Suite, you should choose the Per Node tier.

お客様の通貨およびリージョンでの現在の価格については、「Application Insights の価格」をご覧ください。For current prices in your currency and region, see Application Insights pricing.

注意

2018 年 4 月に、Azure Monitoring 用の新しい価格モデルを導入しました。In April 2018, we introduced a new pricing model for Azure monitoring. このモデルでは、監視サービスのポートフォリオ全体で単純な "従量課金制" モデルを採用しています。This model adopts a simple "pay-as-you-go" model across the complete portfolio of monitoring services. 新しい価格モデルの詳細、使用パターンに基づいてこのモデルへの移行の影響を評価する方法、新しいモデルを有効にする方法をご確認ください。Learn more about the new pricing model, how to assess the impact of moving to this model based on your usage patterns, and how to opt into the new model

Per Node レベルと Operations Management Suite のサブスクリプションの権利Per Node tier and Operations Management Suite subscription entitlements

以前の発表のとおり、Operations Management Suite E1 および E2 を購入したお客様は、追加コストなしで追加コンポーネントとして Application Insights Per Node を取得できます。Customers who purchase Operations Management Suite E1 and E2 can get Application Insights Per Node as an additional component at no additional cost as previously announced. 具体的には、Operations Management Suite E1 および E2 の各ユニットには、Application Insights Per Node レベル 1 ノード分の権利が含まれています。Specifically, each unit of Operations Management Suite E1 and E2 includes an entitlement to one node of the Application Insights Per Node tier. Application Insights の各ノードは、追加コストなしで、1 日あたり最大 200 MB のデータを取り込み (Log Analytics のデータ インジェストを除く)、90 日間保持できます。Each Application Insights node includes up to 200 MB of data ingested per day (separate from Log Analytics data ingestion), with 90-day data retention at no additional cost. レベルについては、この記事で後ほど詳しく説明します。The tier is described in more detailed later in the article.

このレベルは Operations Management Suite サブスクリプションをお持ちのお客様だけに適用されるので、Operations Management Suite サブスクリプションをお持ちでないお客様にはこのレベルを選ぶオプションは表示されません。Because this tier is applicable only to customers with an Operations Management Suite subscription, customers who don't have an Operations Management Suite subscription don't see an option to select this tier.

注意

この権利を取得するには、Application Insights リソースが Per Node 価格レベルである必要があります。To ensure that you get this entitlement, your Application Insights resources must be in the Per Node pricing tier. この権利は、ノードとしてのみ適用されます。This entitlement applies only as nodes. Per GB レベルの Application Insights リソースでは、メリットは実現されません。Application Insights resources in the Per GB tier don't realize any benefit. この権利は、 [使用量と推定コスト] ウィンドウに表示される見積もりコストには表示されません。This entitlement isn't visible in the estimated costs shown in the Usage and estimated cost pane. また、サブスクリプションを 2018 年 4 月の新しい Azure Monitoring 価格モデルに移行した場合、使用可能なレベルは Per GB レベルだけです。Also, if you move a subscription to the new Azure monitoring pricing model in April 2018, the Per GB tier is the only tier available. Operations Management Suite サブスクリプションをお持ちの場合、新しい Azure Monitoring 価格モデルへのサブスクリプションの移行はお勧めしません。Moving a subscription to the new Azure monitoring pricing model isn't advisable if you have an Operations Management Suite subscription.

Per Node レベルのしくみHow the Per Node tier works

  • Per Node レベルでは、アプリに対してテレメトリを送信するノードごとに料金が課金されます。You pay for each node that sends telemetry for any apps in the Per Node tier.
    • ノードとは、アプリをホストする物理または仮想サーバー マシン (または、サービスとしてのプラットフォーム (PaaS) ロール インスタンス) のことです。A node is a physical or virtual server machine or a platform-as-a-service role instance that hosts your app.
    • 開発マシン、クライアントのブラウザー、およびモバイル デバイスはノードとしてカウントされません。Development machines, client browsers, and mobile devices do not count as nodes.
    • テレメトリを送信するコンポーネント (Web サービスやバックエンド ワーカーなど) がアプリに複数ある場合、それらは個別にカウントされます。If your app has several components that send telemetry, such as a web service and a back-end worker, the components are counted separately.
    • ライブ メトリック ストリーム データは、課金対象としてカウントされません。Live Metrics Stream data isn't counted for pricing purposes. サブスクリプション内では、料金はノード単位で計算されます (アプリ単位ではありません)。In a subscription, your charges are per node, not per app. 12 のアプリに対して 5 つのノードがテレメトリを送信する場合、料金は 5 ノード分になります。If you have five nodes that send telemetry for 12 apps, the charge is for five nodes.
  • 料金の見積りは月単位で計算されますが、実際の料金は、ノードがアプリからテレメトリを送信した時間分しか課金されません。Although charges are quoted per month, you're charged only for any hour in which a node sends telemetry from an app. 1 時間あたりの料金は、1 か月あたりの見積り額を 744 で割ったものです (1 か月 31 日の時間数)。The hourly charge is the quoted monthly charge divided by 744 (the number of hours in a 31-day month).
  • 検出された各ノードに、1 日あたり 200 MB のデータ量の割り当てが (時間単位の精度で) 与えられます。A data volume allocation of 200 MB per day is given for each node that's detected (with hourly granularity). 未使用のデータ割り当て分が日をまたいで繰り越されることはありません。Unused data allocation isn't carried over from one day to the next.
    • Per Node の価格レベルを選んだお客様には、テレメトリをサブスクリプション内の Application Insights リソースに送信するノードの数に基づいて、日単位のデータ利用分が提供されます。If you choose the Per Node pricing tier, each subscription gets a daily allowance of data based on the number of nodes that send telemetry to the Application Insights resources in that subscription. したがって、終日データを送信する 5 つのノードがある場合、サブスクリプション内のすべての Application Insights リソースに 1 GB の許容量が適用されます。So, if you have five nodes that send data all day, you'll have a pooled allowance of 1 GB applied to all Application Insights resources in that subscription. 無料データ利用分はすべてのノードで共有されるため、一部のノードのデータ送信量が他のノードより多くても問題はありません。It doesn't matter if certain nodes send more data than other nodes because the included data is shared across all nodes. 特定の日に、Application Insights リソースがサブスクリプションの日単位のデータ利用分を超えるデータを受信した場合は、1 GB ごとに超過データ料金が適用されます。If on a given day, the Application Insights resources receive more data than is included in the daily data allocation for this subscription, the per-GB overage data charges apply.
    • 1 日あたりの無料データ利用分は、各ノードが 1 日にテレメトリを送信する時間数 (UTC を使用) を 24 で割った値に、200 MB を掛け合わせて計算します。The daily data allowance is calculated as the number of hours in the day (using UTC) that each node sends telemetry divided by 24 multiplied by 200 MB. つまり、4 つのノードが、1 日 24 時間のうち 15 時間テレメトリを送信した場合、その日のデータ量は ((4 × 15) / 24) × 200 MB = 500 MB になります。So, if you have four nodes that send telemetry during 15 of the 24 hours in the day, the included data for that day would be ((4 × 15) / 24) × 200 MB = 500 MB. データ超過分 1 GB あたり 2.30 米国ドルの料金ですので、その日ノードが 1 GB のデータを送信した場合、超過データ料金は 1.15 米国ドルになります。At the price of 2.30 USD per GB for data overage, the charge would be 1.15 USD if the nodes send 1 GB of data that day.
    • Per Node レベルの 1 日あたりのデータ利用分は、Per GB レベルが選択されたアプリケーションとは共有できません。The Per Node tier daily allowance isn't shared with applications for which you have chosen the Per GB tier. 無料データの未使用分は、翌日への引き継ぎはできません。Unused allowance isn't carried over from day-to-day.

個別のノード カウントを決定する方法の例Examples of how to determine distinct node count

シナリオScenario 日単位の合計ノード数Total daily node count
1 つのアプリケーションで 3つの Azure App Service インスタンスと 1 つの仮想サーバーが使用されている。1 application using 3 Azure App Service instances and 1 virtual server 44
3 つのアプリケーションが 2 つの VM で実行され、これらのアプリケーションの Application Insights リソースが、同じサブスクリプションの Per Node レベルにある。3 applications running on 2 VMs; the Application Insights resources for these applications are in the same subscription and in the Per Node tier 22
4 つのアプリケーションの Application Insights リソースが同じサブスクリプションにあり、各アプリケーションはピーク外の時間帯 16 時間は 2 つのインスタンス、ピーク時間帯 8 時間は 4 つのインスタンスを実行している。4 applications whose Applications Insights resources are in the same subscription; each application running 2 instances during 16 off-peak hours, and 4 instances during 8 peak hours 13.3313.33
Cloud Services に 1 つの Worker ロールと 1 つの Web ロールが含まれ、それぞれ 2 つのインスタンスを実行している。Cloud services with 1 Worker Role and 1 Web Role, each running 2 instances 44
5 つのノードがある Azure Service Fabric クラスターが 50 のマイクロサービスを実行し、各マイクロサービスが 3 つのインスタンスを実行している。A 5-node Azure Service Fabric cluster running 50 microservices; each microservice running 3 instances 55
  • 正確なノード カウントは、アプリケーションで使用している Application Insights SDK によって異なります。The precise node counting depends on which Application Insights SDK your application is using.
    • SDK バージョン 2.2 以降では、Application Insights Core SDKWeb SDK の両方が、各アプリケーション ホストをノードとして報告します。In SDK versions 2.2 and later, both the Application Insights Core SDK and the Web SDK report each application host as a node. 例としては、物理サーバーと VM ホストのコンピューター名やクラウド サービスのインスタンス名があります。Examples are the computer name for physical server and VM hosts or the instance name for cloud services. 唯一の例外は、.NET Core と Application Insights Core SDK のみを使用するアプリケーションです。The only exception is an application that uses only the .NET Core and the Application Insights Core SDK. その場合は、ホスト名が使用できないためすべてのホストに対して 1 つのノードが報告されます。In that case, only one node is reported for all hosts because the host name isn't available.
    • 以前のバージョンの SDK では、Web SDK は、新しいバージョンの SDK と同じように動作しますが、Core SDK は実際のアプリケーション ホストの数に関係なく 1 つのノードのみ報告します。For earlier versions of the SDK, the Web SDK behaves like the newer SDK versions, but the Core SDK reports only one node, regardless of the number of application hosts.
    • アプリケーションで SDK を使用してロール インスタンスをカスタム値に設定すると、既定ではノード カウントの決定に同じ値が使用されます。If your application uses the SDK to set roleInstance to a custom value, by default, that same value is used to determine node count.
    • クライアント コンピューターやモバイル デバイスから実行されているアプリで新しいバージョンの SDK を使用している場合は、ノード カウントが (クライアント コンピューターやモバイル デバイスの数が多いため) 非常に大きい数値を返す可能性があります。If you're using a new SDK version with an app that runs from client machines or mobile devices, the node count might return a number that's very large (because of the large number of client machines or mobile devices).

AutomationAutomation

Azure Resource Management を使用して、価格レベルを設定するスクリプトを記述することができます。You can write a script to set the pricing tier by using Azure Resource Management. 方法については、こちらをご覧ください。Learn how.

次の手順Next steps