Le sessioni del Technical Cloud Day

L’altro giorno mi è arrivata una mail da Microsoft che mi segnalava la disponibilità online delle sessioni del Technical Cloud Day, un evento a cui purtroppo non ho potuto partecipare (e di questo mi pento amaramente).

Fortunatamente queste interessantissime sessioni, tenute da esperti del settore, sono state registrate e rese disponibili online su Channel 9, e le trovate a questo indirizzo.

Tra le molte sessioni sicuramente troverete qualcuna che vi interesserà.

Io personalmente ritengo le tematiche trattate tutte degne di interesse e di sicuro cercherò di capirne qualcosa in più per poterle poi utilizzarle sul campo quando necessario.

E come già detto in altri post, ricordate che “Scientia potentia est” (ovvero “sapere è potere”).

Annunci
Le sessioni del Technical Cloud Day

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

Mai sentito parlare di Azure Stack?

L’altro giorno stavo guardando questo video della serie #TecHeroes con Paola Presutto che spiega un pochettino cosa sia Azure Stack.

PaolaPAzureStack.png

Ne avevo sentito parlare ma non avevo mai approfondito l’argomento e allora, incuriosito da questo interessante video mi sono messo a cercare un po’ di informazioni.

Cosa è Azure Stack

Azure Stack è stato presentato durante la conferenza americana Ignite del 2015, e pubblicato in Technical Preview 1 a fine gennaio 2016, e si tratta di una piattaforma per il cloud “ibrido”, ovvero da installare nei propri datacenter, basata sullo stesso modello e sulle stesse tecnologie di Azure. Banalizzando il concetto in due parole, una sorta di “Azure installabile in casa”.

In realtà non ci sono (ancora) il 100% delle funzionalità di Azure, ma è comunque una buona soluzione PaaS/IaaS che va incontro a tutte quelle aziende che hanno ancora “paura” di portare i loro “beni” al di fuori dei loro confini.

Microsoft ha fatto quindi una mossa per la serie: se Maometto non va alla montagna, è la montagna che va da Maometto”, e per quanto ne so, non esistono altre piattaforme cloud che abbiano fatto qualcosa di simile.
Questo rappresenta sicuramente una nuova categoria di prodotti, qualcosa che potremmo classificare come “hybrid cloud platform” o simile.

Quali sono i requisiti per poterlo installare

Se avete i requisiti hw e sw qui elencati e volete avere il cloud in casa vostra, potete provare questa Technical Preview 1 di Azure Stack.

Ovviamente non si tratta di una installazione che si può fare in casa, a meno che non abbiate a disposizione un server con un minimo di 12 core e 96 GB di ram (e in quel caso vi invidierei moltissimo).
Il tutto può essere comunque installato su una sola macchina fisica.

Io purtroppo non ho a disposizione i requisiti minimi richiesti, e quindi cercherò di capire qualcosa in più dando un’occhiata in rete per capire se qualcuno ha avuto esperienze al riguardo.

Ad ogni modo, Microsoft vuole semplificare più possibile questo requisito, tanto che si sta interfacciando con i suoi vendor di riferimento per definire delle soluzioni hardware specificatamente progettate per Azure Stack.

Qual è il target di riferimento

Il target è sicuramente quello aziendale, con una infrastruttura di un certo livello ed esigenze ben specifiche.

Anche la procedura di installazione, sebbene Microsoft tenda sempre a semplificarla a vantaggio degli utenti, in questo caso non è proprio alla portata di tutti.

Quindi hardware e software come da requisiti si, ma anche figure capaci di “costruire” una infrastruttura ex-novo (praticamente) e di saperla poi governare adeguatamente.

Insomma è un gran bel giocattolo ma bisogna saperlo usare. Staremo a vedere in futuro se ci saranno casi concreti da esaminare.

Caratteristiche e concetti principali di Azure Stack

Vista la consistenza di questo “prodotto”, sul portale avremo (stando alle immagini sul sito ufficiale) la stessa esperienza utente che abbiamo su Azure:

image3

Questo rappresenta un ovvio vantaggio per chi è già pratico del cloud di Microsoft. Infatti con le stesse funzionalità (su fronti diversi) si potranno gestire contemporaneamente le risorse nel proprio datacenter, le risorse su Azure e le risorse su altri datacenter (se avviati con lo stesso prodotto).

E come il cloud di Microsoft, da questa installazione si potranno creare piani e sottoscrizioni per poter rendere disponibili i vari servizi nell’ecosistema di destinazione.
Nei piani potranno essere configurati i vari servizi disponibili con le quote decise per ogni servizio (per esempio banda massima utilizzabile, percentuale cpu massima utilizzabile, ecc.).

Insomma con Azure Stack ne vedremo delle belle!

Mai sentito parlare di Azure Stack?

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