管理 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 應用程式 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. 針對匯入至分析的表格式資料,資料量是以傳送至 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. 這種新的計量可在監視技術之間共用,例如 Application 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 監視器定價計算機來預估使用 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 監視器",然後按一下產生的 [Azure 監視器] 磚。Start by entering "Azure Monitor" in the Search box, and clicking on the resulting Azure Monitor tile. 在頁面上向下 Azure 監視器,然後從 [類型] 下拉式清單中選取 [Application Insights]。Scroll down the page to Azure Monitor, and select Application Insights from the Type dropdown. 您可以在這裡輸入每月預期要收集的資料 GB 數目,因此問題是 Application Insights 收集監視應用程式的資料量。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.

有兩種方法可以解決這種情況:使用 ASP.NET SDK 中提供的預設監視和調適型取樣,或 estimtate 您根據其他類似客戶看到的內容 likley 資料內嵌。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個事件,調適型取樣會將每日事件數限制為432000。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,這會對應13.4 到每個節點每31天的遙測資料,每個月裝載您的應用程式(因為取樣是在每個節點的本機執行)。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,您可以使用 [內建取樣) [https://docs.microsoft.com/azure/azure-monitor/app/sampling#ingestion-sampling ],根據要保留的資料百分比來 Application Insights receved 資料,或針對ASP.NET、ASP.NET Core 和 JAVA 設定固定速率取樣用來減少從 web 伺服器和網頁瀏覽器傳送流量的網站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 監視定價計算機中,如果您啟用「根據應用程式活動估計資料量」功能,您可以提供應用程式的相關輸入(每月要求和頁面流覽數,以防您收集用戶端遙測),然後計算機會告訴您類似的應用程式所收集的資料中間值和第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 入口網站中,針對 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. 檢視上個月的資料量趨勢。View data volume trends for the past month.
D.D. 啟用資料擷取取樣Enable data ingestion sampling.
E.E. 設定每日資料量上限。Set the daily data volume cap.

若要更深入調查 Application Insights 的使用量,請開啟 [計量] 頁面,新增名為「資料點量」的計量,然後選取 [套用分割] 選項,以根據「遙測項目類型」拆分資料。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 入口網站的 [帳務] 區段中,或在 Azure 計費入口網站中,查看您的 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 成本管理 + 計費中樞提供了大量有用的功能。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 的 insights/元件),可讓您查看追蹤您的支出。Adding a filter by resource type (to microsoft.insights/components for Application Insights) will allow you see track your spend.

您可以從 Azure 入口網站下載您的使用量,以進一步瞭解您的使用方式。More understanding of your usage can be gained by downloading your usage from the Azure Portal. 在下載的試算表中,您可以看到每天每個 Azure 資源的使用量。In the downloaded spreadsheet you can see usage per Azure resource per day. 在此 Excel 試算表中,您可以藉由先篩選「計量類別」資料行來顯示「Application Insights」和「Log Analytics」,然後在「包含」的「實例識別碼」資料行上新增篩選,來找到您 Application Insights 資源的使用量。[microsoft insights/元件]。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". 大部分的 Application Insights 使用量都會以 Log Analytics 計量類別的計量報告,因為所有 Azure 監視器元件都有單一記錄後端。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. 只有舊版定價層和多重步驟 web 測試的 Application Insights 資源,會以 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. 比方說,若要查看過去一天的資料量內嵌,查詢會是: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.

您傳送的資料量可透過三種方式來管理: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 入口網站中建立 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"、"共同管理員"、"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.

  • 節流:節流會將資料速率限制在每秒 32,000 個事件 (每個檢測金鑰以 1 分鐘計算平均值)。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. 如果每秒速率超過每分鐘平均值,伺服器會拒絕部分要求。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. 您不會失去在 [搜尋] 中的相關項目之間瀏覽的能力。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.

管理您的每日最大資料量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.

設定每日上限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 變更每日上限,要變更的屬性為dailyQuotaTo 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. 取樣演算法會保留相關的遙測項目,因此,例如在使用 [搜尋] 時,您便可以找到與特定例外狀況相關的要求。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.

若要探索實際的取樣率,而不論其套用位置是哪裡,請使用分析查詢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 監視器定價頁面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 頻寬定價頁面中所述,位於兩個區域的 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 注意Note
每日資料總量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. 對於大於 1000 GB 的容量,傳送電子郵件AIDataCap@microsoft.com至。For capacities greater than 1,000 GB, send email to AIDataCap@microsoft.com.
正在節流Throttling 每秒32000個事件32,000 events/second 此限制會測量超過一分鐘。The limit is measured over a minute.
資料保留Data retention 30-730 天30 - 730 days 此資源適用於搜尋分析計量瀏覽器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
每天傳送的分析工具資料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.

舊版企業(每個節點)定價層Legacy Enterprise (Per Node) pricing tier

針對 Azure 應用程式深入解析的早期採用者,仍然有兩個可能的定價層:基本和企業。For early adopters of Azure Application Insights, there are still two possible pricing tiers: Basic and Enterprise. 基本定價層與上面所述相同,而且是預設層。The Basic pricing tier is the same as described above and is the default tier. 它包含所有企業層功能,不需額外費用。It includes all Enterprise tier features, at no additional cost. 基本層帳單主要取決於所內嵌的資料量。The Basic tier bills primarily on the volume of data that's ingested.

注意

這些舊版定價層已重新命名。These legacy pricing tiers have been renamed. 企業定價層現在會針對每個節點呼叫,而基本定價層現在會針對每 GB呼叫。The Enterprise pricing tier is now called Per Node and the Basic pricing tier is now called Per GB. 這些新名稱會在 Azure 入口網站中使用。These new names are used below and in the Azure portal.

每個節點(先前稱為「企業」)層都有每個節點的費用,而且每個節點都會收到每日資料額度。The Per Node (formerly Enterprise) tier has a per-node charge, and each node receives a daily data allowance. 在每個節點定價層中,您需支付超過所包含額度的資料內嵌費用。In the Per Node pricing tier, you are charged for data ingested above the included allowance. 如果您使用 Operations Management Suite,您應該選擇 [每個節點] 層。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 監視定價模型。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

每個節點層和 Operations Management Suite 訂用帳戶權利Per Node tier and Operations Management Suite subscription entitlements

購買 Operations Management Suite E1 和 E2 的客戶可以將每個節點 Application Insights 為其他元件,而不需額外付費,如先前所宣佈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 的一個節點權利。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 節點包含每天最多 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 資源必須位於每個節點的定價層。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. 每 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 監視定價模型,則每 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 監視定價模型。Moving a subscription to the new Azure monitoring pricing model isn't advisable if you have an Operations Management Suite subscription.

每個節點層的運作方式How the Per Node tier works

  • 針對每個節點層中的任何應用程式傳送遙測資料的每個節點,您必須支付費用。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 個應用程式的遙測,則是以五個節點計算收費。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. 每小時的費用是月費報價除以 744 (一個月 31 天的小時數)。The hourly charge is the quoted monthly charge divided by 744 (the number of hours in a 31-day month).
  • 每個節點 (資料粒度為小時) 偵測每日 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.
    • 如果您選擇 [每個節點] 定價層,每個訂用帳戶會根據將遙測傳送至該訂用帳戶中 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 個節點全天候傳送資料,您會有合起來 1GB 的資料額度,套用至該訂用帳戶中的所有 Application Insights 資源。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 資源會收到超過此訂用帳戶的每日資料配置所包含的資料,則適用每 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.
    • 每日資料額度的計算方式,是每個節點在當天傳送遙測資料的時數 (使用 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. 因此,如果您有四個節點在一天 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. 以資料超量每一 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.
    • 每個節點層的每日額度不會與您已選擇每個 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 資源位於相同的訂用帳戶中,且位於每個節點層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
雲端服務有 1 個背景工作角色和 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. 範例包括實體伺服器和虛擬機器主機的電腦名稱,或雲端服務的執行個體名稱。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. 在此情況下,因為主機名稱無法使用,所以只會針對所有主機報告一個節點。In that case, only one node is reported for all hosts because the host name isn't available.
    • 對於較早版本的 SDK,Web SDK 的行為就和較新版的 SDK 一樣,不過不論應用程式主機的數目是多少,Core SDK 都只會報告一個節點。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 來將 roleInstance 設為自訂值,依預設將使用那個相同的值來判斷節點計數。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).

自動化Automation

您可以使用 Azure 資源管理來撰寫腳本,以設定定價層。You can write a script to set the pricing tier by using Azure Resource Management. 了解作法Learn how.

後續步驟Next steps