项目
05/15/2017

2017 年 5 月

第 32 卷，第 5 期

此文章由机器翻译

DevOps - 使用 Application Insights 优化遥测

通过Victor Mushkatin |5 月于 2017 2017年

要监视您的服务的重要性。在本文中，我们将重点讨论基本技术，从而使您监视投资易于管理。在本讨论中，"可管理性"意味着任何遥测收集有关您的服务，而操作的这不占用非常多的资源。

当一切顺利运行时，不一定关心千吉字节的收集的服务执行日志数据。您只关心最常规的趋势。但是，当该服务出现故障或性能较差，您需要的所有内容 — 以及其他一些 — 以诊断问题。如何保证具有必需的来检测问题并需要收集所有时间的数据中具有必需的以解决该问题并都需要被收集，嗯，当都需要收集的数据之间的平衡？

为了说明技术，我们将使用 Microsoft Azure 应用程序见解服务和其具有高度可扩展性 SDK 模型。虽然我们介绍的概念是普遍适用的我们的目标是让您熟悉 Application Insights SDK 现成可用的功能和扩展点，您可以提高您"遥测耗尽"可管理性。阅读完本文后，您将能够了解 Application Insights 域模型、如何收集遥测数据，以及哪些编码技术都可用于减少的遥测，同时保留监视功能、分析的准确性和诊断的深度。

未绑定的遥测数据的卷

需要处理一天的 1 亿个事务的服务。如果记录了有关每个事务的所有详细信息，您将能够回答各种问题 — 例如，有关从特定地理位置或运行特定浏览器的用户的失败率的事务滞后时间 95%的疑问。除了这些监视的度量值，您将能够支持用户，当它们调用并通过查看入日志的特定问题就其失败的事务。你收集的数据越多，可以通过分析应用程序遥测，回答的问题更广的范围。

但是，所有它附带了一个价格。即使使用较低的价格以遥测收集 (bit.ly/2nNhp3c)，您真正需要收集 1 亿个数据点？或者，更糟糕的是，如果每个事务进行一次调用到 SQL Database，不要真正需要从中收集 SQL 数据库的所有调用 10 亿的其他数据点？如果您添加了可能需监视、故障排除和分析服务执行的所有可能的遥测，可能会发现基础结构以支持它是相当昂贵，显著影响监视的投资回报率。

通常情况下，出于监视目的，人们使用各种服务的关键绩效指标 (Kpi) — 例如，服务负载、事务滞后时间和失败率。要公开这些 Kpi，监视系统必须遥测数据结构的理解。它应该能够区分表示从事务执行的事件，让我们假定，表示 SQL 调用的事件。具有定义语义的遥测数据，您可以有效地将遥测的未绑定的卷转换将较低以收集和存储，并有足够的数据来回答您监视的 Kpi 一管理组。

Application Insights SDK 提供了模型，它使应用程序见解服务来呈现有效、直观的 UI，以支持您的监视，故障排除和分析需要，如中所示图 1。

图 1 应用程序遥测数据模型

我们将重点介绍两个应用程序模型进行此检查的一部分，与终结点接收应用程序典型的 Web 应用程序和定期"唤醒"来处理数据存储在某个位置的应用程序、典型的 web 作业或函数的外部请求。在这两种情况下，我们将调用唯一执行某项操作。操作成功或失败时通过异常或它可能依赖于其他服务/存储来执行其业务逻辑。为了反映这些概念，Application Insights SDK 定义了三种遥测类型︰请求、异常和依赖项。对于这些类型的每个项，遥测数据模型定义用来构造常见 Kpi – 名称、持续时间、状态代码和相关的字段。它还允许您还可以扩展每个类型的自定义属性。下面是一些典型的事件类型的每个字段︰

请求 (操作 id、名称、 URL、持续时间、状态代码、 […])
依赖项（父操作 id、名称、持续时间、 […]）
异常 (父操作 id、异常类、调用堆栈 […])

通常情况下，这些类型由应用程序框架定义，并且会自动收集由 SDK。例如，ASP.NET MVC 的概念定义的请求在其模型-视图-控制器探测 – it 的执行定义当请求将启动并将停止，对 SQL 的依赖项调用由 System.Data 和调用 HTTP 终结点定义的 System.Net。但是，一些情况下您可能需要公开您的应用程序所特有的遥测。例如，您可能想要实现诊断日志记录使用熟悉-到-您检测框架，例如，Log4Net 或 System.Diagnostics，或者您可能想要捕获你的服务以分析的使用模式与用户交互。Application Insights 可以识别三个额外的数据类型来帮助进行这样的需求 — 跟踪、事件和度量值︰

跟踪（操作 id、消息、严重性、 […]）
度量值（操作 id、名称、值、 […]）
事件（操作 id、名称、用户 id、 […]）

数据收集，除了 Application Insights 将自动关联到它的一部分操作的所有遥测数据。例如，如果处理请求应用程序时进行某些 SQL 数据库调用、 Web 服务调用和记录的诊断信息，所有它将可自动与相关请求通过将自动生成的唯一操作 id 放入相应的遥测数据负载。

Application Insights SDK 具有分层的模型，其中的 Application Insights API NuGet 包中定义的前面所述的遥测数据类型、扩展点和数据减少算法 (bit.ly/2n48klm)。到焦点讨论组的核心原则，我们将使用此 SDK 来减少特定于技术的数据集合概念尽可能多地数目。

减少技术

Application Insights SDK 中有以下四种数据减少技术。作为开发人员，您可能会利用它们使用内置的可扩展性 API。我们将演示本文中稍后介绍这些 Api 的用法。

度量值提取和聚合是一种方法，让您可以本地缩减通过遥测数据聚合度量值，并发送聚合的值，而不是这些事件本身的数据。假设您有每分钟的 100 个请求。如果您关心的唯一事情是每分钟的请求数，此方法会让您本地请求数目进行计数，并将值发送一次一分钟，而不是发送每个请求并计算从原始遥测的计数。

采样是遥测的一种方法，有选择地收集，您可以评估该服务的特征子集。对于大多数服务可能会收集每个"n 个"请求要获取的服务行为的均匀分布统计的表示形式。这种技术，一方面，让您可以缩减"n"倍的集合中的卷，并手动，保留与度量值派生自这样的遥测的某些准确性统计信息有效性。为获得更好的准确性，必须使用复杂的算法和数据模型。

示范是能够收集感兴趣的样本不会导致无效采样统计的准确性。例如，您可能想要始终收集而不考虑采样配置的请求失败。这种方式，同时帮助您减少遥测负载的采样，则可以保留故障排除的有用数据。

筛选是减少通过过滤掉不关心的遥测数据的能力。例如，您可能希望忽略所生成的综合监控或搜索 bot 流量与相关的所有遥测数据。这样一来，你的度量值将反映与服务的真正的用户交互。

Application Insights SDK

为了演示这些规约技术，是一定要了解如何 Application Insights SDK 处理遥测。它可在逻辑上分为四个阶段中所示图 2。

Application Insights SDK 如何处理遥测

图 2 Application Insights SDK 如何处理遥测

数据收集实现为一组遥测模块，每个负责特定的数据集。例如，没有一个遥测模块，以收集依赖项、异常、性能计数器，等等。

在遥测收集过程每一项是有用的遥测增加。例如，Application Insights SDK 将自动添加的服务器名称作为遥测的每一项的属性之一。有套预定义的遥测初始值设定项;但是，开发人员可以添加任意数量的其他初始值设定项，以便包括帮助你监控、故障排除和分析的进程的属性。例如，对于地理上分散的服务，您可能想要添加分析流量单独处理的每个数据中心的地理位置。实质上，在此步骤中您增加了遥测项的负载。

遥测处理管道是在其中定义逻辑以减少发送到服务的遥测数据量的位置。Application Insights SDK 提供采样遥测处理器可以自动缩减收集的遥测数据而不会影响统计的准确性。

遥测 transmissionis 遥测处理其中排队应用程序处理的所有遥测数据，最后一步批处理、压缩，并定期发送给一个或多个目标。Application Insights SDK 支持传输到 Application Insights Service 和其他渠道，例如事件中心，在初始状态。

在本文中，我们专注于技术可供开发人员可以配置现成可用采样和其他遥测处理器以优化服务的需求的数据收集。这篇文章中的所有示例都生成在代码中从零开始的监视配置。但是，在许多生产环境中，大多数提到参数公开为可以无需应用程序重新编译细微调整配置设置。

度量值聚合

之前就更进了，我们想要讨论遥测类型概念。通常情况下，可以将所有遥测数据拆分为两个存储桶，度量值和事件。

一个度量值定义为时间系列数据，在指定时间间隔内预先进行聚合。例如，假设您想要调用的函数数目进行计数。这是一个简单的度量值，获取对函数的调用发生时每次递增。在一段时间段获取聚合的度量值本身的值 — 例如，一分钟，并在末尾的时间发送。

事件是发出每次匹配项的单个记录。在许多情况下，事件具有非常特定的结构或类型。在 Application Insights 的示例中，域模型的类型事件的请求具有不同的属性比一种异常的事件。回到前面示例中，您想要捕获执行每个功能的情况下，每次执行时它可能会发送事件和函数名称和函数参数。这些事件能够让您回答各种类型的函数执行有关的问题。例如，与原始事件的遥测，可以计算已使用特定的参数值调用此函数的次数。请注意，除了简单的分析，例如计数函数执行的多个数据保真度您现在即可进行分析的函数参数按分组的执行计数。

当原始遥测丰富得多，并且允许您提供更好的洞察力时，没有与处理相关的一个缺点，也与程序相关联的存储成本。若要解决此问题的一种方法是创建任意多个度量值提前为您认为您将需要分析您的应用程序。此方法的问题是，您的业务是更加动态的它不是总能够知道您可能需要提前哪些度量值。Application Insights SDK 通过提供聚合和原始遥测之间的平衡来解决此问题 — 聚合关键应用程序的性能指标，以及发送采样原始应用程序遥测。此采样方法允许最小化的原始数据收集开销的 SDK，并会增加所收集的数据的投资回报率。

采样

有两个现成可用采样遥测处理器提供的 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]

可以看到从这里，前提是在所有相关的遥测项目之间共享用户 Id 或 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 中运行的代码，您将看到立即在应用程序见解搜索选项卡中的遥测。它将类似于中所示图 5。

循环处理在 Application Insights 的遥测数据输出

图 5 循环处理在 Application Insights 的遥测数据输出

分析日志中的，为每个请求可以看到具有相同的操作 id 的跟踪、事件和依赖项遥测。此时，您具有的应用程序将发送各种 Application Insights 遥测将类型，自动收集依赖项调用并将它们关联起来所有到相应的请求。现在，让我们来减少利用现成可用采样遥测处理器的遥测数据量。

如前面所述，Application Insights SDK 定义用来减少的遥测数据发送到门户的遥测处理管道。所有收集的遥测进入管道和每个遥测处理器会决定是否将其进一步传递。正如您将看到配置的扩展的现成遥测处理器采样非常简单，您在管道中注册这些和需要只需几行代码。但为了演示这些处理器的效果，我们将略有修改程序并引入了一个帮助器类，以展示减小比率。

让我们构建会计算出的遥测项中所示通过将大小遥测处理器图 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%的依赖项调用 (在这种情况下，ping 到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}");

在执行应用程序时可以看到该比率可能会高达三次！

现在，如果您转到应用程序 Insights 分析页上，并执行此处提及的查询，您可能会看到中所示的统计信息图 8，证明该工作的采样。您看到只有少数请求表示遥测项数。

遥测数据中的项数 Application Insights 和估计的最初收集的项目数

图 8 遥测中的项目数 Application Insights 和估计的最初收集的项目数

示范和筛选

到目前为止我们已经讨论过采样，您已了解如何构建自定义遥测处理管道和简单遥测处理器。了解这一点，您可以浏览其他两种方法 — 筛选和示范。我们进行了几个示例来展示能做什么。

首先，让我们看看示范。假设您的应用程序是依赖于第三方服务，它用于处理请求保证一定的性能 SLA。使用现有方法时，您可以收集的依赖项调用的示例。但如果您想要收集所有证据，该服务处于不符合其 SLA？为此演示，我们创建了收集与 100 毫秒的 SLA，不符合的所有依赖项调用中所示的示范遥测处理器图 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);
  }
}

不像示范，这实际上，会增加用于更精确的数据保真度的收集遥测数据的卷，筛选器更彻底它降到遥测项在地板上，使其完全看不到该服务。出于演示目的，我们创建了将删除所有依赖项调用中所示的 100 毫秒，比速度更快的示范遥测处理器图 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。

Application Insights 收集的预聚合度量值

图 12 Application Insights 收集的预聚合度量值

此示例中，可以计算调用和您的应用程序花费而调用的依赖关系的持续时间的总数。名称包含的度量值的名称，即依赖关系持续时间（毫秒）;值是所有的 http 调用的总和bing.com; 并且 customDimensions 包含名为具有值 HTTP 类型的自定义维度。没有总共 246 调用跟踪 API 调用中;但是，只有一条记录存储每分钟每个度量值。处理效率和成本是强的情况下，若要公开使用 MetricsManager API 的应用程序遥测。使用此方法时面临的挑战是，您需要定义的所有度量值和维度预先。当有可能时，这是推荐的方法;但是，在某些情况下，它是不可能或维度的基数是太高。在这种情况下，依赖于抽样原始遥测是准确性和遥测卷之间合理的危害。

总结

控制监视遥测数据的卷是进行良好监视投资回报的一个重要方面。通过收集将花费您太多;在收集下将阻止您能够有效地检测、会审和诊断生产问题。此文章所述技术可帮助您管理使用 Application Insights SDK 和它的扩展性模型的数据集空间。使用数据减少技术，如抽样、筛选、度量值聚合和示范，它已演示了如何在保留监视准确性、分析正确性和诊断深度的同时会显著降低的数据量。

已开始的 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。

衷心感谢以下技术专家对本文的审阅： Mario Hewardt、 Vance Morrison 和 Mark Simms
Mario Hewardt 是 Microsoft 和高级 Windows 调试和高级.NET 调试的作者的主体字段工程师。使用超过 17 年在 Microsoft，他曾与 Windows 从 Windows 98 到 Windows Vista 开始开发。随着云计算的问世，Mario 具有 SaaS 领域中工作，并传递 Asset Inventory Service 以及领先的开发人员能够构建下一代 Microsoft 在线管理服务 – Windows Intune 的核心平台团队。Mario 还密切配合工作，与企业客户作为专用开发人员首席现场工程师帮助确保我们的客户构建在 Microsoft 堆栈上他们的解决方案尽可能最高效、可靠方式。

Mark Simms 属于应用程序平台客户顾问团队，致力于帮助客户和合作伙伴构建实时事件驱动的使用 StreamInsight，AppFabric 和 BizTalk 应用程序。

Vance Morrison 是在 Microsoft.NET 运行时的性能架构师。他不辞辛苦，他的时间更快地使各个方面的运行时或其他讲授如何避免使用.NET 的性能缺陷。他一直所涉及的.NET 运行时组件的设计中从诞生之初。以前他推动.NET 中间语言 (IL) 的设计，已经开发领导的只是在运行时的实时编译器。

通过