Qualsiasi programmatore ASP.NET sa bene che una delle cose più importanti da fare quando si effettua il rilascio di un'applicazione in ambiente di produzione è dotarsi di una strategia di test e/o monitor che consenta di misurare l'uptime o availability, ovvero la raggiungibilità del servizio nel corso del tempo: in altre parole, la possibilità da parte degli utenti di accedere al servizio.
Questa necessità può essere gestita nei seguenti modi:
- Avvalendosi di strumenti di controllo di terze parti come Pingdom, Monitis, Uptime Robot, StatusCake e altri servizi similari: per chi non lo sapesse, si tratta di servizi di uptime & performance monitoring esterni che possono essere programmati per effettuare una o più request a intervalli regolari (ad es. ogni 5 minuti) e inviare notifiche SMS, E-Mail e/o Push in caso di irraggiungibilità del servizio. Questi servizi funzionano in modalità SaaS e possono essere gratuiti o a pagamento (solitamente con un sistema monthly fee) a seconda delle caratteristiche che si desidera attivare: numero di test programmabili, tempo di frequenza minima nell'esecuzione di ciascun test, e così via.
- Dotandosi di un sistema di monitoring interno, ovvero di un applicativo apposito installato all'interno del medesimo ambiente di produzione del servizio da controllare.
Uptime & Availability
Affidare il controllo della raggiungibilità delle pagine e/o delle API della nostra applicazione a un servizio di terze parti, e quindi posto al di fuori della server farm di produzione, è indubbiamente un'ottima scelta, per due ragioni principali:
- Il servizio non sarà influenzato da eventuali crash che potrebbero avvenire all'interno della server farm stessa: in altre parole, non rischieremo che diventi indisponibile insieme al servizio che deve controllare, perdendo così la possibilità di avvisarci.
- Il servizio non sarà influenzato da tutte le "regole speciali" che potrebbero esistere all'interno dei network interni alla server farm (routing, configurazioni VPN/firewall/proxy, reindirizzamenti etc.) e potrà quindi effettuare test più verosimili, o per meglio dire più simili alla reale esperienza di chi accede ai nostri sistemi dall'esterno.
Il tutto, inutile dirlo, a patto che il servizio sia sufficientemente affidabile.
Questa metodologia di controllo uptime tramite SaaS, per quanto generalmente più efficace di un sistema di monitoring interno, non è però esente da limitazioni:
- I controlli avvengono sempre tramite chiamate inviate attraverso porte e/o protocolli standard - HTTP request, ICMP request e così via; si tratta di interrogazioni piuttosto superficiali, che non consentono di controllare il corretto funzionamento di funzionalità complesse a livello di back-end. A questo problema si può ovviare facilmente sviluppando apposite "pagine di test" ed esponendole pubblicamente, cosa che però contribuisce ad aggravare la seconda limitazione.
- I controlli impostati sul servizio di terze parti devono poter accedere alle pagine e/o alle API che devono controllare: questo non costituisce un problema nel caso di un monitor impostato sull'home page o sulla pagina di login, ma può diventare critico a livello di sicurezza nel caso in cui lo sviluppatore sia intenzionato a costruire delle pagine di test più approfondite (cfr. punto precedente), le quali potrebbero diventare oggetto di attacco: ad esempio, una pagina che effettua una serie di query a un Database per controllare la raggiungibilità del servizio e lo stato delle tabelle potrebbe diventare facile preda di attacco DDoS. Per ovviare a questo problema è ovviamente possibile configurare le chiamate di questi servizi adottando precauzioni di sicurezza anche molto sofisticate (parametri POST, bearer token, IP whitelist sul firewall di ingresso, etc.), ma è sufficiente una piccola dimenticanza o ingenuità per aprire una falla nella propria infrastruttura.
Ovviamente, questo tipo di problemi non è presente in un sistema di controllo interno: potremmo quindi concludere che la soluzione migliore è nell'utilizzare entrambi gli approcci in modo complementare, affidando l'uptime monitoring ad alto livello ai servizi di terze parti e delegando le verifiche più complesse a un sistema interno non raggiungibile dal web (se non per una singola pagina di controllo di raggiungibilità).
elmah.io
In questo articolato e complementare universo di test interni ed esterni si inserisce elmah.io, uno strumento di Error Management, Deployment Tracking e Uptime Monitoring che si pone l'ambizioso obiettivo di coniugare gli strumenti di controllo interni ed esterni in un unico servizio.
Volendo riassumere le funzionalità principali, la piattaforma offre:
- Un sistema di uptime monitoring dall'esterno, effettuato attraverso una serie di funzionalità in tutto e per tutto simili a quelle fornite dai servizi elencati all'inizio di uesto articolo (Pingdom, StatusCake etc.): in estrema sintesi, un controllo dell'availability della nostra applicazione con notifica puntuale in caso di downtime.
- Un sistema di error tracking & logging interno, effettuato mediante l'installazione di una apposita libreria ASP.NET all'interno della nostra applicazione ASP.NET, ASP.NET MVC o .NET Core. Una volta installata, questa libreria si occuperà di intercettare tutte le eccezioni prodotte dalla nostra applicazione, rendendole consultabili tramite una apposita interfaccia web ed inviando (opzionalmente) una notifica puntuale e/o una sintesi giornaliera di tutti gli errori a uno o più indirizzi e-mail.
Salta subito all'occhio che il vero valore aggiunto di elmah.io è dato dalla combinazione dei due aspetti: l'uptime monitoring esterno ci tiene informati sulla raggiungibilità e disponibilità del sito, mentre l'error tracking interno consente di avere immediatamente notizia di qualsivoglia crash applicativo - con la preziosissima possibilità di poter visionare i dettagli dell'eccezione direttamente dal web.
La screenshot di seguito è relativa alla pagina Overview di uno dei progetti che abbiamo configurato all'interno dello strumento, attraverso la quale si può avere una visione d'insieme sui vari errori riscontrati nel corso del tempo e relative informazioni (affected browsers, frequenza/incidenza, URL, etc.).
Una ricerca più approfondita può essere effettuata attraverso la pagina Search, che consente di individuare le varie eccezioni mediante query full-text e vari filtri (per data, per tipo di errore, etc.).
Installazione
Installare elmah.io all'interno di una applicazione ASP.NET è un'operazione estremamente semplice: è sufficiente creare un account sul sito del servizio, sottoscrivere uno dei piani previsti e creare il relativo progetto attraverso l'interfaccia web.
Una volta fatto questo, il servizio ci mostrerà una pagina contenente le istruzioni per installare la libreria di logging sui vari framework supportati (ASP.NET, ASP.NET MVC, ASP.NET Core etc.) e le crenziali (API KEY e LOG ID) necessarie, da inserire nel file Web.config dell'applicazione:
Se si utilizza Nuget, l'installazione sarà con tutta probabilità ridotta ad una singola riga da digitare all'interno della Package Manager Console:
|
1 |
PM> Install-Package elmah.io |
Gli utilizzatori di Visual Studio potranno inoltre beneficiare di una apposita estensione (elmah.io per Visual Studio) che consente un'integrazione di elmah.io che consente di visualizzare i log del servizio direttamente dalla GUI dell'ambiente di sviluppo.
L'intero processo di installazione e configurazione è illustrato nel seguente video YouTube:
Pricing
Le soluzioni di pricing offerte dal servizio variano molto a seconda del numero degli sviluppatori che vogliamo far accedere al servizio, della retention dei log e di altre funzionalità opzionali che è possibile o meno attivare. Sono inoltre previsti programmi particolari (sconti, licenze NFR etc.) per startup, piccole aziende, MVP e progetti open-source: trattandosi di un servizio realizzato da sviluppatori per sviluppatori, è legittimo aspettarsi un occhio di riguardo nel caso in cui si intenda utilizzare il prodotto a scopi didattici, dimostrativi, divulgativi e/o non a scopo di lucro.
Conclusioni
Prima di scrivere questa recensione abbiamo provato a installare elmah.io su due progetti ASP.NET MVC piuttosto importanti per un periodo di circa due mesi: il risultato ottenuto è stato estremamente soddisfacente, in quanto ci ha consentito - per la prima volta - di effettuare l'analisi di alcuni bug estremamente difficili da riprodurre in un modo totalmente inedito, ovvero osservando una serie di StackTrace prodotti dal sistema a seguito di comportamenti reali degli utenti.
La valutazione è dunque estremamente positiva: siamo convinti che gli sviluppatori abbiano centrato l'obiettivo, realizzando uno strumento che fornisce un notevole valore aggiunto a chiunque sia interessato a investire sulle attività di testing e monitoring del proprio software: una scelta strategica che, oggi come oggi, risulta quantomai necessaria se ci si pone l'obiettivo di rilasciare una applicazione web di qualità.
