發行項
05/15/2017

2017 年 5 月

第 32 卷，第 5 期

此文章由机器翻译。

DevOps - 透過 Application Insights 將遙測最佳化

由 Victor Mushkatin | 2017 年 5 月

監視您的服務的重要性是清楚易懂。在本文中，我們將著重在基本的技巧，讓您監視投資更容易管理。此討論中，「管理」表示您收集有關您的服務，可採取動作，而任何遙測，不會消耗的資源量不合理。

當一切順利運作時，您一定不在意 tb 的服務執行所收集的記錄檔資料。您只需要關注的一般趨勢。不過，當服務中斷或執行不良時，您需要的所有項目，另外還有一些 — 來診斷問題。如何讓擁有所需的偵測問題時，用來收集所有的時間，從擁有所需的問題進行疑難排解，以及需要收集，嗯，當它用來收集資料的資料之間的平衡？

為了說明的技巧，我們將使用 Microsoft Azure 應用程式見解服務和其具有高度擴充性 SDK 模型。雖然我們討論的概念很普遍適用，我們的目標是讓您熟悉 Application Insights SDK 的全新的功能和擴充點，讓您可以讓您「遙測耗盡"容易管理。閱讀這篇文章之後, 您可以了解 Application Insights 網域模型、收集遙測資料的方式，以及哪些程式碼撰寫技術可減少的遙測，同時保留監視功能、分析的精確度和診斷的深度。

未繫結的磁碟區的遙測資料

需要處理一天的 1 億筆交易的服務。如果您記錄每個交易相關的所有詳細資料，您將能夠回答各種問題 — 例如，有關交易延遲第 95 個百分位數從特定的地理位置或執行特定瀏覽器的使用者的失敗率的問題。除了這些監視的度量，您可以呼叫並詢問失敗的交易中的特定問題，探討記錄檔時，支援使用者。所收集的詳細資料，您可以藉由分析應用程式遙測來回答的問題較寬的範圍。

但有其所有的價格。即使使用的遙測集合的低價格 (bit.ly/2nNhp3c)，您真的需要收集 1 億個資料點？或者，更糟的是，每一筆交易只需要呼叫至 SQL 資料庫，如果您真的需要收集的所有 SQL 資料庫呼叫其他 1 億個資料點？如果您加入可能需要以監視、疑難排解和分析服務執行的所有可能遙測，您可能會發現的基礎結構來支援它會非常耗時，太大影響的監視的 ROI。

一般而言，針對監視用途，人們使用各種服務關鍵效能指標 (Kpi) — 例如，服務載入、交易延遲和失敗率。以公開這些 Kpi，監視系統必須了解的遙測資料結構。它應該能夠區分事件，以表示交易的執行，讓我們假設代表 SQL 呼叫的事件。具有已定義語意的遙測，您可以有效率地轉換未繫結的磁碟區的遙測資料會收集和儲存與資料不足，無法回答您監視問題的成本低廉的 Kpi 可管理集合。

Application Insights SDK 會提供可讓應用程式見解服務呈現有效且直覺式的 UI，以支援您的監視，疑難排解和分析需求模型中所示**[圖 1**。

[圖 1 應用程式遙測資料模型

我們將著重於兩個應用程式模型，做為此檢閱的一部分，具有端點接收一般常見的 Web 應用程式，並定期「喚醒」來處理資料儲存在某個地方的應用程式、 WebJobs 或函式的典型的外部要求的應用程式。在這兩種情況下，我們將稱為唯一的執行作業。作業成功或失敗透過例外狀況，或可能依賴其他服務/儲存空間來執行其商務邏輯。若要反映這些概念，Application Insights SDK 會定義三個遙測類型︰要求、例外狀況和相依性。針對這些類型的每個遙測資料模型會定義用來建構常見 Kpi – 名稱、持續時間、狀態碼和相互關聯的欄位。它也可讓您擴充的自訂屬性的每個型別。以下是一些一般的欄位，每個事件類型︰

要求 (作業識別碼名稱、 URL、持續時間、狀態碼、 [...])
相依性父作業識別碼、名稱、持續時間（[...]）
例外狀況 (父作業識別碼、例外狀況類別、呼叫堆疊 [...])

一般而言，這些類型的應用程式架構所定義，而且由 SDK 會自動收集。ASP.NET MVC 會概念的定義，例如要求的執行模型-檢視-控制器配管 – it 在定義時要求啟動及停止時，SQL 的相依性呼叫定義所 System.Data，HTTP 端點的呼叫會由 System.Net。不過，有些情況是您可能需要公開您的應用程式唯一的遙測。例如，您可能想要實作診斷記錄功能使用熟悉的-若要為您的檢測架構，例如 Log4Net 或 System.Diagnostics，或您可能想要擷取您的服務，來分析使用模式的使用者互動。Application Insights 會辨識三種額外的資料類型，可協助您進行這種需要 — 追蹤、事件和度量︰

追蹤作業識別碼、訊息、嚴重性（[...]）
作業識別碼、名稱、值（[...]）的度量
作業識別碼、名稱、使用者識別碼（[...]）的事件

資料收集，除了 Application Insights 將會自動相互關聯作業，它是在其中一部分的所有遙測。比方說，如果在處理要求的應用程式進行某些 SQL 資料庫呼叫、 Web 服務呼叫，而且記錄的診斷資訊，它將自動相互關聯與要求藉由自動產生的唯一作業識別碼放入個別的遙測裝載。

Application Insights SDK 具有先前所述的遙測資料類型、擴充性點和資料縮減演算法 Application Insights API NuGet 封裝中定義所在的分層式模型 (bit.ly/2n48klm)。焦點討論的核心原則，我們將使用此 SDK，來減少技術專屬的資料集合概念儘可能。

縮減技術

有四個資料縮減技術在 Application Insights SDK。身為開發人員，您可能會利用使用內建的擴充性 API。我們將示範使用這些 Api 在本文稍後。

度量擷取和彙總是一種技術，可讓您在本機減少從遙測資料彙總的度量，並傳送僅彙的總值，而不是事件本身的資料。假設您有 100 個要求每分鐘。唯一您關心的是每分鐘的要求數目，如果這項技術會讓您在本機計算要求的數目和傳送的值一次一分鐘，而不是傳送每個要求，並計算中的原始遙測的計數。

取樣是遙測的一種技術，選擇性地收集，可讓您評估服務的特性子集。大部分的服務，您可能會收集要取得服務行為，平均分散統計表示每個「 n 」要求。這項技術，一方面，可讓您減少集合"n"倍的磁碟區，並相反地，保留與特定精確度統計驗證這類遙測所衍生的度量。更好的精確度，必須使用複雜的演算法和資料模型。

Exemplification 是不含失效取樣統計的精確度會收集樣本感興趣的能力。例如，您可能要一律收集要求失敗，而不管取樣設定為何。如此一來，雖然減少遙測負載與取樣，您可以保留有用的疑難排解資料。

篩選是降低篩選出您不在意的遙測資料的能力。例如，您可能想要忽略綜合監視或搜尋 bot 所產生的流量與相關的所有遙測。如此一來，您的度量將會反映真正的使用者與服務的互動。

Application Insights SDK

為了示範這些縮減技術，請務必瞭解 Application Insights SDK 如何處理遙測。它可以以邏輯方式分組到四個階段，如所示**[圖 2**。

[圖 2 Application Insights SDK 如何處理遙測

資料收集會實作為一組遙測模組，每個皆負責特定的資料集。比方說，是遙測模組來收集相依性、例外狀況、效能計數器，依此類推。

遙測擴充期間每個項目，來擴充有用的遙測。例如，Application Insights SDK 會自動加入的伺服器名稱做為其中每個遙測項目的屬性。有組預先定義的遙測初始設定式。不過，開發人員可以加入任意數目的其他初始設定式包含可幫助監視、疑難排解和分析程序的屬性。比方說，地理位置分散的服務，您可能想要新增分析流量分開處理每個資料中心的地理位置。基本上，在此步驟中您會增加內容的遙測項目。

遙測處理管線是遙測的您用來定義邏輯減少傳送至服務的位置。Application Insights SDK 會提供自動減少收集的遙測資料，而不會破壞統計精確度的取樣遙測處理器。

遙測 transmissionis 遙測處理，其中應用程式處理的所有遙測資料會排入都佇列，最後一個步驟您批次、壓縮，並定期傳送至一個或多個目的地。Application Insights SDK 支援 Application Insights 服務和其他通道，例如事件中心現成傳輸。

在本文中我們專注於技術供開發人員若要設定的方塊外的取樣和其他遙測處理器微調資料收集服務的需求。這篇文章中的所有範例都建置全新的程式碼中的監視設定。不過，許多實際執行環境中，大部分的所述的參數會公開為可以調整，而不需要重新編譯應用程式的組態設定。

度量的彙總

之前繼續進行，我們要討論遙測類型概念。一般而言，您可以將所有遙測都分割成兩個值區 — 度量和事件。

度量的定義為時間序列資料，在指定的間隔時間內會預先彙總。例如，假設您想要計算的函式引動過程數目。這是一種簡單的度量，取得遞增函式呼叫就會發生一次。本身的度量值取得彙總一段時間 — 比方說，一分鐘，並在結尾的傳送時間。

事件是送出每次出現的單筆記錄。在許多情況下，事件會有非常特定的結構或型別。Application Insights 的範例中，在網域模型的事件類型要求會有不同的屬性類型的例外狀況的事件。回到前一個範例中，如果您想要擷取每個函式執行，您可能會傳送事件以函式名稱和函式參數每次執行時。這些事件可讓您回答各種問題有關的執行函數。例如，與原始事件遙測，您可以計算已使用特定的參數值呼叫此函式的次數。請注意，除了簡單的分析，例如函式執行次數的詳細資料精確度與您可以現在分析函式參數所執行的次數。

雖然原始遙測更豐富，而且可讓您提供較佳的洞察，還有與處理相關的缺點和與之相關聯的儲存體成本。為了解決這種方法之一是建立相當多的計量事先您認為您要分析您的應用程式。此方法的問題是您的企業是更為動態，並不一定能夠知道您需要事先的度量項目。Application Insights SDK 提供彙總和原始遙測之間取得平衡以解決這個問題，則會彙總主要應用程式效能指示器及傳送取樣未經處理的應用程式遙測。此取樣方法可讓原始資料收集的負擔降至最低的 SDK，並增加所收集資料的 ROI。

取樣

有兩個 Application Insights SDK 所提供的方塊外取樣遙測處理器 — 固定取樣和調適性取樣 (bit.ly/2mNiDHS)。

固定速率取樣可減少每個節點的遙測。例如，您可能要從每個節點收集只有 20%的所有遙測資料。

調適性 samplingautomatically 調整磁碟區的每個節點的遙測資料。比方說，您可能要減少集合，當負載大於 5 的 eps 節點。

注意: 有的也擷取取樣該捨棄的遙測，您的應用程式到達服務內嵌端點。我們不打算涵蓋在本文中，這項技術，但在找不到文件bit.ly/2mNiDHS。

這兩個取樣遙測處理器使用常用的演算法，可讓您混用，而且符合這些處理器不會影響統計資料的準確性。若要決定是否遙測項目或縮小取樣，SDK 會使用無狀態的雜湊函式，並比較會傳回值設定比例。這表示，不論哪一個執行緒、處理或伺服器處理資料，遙測低於臨界值的雜湊值將會一致地取樣中。簡化形式中，您可以編寫此演算法就像這樣︰

If exist(UserID): Hash(UserID) = (returns value [0..100])
ElseIf exist(OperationID): Hash(OperationID) (returns value [0..100])
Else: Random [0..100]

您可以看到從這裡開始，只要使用者識別碼或 OperationID 所有關聯的遙測項目之間共用，所有會有相同的雜湊值和一致的方式取樣或縮小。收集資料時，預設的 application Insights 可讓調適性取樣。儲存在服務中的所有遙測都具有名為 itemCount 的資料行。它代表的取樣比率時的資料收集。雜湊計算演算法是無狀態，因為這個數字並不代表實際數目的取樣出遙測，它只會告訴統計遙測中取樣的比率。若要快速地分析如果取樣您的遙測，您可以執行下列分析查詢，以比較服務所處理的記錄數目與儲存的記錄數目︰

requests | summarize sum(itemCount),
     count()

如果您看到這兩個數字之間的差異，則已啟用取樣，而且已降低您的資料集。

減少作用中的資料

讓我們來檢閱所有技巧。我們使用主控台應用程式以反白顯示主要概念。應用程式 ping bing.com 迴圈和存放區的遙測資料，在 Application Insights 中。自動它每次迴圈執行視為要求遙測收集相依性資料並相互關聯它所屬的所有遙測，以適當的「要求」。

若要初始化 Application Insights SDK，您需要執行三個簡單步驟。首先，您必須使用檢測金鑰初始化組態。檢測金鑰是用來將遙測資料與 Application Insights 資源相關聯的識別碼，而且可透過 Azure 入口網站中建立它時︰

// Set Instrumentation Key
var configuration = new TelemetryConfiguration();
configuration.InstrumentationKey = "fb8a0b03-235a-4b52-b491-307e9fd6b209";

接著，您必須初始化相依性追蹤模組會自動收集相依性資訊︰

// Automatically collect dependency calls
var dependencies = new DependencyTrackingTelemetryModule();
dependencies.Initialize(configuration);

最後，您必須加入將常見的相互關聯 id 加入至相關的所有遙測的遙測初始設定式︰

// Automatically correlate all telemetry data with request
configuration.TelemetryInitializers.Add(new                        
  OperationCorrelationTelemetryInitializer());

此時，Application Insights SDK 會完全初始化，而且中所示，您可以存取所有的 Api，透過 TelemetryClient 物件和程式碼主迴圈， [圖 3。

[圖 3 典型程式碼檢測，用於監視迴圈處理

var client = new TelemetryClient(configuration);
var iteration = 0;
var http = new HttpClient();
while (!token.IsCancellationRequested)
{
  using (var operation = client.StartOperation<RequestTelemetry>("Process item"))
  {
    client.TrackEvent("IterationStarted",
      properties: new Dictionary<string, string>(){{"iteration",
      iteration.ToString()}});
    client.TrackTrace($"Iteration {iteration} started", SeverityLevel.Information);
    try
    {
      await http.GetStringAsync("https://bing.com");
    }
    catch (Exception exc)
    {
      // This call will not throw
      client.TrackException(exc);
      operation.Telemetry.Success = false;
    }
    client.StopOperation(operation);
    Console.WriteLine($"Iteration {iteration}. Elapsed time:
      {operation.Telemetry.Duration}");
    iteration++;
  }
}

當您執行此應用程式時，您會看到顯示的畫面**[圖 4**主控台視窗中。

[圖 4 迴圈處理遙測輸出 — 反覆項目數目和每個循環持續時間

所有遙測資料會傳送至雲端，而且可以使用 Azure 入口網站存取。在開發期間，很容易分析 Visual Studio 中的遙測。因此如果您執行程式碼在 Visual Studio 中偵錯工具下，您會看到立即在 Application Insights 搜尋索引標籤中的遙測。它會如下所示**[圖 5**。

[圖 5 迴圈處理在 Application Insights 的遙測輸出

分析每個要求此記錄檔，您可以看到追蹤、事件和相依性遙測，具有相同的作業識別碼。此時，您必須傳送各種 Application Insights 遙測類型、自動收集相依性呼叫並將它們全部加入適當的要求相互關聯的應用程式。現在，讓我們減少使用的方塊外取樣遙測處理器的遙測資料量。

如前所述，Application Insights SDK 會定義用來減少傳送至入口網站的遙測的遙測處理管線。所有收集的遙測進入管線時，而每個遙測處理器決定是否要將它傳遞進一步。如您所見，設定的取樣與方塊外的遙測處理器非常簡單，只要在管線中登錄這些，和需要的幾行程式碼。但是為了示範這些處理器的效果，我們會稍微修改程式，並介紹 helper 類別，可展示減少比率。

我們將建置計算的遙測項目會透過，如所示的大小，將遙測處理器**[圖 6**。

[圖 6 遙測項目大小計算處理器

internal class SizeCalculatorTelemetryProcessor : ITelemetryProcessor
{
  private ITelemetryProcessor next;
  private Action<int> onAddSize;
  public SizeCalculatorTelemetryProcessor(ITelemetryProcessor next,
    Action<int> onAddSize)
  {
    this.next = next;
    this.onAddSize = onAddSize;
  }
  public void Process(ITelemetry item)
  {
    try
    {
      item.Sanitize();
      byte[] content =
        JsonSerializer.Serialize(new List<ITelemetry>() { item }, false);
      int size = content.Length;
      string json = Encoding.Default.GetString(content);
      this.onAddSize(size);
    }
    finally
    {
      this.next.Process(item);
    }
  }
}

現在您已準備好要建置的遙測處理管線。它將包含四個遙測處理器。第一個會計算的大小和計數的遙測資料傳送至管線。然後，您會使用固定的取樣遙測處理器範例只有 10%的相依性呼叫 (在此情況下，偵測到 bing.com)。此外，您會啟用所有遙測資料類型，但事件的調適性取樣。這表示，將會收集所有事件。最後一個遙測處理器將計算的大小和後續傳輸至服務，將會傳送至通道的遙測項目計數，如所示**[圖 7**。

[圖 7 建置與遙測處理鏈結項目取樣

// Initialize state for the telemetry size calculation
var collectedItems = 0;
var sentItems = 0;
// Build telemetry processing pipeline
configuration.TelemetryProcessorChainBuilder
  // This telemetry processor will be executed
  // first for all telemetry items to calculate the size and # of items
  .Use((next) => { return new SizeCalculatorTelemetryProcessor(next,
    size => Interlocked.Add(ref collectedItems, size)); })
  // This is a standard fixed sampling processor that'll let only 10%
  .Use((next) =>
  {
    return new SamplingTelemetryProcessor(next)
    {
      IncludedTypes = "Dependency",
      SamplingPercentage = 10,
    };
  })
  // This is a standard adaptive sampling telemetry processor
  // that will sample in/out any telemetry item it receives
  .Use((next) =>
  {
    return new AdaptiveSamplingTelemetryProcessor(next)
    {
      ExcludedTypes = "Event", // Exclude custom events from being sampled
      MaxTelemetryItemsPerSecond = 1, // Default: 5 calls/sec
      SamplingPercentageIncreaseTimeout =
        TimeSpan.FromSeconds(1), // Default: 2 min
      SamplingPercentageDecreaseTimeout =
        TimeSpan.FromSeconds(1), // Default: 30 sec
      EvaluationInterval = TimeSpan.FromSeconds(1), // Default: 15 sec
      InitialSamplingPercentage = 25, // Default: 100%
    };
  })
  // This telemetry processor will be executed ONLY when telemetry is sampled in
  .Use((next) => { return new SizeCalculatorTelemetryProcessor(next,
    size => Interlocked.Add(ref sentItems, size)); })
  .Build();

最後，您將稍微修改主控台輸出來收集及傳送遙測和減少的比例，請參閱︰

Console.WriteLine($"Iteration {iteration}. " +
  $"Elapsed time: {operation.Telemetry.Duration}. " +
  $"Collected Telemetry: {collectedItems}. " +
  $"Sent Telemetry: {sentItems}. " +
  $"Ratio: {1.0 * collectedItems / sentItems}");

執行應用程式時，您可以看到比可能高達三倍！

現在，如果您移至 Application Insights 分析頁面，並執行查詢，本文所述，您可能會看到所示 stats [圖 8，證明有效的取樣。您會看到只有少數要求代表許多遙測項目。

Application Insights 和估計的數量原本收集的項目中的遙測項目數目
[圖 8 遙測中的項目數 Application Insights 和估計的最初收集的項目數目

Exemplification 和篩選

到目前為止，我們談取樣，並了解如何建置自訂的遙測處理管線和簡單的遙測處理器。具備這項知識，您可以瀏覽其他兩種技術 — 篩選和 exemplification。我們做了幾個範例，以展示您可以執行。

首先，讓我們看一下 exemplification。讓我們假設您的應用程式依存於協力廠商服務，它可以保證特定的效能 SLA 來處理要求。使用現有的方法，您可以收集相依性呼叫的範例。但是，如果您要收集所有的辨識項，該服務已不符合其 SLA？基於此示範目的，我們建立了收集 100 毫秒 SLA，使得所有相依性呼叫中所示的 exemplification 遙測處理器**[圖 9**。

[圖 9 標示緩慢相依性呼叫集合和豁免取樣

internal class DependencyExampleTelemetryProcessor : ITelemetryProcessor
{
  private ITelemetryProcessor next;
  public DependencyExampleTelemetryProcessor(ITelemetryProcessor next)
  {
    this.next = next;
  }
  public void Process(ITelemetry item)
  {
    // Check telemetry type
    if (item is DependencyTelemetry)
    {
      var r = item as DependencyTelemetry;
      if (r.Duration > TimeSpan.FromMilliseconds(100))
      {
        // If dependency duration > 100 ms then "sample in"
        // this telemetry by setting sampling percentage to 100
        ((ISupportSampling)item).SamplingPercentage = 100;
      }
    }
    // Continue with the next telemetry processor
    this.next.Process(item);
  }
}

不同於 exemplification，而事實上，就會增加所收集的遙測資料，以更精確的資料精確度的磁碟區，篩選是更巨大，因為它會卸除遙測項目在前，讓它們完全看不到服務。基於示範目的，我們建立了會卸除所有的相依性呼叫中所示的較快，100 毫秒，exemplification 遙測處理器圖 10。

[圖 10 篩選的快速的相依性呼叫遙測

internal class DependencyFilteringTelemetryProcessor : ITelemetryProcessor
{
  private readonly ITelemetryProcessor next;
  public DependencyFilteringTelemetryProcessor(ITelemetryProcessor next)
  {
    this.next = next;
  }
  public void Process(ITelemetry item)
  {
    // Check telemetry type
    if (item is DependencyTelemetry)
    {
      var d = item as DependencyTelemetry;
      if (d.Duration < TimeSpan.FromMilliseconds(100))
      {
        // If dependency duration > 100 ms then stop telemetry
        // processing and return from the pipeline
        return;
      }
    }
    this.next.Process(item);
  }
}

遙測篩選是有效減少遙測並提升其品質。當您知道遙測項目不是可採取動作時，您不想在分析中查看。在上述範例中，使用遙測處理器，您只會看到呼叫相依性較 100 毫秒。因此如果您嘗試計算相依性處理程序根據相依性記錄的平均持續時間，會收到不正確的結果。

讓我們試著解決此問題可以在本機彙總相依性呼叫遙測，並傳送至服務的"true"的度量。若要這樣做，我們將使用新的度量 API 而修改遙測處理器中所示，然後再卸除的遙測，公開度量**[圖 11**。

[圖 11 篩選的快速的相依性呼叫遙測度量預先彙總

internal class DependencyFilteringWithMetricsTelemetryProcessor
                                        : ITelemetryProcessor, IDisposable
{
  private readonly ITelemetryProcessor next;
  private readonly ConcurrentDictionary<string, Tuple<Metric, Metric>> metrics
    = new ConcurrentDictionary<string, Tuple<Metric, Metric>>();
  private readonly MetricManager manager;
  public DependencyFilteringWithMetricsTelemetryProcessor(
    ITelemetryProcessor next, TelemetryConfiguration configuration)
  {
    this.next = next;
    this.manager = new MetricManager(new TelemetryClient(configuration));
  }
  public void Process(ITelemetry item)
  {
    // Check telemetry type
    if (item is DependencyTelemetry)
    {
      var d = item as DependencyTelemetry;
      // Increment counters
      var metrics = this.metrics.GetOrAdd(d.Type, (type) =>
      {
        var dimensions = new Dictionary<string, string> { { "type", type } };
        var numberOfDependencies =
          this.manager.CreateMetric("# of dependencies", dimensions);
        var dependenciesDuration =
           this.manager.CreateMetric("dependencies duration (ms)", dimensions);
        return new Tuple<Metric, Metric>(
          numberOfDependencies, dependenciesDuration);
      });
      // Increment values of the metrics in memory
      metrics.Item1.Track(1);
      metrics.Item2.Track(d.Duration.TotalMilliseconds);
      if (d.Duration < TimeSpan.FromMilliseconds(100))
      {
        // If dependency duration > 100 ms then stop telemetry
        // processing and return from the pipeline
        return;
      }
    }
    this.next.Process(item);
  }
  public void Dispose()
  {
    this.manager.Dispose();
  }
}

如您所見，我們將建立兩個度量，"# 相依性」和「相依性持續時間（毫秒）」 — 與相依性類型的維度。在本例中，所有的相依性呼叫被標記的 HTTP 型別。前往分析時，您是否可以針對您自訂的度量收集的資訊中所示圖 12。

[圖 12 Application Insights 收集之預先彙總的度量

此範例可讓您計算總時數的呼叫，您的應用程式在哪方面耗費同時相依性呼叫持續時間。名稱包含名稱的度量，也就是相依性持續時間（毫秒）。值是所有 http 呼叫的總和 bing.com; 和 customDimensions 包含自訂維度稱為值 HTTP 型別。一共有的 246 呼叫追蹤 API 呼叫。不過，只有一筆記錄會儲存每分鐘每個度量。處理效率與成本是強式的情況下公開使用 MetricsManager API 的應用程式遙測。使用此方法時所面臨的挑戰是，您必須定義所有度量和事先維度。是可行的時，建議的方式。不過，在某些情況下，它不是不可能或維度的基數是太高。在這種情況下，依賴取樣的原始遙測是合理的折衷精確度與遙測磁碟區。

總結

控制監視遙測的磁碟區是讓您監視的投資報酬率很好的重要層面。透過收集要花費太多。在收集會防止您能夠有效地偵測、分級和診斷生產環境問題。這篇文章討論的技術，協助您管理使用 Application Insights SDK 和其擴充性模型的資料收集使用量。使用資料縮減技術，例如取樣、篩選、度量的彙總，以及 exemplification，它已示範了如何大幅降低的資料量，同時保留正確性監視、分析的正確性和診斷深度。

Application Insights 方法採用許多新的 Microsoft 服務和架構，例如 Azure 函式和服務網狀架構（這項支援將在今年的 Microsoft 建置 2017年研討會發表）以及透過在 GitHub 上的 OS 貢獻社群 (bit.ly/2n1GFzF)。除了.NET Framework 中，還有其他 Sdk 供選擇，包括 JavaScript、 Java 和 Node.js （Node.js Application Insights SDK 改善像更好的遙測收集和相互關聯，以及在 Azure 中的更容易啟用，便會發佈在組建 2017年）。透過 SDK 一致、可延伸、跨平台的資料集合，您可以控制和跨異質應用程式環境「管理」您的遙測。

Victor Mushkatin是 Application Insights 小組的群組程式經理。他擅長的領域的主要區域是應用程式效能監視的技術和 DevOps 做法。與他連絡 victormu@microsoft.com。

Sergey Kanzhelev是 Application Insights 小組的主要軟體開發人員。他有完全專用應用程式監視和診斷。他是熱衷於連接與客戶，以及勤部落格作者和 GitHub 的參與者。與他連絡 sergkanz@microsoft.com。

感謝閱本篇文章的下列技術專家︰伊 Hewardt、 Vance Morrison 和 Mark Simms
伊 Hewardt 是 Microsoft 和作者的進階 Windows 偵錯和進階.NET 偵錯的主體欄位工程師。有超過 17 年在 Microsoft，曾與從 Windows 98 到 Windows Vista 的 Windows 開發。雲端運算的問世，伊有參加 SaaS 競技場與傳遞資產清查服務，以及導致一組開發人員建置下一代 Microsoft 線上管理服務-Windows Intune 的核心平台。伊也緊密合作企業客戶做為專用的開發人員工程師協助確保我們的客戶建置解決方案 Microsoft 堆疊上以最有效率且可靠的方式。

Mark Simms 是應用程式平台客戶諮詢團隊成員，著重於協助客戶和合作夥伴建置即時事件驅動使用 StreamInsight，AppFabric 和 BizTalk 應用程式。

Vance Morrison 是 Microsoft.NET 執行階段效能架構設計人員。他花時間進行執行階段的各個層面更快或其他教導如何避免使用.NET 的效能陷阱。他參與了.NET 執行階段元件的設計中自創立。之前他負責推動的.NET 中繼語言 (IL) 的設計，且已被開發組長會針對為只有在執行階段的時間編譯器。