針對 Application Insights 中的高數據擷取進行疑難解答

Application Insights 或 Log Analytics 的計費費用增加通常會因為高數據擷取而發生。本文可協助您針對此問題進行疑難解答，並提供降低數據擷取成本的方法。

一般疑難排解步驟

步驟 1：識別呈現高數據擷取的資源

在 Azure 入口網站中，流覽至您的訂用帳戶，然後選取 [成本管理>成本分析]。此界面提供成本分析視圖，以顯示每項資源的成本，如下所示：

顯示 [成本分析] 面板的螢幕快照。

步驟 2：識別因高數據擷取而成本高昂的數據表

識別 Application Insights 資源或 Log Analytics 工作區之後，請分析數據，並判斷最高數據導入的地方。請考慮最適合您案例的方法：

根據原始記錄計數

使用下列查詢來比較資料表之間的記錄計數：
```
search *
| where timestamp > ago(7d)
| summarize count() by $table
| sort by count_ desc
```
此查詢可協助識別 最吵鬧的 數據表。您可以從該處精簡查詢，以縮小調查範圍。

以取用的位元組為基礎

使用 format_bytes() 純量函式，判斷具有最高位元組消耗的資料表：

systemEvents
| where timestamp > ago(7d)
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize TotalBillingTelemetrySize = sum(BillingTelemetrySizeInBytes) by BillingTelemetryType
| extend BillingTelemetrySizeGB = format_bytes(TotalBillingTelemetrySize, 1 ,"GB")
| sort by BillingTelemetrySizeInBytes desc
| project-away BillingTelemetrySizeInBytes

與記錄計數查詢類似，上述查詢可協助您識別最活躍的數據表，讓您找出特定數據表以進行進一步調查。

使用 Log Analytics 工作區活頁簿

在 Azure 入口網站中，流覽至您的 Log Analytics 工作區，選取 [監控工作簿]，然後選取 [Log Analytics 工作區深入解析] 下的 [使用量]。

此活頁簿提供寶貴的見解，例如每個資料表的資料擷取百分比，以及報告至相同工作區的每個資源的詳細擷取統計資料。

步驟 3：判斷導致高數據擷取的因素

識別具有高數據擷取的數據表之後，請專注於具有最高活動的數據表，並判斷導致高數據擷取的因素。這可能是一個特定應用程式，其會產生比其他人更多的數據、記錄太頻繁的例外狀況訊息，或是發出太多資訊的新記錄器類別。

以下是一些可用於此識別的範例查詢：

requests
| where timestamp > ago(7d)
| summarize count() by cloud_RoleInstance
| sort by count_ desc

requests
| where timestamp > ago(7d)
| summarize count() by operation_Name
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by cloud_RoleName
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

traces
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

您可以嘗試不同的遙測字段。例如，您可能先執行下列查詢，並觀察沒有明顯原因導致額外的數據收集。

dependencies
| where timestamp > ago(7d)
| summarize count() by target
| sort by count_ desc

不過，您可以嘗試其他的遙測欄位，比如target，而不是type。

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

在某些情況下，您可能需要進一步調查特定的應用程式或實例。使用下列查詢來識別嘈雜的訊息或例外狀況類型：

traces
| where timestamp > ago(7d)
| where cloud_RoleName == 'Specify a role name'
| summarize count() by type
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| where cloud_RoleInstance == 'Specify a role instance'
| summarize count() by type
| sort by count_ desc

步驟 4：研究一段時間內攝取的演變

根據先前識別的因素，檢查攝取隨著時間的演進。如此一來，即可判斷此行為是否一致，或是否在特定時間點發生變更。藉由以這種方式分析數據，您可以找出發生變更的時間，並更清楚瞭解高數據擷取背後的原因。此深入解析對於解決問題及實作有效解決方案而言非常重要。

在下列查詢中， bin（） Kusto 查詢語言（KQL）純量函式會用來將數據分割成一天的間隔。這種方法有助於趨勢分析，因為您可以看到數據在一段時間內如何變更或未變更。

dependencies
| where timestamp > ago(30d)
| summarize count() by bin(timestamp, 1d), operation_Name
| sort by timestamp desc

使用聚合函數 min() 來識別特定因素最早記錄的時間戳。此方法有助於建立基準，並提供第一次發生事件或變更時的深入解析。

dependencies
| where timestamp > ago(30d)
| where type == 'Specify dependency type being investigated'
| summarize min(timestamp) by type
| sort by min_timestamp desc

特定案例的疑難解答步驟

案例 1：Log Analytics 中的高資料匯入

查詢 Log Analytics 工作區內的所有資料表：

search *
| where TimeGenerated > ago(7d)
| where _IsBillable == true
| summarize TotalBilledSize = sum(_BilledSize) by $table
| extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
| sort by TotalBilledSize desc
| project-away TotalBilledSize

您可以知道哪一個數據表是成本的最大貢獻者。以下是 AppTraces 的範例：

顯示 AppTraces 資料表是成本最大來源的截圖。

查詢驅動追蹤成本的特定應用程式：

AppTraces
| where TimeGenerated > ago(7d)
| where _IsBillable == true
| summarize TotalBilledSize = sum(_BilledSize) by  AppRoleName
| extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
| sort by TotalBilledSize desc
| project-away TotalBilledSize

螢幕快照顯示特定應用程式如何驅動追踪成本。

執行該應用程式特定的下列查詢，並進一步查看將遙測傳送至 AppTraces 數據表的特定記錄器類別：

AppTraces
| where TimeGenerated > ago(7d)
| where _IsBillable == true
| where AppRoleName contains 'transformation'
| extend LoggerCategory = Properties['Category']
| summarize TotalBilledSize = sum(_BilledSize) by tostring(LoggerCategory)
| extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
| sort by TotalBilledSize desc
| project-away TotalBilledSize

結果顯示負責成本的兩個主要類別：

顯示將遙測傳送至 AppTraces 資料表的特定記錄器類別的螢幕快照。

案例 2：Application Insight 中的高數據攝取

若要判斷造成成本的因素，請遵循下列步驟：

查詢所有資料表的遙測數據，並取得每個資料表和 SDK 版本的記錄計數：
```
search *
| where TimeGenerated > ago(7d)
| summarize count() by $table, SDKVersion
| sort by count_ desc
```
下列範例顯示 Azure Functions 正在產生大量追蹤和錯誤遙測：

執行下列查詢，以取得產生比其他應用程式更多的追蹤的特定應用程式：

AppTraces
| where TimeGenerated > ago(7d)
| where SDKVersion == 'azurefunctions: 4.34.2.22820'
| summarize count() by AppRoleName
| sort by count_ desc

顯示哪個應用程式產生最多追蹤的螢幕快照。

精簡查詢以包含該特定應用程式，併為每個個別訊息產生記錄計數：

AppTraces
| where TimeGenerated > ago(7d)
| where SDKVersion == 'azurefunctions: 4.34.2.22820'
| where AppRoleName contains 'inbound'
| summarize count() by Message
| sort by count_ desc

結果會顯示特定訊息增加擷取成本：

顯示每個訊息記錄計數的螢幕快照。

案例 3：意外達到每日上限

假設您在 9 月 4 日意外達到每日上限。使用下列查詢來取得自定義事件的計數，並識別與每個事件相關聯的最新時間戳：

customEvents
| where timestamp between(datetime(8/25/2024) .. 15d)
| summarize count(), min(timestamp) by name

這項分析表明，某些事件開始於9月4日被內嵌，隨後很快變得嘈雜。

降低數據擷取成本

識別 Azure 監視器數據表中負責非預期數據擷取的因素之後，請根據您的案例使用下列方法來減少數據擷取成本。

方法 1：更新每日上限設定

調整每日上限以防止過度接收遙測資料。

方法 2：切換表佈局方案

切換至 Application Insights 的另一個支持數據表計劃。資料擷取的計費取決於資料表方案和 Log Analytics 工作區的區域。請參閱表格計劃和支援 Azure 監視器記錄中基本表格計劃的資料表。

方法 3：針對 Java 代理程式使用遙測 SDK 功能

默認建議的解決方案是使用採樣覆寫。 Application Insights Java 代理程式提供兩種類型的取樣。常見的使用案例是抑制收集健康檢查的遙測數據。

針對取樣覆蓋，有一些補充方法：

降低traces表的成本。
- 減少遙測記錄層級。
- 移除具有 MDC 屬性和取樣覆寫的應用程式日誌（不包括框架/庫）。
- 藉由更新 applicationinsights.json 檔案來停用日誌工具：
```
{
  "instrumentation": {
    "logging": {
      "enabled": false
    }
  }
}
```
降低dependencies表的成本。
- 隱藏收集產生相依性遙測之 Java 方法的遙測。
- 停用產生相依性遙測數據的工具。
  
  如果相依關係是資料庫呼叫，您就不會在應用程式地圖上看到資料庫。如果您移除 HTTP 呼叫或訊息的相依性檢測（例如 Kafka 訊息），則會卸除所有下游遙測數據。
降低customMetrics表的成本。
- 增加計量間隔。
- 排除具有遙測處理器的計量。
- 增加心跳間隔。
降低 OpenTelemetry 屬性的成本：

OpenTelemetry 屬性會新增至 customDimensions 數據行。它們會以 Application Insights 中的屬性表示。您可以使用屬性遙測處理器來移除屬性。如需詳細資訊，請參閱遙測處理器範例 - 刪除。

方法 4：更新應用程式程式代碼（記錄層級或例外狀況）

在某些情況下，直接更新應用程式代碼可能有助於減少 Application Insights 後端服務產生及取用的遙測數據。常見的範例可能是應用程式所呈現的嘈雜例外狀況。

參考資料

協力廠商連絡資訊免責聲明

Microsoft 提供協力廠商連絡資訊，以協助您尋找有關此主題的其他資訊。此連絡資訊可能會變更而不另行通知。 Microsoft 不保證協力廠商連絡資訊的準確性。

與我們連絡，以取得說明

如果您有疑問，可以詢問 Azure 社群支援。您也可以向 Azure 意見反應社群提交產品意見反應。

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-11-14