Mai 2017

Band 32, Nummer 5

Dieser Artikel wurde maschinell übersetzt

DevOps: Optimieren von Telemetrie mit Application Insights

Durch Victor Mushkatin | Mai 2017

Die Bedeutung von Ihrem Überwachungsdienst ist klar. In diesem Artikel konzentrieren wir uns auf die grundlegenden Techniken, mit denen die Überwachung Investitionen verwaltbar zu machen. Im Rahmen dieser Diskussion bedeutet, dass alle Telemetriedaten Sammeln von Informationen zu Ihrem Dienst, während brauchbare Ressourcen übermäßig viel nutzen nicht "verwaltet".

Wenn alles reibungslos funktioniert, wichtig nicht zu Terabyte an Daten gesammelt, die für die dienstausführung unbedingt. Wichtig ist nur über die allgemeinen Trends. Wenn der Dienst ausfällt oder nicht korrekt funktioniert, benötigen Sie jedoch alles – sowie einige – um die Probleme zu diagnostizieren. Wie halten Sie das Gleichgewicht zwischen den Daten, die ist erforderlich, um das Problem zu erkennen und jederzeit aus den Daten gesammelt zu werden, das ist erforderlich, um das Problem zu beheben und muss, auch erfasst werden, wenn sie gesammelt werden muss?

Um die Techniken zu veranschaulichen, verwenden wir den Microsoft Azure Application Insights-Dienst und dem stark erweiterbar SDK-Modell. Während wir behandeln Konzepte universell anwendbar sind, ist unser Ziel, Sie mit Application Insights-SDK-Out-of-the-Box-Funktionen und Erweiterungspunkte, mit denen Sie die verwaltbar zu machen, Ihre "Telemetrie-ausrechnen" vertraut. Nach dem Lesen dieses Artikels werden Sie verstehen, die Application Insights-Domänenmodell, wie Telemetriedaten gesammelt werden und welche Codierungstechniken, die Menge der Telemetrie zu verringern, Beibehaltung von Überwachungsfunktionen, analytische Genauigkeit und Diagnose von Tiefe verfügbar sind.

Nicht gebundene Volume von Telemetriedaten

Nehmen Sie einen Dienst, der verarbeitet 1 Milliarde Transaktionen pro Tag in Anspruch. Wenn Sie alle Details zu jeder Transaktion anmelden, Sie werden alle möglichen Fragen beantworten, z. B. Fragen zu Transaktion Latenz 95. Perzentil aus einer bestimmten geografischen Standort oder die Fehlerrate für Benutzer, die einen bestimmten Browser ausgeführt. Zusätzlich zu diesen Metriken überwachen müssen Sie in der Lage, Benutzer zu unterstützen, wenn sie aufrufen, und stellen Sie spezifische Fragen über die fehlgeschlagene Transaktion durch einen Blick in die Protokolle. Je mehr Daten Sie sammeln, die breitere Palette an Fragen können Sie durch die Analyse der Anwendung Telemetriedaten beantworten.

Aber kommt es zu einem Preis. Selbst bei niedrigen Preisen für die Erfassung von Telemetriedaten (bit.ly/2nNhp3c), müssen Sie wirklich 1 Milliarde Datenpunkte sammeln? Oder noch schlimmer ist, wenn jede Transaktion eine SQL-Datenbank aufruft, tatsächlich müssen Sie einen zusätzlichen 1 Milliarde Datenpunkte für alle SQL-Datenbank-Aufrufe sammeln? Wenn Sie von allen möglichen Telemetriedaten, die möglicherweise erforderlich hinzufügen, um zu überwachen, Problembehandlung und Analyse der dienstausführung, der Infrastruktur zur Unterstützung von ziemlich teuer sein, werden möglicherweise ROI der Überwachung erheblich beeinträchtigen.

Benutzer verwenden in der Regel für die Überwachung, verschiedene Service Key Performance Indicators (KPIs) – z. B. laden, transaktionslatenzzeit und Fehlerrate-Dienst. Um diese KPIs verfügbar zu machen, muss das Überwachungssystem Kenntnisse über die Telemetrie-Datenstruktur. Sie sollten möglicherweise unterscheiden, Ereignisse, die Ausführung der Transaktion von darstellen, z. B., Ereignisse, die SQL-Aufrufe darstellen. Mit dem definierten können semantische Telemetrie, Sie effizient die ungebundene Volume Telemetrie in eine verwaltbare Anzahl von KPIs konvertieren, die günstig zu sammeln und zu speichern und genügend Daten zur Beantwortung Ihrer Fragen Überwachung sein werden.

Application Insights SDK bietet das Modell, das den Application Insights-Dienst wirksam und intuitive Benutzeroberfläche zur Unterstützung der Überwachung Anforderungen zur Problembehandlung und Analyse ermöglicht, siehe Abbildung 1.

Abbildung 1 Anwendung Telemetrie-Datenmodell

Konzentrieren wir uns auf zwei Anwendungsmodelle im Rahmen dieser Überprüfung-Anwendung mit einem Endpunkt, die externe Anforderungen, die typisch für ASP.NET-Webanwendungen und Anwendungen, die in regelmäßigen Abständen "zum Verarbeiten von Daten an einer beliebigen Stelle gespeichert reaktiviert", die typisch für Webaufträge oder Funktionen zu erhalten. In beiden Fällen nennen eindeutige Ausführung eines Vorgangs wir. Vorgang erfolgreich war oder ein Fehler auftritt, Ausnahme, oder es abhängen, andere Dienste/Speicher ihre Geschäftslogik ausführen. Diese Konzepte darstellen, Application Insights-SDK definiert drei Arten von Telemetriedaten: Anforderung, Ausnahme und Abhängigkeit. Bei jeder dieser Typen definiert Telemetrie-Datenmodell Felder verwendet, um allgemeine KPIs: Name, Dauer, Statuscode und Korrelation zu erstellen. Außerdem können Sie jeden Typ mit den benutzerdefinierten Eigenschaften zu erweitern. Hier sind einige typische Felder für jede der Ereignistypen:

• Anfordern (Vorgangs-Id, name, URL, Dauer, Statuscode, [...])
• Abhängigkeiten (übergeordnete Vorgangs-Id, Name, Dauer, [...])
• Ausnahme (übergeordnete Vorgangs-Id, die Exception-Klasse, die Aufrufliste [...])

In der Regel werden diese Typen werden durch das Anwendungsframework definiert und sind durch das SDK automatisch erfasst. ASP.NET MVC definiert z. B. das Konzept einer Anforderung Ausführung in der Model-View-Controller-Infrastruktur – sie definiert, wenn Anforderung startet und beendet wird, Aufrufen von Abhängigkeiten in SQL werden definiert, indem System.Data und Aufrufe von HTTP-Endpunkte werden definiert, indem System.Net. Es gibt jedoch Szenarien möglicherweise Telemetrie für Ihre Anwendung verfügbar machen müssen. Beispielsweise Diagnoseprotokolle mithilfe einer vertrauten-auf-Sie instrumentationsframework, z. B. Log4Net oder System.Diagnostics, implementieren möchten oder Interaktion des Benutzers mit dem Dienst zum Analysieren von Verwendungsmustern erfassen möchten. Application Insights erkennt drei zusätzliche Datentypen zur Unterstützung bei erforderlich – Trace, Ereignis- und:

• Trace (Vorgangs-Id, Nachricht, Schweregrad, [...])
• Metriken (Vorgangs-Id, Name, Wert, [...])
• Ereignis (Vorgangs-Id, Name, Benutzer-Id, [...])

Neben der Datensammlung wird Application Insights automatisch alle Telemetriedaten für den Vorgang entsprechen, der er gehört. Z. B. wenn bei der Verarbeitung einer Anforderung Anwendung Sie einige SQL-Datenbank-Aufrufe, die Webdienste aufrufen und die erfassten Diagnoseinformationen vornehmen, wird alles automatisch mit der Anforderung korreliert werden eine eindeutige automatisch generierten Vorgangs-Id in die entsprechenden Telemetriedaten Nutzlast platziert.

Das Application Insights-SDK ist ein mehrstufiges Modell, in dem die zuvor genannten telemetrietypen, Erweiterungspunkte und Data Verringerung der Algorithmen im Application Insights-API-NuGet-Paket definiert sind (bit.ly/2n48klm). Um den Fokus Diskussion über die Kernprinzipien wir dieses SDK verwenden, um die Anzahl der spezifische Daten Auflistung Konzepte so weit wie möglich zu reduzieren.

Zustandsräume

Stehen vier Zustandsräume Daten in Application Insights SDK zur Verfügung. Als Entwickler können Sie mit einem integrierten Erweiterbarkeits-API verwenden. Die Verwendung dieser APIs weiter unten in diesem Artikel veranschaulicht.

Metriken extrahieren und Aggregation ist eine Technik, mit der Sie die Daten lokal zu reduzieren, indem Sie Metriken aus Telemetriedaten aggregieren und nur aggregierte Werte, anstatt die Ereignisse selbst senden kann. Angenommen Sie, Sie haben 100 Anforderungen pro Minute. Ist das einzige, dem was Sie brauchen, die Anzahl der Anforderungen pro Minute, würde dieser Technik können lokal zählt die Anzahl der Anforderungen und senden den Wert einmal pro Minute, anstatt jede Anforderung senden und zur Berechnung von die rohen Telemetriedaten Anzahlen.

Das Sampling ist eine Technik, die selektiv Teilmengen von Telemetriedaten erfasst werden, mit dem Sie die Merkmale des Diensts einschätzen können. Für die meisten Dienste können Sie jede "n-ten"-Anforderung zum Abrufen von gut verteilte statistische Darstellung Dienstverhalten sammeln. Diese Technik einerseits, können Sie die Sammlung von "n" Zeiten zu reduzieren, und andererseits, bewahrt mit bestimmten Genauigkeit statistische Gültigkeit der Metriken Telemetrie dieser Art abgeleitet. Für eine höhere Genauigkeit muss einen hoch entwickelten Algorithmus und das Datenmodell verwendet werden.

Gehalten ist die Fähigkeit, Samplings von Interesse zu sammeln, ohne sampling statistische Genauigkeit für ungültig erklärt. Sie möchten z. B. Anforderungsfehler unabhängig von Samplingkonfiguration immer erfassen. Auf diese Weise während Sie Telemetrie-Auslastung mit Sampling, verringern, können Sie nützliche Problembehandlung Daten beibehalten.

Filtern ist die Möglichkeit, Daten zu reduzieren, indem Sie Telemetrie, die Sie interessieren nicht herausfiltern. Sie möchten z. B. alle Telemetriedaten zu Netzwerkverkehr synthetische Überwachung oder Suche Bots ignorieren. Auf diese Weise werden die Metriken true Benutzerinteraktion mit dem Dienst wiedergegeben.

Application Insights-SDK

Um diese Reduzierung Techniken zu veranschaulichen, ist es wichtig zu verstehen, wie das Application Insights SDK Telemetriedaten verarbeitet. Sie können logisch gruppiert werden in vier Phasen Siehe Abbildung 2.

Abbildung 2 Verarbeitung von Application Insights-SDK Telemetriedaten

Datensammlung wird als eine Reihe von telemetriemodule verantwortlich sind für bestimmte Gruppen von Daten implementiert. Es ist z. B. ein Telemetrie-Modul Abhängigkeit, Ausnahmen und Leistungsindikatoren usw. zu sammeln.

Während der Telemetrie Anreicherung wird jedes Element mit nützlich Telemetrie erweitert. Beispielsweise wird der Application Insights-SDK automatisch den Namen des Servers als eine der Eigenschaften für jedes telemetrieelement hinzu. Es gibt mehrere vordefinierte telemetrieinitialisierer. Entwickler können jedoch eine beliebige Anzahl von zusätzlichen Initialisierer Eigenschaften enthalten, die bei der Überwachung, Fehlerbehebung und Analysen hinzufügen. Beispielsweise kann für geografisch verteilte Dienste hinzuzufügenden Geolocation zum Analysieren der Datenverkehr von jedem Datencenter separat verarbeitet. Während dieses Schritts erhöhen Sie im Wesentlichen die Nutzlast der telemetrieelemente.

Die Telemetriedaten Verarbeitungspipeline ist der Ort, in dem Sie die Logik zum Verringern der Menge an Telemetriedaten an den Dienst gesendeten definieren. Application Insights SDK bietet Sampling Telemetriedaten Prozessoren, um die gesammelten Telemetriedaten automatisch reduziert, ohne Beeinträchtigung der statistischen Genauigkeit.

Telemetrie Transmissionis im letzten Schritt der Telemetrie-Verarbeitung, in dem alle Telemetriedaten, die von einer Anwendung verarbeitet wird in der Warteschlange, in einem Batch verarbeitet, ZIP und in regelmäßigen Abständen an ein oder mehrere Ziele gesendet. Application Insights SDK unterstützt die Übertragung an den Application Insights-Dienst und andere Kanäle, wie Event Hub im Paket.

In diesem Artikel konzentrieren wir Verfahren zum Konfigurieren von Out-of-the-Box-Sampling und zusätzliche Telemetrie-Prozessoren, Optimieren Sie die Datensammlung auf die Anforderungen an die Entwickler zur Verfügung. Alle Beispiele in diesem Artikel erstellen Sie die Konfiguration die Überwachung im Code von Grund auf neu. Jedoch werden in vielen produktionsumgebungen, die meisten erwähnten Parameter als Konfigurationseinstellungen verfügbar gemacht, die ohne die Neukompilierung der Anwendung optimiert werden können.

Aggregation von Metriken

Vor dem fortfahren, möchten wir Telemetriedaten Typ Konzepte erläutert. Im Allgemeinen können Sie alle Telemetriedaten in zwei Buckets Teilen – Metriken und Ereignisse.

Eine Metrik ist definiert als ein Zeitreihen-Daten, die in angegebenen Intervallen vorab aggregiert. Angenommen Sie, dass die Anzahl der Aufrufe der Funktion ermittelt werden soll. Dies ist eine einfache Metrik, die jedes Mal erhöht wird beim Aufruf von Funktion erfolgt. Ruft der Wert der Metriken selbst über einen Zeitraum aggregiert – z. B. eine Minute, und am Ende dieser Zeit gesendet wird.

Ein Ereignis ist ein einzelner Datensatz ein Vorfall, der an jedes Mal gesendet werden. In vielen Fällen sind Ereignisse ganz spezifische Struktur oder Typ. Im Beispiel von Application Insights verfügt die Domäne Modell Ereignis eines Typs Anforderung über andere Eigenschaften als Ereignis eine Ausnahme des Typs. Wechseln zur vorherigen Beispiel für den Fall, dass Sie jede funktionsausführung aufzeichnen möchten, können Sie senden Ereignis mit Funktionsnamen und die Parameter für jedes Mal, wenn er ausgeführt wird. Diese Ereignisse können Sie alle möglichen Fragen zur Ausführung zu beantworten. Mit Rohdaten Telemetrie, können Sie z. B. wie viele Male berechnen dieser Funktion mit einem bestimmten Parameterwert aufgerufen wurde. Beachten Sie, dass genauer Daten wiedergibt, zusätzlich zur einfachen Analyse, z. B. die Anzahl der Ausführung der Funktion jetzt die Anzahl der Ausführung, gruppiert nach Funktionsparameter analysieren können. 

Unformatierten Telemetriedaten ist viel umfangreicher und ermöglicht eine bessere Einblicke, aber es gibt einen Nachteil im Zusammenhang mit der Verarbeitung und Speicherkosten zugeordnet sind. Eine Möglichkeit zur Behebung des Problems werden beliebig viele Metriken für erstellen vorab als Sie denken, dass Sie zum Analysieren der Anwendung benötigen. Das Problem bei diesem Ansatz ist, dass Ihr Unternehmen weitaus dynamischeren ist und es nicht immer möglich ist, welche Metriken wissen Sie möglicherweise im Voraus müssen. Application Insights SDK löst dieses Problem durch einen Ausgleich zwischen aggregierten und unformatierten Telemetriedaten bereitstellen, wird die grundlegende Leistungsindikatoren aggregiert und sendet geprüften unformatierten anwendungstelemetrie. Dieser Ansatz Sampling-können das SDK minimiert den Aufwand für Rohdaten-Auflistung und erhöht die Rendite der gesammelten Daten.

Sampling

Es gibt zwei Prozessoren des Out-of-the-Box-Sampling-Telemetrie von Application Insights-SDK bereitgestellt – feste Sampling und adaptive Sampling (bit.ly/2mNiDHS).

Sampling-Rate reduziert die Menge der pro Knoten Telemetrie. Sie möchten z. B. nur 20 Prozent aller Telemetriedaten aus den einzelnen Knoten zu sammeln.

Adaptive Samplingautomatically passt die Menge der pro Knoten Telemetrie. Sie möchten z. B. Auflistung zu verringern, wenn die Auslastung größer als 5 Eps-Knoten ist.

Hinweis: Es einer auch Erfassung sampling, verwirft Telemetrie-Endpunkt der Erfassung von Ihrer app erreicht. Wir haben nicht vor, um dieses Verfahren in diesem Artikel behandelt, aber Dokumentation finden Sie unter bit.ly/2mNiDHS.

Beide Sampling Telemetrie-Prozessoren verwenden einen gemeinsamen Algorithmus, mit dem Sie das Mischen und kombinieren diese Prozessoren ohne statistische Genauigkeit der Daten. Um zu entscheiden, verfügt der telemetrieelement oder als Stichprobe verwendet werden, wird das SDK verwendet eine statusfreie Hashfunktion und vergleicht-Wert mit Konfiguration Verhältnis zurückgegeben. Es bedeutet, dass unabhängig davon, welcher Thread, Prozess oder Server die Daten verarbeitet, Telemetriedaten mit einem Hashwert unterschreitet konsistent geprüft werden wird. In vereinfachter Form können Sie diesen Algorithmus wie folgt festzuschreiben:

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

Wie Sie hier sehen, solange der Benutzer-ID oder OperationID von alle verknüpften Telemetriedaten Elemente gemeinsam verwendet wird, müssen alle die gleiche Hashwert und konsistent gemessen werden, oder. Application Insights standardmäßig aktiviert das adaptive Sampling beim Sammeln von Daten. Alle Telemetriedaten in den Diensten gespeicherten verfügt über eine Spalte namens ItemCount. Es stellt die Stichprobennahme zum Zeitpunkt der Datensammlung dar. Da die Berechnung Hashalgorithmus zustandslos ist, diese Zahl nicht der tatsächlichen Anzahl der geprüften, Telemetriedaten wird angewiesen, nur das statistische Verhältnis von Telemetriedaten Stichprobe. Um schnell zu analysieren, wenn Ihre Telemetriedaten geprüft wurde, können Sie zum Vergleichen der Anzahl von Datensätzen mit der Anzahl der Datensätze, die vom Dienst verarbeitet die folgende analytische Abfrage ausführen:

requests | summarize sum(itemCount),
     count()

Wenn Sie den Unterschied zwischen diese beiden Zahlen sehen, klicken Sie dann Sampling aktiviert wurde, und die Datenmenge reduziert wurde.

Reduzierung der Datenmenge in Aktion

Betrachten Sie jedes dieser Verfahren. Wir werden eine mit der um wichtigsten Konzepte zu markieren. Die Anwendung Pings bing.com in einer Schleife und speichert Daten in Application Insights. Es behandelt jede schleifenausführung einer Anforderung Telemetriedaten automatisch Abhängigkeitsdaten erfasst und korreliert alle Telemetriedaten an die entsprechende "Anforderung" zu der er gehört.

Um Application Insights SDK zu initialisieren, müssen Sie drei einfache Schritte ausführen. Zuerst müssen Sie mit dem Instrumentationsschlüssel Konfiguration initialisieren. Instrumentationsschlüssel ist ein Bezeichner verwendet, um Telemetriedaten mit Application Insights-Ressource verknüpfen und kann im Azure-Portal abgerufen werden, bei deren Erstellung:

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

Als Nächstes müssen Sie das Modul Abhängigkeit verfolgen, um Abhängigkeitsinformationen automatisch sammeln zu initialisieren:

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

Als Letztes müssen Sie Telemetrie-Initialisierung hinzufügen, die alle verknüpften Telemetriedaten allgemeine Korrelations-Id hinzufügt:

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

An diesem Punkt Application Insights SDK vollständig initialisiert ist und Sie können alle APIs über TelemetryClient-Objekt und Code der main-Schleife zugreifen, siehe Abbildung 3.

Abbildung 3 normalen Codeinstrumentation für die Überwachung der Verarbeitung

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++;
  }
}

Wenn Sie diese Anwendung ausführen, sehen Sie den Bildschirm in Abbildung 4 in einem Konsolenfenster.

Abbildung 4-Schleife Telemetriedaten Ausgabe – Anzahl Iterationen und die Dauer jeder Zyklus

Alle Telemetriedaten in der Cloud gesendet und kann mithilfe der Azure-Portal zugegriffen werden. Während der Entwicklung ist es einfacher, Analysieren von Telemetriedaten in Visual Studio. Wenn Sie den Code in Visual Studio-Debugger ausführen, wird also Telemetriedaten sofort in der Registerkarte Application Insights-suchen angezeigt. Es sieht in angezeigten Abbildung 5.

Abbildung 5-Schleife, die Verarbeitung der Ausgabe von Telemetriedaten in Application Insights

Analysieren dieses Protokoll, für jede Anforderung können Sie verfolgen, zu Events und Abhängigkeit Telemetriedaten mit der gleichen Vorgangs-Id anzeigen. An diesem Punkt haben Sie eine Anwendung, die verschiedene Application Insights Telemetriedaten Typen automatisch abhängigkeitsaufrufe erfasst und korreliert diese dann in die entsprechenden Anforderungen sendet. Nun reduzieren wir Telemetriedaten Volume, das mit der Out-of-the-Box-Sampling Telemetriedaten Prozessoren.

Wie bereits erwähnt definiert das Application Insights-SDK die Telemetrie-Verarbeitungspipeline, die verwendet wird, um die an das Portal gesendete Telemetriedaten zu verringern. Alle gesammelten Telemetriedaten in die Pipeline gelangt, und jeder Prozessor Telemetriedaten entscheidet, ob es weitere entlang übergeben. Wie Sie sehen werden, für die Stichprobe mit der Out-einsetzbaren Telemetriedaten Prozessoren konfigurieren ist ebenso einfach wie die Registrierung in der Pipeline und erfordert ein paar Codezeilen. Doch um die Auswirkung dieser Prozessoren zu veranschaulichen, wir etwas ändern Sie die Anwendung und führen Sie eine Hilfsklasse, um das Verhältnis der Reduzierung zu präsentieren.

Erstellen der Telemetrie-Prozessor, der die Größe der Telemetrie-Elemente, die über, siehe hier berechnen müssen Abbildung 6.

Abbildung 6 Telemetrie-Prozessor für die Berechnung der Datenbankgröße Element

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);
    }
  }
}

Sie können nun die Telemetrie-Verarbeitungspipeline zu erstellen. Es besteht aus vier Telemetrie-Prozessoren. Zuerst berechnet die Größe und Anzahl der Telemetrie, die in die Pipeline gesendet. Anschließend verwenden Sie den festen Sampling Telemetriedaten Prozessor nur 10 Prozent der abhängigkeitsaufrufe ausgewählt wird (in diesem Fall zu pingen bing.com). Darüber hinaus müssen Sie adaptive Sampling für alle Arten von Telemetriedaten, mit Ausnahme von Ereignissen aktivieren. Es bedeutet, dass alle Ereignisse erfasst werden. Der letzte Telemetriedaten Prozessor berechnet die Größe und Anzahl der telemetrieelemente, die an den Kanal für die nachfolgende Übertragung an den Dienst gesendet werden, werden Siehe Abbildung 7.

Abbildung 7 erstellen eine Telemetrie Verarbeitung Kette mit Sampling Elemente

// 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();

Abschließend müssen Sie die Konsolenausgabe, die Telemetriedaten werden erfasst und gesendet, und das Verhältnis für die Reduzierung der finden Sie unter etwas ändern:

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

Beim Ausführen der app sehen Sie sich, dass das Verhältnis als drei Mal so hoch sein kann.

Jetzt, wenn Sie Seite Insights Anwendungsanalyse zur, führen Sie die Abfrage, die hier genannten vermutlich die Statistiken in dargestellt Abbildung 8, nachweisen, Sampling gearbeitet. Sie sehen nur wenige Anforderungen, die viele telemetrieelemente darstellt.

Abbildung 8 Artikelanzahl Telemetriedaten in Application Insights und die geschätzte Anzahl der ursprünglich gesammelte Elemente

Gehalten und Filtern

Bisher gesprochen Sampling und haben Sie erfahren, wie einen benutzerdefinierten Telemetrie, die Verarbeitung der Pipeline und einfache Telemetriedaten Prozessor zu erstellen. Mit diesem Wissen können Sie zwei weitere Techniken durchsuchen, Filtern und gehalten. Wir haben einige Beispiele zur Veranschaulichung, was Sie tun können.

Zunächst werfen wir einen Blick auf die gehalten. Angenommen, Ihre Anwendung eine Drittanbieter-Dienst abhängig ist und für die Verarbeitung von Anforderungen eine bestimmten Performance-SLA garantiert. Mit dem vorhandenen Ansatz können Sie Beispiele für abhängigkeitsaufrufe erfassen. Aber was geschieht, wenn Sie alle Beweisen erfassen, wobei nicht kompatibel mit der SLA war? Zu diesem Zweck Demo haben wir einen gehalten Telemetrie-Prozessor, der erfasst alle abhängigkeitsaufrufe, die nicht kompatibel mit 100 ms SLA, siehe erstellt Abbildung 9.

Abbildung 9 markieren Abhängigkeitsaufrufe für Sammlung langsam und schließen Sie sie von Stichproben aus

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);
  }
}

Im Gegensatz zu gehalten, die in der Tat die Menge der gesammelten Telemetriedaten für genauere Daten Fidelity zunimmt, ist die Filterung radikalere wie Telemetrie-Elemente auf dem Boden, legt er somit vollständig unsichtbar für den Dienst. Zur Veranschaulichung, haben wir einen gehalten Telemetrie-Prozessor, der alle abhängigkeitsaufrufe, die schneller als 100 ms gelöscht, siehe erstellt Abbildung 10.

Abbildung 10 schnelle Aufrufe Abhängigkeitstelemetrie filtern

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);
  }
}

Filtern der Telemetriedaten eignet sich zum Verringern der Anzahl der Telemetrie und deren Qualität zu erhöhen. Wenn Sie wissen, dass das Element Telemetriedaten umsetzbare nicht, möchten Sie es in der Analyse finden Sie unter. Verwenden im vorherigen Beispiel des Telemetrie-Prozessors, wird nur abhängigkeitsaufrufe schneller als 100 ms angezeigt. Also, wenn Sie versuchen, die durchschnittliche Dauer der Abhängigkeit Verarbeitung basierend auf Abhängigkeit Datensatz zu berechnen, erhalten Sie falsche Ergebnisse.

Versuchen Sie zur Behebung des Problems lokal Aufruf abhängigkeitstelemetrie usw. Metriken "true" an den Dienst gesendet. Zu diesem Zweck wird jetzt eine neue Metrik API verwenden und ändern Sie die Telemetriedaten Prozessor Metriken vor dem Löschen der Telemetrie verfügbar machen, siehe Abbildung 11.

Abbildung 11 zu filtern, der schnelle Aufrufe Abhängigkeitstelemetrie mit Metriken vor Aggregation

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();
  }
}

Wie Sie sehen, erstellen wir zwei Metriken: "# Abhängigkeiten" und "Abhängigkeiten Dauer (ms)" – mit Dimensionalität einen Typ der Abhängigkeit. In diesem Fall werden alle abhängigkeitsaufrufe mit HTTP-Typ gekennzeichnet. Wenn Sie für die Analyse wechseln, erhalten Sie die Informationen für Ihre benutzerdefinierten Metriken erfasst Siehe Abbildung 12.

Abbildung 12 vorab aggregierte Metrik von Application Insights erfasst

In diesem Beispiel können Sie die Gesamtanzahl der Aufrufe und Dauer an, die Ihre app beim Aufrufen von Abhängigkeiten aufwendet. Name enthält den Namen der Metriken, also Abhängigkeit Dauer (ms); Wert ist die Summe aller HTTP-Aufrufe bing.com; und CustomDimensions enthält eine benutzerdefinierte Dimension Typ mit dem Wert HTTP bezeichnet. Insgesamt 246 Aufrufe der Spur API-Aufruf wurden; Allerdings wurde nur ein einziger Datensatz pro Minute für jede Metrik gespeichert. Effizientere Verarbeitung und Kosten sind starke Fällen app-Telemetrie, die mithilfe der MetricsManager-API verfügbar gemacht. Die Herausforderung bei diesem Ansatz ist, dass Sie alle Metriken und Dimensionen vorab definieren. Wenn es möglich ist, ist es eine empfohlene Vorgehensweise. in einigen Fällen ist es jedoch nicht möglich oder die Kardinalität der Dimension ist zu hoch. In solchen Fällen ist aufgenommenen unformatierten Telemetriedaten den angemessenen Kompromiss zwischen Richtigkeit und Telemetrie Volume.

Zusammenfassung

Steuern das Volume der Telemetrie-Überwachung ist ein wichtiger Aspekt machen gute Kapitalrendite Ihre Überwachung. Über das Sammeln von kostet Sie zu viel; unter Sammeln von ist es nicht daran hindern, sich effizient Erkennung, Eingrenzung und diagnose von Problemen bei der Produktion. Dieser Artikel erläutert Techniken, mit denen Sie verwalten den Daten Auflistung Platzbedarf mit Application Insights SDK und das Erweiterbarkeitsmodell. Mit Data Verringerung Techniken an, wie z. B. Sampling, Filterung, Aggregation von Metriken und gehalten, zeigte es wie die Datenmenge erheblich verringern, Beibehaltung Überwachung Genauigkeit und Richtigkeit des analytischen sowie Diagnose Tiefe.

Der Application Insights-Ansatz ist übernommene durch viele neue Microsoft-Dienste und Frameworks, z. B. Azure-Funktionen und Service Fabric (diese Unterstützung wird auf der Konferenz Microsoft Build 2017 vorgestellt) und Community anhand von OSS-Beitrag auf GitHub (bit.ly/2n1GFzF). Zusätzlich zu .NET Framework sind andere SDKs verfügbar, einschließlich JavaScript, Java und Node.js (Node.js Application Insights-SDK-Verbesserungen wie bessere Telemetrie-Erfassung und Korrelation sowie einfacher Aktivierung in Azure, wird auf der Build 2017 vorgestellt). Durch eine konsistente, erweiterbar und plattformübergreifende Datensammlung SDK können Sie steuern und "verwalten" der Telemetriedaten über Ihre heterogene anwendungsumgebung.

Victor Mushkatinist Group Programmmanager im Application Insights-Team. Seine main Fachgebiet ist Application Performance monitoring Technologien und DevOps-Methoden. Sie erreichen ihn unter victormu@microsoft.com.

Sergey Kanzhelevist ein leitender Software-Entwickler im Application Insights-Team. Seine Karriere wurde vollständig Überwachung und Diagnose zugeordnet wurde. Er ist zum Herstellen einer Verbindung mit dem Kunden als auch ein engagierter Autor und GitHub Contributor. Sie erreichen ihn unter sergkanz@microsoft.com.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Mario Hewardt, Vance Morrison und Mark Simms
Mario Hewardt ist ein Prinzipal Field Engineer im Microsoft und Autor von erweiterten Windows Debugging und erweiterte .NET Debuggen. Mit 17 Jahren bei Microsoft arbeitete er mit der Entwicklung von Windows, die von Windows 98 bis Windows Vista ab. Mit der Einführung von Cloud computing hat Mario war in der SaaS-Spielbereich und Asset Inventory Service sowie führende von einem Team von Entwicklern, die Erstellung der Plattform für die nächste Generation Microsoft online-Verwaltungsdienst – Windows Intune bereitgestellt. Mario auch arbeitet eng mit Unternehmenskunden als eine auf dedizierte Developer Premier Field Engineer hilft sicherzustellen, dass unsere Kunden ihre Lösungen auf der Microsoft-Stapel auf die effiziente und zuverlässige Weise erstellen. 

Mark Simms Mitglied des Application Platform Customer Advisory Teams, konzentriert sich Kunden und Partner erstellen in Echtzeit ereignisgesteuerte Programme mit StreamInsight, AppFabric und BizTalk.

Vance Morrison ist die Leistung Architekt für die .NET Runtime bei Microsoft.  Er verbringt seine Zeit, die verschiedene Aspekte der Laufzeit schneller zu machen, oder zum anderen das Vermeiden von Leistungsproblemen, die mit .NET.   Er wurde ein Beteiligten in Entwürfen der Komponenten von .NET Runtime seit seiner Einführung.  Zuvor Er steuerte den Entwurf für die .NET Intermediate Language (IL) und der Entwicklungsleiter für genau wurde in Time-Compiler für die Common Language Runtime.