Application Insights (again)

Si lo so, qualcuno penser√†: “ancora sto Application Insights? e basta!” e c’ha pure ragione dico io.

Solo che stavolta voglio segnalare un podcast, fatto direttamente da me, perché se a qualcuno serve capire qualcosa anche ascoltando e non leggendo, eccolo qua.

Ad ogni modo in questi giorni non ho scritto molto, ero impegnato con varie cose, tra cui un ennesimo (spero e credo fiduciosamente che sia l’ultimo) cambio di lavoro.

Questo però non cambierà le cose: scrivere e condividere è importante, per cui non bisogna fermarsi mai.

Application Insights (again)

Esportare i dati da Application Insights

Se usiamo Application Insights sicuramente ci può interessare, ad un certo punto, di esportare i dati riguardanti la telemetria, e questo può essere facilmente fatto usando le funzioni di export presenti nei vari blade dove vediamo i nostri dati, un esempio di seguito lo vediamo nel Metrics Explorer:

IMG.png

Questa operazione produce un file Excel (.xsls) con i dati riguardanti la “vista” che abbiamo in quel blade:

IMG

Una delle cose che mi piace di pi√Ļ di Application Insights¬†√® per√≤ la capacit√† di poter esportare i dati in maniera¬†continuativa.

IMPOSTIAMO LA CONTINUOUS EXPORT

All’interno della dashboard della nostra risorsa possiamo trovare la funzionalit√† di “Continuous export”:

IMG

in cui possiamo impostare una modalità di esportazione molto interessante.

Aggiungendo un “profilo di esportazione” (non conosco il nome preciso ma lo chiameremo “profilo” per capirci) possiamo decidere innanzitutto¬†quali¬†tipologie di informazioni esportare:

IMG

E lo storage e il container dove collocare queste esportazioni:

IMG.png

N.B.: sto dando per scontato che¬†chi legge questo post sappia cosa sia uno storage su Azure e come siano organizzati i dati all’interno di questi, magari in un altro post futuro prover√≤ a spiegare meglio il concetto.

CHE TIPO DI OGGETTO¬†OTTENIAMO CON L’ESPORTAZIONE

Quello che otterremo nel nostro container sarà una serie di file .blob:

IMG.png

aprendone uno scopriremo che si tratta “semplicemente” di un file json con le informazioni che riguardano la nostra risorsa Application Insights:

IMG

E’ importante specificare che data e ora indicate¬†all’interno dei json riguardano¬†il fuso orario¬†UTC, e quindi potremmo vedere un’altra data e ora rispetto al nostro fuso orario atteso per quell’evento.

 

CON QUALE FREQUENZA VENGONO ESPORTATI I DATI

L’esportazione avviene, come dice il nome, in maniera continuativa, ovvero ad ogni registrazione riguardante¬†uno dei tipi di dato che vogliamo esportare, tra quelli¬†indicati¬†nel profilo di esportazione.

Quindi ogni volta che avviene una registrazione sulla telemetria, e questa registrazione afferisca ad uno dei tipi riportati sopra, questo viene “esportato” cos√¨ come abbiamo indicato nel nostro profilo di esportazione, o meglio, viene “preparato all’esportazione”.

Infatti √® meglio precisare che non si tratta di¬†un sistema di esportazione in real-time, in quanto¬†il dato nello storage potrebbe essere presente fino ad un’ora dopo l’accadere dell’evento.

Queste tempistiche vengono gestite direttamente dalla piattaforma, che si occupa di eseguire questo processo quando lo ritiene opportuno (probabilmente in funzione delle risorse a disposizione, ma è una mia supposizione, non ho fonti specifiche).

Per gli scopi dell’export, comunque, si tratta di un processo che va benissimo per lo scopo di chi vuole “manipolare” i dati e ottenerne qualcosa in termini di analisi, non √® quindi (lo ripeto) uno strumento per la gestione in real-time dei dati.

QUANTO MI COSTA ESPORTARE

Questa funzionalità purtroppo non è disponibile nel profilo gratuito di Application Insights, per cui bisogna avere un profilo tra quelli a pagamento visibili a questa pagina ma si tratta, a mio avviso, di un costo tutto sommato sostenibile nel caso abbiamo la necessità di usufruire di questa funzionalità.

COME PROCESSARE QUESTI DATI

Una volta ottenuti i dati, cosa me ne faccio?

Con tanti dati a disposizione, bisogna ricorrere a¬†strumenti (e competenze) di analisi dei dati, la cosiddetta Business Intelligence, altrimenti avere molti dati ma averli in forma¬†“grezza” non potranno esserci di grande aiuto.

Sicuramente possiamo ricorrere ad altri strumenti di Microsoft, alcuni dei quali anche disponibili su Azure ma di questo ne parleremo in un altro post…

 

Esportare i dati da Application Insights

Metric Alerts in Application Insights

Torniamo a parlare di Application Insights dopo averne già parlato in diversi post precedenti per affrontare stavolta un aspetto nuovo: la gestione degli alert.

Qualunque strumento¬†che si occupi di monitorare¬†un sistema √® normalmente dotato di sistemi di “allarme” che possono scatenare notifiche al manifestarsi di specifici eventi, e Application Insights¬†non √® da meno in questo senso.

Per gestire le regole di alert,¬†accediamo in¬†Azure, e dalla¬†dashboard della nostra risorsa Application Insights, andiamo¬†nella sezione “Settings and Diagnostics”¬†e l√¨ nel gruppo “Configure”¬†troveremo la voce “Alerts”,¬†come potete vedere nella prossima figura:

IMG

Allo stesso blade possiamo arrivare con un percorso diverso, ovvero dalla nostra risorsa Application Insights scegliamo “Metrics Explorer” e in quel blade usiamo il pulsante “Alerts”:

IMG.png

Nell’immagine¬†potrete notare due “gruppi” di alert, ed in effetti sono due le categorie di alert che √® possibile impostare:

  • Metric Alerts (indicati nella schermata come “components”)
    molto utili per monitorare tempestivamente problemi di funzionamento
  • Web Tests (indicati nella schermata come “webtests”)
    particolarmente indicati per monitorare la disponibilità e le performance

Si tratta in effetti di cose diverse, ma che hanno in comune il concetto di “alert”, ovvero di notifica al verificarsi di una condizione¬†specifica.

Dato che si tratta di funzionalit√† “simili” ma non del tutto uguali, in questo post ci dedicheremo ai Metric Alert, e in un post successivo

Creare un Metric Alert

Tra le varie metriche che desideriamo avere a disposizione, ce ne può essere qualcuna di cui preferiamo avere immediatamente notizia in particolari situazioni.

Facciamo un esempio molto banale: se il ¬†nostro sito carica la pagina principale in pi√Ļ di 5 secondi, questo potrebbe significare¬†un rallentamento delle prestazioni dovuto a diversi fattori, magari un servizio esterno non raggiungibile oppure un problema con il db, ad ogni modo, poniamo il ¬†caso mi interessi monitorare velocemente questo aspetto.

La prima cosa da fare √® (come indicato nella¬†figura che segue) andare nella pagina¬†degli alert, e tramite il pulsante “+ Add” aprire il blade per l’inserimento di un ¬†nuovo alert.

IMG.png

Inserire a questo punto le informazioni principali del nostro alert tra cui ovviamente la risorsa e il tipo di metrica.
Suggerisco di usare sempre “nomi parlanti”, cos√¨ da sapere sempre cosa fa quel determinato alert anche senza indagare nel dettaglio.

IMG.pngScendendo pi√Ļ in basso nel blade si possono¬†inserire le informazioni che indicano proprio la “condizione” che fa scatenare l’alert, nell’esempio che abbiamo fatto nel nostro caso,¬†la nostra condizione √® che il caricamento della pagina principale del sito impieghi pi√Ļ di 5 secondi al caricamento.

Interessante √® il campo¬†che indica il¬†“periodo” che indica l’intervallo di aggregazione dei dati di cui vogliamo tenere conto.

Dato che l’alert¬†consente l’invio ¬†di mail, possiamo impostare la mail di destinazione di un eventuale notifica per la condizione che abbiamo impostato.

A quel punto con il tasto Ok confermiamo l’alert.

Dopo qualche secondo troveremo il nostro alert in lista pronto per mandarci la notifica richiesta in caso di necessità.

 

Comandi del nostro alert

Ora che abbiamo creato il nostro alert, questi è immediatamente operativo.

Spieghiamo cosa vuol dire.¬†Se andiamo nella pagina dei nostri alert, e selezioniamo quello appena creato, andremo in “edit” del nostro alert, come mostrato nella prossima figura:

IMG.png

In questo blade possiamo ovviamente modificare le informazioni / impostazioni del nostro alert ma possiamo anche fare altre azioni aggiuntive tramite una serie di pulsanti:

  • Save, salva la regola quando i suoi¬†valori sono stati¬†modificati
  • Discard, annulla le modifiche apportate e riporta la regola¬†all’ultimo valore
  • Enable, abilita l’alert
  • Disable, disabilita l’alert
  • Delete, elimina l’alert

Quindi possiamo mettere “offline” il nostro alert semplicemente disabilitandolo, e nel periodo in cui lo sar√†, non far√† semplicemente nulla.

Come funziona un alert

Abbiamo capito tutto? Probabilmente non tutto, perch√© seppure si tratti di un aspetto “semplice” ha la sua modalit√† di funzionamento e va spiegata bene per potere essere capita.

Partiamo dal fatto che un alert ha in pratica due soli stati:

  • alert
  • healty

Il periodo di cui abbiamo parlato prima serve per l’aggregazione dei dati.
Lo stato in cui si verrà a trovare un alert dipende dal dato aggregato rispetto al periodo di raggruppamento.

Anche quando lo stato cambia parte una mail di notifica.

Cosa monitorare con un alert

Principalmente conviene monitorare aspetti cruciali del nostro business su cui abbiamo necessità di intervenire rapidamente per ripristinare qualcosa che stia impedendo la continuità e/o produttività del nostro servizio.

Troppe mail porterebbero a mio avviso ad una “assuefazione” con conseguente inutilit√† dell’alert stesso.

Meglio ricevere poche mail, solo nelle situazioni ¬†di concreta¬†“emergenza” piuttosto che cento mail al giorno per¬†informazioni poco critiche.

Metric Alerts in Application Insights

La classe TelemetryClient di Application Insights

Abbiamo gi√† detto¬†come per Application Insights siano disponibili diversi SDK, in particolare √® interessante vedere come sia facile implementare sul fronte ASP.NET del codice che preveda l’interazione con questo servizio di telemetria.

Una volta che abbiamo il nostro progetto con Application Insights integrato¬†(cos√¨ come avevamo visto in questo post e in quest’altro post), e una volta integrato anche il codice JavaScript recuperabile dalla dashboard su¬†Azure, avremo la possibilit√† di tracciare da subito le visite alle pagine,¬†la provenienza delle request ed altre informazioni¬†di questo genere.

Ma abbiamo anche detto, in precedenza, come Application Insights sia utile per comprendere le problematiche applicative e per risolverle. Quindi questo vuol dire andare a rilevare e tracciare le eccezioni e renderle disponibili in una metrica specifica.

Per fare questo (e tanto altro) faremo la conoscenza di una classe utilissima: TelemetryClient, che gi√† nel¬†nome fa comprendere il suo scopo, che √® quello di “comunicare” alla nostra risorsa Application Insights le informazioni da monitorare.

Un esempio semplice

Nel nostro applicativo web, che per comodità sarà un progetto ASP.NET MVC, abbiamo la possibilità di utilizzare la classe MvcApplication (nel file Global.asax.cs) e in particolare il metodo Application_Error per gestire tutti gli errori che non vengono gestiti.
In questo metodo possiamo¬†effettuare un “trace” dell’errore e portarlo fino alla nostra dashboard di telemetria.

using Microsoft.ApplicationInsights;
...
public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Error(Object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError();
        TelemetryClient client = new TelemetryClient();
        client.TrackException(ex);
    }
}

Con queste poche righe abbiamo fatto in modo di rilevare l’errore intervenuto e farlo pervenire a Application Insights tramite una istanza della classe TelemetryClient, che stabilisce una connessione con la nostra risorsa su Azure, identificata dalla Instrumentation Key indicata nel file ApplicationInsights.config che troveremo nel nostro progetto.

Istanziare TelemetryClient con una Instrumentation Key diversa

Se abbiamo ambienti diversi, possiamo utilizzare un costruttore della TelemetryClient che consenta di utilizzare una TelemetryConfiguration contenente una Instrumentation Key specifica.

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;
...
public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Error(Object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError();
        TelemetryConfiguration myConfiguration = new TelemetryConfiguration { InstrumentationKey = "myInstrumentationKey" };
        TelemetryClient client = new TelemetryClient(myConfiguration);
        client.TrackException(ex);
    }
}

Riprendendo come esempio quello che avevamo illustrato¬†in questo post, possiamo anche agire direttamente sulla Instrumentation Key della TelemetryConfiguration “attiva”, cos√¨ il costruttore di base utilizzer√† quella chiave,¬†in questo modo:

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;
using System.Web.Configuration;
...
public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
         TelemetryConfiguration.Active.InstrumentationKey = WebConfigurationManager.AppSettings["ApplicationInsightsInstrumentationKey"];
    }
    
    protected void Application_Error(Object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError();
        TelemetryClient client = new TelemetryClient();
        client.TrackException(ex);
    }
}

Cosa possiamo tracciare oltre alle Exception

La classe TelemetryClient consente vari tipi di tracciatura:

  • TrackException => Eccezioni, vista sopra
  • TrackPageView =>¬†Pagine, schermo, form, ecc.
  • TrackEvent => Eventi utenti o applicativi
  • TrackMetric => Metriche
  • TrackRequest => Caratteristiche request
  • TrackTrace => Messaggi diagnostica
  • TrackDependency => Monitoraggio dipendenze

Capirete che le potenzialit√† ci sono per portare su Azure¬†(e rivedere poi sulla Dashboard di Application Insights) pi√Ļ informazioni possibili, anche in funzione di quello che vogliamo sapere della nostra applicazione.

Ovviamente conviene non esagerare con le tracciature inutili, mentre potrebbe essere¬†pi√Ļ utile¬†censire preliminarmente le informazioni che¬†vogliamo avere sotto osservazione della nostra applicazione e cosa pensiamo sia utile tracciare anche in funzione di debug e fix da fare.

Tracciatura lato client

Quello che abbiamo visto sopra è chiaramente possibile, allo stesso modo, lato client, cioè direttamente dalla pagina HTML.

Del resto gi√† nello script di cui abbiamo parlato in un precedente post (che riporto di seguito per comodit√†) vediamo¬†come venga “istanziato” un oggetto appInsights equivalente al TelemetryClient e di esso venga utilizzato il metodo trackPageView per tracciare appunto le visite alle pagine:

 var appInsights = window.appInsights || function (config) {
 function r(config) { t[config] = function () { var i = arguments; t.queue.push(function () { t[config].apply(t, i) }) } } var t = { config: config }, u = document, e = window, o = "script", s = u.createElement(o), i, f; for (s.src = config.url || "//az416426.vo.msecnd.net/scripts/a/ai.0.js", u.getElementsByTagName(o)[0].parentNode.appendChild(s), t.cookie = u.cookie, t.queue = [], i = ["Event", "Exception", "Metric", "PageView", "Trace"]; i.length;) r("track" + i.pop()); return r("setAuthenticatedUserContext"), r("clearAuthenticatedUserContext"), config.disableExceptionTracking || (i = "onerror", r("_" + i), f = e[i], e[i] = function (config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t["_" + i](config, r, u, e, o), s }), t
 }({
 instrumentationKey: "6ab464ae-42ad-4928-8250-ac102c892085"
 });
 window.appInsights = appInsights;
 appInsights.trackPageView();

Ovviamente oltre al metodo trackPageView è possibile usare anche gli altri metodi della classe TelemetryClient indicati in precedenza.

La classe TelemetryClient di Application Insights

Gli SDK disponibili per Application Insights

Abbiamo visto un po’ di cose su Application Insights ultimamente, ma √® arrivato il momento di iniziare a parlare di codice.

Application Insights consente agli sviluppatori di interagire con diversi linguaggi e/o piattaforme.

Un elenco (non esaustivo) di SDK è il seguente:

Questo vi faccia capire come questo strumento non vuole essere solo un prodotto legato al¬†solo¬†ecosistema Microsoft, ma sia aperto a pi√Ļ¬†fronti.

Personalmente ho provato¬†solo l’interazione nel codice .NET ma immagino che sia equivalente in tutto e per tutto anche negli altri ambienti / linguaggi.

Qualche giorno fa stavo vedendo un po’ come funziona PHP, incuriosito da¬†classifiche sulla diffusione di linguaggi di programmazione e robe del genere,¬†magari potrei provare a vedere un po’ con quel linguaggio come va, appena ho qualcosa di concreto comunque vi faccio sapere.

Gli SDK disponibili per Application Insights

Le metriche di Application Insights

Quando ho deciso di scrivere un post per spiegare le tipologie di metriche di Application Insights mi sono reso conto di averne già scritto uno su Aspitalia.com .

Per questo forse √® meglio risparmiare energie e riportarvi direttamente il link all’articolo.

 

marketing-performance-metrics

Chiaro che le metriche di Application Insights sono veramente tantissime¬†ma nell’articolo che scrissi qualche tempo spiegavo¬†le tipologie e facevo alcuni esempi per dare un’idea di massima di come funzionano le metriche, per le altre “divertitevi” a girare in autonomia nella dashboard, e vedere quali fanno al caso vostro.

Le metriche di Application Insights

La dashboard di Application Insights

Da diversi post vi sto parlando di Application Insights e delle sue varie caratteristiche, e si √®¬†detto pi√Ļ volte che per utilizzarlo abbiamo bisogno di una sottoscrizione Azure.

In questo post voglio accompagnarvi in un “virtual tour” nella dashboard che troverete (nel caso non l’abbiate¬†ancora mai vista) e dare dei suggerimenti su come usarla.
Il post sarà quindi abbastanza fornito di schermate, necessarie allo scopo.

N.B.: Questo post non ha l’intenzione di entrare nel dettaglio delle metriche disponibili, di cui ci occuperemo in un successivo post.

Iniziamo il nostro tour nella dashboard di Application Insights

Innanzitutto il link, sempre quello:

http://portal.azure.com

Una volta effettuato il login,¬†sulla “spalla” sinistra selezionate Application Insights, in questo modo vi troverete la lista delle vostre risorse di telemetria, in una situazione pi√Ļ o meno come questa¬†illustrata di seguito:

IMG

A questo punto selezionate la risorsa Application Insights di cui volete vedere il dettaglio e a destra dell’elenco vi apparit√† un nuovo¬†“blade”¬†(cos√¨ si chiamano i “pannelli” che sul portale di “Azure” si aprono a destra man mano che scendiamo nei dettagli)¬†che conterr√†¬†le prime informazioni della risorsa stessa:

IMG

Come si pu√≤ vedere, nel blade che viene mostrato¬†vi sono nella parte superiore le informazioni “principali” inerenti la risorsa stessa (gruppo di risorse, subscription id, Instrumentation Key, ecc.) e nella parte inferiore alcune informazioni di riepilogo¬†(con uno scroll nella zona inferiore appariranno anche dei grafici).

Subito insieme al blade “principale” viene proposto a destra un blade dei “settings and diagnostics”, blade che si raggiunge anche con il link¬†in blu visibile nella parte superiore del blade principale.

Settings and Diagnostics

Nel¬†blade “Settings and Diagnostics” sono presenti diverse voci, filtrabili velocemente tramite una textbox posta in alto.

Questi “items” sono organizzati in tre “gruppi”:

  • Investigate
  • Configure
  • Resource Management

Nel¬†gruppo Investigate” troviamo di fatto delle metriche. Anche se non √® da l√¨ che dobbiamo necessariamente partire per esplorare le metriche, possiamo comunque da qui raggiungere alcune delle metriche¬†pi√Ļ utili soprattutto per la risoluzione di bug fixing ed errori, ma anche per comprendere problemi di performance o altro.

Nel gruppo “Configure” troviamo¬†items di vario genere, ma quello che a mio avviso pu√≤ essere subito utile √® la voce “Getting started”, in cui si viene “guidati” nell’utilizzo di script e codice utile per lo sviluppo applicativo, sia lato frontend che lato backend. Ci sono anche¬†altri items molto utili come¬†gli¬†“Alerts”, la “Continuous export” ecc.¬†Ad alcuni di questi verranno¬†poi “dedicati” dei¬†post ad hoc.

Nel gruppo “Resource Management” vediamo le funzionalit√† di gestione delle autorizzazioni¬†(in termini di persone e ruoli) che possiamo associare alle nostre risorse Application Insights, consentendo quindi l’accesso per funzionalit√† specifiche. In questo modo possiamo condividere, giusto per fare un¬†esempio, i dati con il “capo” in sola visualizzazione associandogli un profilo di sola lettura.

Il Metrics Explorer

Lo strumento “principale” (diciamo cos√¨) per la visualizzazione delle metriche e dei relativi dati √® il Metrics Explorer, che possiamo attivare da qui:

IMG.png

Si tratta di uno strumento che consente di “comporre” una sorta di “immagine” con grafici a nostro piacimento e personalizzati nell’aspetto grafico e nella rappresentazione del dato.

Per capirci meglio, dal Metrics Explorer si pu√≤ decidere quali metriche rappresentare, con che tipologia di grafico (a istogrammi, a linee piene, vuote, ecc.), variare l’intervallo di tempo in esame, ecc.

Posso aggiungere pi√Ļ grafici e in ogni grafico ci possono essere pi√Ļ metriche. Posso anche salvare nei “preferiti” questa “rappresentazione” delle informazioni, per poterla recuperare in seguito.

Da questo blade √® anche possibile esportare i dati, e con un profilo diverso da¬†quello gratuito √® possibile anche impostare una “continuous export” verso un container su Azure.

Sul Metrics Explorer va fatto un post a parte, prima di tutto perché ci sono tante di quelle cose da dire che spiegarlo velocemente rende poco giustizia allo strumento, e poi ovviamente per cercare di dare un aiuto concreto a chi non lo conosce.

Questa “panoramica ultraveloce” sulla dashboard di Application Insights¬†√® solo l’assaggio degli¬†approfondimenti che¬†seguiranno, per dare un taglio pi√Ļ verticale a questi dati.

La dashboard di Application Insights