Articolo
05/15/2017

Maggio 2017

Volume 32 Numero 5

Il presente articolo è stato tradotto automaticamente.

DevOps - Ottimizza la telemetria con Application Insights

Da Victor Mushkatin | Maggio 2017

L'importanza di monitoraggio del servizio è ovvie. In questo articolo ci concentreremo su tecniche fondamentali per semplificare i vostri investimenti in monitoraggi. Ai fini di questa discussione, "gestibile" significa che qualsiasi telemetria è raccogliere informazioni sul servizio, mentre eseguibili, non utilizza una quantità eccessiva di risorse.

Quando tutto funziona correttamente, non è necessariamente rilevante terabyte di dati di log raccolti per l'esecuzione del servizio. Importante solo le tendenze generali. Tuttavia, quando il servizio si arresta o è scarse, è necessario tutto e molto altro, per diagnosticare i problemi. Come mantenere l'equilibrio tra i dati necessari per rilevare il problema e devono essere raccolti ogni volta, i dati necessari per risolvere il problema e devono essere raccolti, anche quando è necessario raccogliere?

Per illustrare le tecniche, si userà il servizio di Microsoft Azure Application Insights e il relativo modello SDK estendibile. Mentre vengono trattati i concetti sono universalmente applicabili, il nostro obiettivo è acquisire dimestichezza con le funzionalità di Application Insights SDK out-of-the-box e punti di estensibilità che consentono di semplificare la "i dati di telemetria di scarico". Dopo aver letto questo articolo, sarà in grado di comprendere il modello di dominio di Application Insights, come i dati di telemetria vengono raccolti e le tecniche disponibili per ridurre la quantità di dati di telemetria, mantenendo le funzionalità di monitoraggio, analitico accuratezza e la diagnosi di profondità.

Volume non associata di dati di telemetria

Richiedere un servizio che elabora 1 miliardo di transazioni al giorno. Se si accede a tutti i dettagli relativi a ogni transazione, sarà in grado di rispondere a tutti i tipi di domande, ad esempio, domande su percentile 95 ° di latenza delle transazioni da un particolare geolocation o percentuale di errori per gli utenti che eseguono un determinato browser. Oltre a queste metriche di monitoraggio, sarà in grado di supportare gli utenti quando chiamare e porre domande specifiche sulla transazione non riuscita per la ricerca nei registri. I dati di più raccolte, la più ampia gamma di domande è possibile rispondere mediante l'analisi dei dati di telemetria dell'applicazione.

Ma tutto viene fornito con un prezzo. Anche con prezzi contenuti per la raccolta di dati di telemetria (bit.ly/2nNhp3c), è effettivamente necessario raccogliere i punti dati di 1 miliardo? O peggio, se ogni transazione effettua una chiamata al Database SQL, è veramente necessario raccogliere un ulteriori 1 miliardo punti dati per tutte le chiamate di Database SQL? Se si somma tutti i dati di telemetria possibili che potrebbero essere necessarie per monitorare, risolvere i problemi e analizzare l'esecuzione del servizio, si noterà l'infrastruttura per supportare in modo da essere piuttosto costosa, un notevole impatto sul ROI del monitoraggio.

In genere, per il monitoraggio, gli utenti utilizzano vari indicatori di prestazioni chiave di servizio (KPI), ad esempio, servizio carico, la latenza delle transazioni e la percentuale di errore. Per esporre i KPI, il sistema di monitoraggio deve avere una conoscenza della struttura di dati di telemetria. Deve essere in grado di distinguere gli eventi che rappresentano l'esecuzione delle transazioni, ad esempio, gli eventi che rappresentano chiamate SQL. Con l'oggetto definito semantica dei dati di telemetria, in modo efficiente convertire il volume di dati di telemetria non associato in un insieme gestibile di indicatori KPI che sarà economico raccogliere e archiviare e sono disponibili dati sufficienti per rispondere alle domande di monitoraggio.

Application Insights SDK offre il modello che consente al servizio di informazioni dell'applicazione eseguire il rendering dell'interfaccia utente efficaci e intuitive per supportare il monitoraggio, esigenze di analisi e risoluzione dei problemi, come illustrato nella figura 1.

Figura 1 modello di dati di telemetria di applicazione

Ci concentreremo su due modelli di applicazione come parte di tale esame, le applicazioni con un endpoint che ricevono le richieste esterne, tipiche delle applicazioni Web e applicazioni che periodicamente "riattivano" per elaborare i dati archiviati in un punto, tipiche delle funzioni o i processi Web. In entrambi i casi, verrà chiamato esecuzione univoco un'operazione. Operazione ha esito positivo o negativo eccezione o potrebbe dipendere da altri servizi o archiviazione per eseguire la logica di business. Per riflettere questi concetti, Application Insights SDK definisce tre tipi di dati di telemetria: richiesta, eccezioni e delle dipendenze. Per ognuno di questi tipi, il modello di dati di telemetria definisce i campi utilizzati per costruire comuni gli indicatori KPI, nome, durata, codice di stato e la correlazione. È anche possibile estendere ogni tipo con le proprietà personalizzate. Ecco alcuni campi tipico per ognuno dei tipi di evento:

Richiesta (id operazione, assegnare un nome, URL, durata, codice di stato, [...])
Dipendenze (id operazione padre, nome, la durata, [...])
Eccezione (padre id operazione, la classe di eccezione, stack di chiamate [...])

In genere, questi tipi sono definiti dal framework di applicazione e vengono raccolti automaticamente dal SDK. Ad esempio, ASP.NET MVC definisce la nozione di una richiesta di esecuzione il plumbing model-view-controller – IT definisce quando richiesta avvia e viene arrestato, le chiamate di dipendenza di SQL è definiti da System. Data e chiamate all'endpoint HTTP sono definite da System.Net. Tuttavia, vi sono casi in cui è possibile esporre i dati di telemetria alla propria applicazione. Ad esempio, si consiglia di implementare la registrazione diagnostica usando un framework comune-a-si strumentazione, ad esempio Log4Net o System. Diagnostics, oppure è possibile acquisire l'interazione dell'utente con il servizio per analizzare i modelli di utilizzo. Application Insights riconosce tre tipi di dati aggiuntivi per agevolare il caso di necessità, traccia, eventi e metriche:

Traccia (id operazione, messaggio, gravità, [...])
Metriche (id operazione, nome, valore, [...])
Evento (id operazione, nome, id utente, [...])

Oltre alla raccolta dei dati, Application Insights verranno correlare automaticamente tutti i dati di telemetria per l'operazione di cui fa parte. Ad esempio, se durante l'elaborazione di un'applicazione richiesta si apportano alcune chiamate al Database SQL, chiamate di servizi Web e informazioni di diagnostica registrati, tutto viene automaticamente correlato con richiesta inserendo un id operazione univoci generati automaticamente nel payload di dati di telemetria corrispondente.

Application Insights SDK include un modello a più livelli in cui sono definiti i tipi di telemetria indicate in precedenza, i punti di estendibilità e gli algoritmi di riduzione di dati nel pacchetto NuGet di Application Insights API (bit.ly/2n48klm). Discussione lo stato attivo su principi di base, si utilizzerà questo SDK per ridurre il numero di concetti di raccolta dati specifici della tecnologia per quanto possibili.

Tecniche di riduzione

Sono disponibili quattro tecniche di riduzione dei dati in Application Insights SDK. Gli sviluppatori, si potrebbe utilizzarli utilizzando un API di estensibilità incorporata. Verrà illustrata in utilizzo di tali API più avanti in questo articolo.

Aggregazione e l'estrazione di metriche è una tecnica che consente di ridurre localmente i dati di aggregazione delle metriche da dati di telemetria e inviando solo valori aggregati, anziché gli eventi stessi. Si supponga di che avere fino a 100 richieste al minuto. Se l'unica cosa che interessano il numero di richieste al minuto, questa tecnica sarebbe consentono di contare il numero di richieste e inviare il valore di una volta al minuto, anziché l'invio di ogni richiesta e sul calcolo dei conteggi da dati di telemetria non elaborati in locale.

Il campionamento è una tecnica che raccoglie in modo selettivo i subset di dati di telemetria che consente di valutare le caratteristiche del servizio. Per la maggior parte dei servizi è possibile raccogliere ogni richiesta di "n-th" per ottenere ben distribuito rappresentazione statistica del comportamento del servizio. Questa tecnica, da un lato, consente di ridurre il volume della raccolta da volte "n" e d'altra parte, con alcune validità statistica accuratezza delle metriche derivate da tali dati di telemetria. Per una migliore accuratezza, è necessario utilizzare un modello sofisticato algoritmo e i dati.

Chiarezza è la possibilità di raccogliere campioni di interesse senza invalidare il campionamento statistico. Potrebbe ad esempio, si desidera raccogliere sempre richieste non riuscite indipendentemente dalla configurazione di campionamento. In questo modo, mentre è ridurre il carico di dati di telemetria con campionamento, è possibile mantenere i dati utili sulla risoluzione dei problemi.

Il filtro è la possibilità di ridurre i dati filtrando i dati di telemetria che non è rilevante. Potrebbe ad esempio, si desidera ignorare tutti i dati di telemetria relativi al traffico generato dalle sintetica Bot di monitoraggio o la ricerca. In questo modo, le metriche rifletterà l'interazione dell'utente true con il servizio.

Application Insights SDK

Per illustrare le tecniche di riduzione, è importante comprendere la modalità di elaborazione dati di telemetria in Application Insights SDK. È possibile raggruppare logicamente in quattro fasi, come illustrato nella figura 2.

Figura 2 modalità di elaborazione dati di telemetria di Application Insights SDK

Raccolta dei dati viene implementata come un set di moduli di telemetria, ognuno responsabili di specifici set di dati. È ad esempio, un modulo di telemetria per raccogliere delle dipendenze, eccezioni, i contatori delle prestazioni e così via.

Durante l'arricchimento di dati di telemetria, ogni elemento è integrata con i dati di telemetria utile. Ad esempio, Application Insights SDK aggiungerà automaticamente il nome del server come una delle proprietà per ogni elemento di dati di telemetria. Sono disponibili insiemi di inizializzatori di telemetria predefiniti; Tuttavia, gli sviluppatori possono aggiungere qualsiasi numero di inizializzatori aggiuntivi da includere le proprietà che consentono il monitoraggio, risoluzione dei problemi e processi analitici. Ad esempio, per i servizi distribuiti geograficamente, potrebbe essere da aggiungere geolocation per analizzare il traffico elaborato separatamente per ogni Data Center. Essenzialmente, durante questo passaggio si aumenta il payload degli elementi di dati di telemetria.

La pipeline di elaborazione dati di telemetria è il luogo in cui si definisce la logica per ridurre la quantità di dati di telemetria inviati al servizio. Application Insights SDK fornisce processori di telemetria di campionamento per ridurre automaticamente i dati di telemetria raccolti senza compromettere la precisione statistica.

I dati di telemetria transmissionis ultimo passaggio dell'elaborazione dei dati di telemetria in tutti i dati di telemetria elaborati da un'applicazione è in coda, in batch, compressi e inviati periodicamente a uno o più destinazioni. Application Insights SDK supporta la trasmissione al servizio informazioni applicazioni e altri canali, ad esempio Hub eventi predefiniti.

In questo articolo vengono presi in considerazione le tecniche disponibili per lo sviluppatore configurare campionamento out-of-the-box e processori telemetria aggiuntiva per ottimizzare la raccolta dei dati in base alle esigenze del servizio. Tutti gli esempi in questo articolo compila la configurazione del monitoraggio nel codice da zero. In molti ambienti di produzione, tuttavia, la maggior parte dei parametri indicati vengono esposti come impostazioni di configurazione che sono possibile ottimizzare senza la ricompilazione dell'applicazione.

Aggregazione delle metriche

Prima procedere, desideriamo trattati i concetti di tipo di dati di telemetria. In generale, è possibile dividere i dati di telemetria tutti in due bucket, metriche ed eventi.

Una metrica viene definito come dati di serie temporali, pre-aggregati in base agli intervalli specificati. Si supponga, ad esempio, che si desidera contare il numero di chiamate di una funzione. Si tratta di una metrica semplice che viene incrementata ogni volta che si verifica una chiamata alla funzione. Il valore della metrica stesso Ottiene aggregato in un periodo di tempo, ad esempio, un minuto, e alla fine di tale tempo viene inviato.

Un evento è un singolo record di un'occorrenza che viene inviato ogni volta. In molti casi, gli eventi hanno tipo o struttura molto specifico. Nell'esempio di Application Insights, l'evento del modello di dominio di un tipo di richiesta dispone di diverse proprietà di evento di un tipo di eccezione. Tornando all'esempio precedente, nel caso in cui si desidera acquisire ogni esecuzione della funzione, è possibile inviare eventi con il nome di funzione e i parametri di funzione ogni volta che viene eseguito. Questi eventi consentono di rispondere a tutti i tipi di domande sull'esecuzione della funzione. Con i dati di telemetria di eventi non elaborati, ad esempio, è possibile calcolare quante volte questa funzione è stata chiamata con un valore di parametro specifico. Si noti che con maggiore fedeltà dati oltre a semplici analisi, ad esempio numero di esecuzione della funzione, è possibile ora analizzare conteggio di esecuzione raggruppate dal parametro di funzione.

Quando i dati di telemetria non elaborati è molto più ricche e consente di fornire una visione migliore, è disponibile uno svantaggio relativo all'elaborazione e i costi di archiviazione associati. Un modo per risolvere questo problema consiste nel creare tutti i dati statistici fin dall'inizio come si ritiene che è necessario analizzare l'applicazione. Il problema con questo approccio è che l'azienda è molto più dinamica e non è sempre possibile conoscere le metriche che potrebbe essere necessario in anticipo. SDK di Application Insights risolve questo problema fornendo un equilibrio tra i dati di telemetria non elaborati e aggregati, aggrega gli indicatori di prestazioni chiave dell'applicazione e invia campionate telemetria dell'applicazione non elaborati. Questo metodo di campionamento consente di ridurre al minimo l'overhead di raccolta dati non elaborati di SDK e aumenta il ROI dei dati raccolti.

Campionamento

Esistono due processori di telemetria di campionamento di casella forniti da Application Insights SDK, ovvero fisso campionamento adattivo e campionamento (bit.ly/2mNiDHS).

Tasso fisso campionamento consente di ridurre il volume di dati di telemetria per ogni nodo. Potrebbe ad esempio, si desidera raccogliere solo il 20% di tutti i dati di telemetria da ogni nodo.

Samplingautomatically adattiva consente di regolare il volume di dati di telemetria per ogni nodo. È ad esempio ridurre raccolta quando il carico è maggiore di 5 eps/nodo.

Nota: Vi 's, anche l'inserimento di campionamento che elimina i dati di telemetria, che arriva dall'app per l'endpoint di inserimento del servizio. Non ci occuperemo per coprire questa tecnica in questo articolo, ma la documentazione è reperibile in bit.ly/2mNiDHS.

Entrambi i processori telemetria campionamento utilizzano un algoritmo comune che consente di combinare e associare i processori senza influire sulla precisione statistica dei dati. Per stabilire se l'elemento di dati di telemetria deve essere campionato in o out, il SDK utilizza una funzione hash senza stato e confronta restituito valore con un rapporto di configurazione. Ciò significa che indipendentemente dal thread i processi server elabora i dati, i dati di telemetria con un valore hash soglia sarà coerente campionato. Nella forma semplice è possibile codificare questo algoritmo simile al seguente:

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

Come si vede da qui, come ID utente o OperationID è condiviso tra tutti gli elementi di telemetria correlati, tutti avrà lo stesso valore hash e in modo coerente da campionare in o out. Application Insights per impostazione predefinita consente di campionamento adattivo durante la raccolta dei dati. Tutti i dati di telemetria archiviato nei servizi dispone di una colonna denominata itemCount. Al momento della raccolta dei dati rappresenta la frequenza di campionamento. Poiché l'algoritmo di calcolo hash è senza stato, questo numero non rappresenta il numero effettivo dei dati di telemetria campionato out, ma indica solo il rapporto statistico dei dati di telemetria campionato. Per analizzare rapidamente se i dati di telemetria campionati, è possibile eseguire la seguente query analitiche per confrontare il numero di record memorizzati con il numero di record elaborati dal servizio:

requests | summarize sum(itemCount),
     count()

Se la differenza tra questi due numeri, quindi è stato abilitato il campionamento e il set di dati è stata ridotta.

Riduzione dei dati in azione

Esaminare tutte queste tecniche. Si intende utilizzare un'applicazione console per evidenziare i concetti principali. Il ping di applicazione bing.com in un ciclo e archivia i dati di telemetria in Application Insights. Considerati i dati di telemetria una richiesta di ogni esecuzione del ciclo, automaticamente raccoglie dati sulle dipendenze e mette in correlazione tutti i dati di telemetria appropriato "richiesta" a cui appartiene.

Per inizializzare il SDK di Application Insights, è necessario eseguire tre semplici passaggi. In primo luogo, è necessario inizializzare la configurazione con la chiave di strumentazione. Chiave di strumentazione è un identificatore utilizzato per associare i dati di telemetria alla risorsa di Application Insights e può essere ottenuta nel portale di Azure quando viene creata:

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

Successivamente, è necessario inizializzare il modulo di rilevamento delle dipendenze per raccogliere automaticamente informazioni sulle dipendenze:

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

Infine, è necessario aggiungere l'inizializzatore di telemetria che aggiunge un id di correlazione comune per tutti i dati di telemetria correlati:

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

A questo punto, il SDK di Application Insights è completamente inizializzato ed è possibile accedere a tutte le API tramite l'oggetto TelemetryClient e il codice del ciclo principale, come illustrato nella figura 3.

Figura 3 strumentazione codice tipico per il monitoraggio dell'elaborazione di cicli

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

Quando si esegue questa applicazione, si noterà la schermata riprodotta nella figura 4 in una finestra della console.

Figura 4 ciclo di elaborazione dati di telemetria Output, ovvero numero di iterazioni e la durata di ogni ciclo

Tutti i dati di telemetria verranno inviati al cloud e sono accessibili tramite il portale di Azure. Durante lo sviluppo, è più semplice analizzare i dati di telemetria in Visual Studio. Se si esegue il codice in Visual Studio debugger, vi illustrerò i dati di telemetria immediatamente nella scheda Application Insights Cerca. Sarà simile a quello mostrato nella figura 5.

Ciclo di elaborazione di Output di dati di telemetria in Application Insights
Figura 5 ciclo elaborazione di Output di dati di telemetria in Application Insights

L'analisi di questo log per ogni richiesta è possibile visualizzare dati di telemetria di traccia, eventi e delle dipendenze con lo stesso id operazione. A questo punto, si dispone di un'applicazione che invia vari Application Insights i dati di telemetria tipi, automaticamente raccoglie chiamate di dipendenza e li correla tutti per le richieste appropriate. A questo punto, Riduciamo volume di dati di telemetria che utilizzano processori di telemetria campionamento out-of-the-box.

Come descritto in precedenza, Application Insights SDK definisce la pipeline di elaborazione dati di telemetria che viene utilizzata per ridurre la quantità di dati di telemetria inviati al portale. Tutti i dati di telemetria raccolti entra nella pipeline e tutti i processori telemetria decide di passarlo ulteriormente. Come si vedrà, la configurazione di campionamento con i processori di telemetria di fuori della casella basta effettuarne la registrazione nella pipeline e richiede solo un paio di righe di codice. Ma per illustrare l'effetto di questi processori, si sarà leggermente la modifica del programma e introdurre una classe helper per mostrare il rapporto di riduzione.

Verrà ora creato il processore di dati di telemetria che calcolare le dimensioni degli elementi di dati di telemetria verranno tramite, come illustrato nella figura 6.

Figura 6 telemetria processore per il calcolo delle dimensioni elemento

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

Ora si è pronti a creare la pipeline di elaborazione dati di telemetria. Si tratta di quattro processori di telemetria. Il primo calcolare le dimensioni e il numero di dati di telemetria inviati alla pipeline. Quindi, si utilizzerà il processore di dati di telemetria di campionamento predefinito da utilizzare come campione solo il 10% delle chiamate di dipendenza (in questo caso, eseguire il ping per bing.com). Inoltre, si attivano campionamento adattivo per tutti i tipi di dati di telemetria, ad eccezione di eventi. Significa che tutti gli eventi verranno raccolti. Il processore di dati di telemetria ultimo calcolare le dimensioni e il numero degli elementi di dati di telemetria che verrà inviato al canale per la trasmissione successive al servizio, come illustrato nella figura 7.

Figura 7 creando una catena di elaborazione dati di telemetria con elementi di campionamento

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

Infine, che si desidera modificare leggermente l'output per visualizzare i dati di telemetria raccolti e inviati e il rapporto per la riduzione della console:

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

Quando si esegue l'applicazione è possibile osservare che il rapporto può essere a un massimo di tre volte!

A questo punto, se passare alla pagina applicazione approfondimenti Analitica ed eseguire la query sopra indicate, è possibile visualizzare le statistiche nella figura 8, dimostrando il campionamento lavorato. Noterete che rappresenta gli elementi di telemetria molti solo alcune richieste.

Figura 8 numero di elementi di telemetria in Application Insights e numero di elementi raccolti originariamente stimato

Chiarezza e filtro

Finora abbiamo parlato del campionamento e appreso come creare i dati di telemetria personalizzato l'elaborazione della pipeline e i dati di telemetria semplice processore. Con queste informazioni, è possibile esplorare altre due tecniche: applicazione di filtri e chiarezza. Abbiamo apportato un paio di esempi che illustrano operazioni possibili.

In primo luogo, esaminiamo la chiarezza. Si supponga che l'applicazione è dipendente da un servizio di terze parti e garantisce prestazioni un determinato contratto di servizio per l'elaborazione delle richieste. Con l'approccio esistente, è possibile raccogliere gli esempi di chiamate di dipendenza. Ma cosa accade se si desidera raccogliere tutte le prove in cui tale servizio è stato non conforme al relativo contratto di servizio? A questo scopo dimostrativo, abbiamo creato un processore di dati di telemetria chiarezza che raccoglie tutte le chiamate di dipendenza che non sono conformi con 100 ms contratto di servizio, come illustrato nella figura 9.

Figura 9 contrassegno rallentare chiamate di dipendenza per la raccolta e tali esentare dalle campionamento

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

A differenza di chiarezza, aumentando, infatti, il volume dei dati di telemetria raccolti ai fini di conformità dei dati più precisi, il filtro è più radicale, ovvero elimina gli elementi di telemetria sul pavimento, rendendoli completamente invisibile al servizio. A scopo dimostrativo, abbiamo creato un processore di dati di telemetria chiarezza che elimina tutte le chiamate di dipendenza che sono più veloci rispetto a 100 ms, come illustrato nella figura 10.

Figura 10 filtro dei dati di telemetria di chiamate di dipendenza veloce

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

Filtraggio di dati di telemetria è efficace per ridurre la quantità di dati di telemetria e aumentare la qualità. Se si è certi che l'elemento di dati di telemetria non eseguibile, non si desidera visualizzarlo in analitica. Utilizzo del processore di dati di telemetria nell'esempio precedente, è possibile visualizzare solo le chiamate di dipendenza maggiore di 100 ms. Quindi se si tenta di calcolare la durata media di elaborazione delle dipendenze in base a record di dipendenza, si otterranno risultati non corretti.

Proviamo a risolvere questo problema in locale l'aggregazione di dati di telemetria di dipendenza chiamata e inviando metriche "true" per il servizio. A tale scopo, si intende utilizzare una nuova metrica API e modificare il processore di dati di telemetria per esporre le metriche prima di eliminare i dati di telemetria, come illustrato nella figura 11.

Figura 11 filtro dei dati di telemetria chiamate veloce dipendenza con pre-l'aggregazione di metriche

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

Come si può vedere, stiamo creando due metriche, ovvero "# dipendenze" e "durata dipendenze (ms)", ovvero con dimensionalità di un tipo di dipendenza. In questo caso, tutte le chiamate di dipendenza vengono contrassegnate con tipo di HTTP. Se si passa alla Analitica, è possibile visualizzare le informazioni raccolte per le metriche personalizzate, come illustrato nella figura 12.

Metrica Preaggregato raccolto da Application Insights
Figura 12 metrica preaggregati raccolto da Application Insights

In questo esempio consente di calcolare il numero totale di chiamate e la durata che App sta impiegando durante la chiamata alle dipendenze. Nome contiene il nome delle metriche, vale a dire, la durata delle dipendenze (ms); valore è la somma di tutte le chiamate http a bing.com; e customDimensions contiene una dimensione personalizzata denominata tipo con valore HTTP. Durante un totale di 246 chiamate per la chiamata all'API di traccia; Tuttavia, solo un record è stato archiviato al minuto per ogni metrica. L'efficienza di elaborazione e i costi sono casi sicuri per esporre dati di telemetria app tramite l'API MetricsManager. Il problema con questo approccio è che è necessario definire tutte le metriche e dimensioni fin dall'inizio. Quando possibile, è un metodo consigliato; Tuttavia, in alcuni casi, non è possibile o la cardinalità della dimensione è troppo elevata. In questi casi, basarsi su campionati telemetria non elaborati è il ragionevole compromesso tra accuratezza e il volume di dati di telemetria.

Conclusioni

Controllare il volume dei dati di telemetria di monitoraggio è un aspetto importante della creazione di un buon ritorno sugli investimenti del monitoraggi. Tramite la raccolta comporta un costo è troppo elevato; in Raccolta sarà in grado di rilevare, valutare e diagnosticare i problemi di produzione in modo efficace. Questa tecnica articolo discusso che consentirà di gestione il footprint di raccolta dati utilizzando il modello di estendibilità e Application Insights SDK. Utilizzando le tecniche di riduzione di dati, ad esempio il campionamento, il filtro, aggregazione delle metriche e chiarezza, è stato illustrato come una significativa riduzione del volume di dati, mantenendo tuttavia l'accuratezza monitoraggio, correttezza analitica e diagnostica profondità.

L'approccio di Application Insights viene adottata da molti nuovi servizi di Microsoft e i Framework, ad esempio le funzioni di Azure e Service Fabric (questo supporto sarà annunciato nel corso della conferenza Microsoft Build 2017 dell'anno) e una community attraverso il contributo di sistemi operativi su GitHub (bit.ly/2n1GFzF). Oltre a .NET Framework, sono disponibili altri SDK, tra cui JavaScript, Java e Node. js (Node. js Application Insights SDK ai miglioramenti come migliore raccolta di dati di telemetria e correlazione, nonché attivazione più semplice in Azure, saranno annunciati 2017 compilazione). Tramite una raccolta di dati coerenti, estendibile e cross-platform SDK, è possibile assumere il controllo e "gestione" i dati di telemetria nell'intero ambiente applicazioni eterogenee.

Victor Mushkatinè un group program manager del team di Application Insights. Il suo principale area di competenza è tecnologie di monitoraggio delle prestazioni delle applicazioni e procedure DevOps. Contattarlo all'indirizzo victormu@microsoft.com.

Sergey Kanzhelevè uno sviluppatore software principale nel team di Application Insights. La sua carriera è stato interamente dedicato alla diagnostica e monitoraggio dell'applicazione. È passione per la connessione con i clienti, nonché un autore di un blog nel tempo e collaboratori di GitHub. Contattarlo all'indirizzo sergkanz@microsoft.com.

Grazie a seguenti esperti tecnici per la revisione dell'articolo: Mario Hewardt, Vance Morrison e Mark Simms
Mario Hewardt è un Principal Field Engineer in Microsoft e autore di debug avanzate di Windows e avanzate di debug di .NET. Con oltre 17 anni presso Microsoft, ha lavorato con lo sviluppo di Windows a partire da Windows 98 a Windows Vista. Con l'avvento del cloud computing, Mario ha lavorato nell'arena di SaaS e recapitati Asset Inventory Service, nonché iniziali di un team di sviluppatori che creano la piattaforma principale per la successiva generazione online servizio di gestione Microsoft – Windows Intune. Mario ha inoltre collaborato con i clienti aziendali come dedicato per gli sviluppatori Premier Field Engineer in modo da garantire che i clienti creano le soluzioni nello stack di Microsoft nel modo più efficiente e affidabile possibile.

Mark Simms è un membro del Team Advisory cliente piattaforma dell'applicazione, progettate per aiutare i clienti e partner di generare eventi in tempo reale basato su applicazioni che utilizzano StreamInsight, AppFabric e BizTalk.

Vance Morrison è il progettista di prestazioni per il Runtime .NET in Microsoft. Si dedica velocizzando vari aspetti del runtime o insegnare loro come evitare problemi di prestazioni tramite .NET. Ha partecipato un in progettazioni dei componenti del runtime di .NET dall'inizio. In precedenza hanno condotto alla progettazione di .NET Intermediate Language (IL) ed è stato responsabile dello sviluppo per il compilatore ora per il runtime.