Separare sviluppo e produzione su Application Insights

Abbiamo anticipato in un precedente post che avremmo parlato di questo argomento.

Le problematiche che affronteremo (e risolveremo) sono le seguenti:

  • qualora dovessimo cambiare la risorsa Application Insights da utilizzare in un progetto, dovremmo cambiare la Instrumentation Key sia nel file ApplicationInsights.config che nella _Layout.cshtml
  • i dati inviati in fase di sviluppo e debug su Application Insights saranno “fasulli”, e influenzeranno quindi i dati reali della produzione

Per risolvere entrambi questi problemi, faremo ricorso a due cose:

  • più risorse di Application Insights, quindi nel caso di “sviluppo” e “produzione” avremo bisogno di due risorse
  • codice Razor per caricare, in base allo scenario, la Instrumentation Key giusta

Cominciamo.

Andiamo a creare più risorse Application Insights su Azure

Prima di tutto creiamo tutte le risorse necessarie su Azure, e per farlo andiamo al seguente indirizzo:

https://portal.azure.com

Dal portale di Azure selezioniamo la voce “Resource Groups” e quindi usiamo il tasto “+ Add” per inserire un nuovo gruppo:

IMG09

Assegniamo il nome al gruppo e scegliamo la sottoscrizione Azure da utilizzare, come zona geografica di Application Insights per il momento è possibile scegliere solo “Central US”, dato che questo servizio è ancora in “preview” (anche se di preview ormai non si può più parlare di fatto).

IMG

Nel nostro esempio abbiamo messo il suffisso “_GROUP” al nome del nostro gruppo per una questione di nomenclatura, non è necessario né richiesto da alcuna policy del servizio.

Con lo stesso criterio, userò i suffissi “_DEV” e “_PROD” per indicare i nomi dei profili che saranno destinati, rispettivamente, a “sviluppo e test” e “produzione”.

Per farlo procediamo con la selezione a sinistra della voce “Application Insights” e quindi con il pulsante “+ Add” ancora una volta procediamo con l’inserimento:

IMG

Facciamo attenzione ad assegnare la risorsa che andiamo a creare al gruppo che abbiamo poc’anzi creato:

IMG

Una volta creato la prima risorsa “_DEV”, ripetiamo la stessa operazione per la creazione della seconda risorsa “_PROD”.

Da notare che il gruppo di risorse, seppure non  necessario, ci aiuterà a recuperare velocemente le risorse create per quello specifico progetto per cui, seppure non sia documentato come linea guida, l’approccio indicato è fortemente consigliato (da me).

A questo punto prendiamo nota (ad esempio su un “blocco note”) delle due Instrumentation Key delle due risorse in modo da poterle ricopiare e incollare tra poco nel nostro progetto web.

Utilizziamo le risorse Application Insights in Visual Studio

Che si tratti di un nuovo progetto o di un progetto esistente poco cambia, come avevamo già detto in precedenti post, perché in entrambi i casi le informazioni richieste saranno le stesse.

Nel nostro esempio procediamo con la creazione di un nuovo progetto e scegliamo la risorsa Application Insights denominata “_DEV”.

IMG.png

A questo punto procediamo all’aggiunta dello script JavaScript necessario ad Application Insights, così come spiegato in questo post.

Ci troveremo quindi nella situazione di avere un file ApplicationInsights.config e un file _Layout.cshtml che fanno riferimento alla stessa Instrumentation Key, nel caso specifico quella con il suffisso “_DEV”.

<InstrumentationKey>fca7eaf9-717d-4d86-8d7c-70c7914880b4</InstrumentationKey>
    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:"fca7eaf9-717d-4d86-8d7c-70c7914880b4"
    });
    window.appInsights=appInsights;
    appInsights.trackPageView();


La strategia che andremo a perseguire sarà la seguente:

  • aggiungere un setting nel Web.config che rappresenti la Instrumentation Key
  • aggiungere lo stesso setting nel file Web.Release.config in maniera tale da poter sostituire nel momento del deploy in produzione il setting del Web.config con questo
  • andare a dichiarare una variabile che possa, tramite Razor, arrivare fino allo script JavaScript

Procediamo con ordine.

Nel Web.config dichiariamo la seguente variabile che identifica la Instrumentation Key:

<appSettings>
    <!-- Application Insights -DEVELOPMENT- Instrumentation Key -->
    <add key="ApplicationInsightsInstrumentationKey" 
         value="fca7eaf9-717d-4d86-8d7c-70c7914880b4" />
 </appSettings>

come valore andremo a mettere la chiave “_DEV”.
Nel file Web.Release.config andremo a mettere quindi la chiave “trasformata” che rappresenta la risorsa “_PROD”:

<appSettings>
    <!-- Application Insights -PRODUCTION- Instrumentation Key -->
 <add key="ApplicationInsightsInstrumentationKey" 
      value="95e74185-b456-48e4-9e69-f586ffeeb0b1"
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
 </appSettings>

Utilizzando questa modalità che ci viene offerta da Visual Studio, avremo quindi il risultato di “portare” nel Web.config presente nel deploy fatto in produzione la chiave giusta (a patto ovviamente che nel nostro package di deploy indichiamo la configurazione di “Release”).

A questo punto dobbiamo procedere alla “lettura” di questo valore dal file Web.config che il codice troverà in esecuzione.
Per far questo possiamo procedere alla lettura all’interno del file Global.asax, e più precisamente nel metodo di Application_Start:

protected void Application_Start()
{
    // altro codice
    //...
    // lettura della instrumentation key in base alla configurazione
    Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey = System.Web.Configuration.WebConfigurationManager.AppSettings["ApplicationInsightsInstrumentationKey"];
}

Con questa istruzione abbiamo impostato che la Instrumentation Key venga “letta” dal file Web.config ogni volta che viene avviata l’applicazione.
Ovviamente, in funzione dell’ambiente in cui ci si troverà, grazie alla trasformazione applicata precedentemente nei file di config, troveremo la chiave giusta, quindi “_DEV” in ambiente di sviluppo e “_PROD” nell’ambiente di produzione.

Ora i nostri dati saranno puliti?
Ancora non del tutto. Con quanto fatto finora abbiamo infatti garantito che lato server abbiamo discriminato le due chiavi, ma abbiamo ancora una chiave “cablata” nel JavaScript di Application Insights, e questo lo risolviamo facilmente con una sostituzione della chiave stessa con una variabile caricata a “runtime” tramite Razor, il risultato è il seguente:

    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: "@(Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey)"
    });
    window.appInsights=appInsights;
    appInsights.trackPageView();

Ora sì che possiamo dire di aver risolto tutti i possibili conflitti delle chiavi. Infatti, con questa “semplice” sostituzione del valore con una variabile letta dal server, e che nel nostro caso è proprio la stessa Instrumentation Key che abbiamo impostato durante la fase di “application start”, possiamo essere sicuri che anche nelle pagine del frontend troveremo le giuste chiavi per i due ambienti diversi.

Fra “qualche post” spiegheremo cos’è e a cosa serve la classe TelemetryClient, e come invocare le varie API messe a disposizione da Application Insights.

Per ora divertitevi a fare delle prove con questo codice.

Annunci
Separare sviluppo e produzione su Application Insights

Agganciare Application Insights ad un progetto esistente in ASP.NET MVC

In un precedente post avevo illustrato come fare per utilizzare Application Insights in un progetto ex-novo basato su tecnologia ASP.NET MVC.

In questo post andremo invece a vedere come possiamo utilizzare Application Insights in un progetto già esistente, sempre basato su ASP.NET MVC.

Ricordo che per usare le comode funzionalità presenti in maniera integrata in Visual Studio è necessario usare la versione 2013 Update 3 o la versione 2015.

Andiamo quindi su un progetto già esistente, basato su ASP.NET MVC in Visual Studio 2015.

Anche in questa situazione si può aggiungere velocemente e con pochi click Application Insights al progetto, facendo semplicemente tasto destro all’interno del Solution Explorer sul nodo che rappresenta il nostro progetto, e quindi utilizzare la voce “Add Application Insights Telemetry…” che troveremo nel menù contestuale:

IMG08

Ci verrà proposta una dialog in cui verranno richieste le informazioni da utilizzare per creare una nuova risorsa Application Insights su Azure, o per utilizzarne una che abbiamo già creata, alla stregua di quanto avviene nel caso in cui partivamo con un progetto da zero:

IMG09.png

Una volta creata la nuova risorsa Application Insights (o agganciata una già esistente) saremo nella stessa situazione del post in cui partivamo da un progetto ex-novo, quindi dovremo inserire lo script JavaScript della nostra risorsa Application Insights nella “master page” di MVC, ovvero nel file _Layout.cshtml.

Nel prossimo post mostrerò come utilizzare risorse Application Insights distinte per separare l’ambiente di sviluppo e debug da quello di produzione.

Agganciare Application Insights ad un progetto esistente in ASP.NET MVC

Utilizzare Application Insights in un nuovo progetto ASP.NET MVC

Ore che stiamo cominciando a conoscere Microsoft Application Insights, e dopo che ne abbiamo cominciato a vedere le prime nozioni di base, possiamo parlare di sviluppo.

In questo post voglio far vedere la semplicità con cui possiamo usare Application Insights in un progetto ASP.NET MVC nel caso di un nuovo progetto, nel successivo post mostrerò anche il caso di un progetto già esistente in cui la telemetria di Microsoft non era stata prevista sin dall’inizio.

Ricordo che per usare Application Insights non è necessario per forza usare Visual Studio e pensare allo sviluppo con il .NET framework, dato che l’elenco di SDK , per vari linguaggi e piattaforme, è molto variegato.
Nel nostro esempio, per semplicità andremo sugli ambienti a me più familiari. Infatti con Visual Studio 2013 (service pack 3) o Visual Studio 2015, la piattaforma di Application Insights si può trovare già integrata e pronta all’uso (in termini di librerie per lo sviluppo).

Prima di proseguire, accertatevi di avere una subscription attiva su Azure, come vi avevo già spiegato.

Partiamo quindi con un progetto ex-novo, basato su ASP.NET MVC su Visual Studio 2015.

Da Visual Studio 2015 facciamo, come sempre, File > New > Project… > Web > ASP.NET Web Application per partire con un nuovo progetto ASP.NET MVC.

IMG01

Come potete notare dall’immagine sopra, sul lato destro della dialog di creazione di un nuovo progetto trovate già un check che ci consente l’utilizzo di Application Insights all’interno del progetto che stiamo andando a creare.
Chiaramente se non vogliamo che il nostro progetto usi la telemetria si può anche deselezionare.

Nel nostro caso lo lasciamo selezionato e subito sotto andiamo a configurare l’account, sottoscrizione e risorsa di Azure da usare per la creazione di questa telemetria.
Lascio a voi le prove per la configurazione, magari utilizzando anche la voce “Configure settings…” presente sempre tra i parametri, è talmente semplice da fare in autonomia che spiegarlo nel dettaglio non serve.

L’unica cosa da fare è scegliere il tipo di progetto web e attendere quei 20-30 secondi necessari per la configurazione automatica.

Importante sapere che se avevate già creato su Azure una risorsa Application Insights e volete utilizzare quella per la telemetria, potete sempre selezionarla nel menù a tendina che trovate in questa dialog.

Nel caso più comune, possiamo crearne una nuova e lasciare a questo wizard il compito di generare tutta l’infrastruttura necessaria sul cloud, operazione che richiede in genere circa 20-30 secondi, quindi sicuramente più veloce di quello che impiegheremmo noi a crearla dal portale di Azure.

Al termine di questa operazione avremo il nostro progetto creato e la risorsa Application Insights creata e pronta all’uso.

All’interno del nostro progetto troveremo un file ApplicationInsights.config, che di fatto è un xml così come lo è il classico web.config, in cui troveremo tutte e sole le informazioni relative alla risorsa Application Insights che utilizziamo nel nostro progetto.

IMG02

All’interno di questo file troveremo una serie di informazioni che andremo ad analizzare in un post successivo.

Intanto la cosa che ci serve subito indicare è la Instrumentation Key, che è di fatto la “chiave” identificativa univoca della nostra risorsa Application Insights:

 IMG03.png

Se volessimo quindi un giorno cambiare la risorsa Application Insights da utilizzare per la nostra telemetria, sarebbe qui che dovremmo intervenire una volta creata una nuova risorsa sulla nostra sottoscrizione Azure.

Passo successivo: importazione dello script JavaScript di Application Insights.

A questo punto la nostra applicazione web è “quasi” pronta, nel senso che adesso sa “dove” inviare le informazioni che verranno raccolte e catalogate, ma non sa ancora “quali” informazioni inviare.

Si, perchè se non l’avete ancora capito, le informazioni che troverete su Application Insights sono inviate dalla vostra applicazione, e non si generano in automatico per magia…

Per quanto riguarda i sistemi di telemetria, o Web Analytics, come lo è appunto Application Insights (e come lo è, giusto per fare un esempio magari più noto, Google Analytics), la prima cosa che fanno nella maniera più semplice del mondo, è quella di raccogliere informazioni sulle pagine visitate e altre info quali, ad esempio, la provenienza delle chiamate, il tipo di dispositivo, ecc.

Questa è la prima cosa che si fa in questi sistemi di telemetria, di solito usando un semplice script JavaScript da inserire nelle pagine da monitorare.
E infatti lo possiamo fare anche con Application Insights.

Questa operazione non avviene in automatico ed è una delle poche cose da fare subito da soli una volta impostato il nostro progetto.

Per copiare il nostro script a questo punto dobbiamo andare sul portale di Azure all’indirizzo:

https://portal.azure.com

IMG04.png

Selezionando dall’elenco a sinistra la voce “Application Insights”, vi verranno mostrate le risorse di telemetria che avete nella vostra sottoscrizione, selezionando quella che riguarda il progetto appena creato avremo una vista del genere:

IMG05.png

Come potete vedere nell’immagine sopra, vi verranno mostrate tutta una serie di informazioni relative alla risorsa Application Insights che avete utilizzato.
La semplicità di utilizzo della dashboard di Azure vi aiuterà moltissimo a trovare tutto quello che vi serve per la telemetria, di questo aspetto ne parleremo in seguito.

Per i nostri scopi, ovvero trovare lo script JavaScript da utilizzare, possiamo andare alla sezione dei settings (tramite la label “Settings and Diagnostics” che trovate nel “blade” centrale (ricordo che i “blade” in Azure sono le “sezioni” che man mano si aprono a destra dell’item che selezioniamo), e una volta selezionato quello, a destra andate nella sezione “Getting started”, quindi scegliere “MONITOR AND DIAGNOSE CLIENT SIDE APPLICATION” e arriveremo a trovare lo script che vediamo di seguito:

IMG06.png

Come vedete dall’immagine, si tratta di uno script JavaScript che possiamo copiare velocemente nella nostra clipboard utilizzando il tastino sopra evidenziato, a quel punto possiamo copiarlo nelle pagine del nostro progetto ASP.NET MVC che stavamo preparando.

La cosa più veloce da fare, di solito, è quella di mettere lo script nella “master page” del progetto, per far si che ogni pagina venga tracciata senza doversi preoccupare di ripetere lo script in ogni nuova pagina della nostra applicazione.

Per quanto riguarda ASP.NET MVC, la “master page” è rappresentata dalla pagina (o view) _Layout.cshtml, in cui a questo punto possiamo posizionare il codice appena copiato:

IMG07

Da questo momento in poi, le visite alle nostre pagine verranno tracciate su Application Insights, e potremo sempre verificare quali tipo di device o browser ha visitato la pagina e quando lo ha fatto ed altre informazioni a riguardo.

Personalmente sono solito mettere lo script in una partial view ad hoc (ad esempio chiamandola “_ApplicationInsights.cshtml”) e aggiungere la partial view nella _Layout.cshtml, ma è solo una questione di “leggibilità” del codice, non c’è nessun vantaggio pratico nel farlo.

Un paio di cose da ricordare prima di chiudere:

  • con la situazione appena descritta, qualora dovessimo cambiare la risorsa Application Insights da utilizzare, si dovrebbe cambiare la Instrumentation Key sia nel file ApplicationInsights.config che nella _Layout.cshtml, a meno di far si che da quest’ultimo file la chiave venga passata tramite Razor
  • i dati inviati in fase di sviluppo e debug saranno “fasulli”, quindi allo scopo del nostro business non saranno dati utili, è quindi molto più saggio (e direi necessario) usare due risorse distinte di Application Insights, una per lo sviluppo, e una per la produzione

Per entrambi i punti sopra descritti, scriverò un post apposito per la gestione di più environment applicativi, in cui entrambi i punti saranno risolti. Ma abbiate pazienza ancora qualche giorno per leggerlo…

Intanto cominciate a dare un’occhiata a quello che vi ho detto, probabilmente troverete tutto ancora più semplice anche di come ve l’ho descritto io… 😉

 

Utilizzare Application Insights in un nuovo progetto ASP.NET MVC

Articolo “Introduzione a Microsoft Application Insights” su Windows Azure Italia

Ieri sul network Aspitalia.com e in particolare su WindowsAzureItalia.com è stato pubblicato un mio articolo su Microsoft Application Insights, un servizio che ci consente di effettuare operazioni di telemetria su una web application o un web service (ASP.NET o Java) o su mobile application (Windows Phone o Windows Store app).

E’ un servizio molto interessante sul quale mi piacerà fare degli approfondimenti.

Erano più di quattro anni che non scrivevo per il network Aspitalia, per motivi personali o di lavoro avevo un po’ perso questa sana abitudine, e quando approfondivo un argomento poi non scrivevo nulla.

Ma ho deciso che “approfondire e condividere” sono verbi che devono viaggiare di pari passo.

Trovate l’articolo qui.

Articolo “Introduzione a Microsoft Application Insights” su Windows Azure Italia

Evento: DotNetToscana – Creare App per Office 365 e SharePoint 2013 con ASP.NET MVC 5

La community DotNetToscana ha organizzato questo ottimo evento, in cui verrà illustrato il nuovo “App-Model” introdotto dalla nuova versione di Office 365 e da SharePoint 2013.

Si parlerà anche di com’è possibile sfruttare le conoscenze di ASP.NET MVC 5 e SQL Azure, per scrivere un’App che interagisca con i servizi e i contenuti offerti da SharePoint e che funzioni sul Cloud ed on-premises.

L’evento, della durata di un’ora dalle 17 alle 18 di Lunedì 28 Aprile 2014, sarà curato da Emanuele Bartolesi di DotNetToscana e da Giuseppe Marchi (SharePoint MVP).

Questi sono i link per la pagina dell’evento e per l’iscrizione, mentre qui trovate la pagina Facebook della community.

I posti sono limitati, se siete interessati iscrivetevi (gratuitamente) al più presto.

 

Evento: DotNetToscana – Creare App per Office 365 e SharePoint 2013 con ASP.NET MVC 5

Developing Microsoft® SharePoint® Applications Using Windows Azure™ by Steve Fox

Developing Microsoft® SharePoint® Applications Using Windows Azure™ by Steve FoxThis book clearly explains the points of contact and possible integration between Microsoft® SharePoint® 2010 and Windows Azure™.

It begins with a series of introductory chapters, using products and technologies characteristics, to introduce reader to most interesting concepts for the purpose of the book.

Successive chapters are focused on techniques to allow data access and consuming, and other interesting methods to understand how to implement applications and web parts using both components.

The examples inside the book represent a good entry point on the route to this kind of integration, and are explained so well through code and screenshots that guides the developer on his steps to follow to accomplish the objectives.

If I should define a defect for this book, then it is its brevity. I think that a deep understanding of this kind of integration is not possibile with this number of pages. So this could be a starting point but will not be exhaustive to define himself an “expert”.

At the end, I think this is a good reference to have always on own desk, the target reader is in my humble opinion should be a developer focused on SharePoint 2010 (better if senior developer but not mandatory) and must have known basic concepts about Azure and its platform. Also a basic skill on WCF could be useful for correct understanding of some paragraphs and examples.

You can buy the book here.

Developing Microsoft® SharePoint® Applications Using Windows Azure™ by Steve Fox

Microsoft Certifications: Beta exams available for Silverlight 4 and Azure

Great opportunity to contribute in Microsoft certifications refinement having at the same time the possibility to earn the certification without fee paying (obviously if you are almost able to earn it!)

Silverlight 4

Beta Exam 71-506, TS: Silverlight 4, Development

Azure

Beta Exam 71-583, Pro: Designing and Developing Windows Azure Applications

 

Register immediately! But do it only if you’re sure to participate, else please leave room for other people!

Good luck! 🙂

Microsoft Certifications: Beta exams available for Silverlight 4 and Azure