a casa di Emma: MELANZANE SOTT'OLIO\nMamma tecnologica,tuttofare, realistica e pratica vi accoglie nel suo blog come a casa sua...\nUna mia esclusiva ricetta, tramandata da mia nonna, le mitiche melanzane sott'olio.\nSenza cottura senza odore di aceto in casa\nMELANZANE ALMENO 4 (PER 1 VASETTO)\n1 LIT DI ACETO BIANCO\nSALE GROSSO (UN BICCHIERE)\n1 PIATTO TONDO\nPrivate le melanzane delle estremità, tagliatele in due e con un coltello ben affilato tagliate via tutta la buccia, tagliatele a fette spesse circa 1 cm e poi a filetti sempre di circa un cm,(come foto).\nMan mano che sono tagliate adagiatele in un colapasta appoggiato su un contenitore.\nAdesso è il momento di aggiungere il sale, versatelo sulle melanzane e giratele con le mani, assicuratevi che il sale arrivi su tutte, se ne fate tante dovrete mettere molto più di un bicchiere! Vedrete che lasceranno subito andare dell'acqua.\nAssicuratevi che il sotto dello scolapasta no rimanga a contatto ravvicinato del contenitore dove è appoggiato perché rischiate che l'acqua venga a contatto con le melanzane, mettete un piccolo contenitore di plastica per sopraelevare lo scolapasta.(quello arancione nella foto)\nCoprite le melanzane con un piattino tondo facendo attenzione che non tocchi i bordi dello scolapasta(altrimenti non fa pressione), sopra al piatto appoggiate una pentola piena d'acqua per esercitare pressione. Lasciate almeno 10 ore. L'ideale è farle alla sera così al mattino concludete.\nPassato il periodo sotto pressione, strizzatele manualmente cercando di togliere l'ultima acqua rimasta, vedrete che di sale non ce né più (anche se c'è lasciatelo).\nUna volta strizzate bene prendete mettetele in un contenitore e riempitelo di aceto fino a coprirle completamente, coprite e lasciate riposare dalle 2 alle 3 ore (se le volete belle acetose 3 ore)\nPassato questo tempo, strizzatele bene manualmente per più volte. Rimettetele in un contenitore e conditele con origano, aglio, peperoncino, alloro, e olio. Mescolatele e mettetele in un vasetto schiacciandole bene. Versate l'olio fino a coprirle completamente.\nL'ideale è aspettare almeno 1 settimana, io personalmente me le mangio anche il giorno stesso, se le tenete in frigo sono ancora più buone!(è solo una preferenza)\nPubblicato da EMMA a venerdì, aprile 17, 2009\nEtichette: conserve, Ricette\nDual 23 aprile 2009 14:11\nGironzolando sono arrivato nel tuo blog!Un saluto Dual!\nèmmamma 25 aprile 2009 05:35\nCiao Dual,un saluto a te e grazie della visita!\nLinda 27 aprile 2009 07:39\nCara Emma, questa ricetta sembra fatta per me!!\ngrazie mille per averla scritta, la proverò di sicuro perchè sono ghiotta di verdurine sott'olio!!\nEMMA 27 aprile 2009 10:22\nPrego Linda, è un piacere!Te le consiglio...qua vanno a ruba! ti ho pensato quando l'ho scritta, così non avrai il problema dell'odore...\nLinda 28 aprile 2009 06:08\nAdesso la prima volta che metto piede in un supermercato faccio razzia di melanzane e poi ti dico come mi sono venute!\nEMMA 30 aprile 2009 05:05\n...sicuramente buonissime vedrai!!!\nmmmm io ne ho già fatto fuori un vasettone!!ne ho già altre da fare...non posso più restare senza...!!\naspetto tue notizie...;-))\nGabriella 29 agosto 2010 01:06\nvorrei sapere se le melanzane come le fai tu durano per mesi grazie gabriella\nEMMA 29 agosto 2010 11:31\nCiao Gabriella, allora se vuoi conservarle per mesi devi prima far bollire i vasi vuoti (ci sono dei vasi che si prestano bene, hanno il tappo autosigillante che tiene molto bene li trovi nei supermercati)e i tappi per sterilizzarli e lasciarli asciugare bene. Poi dopo averli riempiti e chiusi devi dargli un'altra scottata di 30 secondi in acqua bollente (che bolle propio), poi metti il vaso a testa in giù e lascialo raffreddare, vedrai che ricapovolgendolo si è creato il famoso "sottovuoto". in questo modo si conservano di più, io non lo faccio mai perchè se mi durano 2 settimane è tanto..:-)\nfammi sapere ciao Emma\nfarfallina 27 settembre 2010 02:29\nOggi proverò a farle anche io :) speriamo bene!! Ho provato un po' di giorni fa a fare la ricetta che prevede la cottura in acqua e aceto e ho dovuto buttare tutto! :(\nEMMA 27 settembre 2010 05:24\nla cottura in acqua e aceto è riservata ai veri esperti. bastano 20 secondi in più e si disfano tutte...anche a me in passato è capitato come a te farfallina... comunque io le faccio e rifaccio come in ricetta e son sempre buone...ultimo vasetto finito ieri :-))\npaolad2007 9 ottobre 2010 04:12\nciao anche io le faccio cosi le melanzane ma anche le zucchine sono squisite\nAnonimo 2 giugno 2011 11:08\nCiao Emma finalmente la ricetta giusta x le melanzane sott olio ..... Sei una galla!!! Debora da genova\nAnonimo 11 giugno 2011 14:42\npaulo(bondearte) 20 giugno 2011 17:59\nCredo che questa ricetta deve essere molto gustosa,\nCercherò di farlo qui a casa:))\nMarco da Roma 13 agosto 2011 15:13\nHey Emma complimenti a Te e alla Nonna, queste melanzane sono buonissime, una delizia, degne della Tua bravura. Complimenti!!!\nSe hai qualche altra chicca, daccela.\nMarco da Roma.\nMaria 14 agosto 2011 01:25\nHo trovato la tua ricetta semplice e veloce, queste melanzane devono essere proprio gustose, proverò sicuramente!\nAnonimo 21 agosto 2011 04:51\nAnche agli ometti piace fare queste cosine. Ricetta sperimentata con successo! Grazie Emma\ncarpediemSARA 22 agosto 2011 10:48\nHo appena stampato la ricetta!\nI prossimi giorni le faremo, poi ti dico come sono venute! ;) ma sicuramente saranno buonissime, grazie!**\nAnonimo 27 agosto 2011 07:00\nAppena "invasettate" il profumo è mooooolto invogliante, non so se resisterò una setimana!!!\nAnonimo 6 settembre 2011 13:02\nGrazie Emma!Girovagavo tra i blog di cucina in cerca di consigli su come conservare le melazane che la mia vicina mi ha regalato in quantità industriale!\nSe ti va ti aspetto sul mio blog di cucina inaugurato da poco..\nteresa 26 settembre 2011 01:02\ngrazie emma vado ad eseguire\nLe dosi da te riportate sono riferite solo per 4 melanzane, cioè per fare solo un vaso?\ngraziella 8 dicembre 2011 03:20\nOttima ricetta. Mi erabno avanzate delle melanzane in frigo e ora le ho messe sotto sale. Credo che seguirò la tua ricetta.\nAnonimo 26 febbraio 2012 09:22\nbrava!!!!semplice ma buona!!!\nAnonimo 9 giugno 2012 03:59\nciao a tutti, mi chiamo vittoria e abito a casablanca, in marocco e preparo le nostre schisitezze per i miei amici marocchini che sono islmici e non posso usare l'aceto di vino. qua esiste una cosa francese che si ciama vinagre che loro consumano abituamente ed e' composta da limone ed alcol puro pensate che potrebbe andare bene? o che alternativa mi proponete ?? grazie vittoria\nAnonimo 30 luglio 2012 04:09\nvittoria, usa l'aceto di mele\nfunziona benissimo per i sott'olio\nAnonimo 7 agosto 2012 16:14\nCiao Emma,io in cucina non sono granché ma con le tue melanzane ho fatto un figurone ( mangiate come contorno alla mozzarella di bufala doc!!!). Ora anche mia sorella, grande cuoca, mi ha chiesto la tua ricetta. Grazieeeee,\naborto interno (1)\nacquistare un cavallo (1)\naprire un negozio abbigliamento (1)\nbi test (1)\ncompleto sposo su misura (1)\ncontatore visite (1)\ngravidanza interrotta (1)\nGUIDA alle nozze (1)\ninsalata russa (3)\nlibretto messa (2)\nmamme sole (1)\nmanuale per organizzare matrimonio (1)\nMatrimonio e battesimo rito unico (1)\nProblemi di peso (1)\nsalvare un cavallo (1)\nsartoria su misura (1)\nscarpe su misura (1)\nsecondo figlio (1)\nStrumenti per valutare la sua crescita (2)\nLandini: il Fascismo non è idea ma un Crimine\nSWEET DREAMING CAT\nVenezia, manifesta No Grandi Navi\nPerchè uso CleanMyMac e perchè lo consiglio a chi ha un Mac\nBeautiful Girl with Concepts and Future Cars\nEl Podcast Terremoto\nUn Mondo Incantato...La Fata dell'Alba..\nThe Perfect Easter Dress!\nTemplate di BudTerenceFe.tk\nPer chi è diventato lettore fisso qui...\nIscriviti a èmmamma\nPREPARARE LO YOGURT IN CASA SENZA YOGURTIERA\nNON COPIARE - NON PRELEVARE FOTO


IngForum •Leggi argomento - Ingegneria fluidodinamica\nOggi è giovedì 16 luglio 2020, 16:59\nOggetto del messaggio: Ingegneria fluidodinamica\nInviato: sabato 29 dicembre 2018, 14:52\nIscritto il: sabato 29 dicembre 2018, 14:03\nl'anno scorso ho ripreso a studiare un corso di laurea triennale in ingegneria edile.\nOra sto svolgendo l'erasmus per migliorare l'inglese, in particolare quello tecnico.\nA dicembre 2019 dovrei laurearmi e a 32 anni sarò ingegnere.\nHo una forte curiosità, mi piace la matematica e soprattutto la fisica. Sono appassionato di architettura e mi piace concentrarmi sull'implementazione.\nSto valutando due opzioni:\n- tirocinio post-laurea con inserimento nel mondo del lavoro\n- un corso di laurea magistrale affiancato da una attività lavorativa (ho lavorato molto nella vita, anche studiando e riconosco che non è facile ma si può fare)\nQuali aziende e università sono specializzate nell'ambito di studi in oggetto (titolo messaggio)?\nMi piacerebbe avere opzioni sia sull'Italia che l'estero, amo viaggiare.\nOggetto del messaggio: Re: Ingegneria fluidodinamica\nInviato: sabato 29 dicembre 2018, 18:07\nnon so darti indicazioni, ma, siccome ti piace anche l'architettura, vedo che uno dei problemi molto attuali è quello del vento in ambito urbano (o in generale le sue azioni sulle costruzioni) sia dal punto di vista statico che da quello termico\nInviato: lunedì 7 gennaio 2019, 18:25\nE' un ottimo inizio!


Primo impegno post-ZERO1 per James Raideen negli USA | Zona Wrestling\nHome News Altro Primo impegno post-ZERO1 per James Raideen negli USA\nPrimo impegno post-ZERO1 per James Raideen negli USA\nIeri James Raideen ha combattuto il suo primo match negli USA dal licenziamento dello scorso Giugno in ZERO1.\nRaideen ha combattuto nello show della Full Impact Pro (FIP) "Declaration Of Independence 2014", battendo Jack Gallow; per Raideen è il primo match dallo scorso 30 Marzo, quando combattè per l'ultima volta in ZERO1 perdendo lo ZERO1 World Heavyweight Title a favore di Kohei Sato.\nRicordiamo che dietro ai motivi del suo licenziamento ci sarebbe, secondo la versione rilasciata dallo stesso lottatore, interessi manifestati da WWE e TNA per fargli fare dei Tryout di prova; secondo le voci invece arrivate dalla ZERO1, all'origine del suo licenziamento sembra esserci stato numerosi problemi di backstage, fra cui sembra anche presunte molestie sessuali ai danni di una ragazza.


Autore: William Bellamy, Microsoft Principal Escalation Engineer\nBryan Lamos, Microsoft Senior Program Manager, qualità prodotti\nKevin Williamson, Microsoft Senior Escalation Engineer, supporto per sviluppatori Azure\nPranay Doshi, Microsoft Senior Program Manager, servizi di produzione Azure\nTom Christian, Microsoft Senior Escalation Engineer, supporto per sviluppatori Azure\nLa priorità di base di Microsoft è quella di consentire ai clienti di Azure di mantenere operative e in esecuzione le proprie applicazioni. I contratti di servizio di Azure definiscono una disponibilità del 99,95% di connettività esterna quando si distribuiscono due o più istanze di ruolo. La connettività esterna garantisce tuttavia la possibilità di raggiungere l'applicazione dall'esterno dei data center Microsoft, situazione diversa rispetto alla disponibilità di un sito operativo. Alla maggior parte dei servizi Azure sono associate più dipendenze, ad esempio SQL Azure, memorizzazione nella cache, rete per la distribuzione di contenuti, risorse interne (tramite Azure Connect) e così via. Un comportamento non corretto di una di tali dipendenze può provocare un funzionamento non previsto del servizio Azure.\nNel presente documento vengono descritte le diverse modalità di risoluzione dei problemi e gli approcci consigliati per la progettazione e lo sviluppo di applicazioni più compatibili con la piattaforma Azure. Quando (e non se) si verifica un problema, il fattore tempo è fondamentale. Una pianificazione corretta consente di trovare e risolvere i problemi senza che sia necessario contattare Microsoft per richiedere supporto tecnico. L'approccio consigliato nel presente documento accelera inoltre la risoluzione dei problemi che richiedono l'intervento di Microsoft.\nIl presente documento è destinato a un pubblico di tecnici software, ovvero progettisti e architetti software, professionisti IT, integratori di sistemi, sviluppatori e tester che progettano, compilano e distribuiscono soluzioni Azure. Si presuppone una conoscenza di base del processo di sviluppo delle applicazioni Azure, ad esempio la terminologia e i diversi componenti dell'ambiente di sviluppo e di runtime di Azure. Si presuppone inoltre che vengano seguite le linee guida di base per Azure, ad esempio l'uso della versione più recente di Azure SDK e l'esecuzione di test sulle modifiche del codice prima della distribuzione in produzione.\nIl documento è organizzato in due sezioni:\nPanoramica delle risorse di diagnostica di Azure:\nProcedure consigliate per progettazione, sviluppo e distribuzione compatibili\nAttività preliminari allo sviluppo dell'applicazione\nProgettazione e monitoraggio in base alla modalità di errore immediato\nOperazioni da eseguire quando si verifica un problema\nPanoramica delle risorse di diagnostica di Azure\nProgettazione di servizi Azure più supportabili\nRiepilogo e creazione di applicazioni Azure più compatibili\nAppendice B: esempio di codice per un ruolo Web\nAppendice C: esempio di codice per un ruolo di lavoro\nAppendice D: ServiceDefinition.csdef\nAppendice E: ServiceConfiguration.Local.cscfg\nAppendice F: diagnostics.wadcfg\nAppendice G: configurazione predefinita\nNessun sviluppatore si aspetta che la propria applicazione non funzioni una volta distribuita in produzione. Anche se l'impegno messo in atto per testare il codice durante lo sviluppo in modo che sia abbastanza affidabile per essere eseguito senza errori mentre si passa al progetto successivo è notevole, sfortunatamente talvolta il codice non funziona in modo corretto. In un ambiente distribuito gli errori di entità minore possono diventare estremamente gravi a causa delle complessità inerenti alla separazione dei componenti dell'applicazione. Per questo motivo è necessario predisporre una strategia di registrazione e di traccia nell'applicazione fin dall'inizio. Idealmente, tale strategia include l'esecuzione del provisioning per effettuare modifiche dinamiche senza la necessità di ricompilare o ridistribuire il tipo o il volume della registrazione a livello di un componente. La disponibilità di una grande quantità di log non garantisce una risoluzione rapida né una quantità maggiore è necessariamente migliore perché un numero elevato di dati richiede molto tempo per la decrittazione e potrebbe potenzialmente rallentare le prestazioni dell'applicazione. La registrazione modificabile controlla sia le dimensioni che il costo di archiviazione dei dati di log.\nLe applicazioni distribuite come quelle eseguite nella piattaforma Azure sono costituite da più componenti che interagiscono tra loro quando l'utente usa l'applicazione. Tramite una registrazione coerente e frequente del flusso del codice con una speciale attenzione rivolta alle chiamate ai servizi esterni, chiunque è virtualmente in grado di seguire il flusso di esecuzione dell'applicazione. Questo aspetto può essere di importanza fondamentale tra un anno o due quando si verifica un problema in produzione. Idealmente il livello di registrazione deve essere modificabile nel file ServiceConfiguration.cscfg in modo che sia possibile cambiarlo senza eseguire una ridistribuzione.\nDurante lo sviluppo è conveniente usare una compilazione di debug per ottenere la quantità massima di informazioni sugli errori. Gli sviluppatori in genere aggiungono istruzioni di debug e talvolta una qualche forma di registrazione di errori. È necessario tuttavia tenere presente che le istruzioni di debug vengono rimosse nella compilazione di produzione e questo può rappresentare un aspetto negativo quando si verifica un problema. La maggior parte dei clienti non desidera infatti eseguire la ridistribuzione con una compilazione di debug per risolvere un problema in produzione. Mike Kelly pone l'accento su quattro tipi di output di dati diagnostici che gli sviluppatori devono configurare:\nOutput di debug - Solo in modalità debug la compilazione include istruzioni Assert\nTraccia - Output che registra il flusso di controllo durante l'esecuzione\nRegistrazione eventi - Eventi principali\nRegistrazione errori - Situazione eccezionale o pericolosa\nPer sfruttare i livelli di traccia diversi, molti dei messaggi di debug devono essere realizzati in istruzioni di traccia. Diagnostica Azure consente inoltre di configurare la diagnostica e di disabilitare i trasferimenti in modo che sia possibile controllare il momento in cui le informazioni vengono scritte nell'archiviazione permanente.\nNelle sezioni seguenti vengono descritte alcune risorse per la risoluzione dei problemi disponibili agli sviluppatori che compilano applicazioni in Azure.\nPrima di esaminare Azure, esaminiamo il processo di risoluzione dei problemi corrente per applicazioni Windows Server. Quando si verifica un problema in fase di produzione, gli sviluppatori in genere esaminano i log. I log IIS e i registri eventi sono attivati per impostazione predefinita e rimangono invariati anche dopo le operazioni di riavvio (purché non si verifichi un errore del disco).\nLo stesso processo si applica a un'applicazione Azure se Desktop remoto è abilitato dato che gli sviluppatori possono connettersi a ogni istanza per raccogliere dati di diagnostica. Per effettuare la raccolta, è possibile copiare i log nell'archiviazione o configurare RDP in modo che sia possibile copiare i log nel computer locale. Questo processo può richiedere molto tempo e non viene eseguito in modo corretto se viene ricreata l'immagine dell'istanza, operazione che determina l'avvio di un ruolo di lavoro o di una nuova versione del Web, priva naturalmente di tutti i log precedenti. Un'immagine può essere ricreata nel caso di un aggiornamento del sistema operativo dell'host o della macchina virtuale guest e tale operazione è normale nell'architettura di Azure.\nDiagnostica di Azure\nAzure SDK 1.0 include funzionalità per la raccolta di dati diagnostici e la relativa archiviazione in Azure, denominate collettivamente Diagnostica Azure. Questo software, basato sul framework Event Tracing for Windows (ETW), soddisfa due requisiti di progettazione introdotti dall'architettura a scalabilità orizzontale Azure:\nSalvare i dati di diagnostica che potrebbero essere persi durante una ricreazione dell'immagine dell'istanza.\nFornire un repository centrale per la diagnostica da più istanze.\nLo spazio dei nomi Microsoft.WindowsAzure.Diagnostic estende lo spazio dei nomi System.Diagnostics in modo che sia possibile usare il framework ETW in un'applicazione Azure.\nDopo aver incluso Diagnostica di Azure nel ruolo (file ServiceConfiguration.cscfg e ServiceDefinition.csdef), tale funzionalità raccoglie i dati di diagnostica da tutte le istanze del ruolo specifico. I dati possono quindi essere usati per il debug, la risoluzione dei problemi, la valutazione delle prestazioni, il monitoraggio dell'uso delle risorse, l'analisi del traffico, la pianificazione della capacità e il controllo. I trasferimenti nell'account di archiviazione di Azure per la persistenza possono essere pianificati o su richiesta.\nDiagnostica di Azure modifica il paradigma server in quattro modi importanti:\nLa diagnostica deve essere abilitata al momento della creazione dell'applicazione.\nPer visualizzare i risultati di diagnostica, sono necessari passaggi e strumenti specifici.\nGli arresti anomali determineranno la perdita dei dati diagnostici se questi non sono scritti in un archivio durevole (Archiviazione di Azure anziché nelle singole istanze).\nL'archiviazione diagnostica comporta un costo mensile se avviene in Archiviazione di Azure.\nL'aspetto relativo al costo è di particolare importanza perché uno dei vantaggi chiave della piattaforma Azure è la riduzione dei costi. L'unico modo per eliminare il costo legato all'uso di WAD è attualmente quello di lasciare i dati nella macchina virtuale. Questa soluzione può funzionare in una distribuzione di dimensioni non elevate, ma è impraticabile in presenza di numerose istanze. Di seguito vengono indicati alcuni modi possibile per ridurre l'impatto finanziario.\nVerificare che l'account di archiviazione si trovi nello stesso data center dell'applicazione. In caso contrario, scegliere in modo opportuno l'intervallo dei trasferimenti pianificati. Tempi di trasferimento più brevi aumentano la rilevanza dei dati, ma tale compromesso potrebbe non essere sufficiente per giustificare l'ulteriore larghezza di banda e il sovraccarico di elaborazione.\nCopiare e cancellare periodicamente i dati di diagnostica da Archiviazione di Azure. I dati di diagnostica transiteranno nell'archiviazione di Azure, senza risiedervi inutilmente. Per effettuare questa operazione, sono disponibili strumenti diversi, Monitoring Pack di System Center per Azure, Azure Diagnostics Manager di Cerebrata e i cmdlet di PowerShell per Azure.\nScegliere solo dati di diagnostica necessari per risolvere i problemi e monitorare l'applicazione. Oltre a determinare costi significativamente più elevati, l'acquisizione di un numero troppo elevato di dati può rendere più difficile la risoluzione dei problemi.\nControllare la raccolta e le dimensioni dei dati di diagnostica implementando un'opzione a richiesta nell'applicazione.\nUsare il livello di registrazione (dettagliato, informativo, di avviso o di errore) in modo che tutte le informazioni siano disponibili, quindi usare la configurazione di WAD post-distribuzione per raccogliere in dati in modo selettivo.\nL'archiviazione di Azure è la base di ogni applicazione compatibile e idealmente questa funzionalità dovrebbe essere configurata e attiva per ogni applicazione.\nAnalisi archiviazione di Azure consente di registrare e generare dati di metrica per un account di archiviazione. È possibile usare tali dati per tenere traccia delle richieste di archiviazione, analizzare le tendenze di uso ed eseguire la diagnostica dei problemi relativi all'account di archiviazione. Risorse di SQL Azure\nPer scrivere codice SQL Azure compatibile, è fondamentale esaminare i codici restituiti e verificare di disporre di un codice tentativi affidabile per gestire gli errori.\nMonitoring Pack di Microsoft System Center per applicazioni Azure\nQuesto Monitoring Pack permette di usare Microsoft System Center Operations Manager per monitorare la disponibilità e le prestazioni delle applicazioni Azure:\nIndividuazione di applicazioni Azure.\nRestituzione dello stato di ogni istanza del ruolo.\nRaccolta e monitoraggio di informazioni sulle prestazioni.\nRaccolta e monitoraggio di eventi di Windows.\nRaccolta e monitoraggio dei messaggi di traccia di .NET da ogni istanza del ruolo.\nGestione dei dati su prestazioni ed eventi e dei dati di traccia di .NET Framework dall'account di archiviazione di Azure.\nModifica del numero delle istanze del ruolo.\nMicrosoft System Center Operations Manager 2007 rappresenta la soluzione ottimale per monitorare l'integrità di un'applicazione Azure.\nAttualmente Azure non fornisce una soluzione completa che consenta ai clienti di monitorare e gestire il proprio servizio ospitato. Per informazioni sulle funzionalità di rete, speedtest.net fornisce uno strumento che misura i tempi, la larghezza di banda e la qualità complessiva della connessione. Quando si usa Azure, può essere utile sfruttare un certo numero di strumenti disponibili. L'elenco seguente non vuole raccomandare né consigliare alcuno strumento d terze parti specifico.\nCmdlet di PowerShell per Azure\nIl modo migliore per gestire i problemi di diagnostica in modalità remota è quello di usare i cmdlet di PowerShell per Azure. I cmdlet si basano sulle API di gestione e di diagnostica di Azure e il codice sorgente completo è disponibile tramite il progetto CodePlex in modo che le API sottostanti siano più facilmente comprensibili. La versione 2.0 consente di configurare, scaricare ed esaminare tutti gli aspetti di Diagnostica Azure. Nel blog di Michael Washam vengono forniti alcuni script di esempio.\nMonitoraggio della rete: AlertBot, Gomez, Keynote, Pingdom\nLa soluzione di gestione delle prestazioni delle applicazioni Gomez di Compuware, Keynote, Pingdom e AlertBot sono soluzioni che consentono di monitorare l'applicazione Azure dall'esterno. verificandone la disponibilità e ottimizzando le prestazioni. Alcuni servizi, ad esempio Pingdom, consentono l'invio di una notifica tramite e-mail o SMS o tramite uno strumento sul desktop quando viene rilevato un errore. Per essere eseguito in modo corretto, questo tipo di monitoraggio deve simulare le operazioni effettuate da un utente perché talvolta un ruolo Web potrebbe visualizzare la home page senza essere completamente funzionale.\nPer usare lo strumento, è necessario scaricare il codice relativo e aggiungerlo alla propria distribuzione come attività di avvio. Lo strumento presenta il vantaggio di non dover archiviare i log nell'account di archiviazione dell'utente con una conseguente riduzione dei costi di monitoraggio.\nAzure Diagnostic Manager di Cerebrata è un client basato su per la gestione di Diagnostica Microsoft Azure che consente di visualizzare o scaricare i log raccolti da tale funzionalità. È inoltre possibile gestire la configurazione di WAD, mentre un dashboard consente di monitorare le prestazioni in tempo reale.\nStrumenti di esplorazione dell'archiviazione di Azure\nEsistono molti modi per esplorare gli archivi di Azure e il team di Archiviazione di Azure ha realizzato un elenco di strumenti di esplorazione dell'archiviazione. Alcuni di tali strumenti consentono di visualizzare file di WAD e file di Analisi archiviazione di Azure. Nella pagina relativa allo strumento di esplorazione per l'archiviazione BLOB di Azure nel sito CloudBerry Lab è disponibile un'interfaccia utente che consente di abilitare direttamente Analisi archiviazione nell'applicazione facendo clic sul pulsante relativo alle impostazioni di archiviazione.\nMicrosoft Visual Studio 2010 Ultimate contiene IntelliTrace, che può essere abilitato per eseguire il debug di applicazioni prima della distribuzione in produzione. IntelliTrace supporta applicazioni ASP.NET e WCF. IntelliTrace non è supportato quando viene abilitato in un servizio di produzione, ma può essere usato per ottenere le eccezioni per un'applicazione dopo la distribuzione in Azure. Il post del blog di Jim Nakashima descrive come usare IntelliTrace per eseguire il debug dei Servizi cloud di Azure. AVIcode\nIn seguito all'acquisto da parte di Microsoft, AVIcode ora fa parte di Microsoft System Center. Grazie a una serie completa di funzionalità di monitoraggio delle applicazioni, AVIcode consente di verificare le prestazioni delle applicazioni .NET.\nFiddler è un proxy di debug Web che registra tutto il traffico HTTP o HTTPS tra il computer in uso e Internet. Fiddler consente di controllare il traffico, di impostare i punti di interruzione e di gestire i dati in ingresso e in uscita e risulta particolarmente utile per la risoluzione dei problemi di Archiviazione di Azure.\nPer usare Fiddler nell'infrastruttura di sviluppo locale, usare ipv4.fiddler anziché 127.0.0.1:\nAvviare il servizio nell'infrastruttura di sviluppo.\nAccedere all'indirizzo http://ipv4.fiddler:/. Fiddler dovrebbe tenere traccia della richiesta.\nPer usare Fiddler per l'archiviazione per sviluppo locale, è necessario modificare il file di configurazione del servizio per puntare a Fiddler:\nAprire il file ServiceConfiguration.cscfg e modificare la stringa di connessione in Value=“UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler”\nAvviare il servizio. Fiddler dovrebbe tenere traccia di ogni richiesta di archiviazione.\nProfilatura delle prestazioni\nÈ possibile profilare un'applicazione Azure quando viene eseguita in Azure per individuare eventuali problemi di prestazioni. Quando si pubblica l'applicazione Azure da Visual Studio, è possibile scegliere di profilare l'applicazione e selezionare le impostazioni di profilatura richieste.\nVM Assistant di Azure\nLo strumento VM Assistant è un progetto CodePlex che consente di risparmiare tempo nella diagnosi di problemi grazie alla raccolta di tutti i dati rilevanti in un'unica posizione quando si usa Desktop remoto in un'istanza. Il pulsante relativo all'integrità della macchina virtuale consente di visualizzare lo stato corrente dell'istanza.\nNel caso di soluzioni basate sul cloud, per i progettisti e gli sviluppatori software è più importante prepararsi ai problemi in fase di progettazione rispetto al caso di software preconfezionato tradizionale distribuito in server di un data center aziendale. In questa sezione vengono illustrati alcuni scenari specifici del cui adattamento nel cloud sono responsabili gli sviluppatori e vengono fornite indicazioni per risolvere rapidamente eventuali problemi.\nLa differenza fondamentale rispetto a una distribuzione basata su server è l'impossibilità di accedere all'hardware del server. Nel componente Azure SDK 1.3 è stata inclusa la possibilità di usare Servizi Desktop remoto per accedere ai ruoli di Azure. L'uso del componente SDK più recente garantisce pertanto l'esperienza migliore. Per creare un servizio Azure supportabile, è necessario innanzitutto abilitare Desktop remoto. Questo passaggio può essere effettuato solo prima della distribuzione.\nUno dei passaggi necessari per abilitare Desktop remoto è rappresentato dalla scelta di un nome utente, di una password e di una data di scadenza dell'account. Questi tre elementi possono essere modificati nel portale di gestione di Azure e questa possibilità risulta particolarmente utile quando si dimentica la password impostata mesi prima al momento della prima distribuzione del servizio. Quando si fa clic sul pulsante Configura nel portale per modificare uno dei tre parametri, in genere viene visualizzata la sequenza Aggiornamento in corso, Attesa dell'host, Aggiornamento ruolo completato. Attesa dell'host, Pronto. Tale sequenza indica che il ruolo ha ricevuto l'evento di modifica e può gestirlo. I clienti possono effettuare la sottoscrizione agli eventi RoleEnvironment e successivamente, quando ricevono l'evento RoleEnvironment.Changing, possono accettare le modifiche e continuare l'esecuzione (impostazione predefinita) oppure portare l'istanza offline, applicare le modifiche e tornare online (e.Cancel = true).\nSe nel codice è previsto il riciclo del ruolo quando si verificano eventi di modifica, tutte le istanze di tutti i ruoli nel servizio ospitato specifico vengono riciclate. I servizi con più istanze per ruolo non subiranno tempi di inattività a causa dell'architettura del dominio di aggiornamento, ma le prestazioni potrebbero diminuire poiché ogni dominio viene riciclato. Un aspetto ancora più importante è legato a un problema che si ripresenti solo una volta al mese, perché in tal caso si perde la possibilità di acquisire lo stato dell'istanza. Si consiglia pertanto di verificare che sia abilitata una connessione a Desktop remoto con credenziali note, sicure e non scadute.\nSuccessivamente, è necessario effettuare un test per verificare che la connessione funzioni. A tale scopo, fare clic sul pulsante Connetti nel portale. Nella maggior parte dei casi è necessario conservare una copia del file RDP in modo che sia possibile modificare la sezione Risorse locali per includere i dischi locali. In questo modo sarà possibile spostare facilmente i file da e nell'istanza. Per eseguire questa operazione, fare clic sulla scheda Risorse locali, quindi sul pulsante Altro. Le impostazioni di connessione nella scheda Generale consentono di salvare le impostazioni dell'utente in un file RDP.\nCome risolvere i problemi sulla macchina virtuale\nDopo aver effettuato la connessione a un'istanza, cosa è necessario cercare? Se si risolvono i problemi relativi a un ruolo che non si riesce ad avviare, vedere questo articolo in MSDN. È disponibile un eccellente post del blog di Kevin Williamson in cui sono contenute informazioni generali sulla posizione dei file di log e sui processi di cui eseguire il debug. È inoltre possibile installare VM Assistant per esaminare tutti i file di log e ottenere informazioni utili sulla propria istanza nonché installare strumenti diversi, ad esempio Network Monitor o Fiddler, per monitorare la rete. Uno dei test più semplici consiste nell'eseguire Internet Explorer nella propria istanza e connettersi al proprio sito Web per visualizzare i dettagli relativi all'eccezione.\nDebug di un Hosted Web Core\nSe si esegue un ruolo Hosted Web Core, nella macchina virtuale è disponibile solo una finestra di comando ed è pertanto necessario aprirne una nuova. A tale scopo, eseguire il comando start dal prompt dei comandi per evitare un'esperienza Windows Server completa. Di seguito vengono elencati alcuni comandi di base:\nStart - Apre una nuova finestra di comando explorer - Apre Esplora risorse eventvwr - Apre il visualizzatore del registro eventi taskmgr - Apre Gestione attività start iexplore - Esegue Internet Explorer services.msc - Apre Service Manager control - Apre il Pannello di controllo certmgr.msc - Apre lo snap-in Gestione certificati\nregedit - Apre l'editor del Registro di sistema shutdown /r /t 0 - Riavvia l'istanza della macchina virtuale Avvia Gestione attività - Utile se si perde il prompt dei comandi ed è necessario avviarne uno nuovo (in Gestione attività passare a File -> Esegui -> Cmd)\nDesktop remoto è la base di un servizio Azure supportabile, ma presenta alcune limitazioni quando il numero di ruoli e di istanze aumenta. Può risultare difficile, ad esempio, conoscere l'istanza a cui è necessario connettersi quando il numero di istanze supera 100. L'uso di questo metodo di risoluzione dei problemi può aumentare effettivamente il tempo necessario per recuperare il proprio sito se non si conoscono gli elementi da cercare e la posizione in cui cercarli.\nAbilitare Desktop remoto su ogni ruolo durante la distribuzione.\nImpostare una password complessa e verificare che le credenziali non scadano.\nVerificare l'accesso per assicurarsi che funzioni prima che si verifichi un problema.\nSalvare un file RDP per la connessione.\nPer usare Diagnostica di Azure, sono necessarie quattro attività fondamentali:\nConfigurazione di WAD\nConfigurazione della raccolta dati\nStrumentazione del codice\nL'architettura di Diagnostica di Azure prevede innanzitutto di raccogliere i dati sull'istanza e in seguito di archiviarli in modo permanente in Archiviazione di Azure. È necessario pertanto accedere al portale di gestione di Azure per creare un account di archiviazione, ad esempio logpersonali. È consigliabile creare l'account di archiviazione nella stessa posizione geografica in cui si trova l'applicazione Azure per evitare di sostenere costi di larghezza di banda esterna e ridurre la latenza.\nUna delle maggiori funzionalità di sviluppo di Strumenti di Azure per Visual Studio versione 1.4 (agosto 2011) e versioni successive è la possibilità di disporre di file di configurazione diversi (ServiceConfiguration.cscfg) per l'ambiente locale e il cloud. Più configurazioni di servizio possono risultare molto utili per la diagnostica perché semplificano l'uso gratuito dell'emulatore di archiviazione per eseguire test locali mantenendo nel contempo un file di configurazione separato per la produzione. In genere, le applicazioni non si avviano quando vengono pubblicate in Azure se si dimentica di modificare una stringa di connessione contenente UseDevelopmentStorage=true infalse.\nVisual Studio semplifica l'abilitazione della diagnostica durante la fase di test tramite l'uso del pulsante Usa emulatore di archiviazione di Azure:\nDopo aver testato l'applicazione e aver verificato che sia pronta per la pubblicazione, è necessario disporre di un account di archiviazione da configurare per il cloud (ServiceConfiguration.Cloug.cscfg). David Makogon indica nel suo blog tre motivi per cui è opportuno disporre di un account di archiviazione specifico per la diagnostica separato da quello di archiviazione dei dati dell'applicazione:\nLa disponibilità di una chiave di accesso separata per la diagnostica consente di accedere ai log senza rischi per i dati dell'applicazione.\nLa presenza di più account di archiviazione non prevede alcun costo aggiuntivo perché i costi sono basati sulle dimensioni dei dati.\nLa disponibilità di un account separato consente di migliorare le prestazioni.\nA questo punto impostare la stringa di connessione:\nI valori AccountName e AccountKey sono disponibili nel portale di gestione nella sezione relativa agli account di archiviazione. AccountName è la prima parte dell'URL per gli endpoint di tabella e di archiviazione BLOB (la parte prima di ".table.core.windows.net"). AccountKey è la chiave di accesso primaria codificata a 64 bit per l'account di archiviazione.\nPer impostazione predefinita, solo i log di Azure sono abilitati anche se non archiviati in modo permanente. Di conseguenza, in seguito sarà necessario decidere la quantità di dati da raccogliere e il momento in cui trasferire i log. Queste decisioni non sono irrilevanti perché influenzano le prestazioni dell'applicazione e determinano i costi mensili correlati all'archiviazione.\nÈ necessario innanzitutto determinare lo spazio totale di archiviazione necessario per i dati raccolti da Diagnostica di Azure. Questo valore è limitato dalle dimensioni del disco in relazione alle dimensioni dell'istanza/macchina virtuale in uso e dalla proprietà OverallQuotaInMB della classe DiagnosticMonitorConfiguration. Se ad esempio il modello del servizio è stato configurato per usare dimensioni della macchina virtuale molto piccole, la quantità massima di spazio di archiviazione locale disponibile è di 20 GB. Per impostazione predefinita, la proprietà OverallQuotaInMB è impostata su 4 GB, pertanto lo spazio totale di archiviazione locale disponibile è di 16 GB, quantità che potrebbe non essere sufficiente per l'applicazione e i file temporanei. La proprietà OverallQuotaInMB imposta le dimensioni di un buffer circolare riscrivibile. D'altra parte, se nel sito Web è presente una quantità elevata di traffico e se sono stati configurati molti contatori delle prestazioni, i dati di diagnostica potrebbero venire sovrascritti soprattutto se non li si trasferisce periodicamente in un'archiviazione permanente.\nDopo che la macchina virtuale è stata impostata, può essere necessario disporre di una quantità di spazio maggiore di 4 GB. A tale scopo, è possibile aggiungere un elemento <LocalStorage> per DiagnosticStore con l'attributo sizeInMB impostato sulla nuova dimensione nel file ServiceDefinition.csdef e modificare il valore OverallQuotaInMB di conseguenza:\nQuando si imposta il valore dell'attributo cleanOnRoleRecycle su false, assicurarsi che la risorsa di archiviazione locale "DiagnosticStore" non venga eliminata nel momento in cui il ruolo viene riciclato. Per il codice completo del file ServiceDefinition.csdef, vedere l'Appendice D: ServiceDefinition.csdef. Questa impostazione non garantisce che i dati vengano conservati se si sposta l'istanza (per problemi hardware e così via). È importante ricordare che le impostazioni di diagnostica sono specifiche di un ruolo ed è pertanto necessario aggiungere una risorsa DiagnosticStore per ciascun ruolo singolarmente.\nIl calcolo delle dimensioni complessive dei dati di diagnostica configurati è estremamente importante perché Diagnostica di Azure non verrà eseguito in modo corretto se il totale supera il valore di OverallQuotaInMB. L'unico modo per visualizzare questo errore consiste nell'associare un debugger o nell'aggiungere un blocco try/catch al metodo OnStart. Se il codice catch scrive un evento, nel registro eventi dell'applicazione viene visualizzato un messaggio analogo al seguente:\nCome è possibile calcolare il totale delle quote secondarie richieste? A ogni tipo di raccolta elementi (registri eventi, contatori delle prestazioni e così via) è associato un buffer dei dati il cui valore predefinito è zero. La proprietà BufferQuotaInMB può essere lasciata sul valore predefinito zero, ovvero un valore minore di quello della proprietà OverallQuotainMB, oppure può essere impostata in modo esplicito. Il valore della proprietà OverallQuotaInMB deve essere minore della somma di tutti i valori delle proprietà BufferQuotaInMB.\nQuando viene raggiunta la quota massima, i dati meno recenti vengono eliminati man mano che vengono aggiunti nuovi dati. Questi criteri di eliminazione si applicano anche se è stato configurato un intervallo di trasferimento per il buffer. Dopo il trasferimento, i dati rimangono nell'archiviazione locale e vengono eliminati in base ai criteri precedenti.\nLe quote secondarie relative alle directory sono impostate su zero in modo da usare la parte rimanente della quota di archiviazione disponibile. Se si imposta un valore specifico, tale valore deve essere maggiore o uguale a quello delle altre quote perché deve essere sufficientemente grande da contenere i log IIS (ruolo Web) e i dump di arresto anomalo del sistema. Per impostazione predefinita, il valore della proprietà Directory.QuotaInMB è 1024 MB e di conseguenza se un dump di arresto anomalo del sistema è maggiore di un gigabyte non sarà possibile eseguirne la scrittura in modo corretto. I minidump rappresentano l'unico modo per ridurre le dimensioni dei dump.\nI file di dump completi contengono una memoria di processo (byte virtuali) al momento dell'arresto anomalo del sistema. Poiché è in esecuzione una versione di Windows a 64 bit, il limite superiore della memoria è costituito dalla memoria fisica del computer. Questo valore è disponibile nella colonna relativa alla memoria nella tabella delle dimensioni dell'istanza/macchina virtuale. Le dimensioni di un dump di arresto anomalo del sistema di un'istanza molto grande possono arrivare fino a 14 GB. Ovviamente questo è lo scenario peggiore, nel quale il processo usa tutta la memoria disponibile, ma è anche quello che si verifica quando si desidera acquisire il file di dump.\nUna volta stabilita la quantità di dati di diagnostica da raccogliere, è necessario determinare una strategia per archiviarli in modo permanente. Un'opzione potrebbe essere quella di non iniziare a raccogliere i dati fino a quando non è stato stabilito che si è verificato un problema. Questa opzione presenta tuttavia due aspetti negativi:\nCome si viene a conoscenza che si è verificato un problema? Anche se i clienti possono affidarsi alla segnalazione di un problema principale, come rilevare problemi più insidiosi come la perdita di memoria?\nQual è la linea di base prima che un problema inizi? L'applicazione usa costantemente l'80% della capacità della CPU o si tratta di un sintomo del problema?\nSorprendentemente, questa opzione è la più popolare perché non è soggetta a costi né richiede alcuna pianificazione o azione, anche se è senza dubbio l'opzione peggiore.\nLa seconda opzione prevede di configurare tutti i contatori necessari, ma di non archiviare in modo permanente i dati in Archiviazione di Window Azure. Quando si verifica un problema, è possibile esaminare i dati oppure avviare manualmente un trasferimento. Sebbene questa opzione sembri una soluzione ideale perché non è soggetta ad alcun costo fino a quando non si verifica un problema, in realtà presenta gli stessi aspetti negativi della prima opzione e il tempo di ripristino aumenta.\nLa terza opzione prevede di impostare le diverse proprietà ScheduledTransferPeriod su valori abbastanza piccoli per garantire che i dati di diagnostica non vengano sovrascritti nell'istanza, ma sufficientemente grandi da non influire negativamente sulle prestazioni dell'applicazione. Il periodo di trasferimento minore che è possibile impostare è pari a un minuto. Fortunatamente, qualsiasi valore inferiore viene arrotondato a 1, pertanto il salvataggio permanente non viene disattivato. Verificare pertanto che i dati di diagnostica vengano trasferiti prima che siano effettivamente necessari.\nUn problema comune che si verifica in numerosi esempi di codice è costituito dal fatto che il valore di ScheduledTransferPeriod è impostato su un minuto, condizione che può influire negativamente sulle prestazioni dell'applicazione in produzione. Negli esempi viene usato il valore minimo per consentire all'utente di verificare rapidamente il funzionamento. La maggior parte degli sviluppatori non desidera attendere 30 minuti per verificare che i log siano stati trasferiti. Per risolvere il problema, è possibile modificare sistematicamente la configurazione WAD dopo la distribuzione tramite uno degli Altri strumenti utili oppure aggiungere codice più un'impostazione al file ServiceConfiguration.cscfg sfruttando la possibilità di disporre di più file di configurazione del servizio citata in precedenza in questa sezione. Tale impostazione viene creata in modo analogo al seguente nel file ServiceConfiguration.Local.cscfg:\nNel file ServiceConfiguration.Cloud.cscfg l'impostazione è invece analoga alla seguente:\nIl codice del metodo OnStart e dell'evento RoleEnvironmentChanging è analogo al seguente:\nL'altra variabile che influisce sulla quantità di dati raccolti è il livello di registrazione. Una delle più importanti origini dati da cui eseguire la raccolta è il registro eventi dell'applicazione, che risulta particolarmente utile con il registro eventi di sistema. I registri eventi di sicurezza non sono disponibili in WAD. Le dimensioni di tali file possono essere modificate tramite i valori di filtro seguenti che specificano il livello delle voci di log:\nIl livello di registrazione è cumulativo, pertanto se il filtro è impostato su Warning verranno trasferite anche le voci impostate su Error e Critical. È possibile usare il metodo precedente per configurare livelli LogLevelFilter specifici per le configurazioni locali e cloud. Il file ServiceConfiguration.Local.cscfg è analogo al seguente:\nIl file ServiceConfiguration.Cloud.cscfg è analogo al seguente:\nIl codice consigliato può anche non soddisfare le esigenze dell'utente. Per coloro che non desiderano aggiungere alcun codice e preferiscono mantenere l'ultima configurazione nota anziché le impostazioni definite nel codice, è prevista un'altra soluzione.\nUso di un file di configurazione\nNel componente Azure SDK 1.3 è stata aggiunta la possibilità di inserire la configurazione in un file XML anziché scrivere codice. David Hardin sostiene che questo è il modo più efficiente per configurare la diagnostica per tutti i tipi di ruolo di Azure. Rispetto alla scrittura di codice, questo metodo presenta numerosi vantaggi:\nWAD viene avviato prima dell'esecuzione del metodo OnStart in modo che vengano rilevati eventuali errori nelle attività di avvio.\nEventuali modifiche apportate alla configurazione in fase di runtime verranno mantenute anche dopo un riavvio.\nViene avviato automaticamente un agente di diagnostica configurato senza la necessità di codice aggiuntivo che può generare un'eccezione e quindi il mancato avvio del ruolo.\nQuesto è l'unico metodo per ottenere diagnostica da un ruolo di macchina virtuale in versione beta.\nLe modifiche alla configurazione non richiedono la ricompilazione del codice.\nUn esempio del file diagnostics.wadcfg è disponibile nell'Appendice F: diagnostics.wadcfg. Il file di configurazione denominato diagnostics.wadcfg deve essere inserito nei percorsi seguenti ed è necessario verificare che l'opzione Copia in directory di output sia impostata su Copia sempre:\nPer i ruoli di lavoro, il file di configurazione si trova nella directory radice del ruolo.\nPer i ruoli Web, il file di configurazione si trova nella directory bin nella directory radice del ruolo.\nPer i ruoli di macchina virtuale in versione beta, il file di configurazione deve trovarsi nella cartella %Programmi%\_Azure Integration Components\_<NumeroVersione>\_Diagnostics dell'immagine server caricata nel portale di gestione di Azure. <NumeroVersione> è la versione di Azure SDK in uso. Nella cartella è presente un file predefinito che è possibile modificare o sovrascrivere con un file personalizzato.\nIl formato di tale file è descritto nel documento MSDN seguente. Il file con estensione wadcfg viene ignorato se è già presente una configurazione XML nel contenitore di archiviazione BLOB wad-control-container. È inoltre necessario verificare che ogni elemento del file sia corretto. In caso contrario, non verrà raccolto alcun dato di diagnostica.\nA questo punto è possibile decidere le informazioni da raccogliere.\nSe non si desidera usare un file di configurazione, il modo migliore per avviare la diagnostica è usare il metodo OnStart con un blocco try/catch. Il blocco garantisce la possibilità di gestire in modo efficiente un eventuale problema, evitando in tal modo che il ruolo si blocchi durante il riciclo. L'aspetto negativo dell'inserimento di codice nel metodo OnStart è la mancata possibilità di gestire tutte le eccezioni, pertanto durante l'operazione di riciclo il ruolo potrebbe entrare in un ciclo di cui è difficile eseguire il debug. In questo metodo invece l'istanza del ruolo è impostata sul valore Occupato e non è disponibile tramite il bilanciamento del carico di Azure. Se il metodo OnStart restituisce false o se si verifica un'eccezione, l'istanza del ruolo viene immediatamente arrestata. Se il metodo restituisce true, Azure avvia il ruolo chiamando il metodo Run.\nSe si esegue il wrapping del codice OnStart in un blocco try/catch, è possibile evitare che il ruolo entri in un ciclo, ovvero che nel portale di gestione il ruolo non sia mai nello stato di pronto, quando si verifica un'eccezione. Il codice catch può contenere una chiamata al metodo Trace.WriteLine (esempio MSDN) oppure è possibile inserire un errore nel registro eventi (blog sul debug in ASP.NET). Se si inserisce un errore nel registro eventi, è più semplice visualizzare il motivo per cui il ruolo non si avvia. Una lieve modifica a questo codice è stata proposta da Tom Christian e prevede la registrazione dell'eccezione nel registro eventi dell'applicazione come indicato di seguito:\nIl codice completo è disponibile nell'Appendice B: esempio di codice per un ruolo Web. Il metodo più potente per configurare la diagnostica consiste nell'usare sia un file di configurazione che codice che consenta di modificare dinamicamente la configurazione nel portale di gestione.\nOra che la diagnostica di Azure è configurata, è possibile iniziare a raccogliere dati. I dati che possono essere raccolti sono di cinque tipi:\nDump di arresto anomalo del sistema\nLa tabella seguente fornisce una panoramica dei dati raccolti localmente per impostazione predefinita e dei dati che è necessario configurare in modo esplicito.\nAbilitata, dati archiviati localmente, nessun trasferimento nell'archiviazione locale definito. Trasferimenti nella tabella di archiviazione WADDiagnosticInfrastructureLogsTable.\nLog specifici dell'infrastruttura di diagnostica. In genere non risultano molto utili.\nAbilitata, dati archiviati localmente, nessun trasferimento nell'archiviazione locale definito. Trasferimenti nella tabella di archiviazione WADLogsTable.\nLog System.Diagnostics.Trace disponibili nel codice dell'applicazione.\nOggetti BLOB wad-iis-failedreqlogfiles, wad-iis-logfiles e wad-crash-dumps vengono creati automaticamente per impostazione predefinita, ciascuno con la proprietà DirectoryQuotaInMB impostata su 1024 MB. È inoltre possibile configurare directory aggiuntive.\nI dati del log verranno trasferiti nell'intervallo di trasferimento definito da ScheduledTransferPeriod.\nDisabilitata. Quando i contatori vengono aggiunti, il nome della tabella di archiviazione è WADPerformanceCountersTable.\nI contatori delle prestazioni devono essere specificati in modo esplicito.\nDisabilitata. Quando i registri eventi vengono aggiunti, il nome della tabella di archiviazione è WADWindowsEventLogsTable.\nNessun oggetto DataSources viene specificato per i registri eventi di Windows.\nI minidump di arresto anomalo del sistema vengono raccolti in locale. È possibile abilitare dump completi. wad-crash-dumps è il nome creato nell'archiviazione BLOB.\nChiamare il metodo EnableCollection(true) per ottenere dump di arresto anomalo del sistema completi.\nDati di traccia delle richieste non riuscite di IIS 7.0\nDisabilitata. Quando tali dati vengono aggiunti, il nome dell'archiviazione BLOB è wad-iis-failedreqlogfiles.\nQuesto elemento deve essere abilitato nel file Web.config.\nDiagnostica di Azure non raccoglie dump di arresto anomalo del sistema in modo automatico. La sintassi è poco chiara, perché per raccogliere minidump è necessario aggiungere il codice seguente:\nIl codice per raccogliere dumo completi è analogo al seguente:\nCome indicato nella sezione relativa all'impostazione della proprietà Directory.QuotaInMB, se sono presenti dump completi è necessario allocare spazio di archiviazione locale e totale sufficiente per salvare un dump completo.\nI registri eventi rappresentano lo strumento migliore per trovare errori nelle applicazioni. Di seguito viene indicato come è possibile aggiungere eventi di sistema e dell'applicazione:\nVerranno raccolti solo gli eventi che si verificano dopo l'avvio di Diagnostica di Azure, aspetto che rende inutili i registri eventi per diagnosticare i problemi di avvio a meno che non si usi il metodo consigliato per avviare e configurare la diagnostica.\nÈ inoltre possibile applicare un filtro per raccogliere solo determinati eventi. Nel blog di Steve Marx viene descritto come creare una query XPath per ottenere solo le informazioni utili. Se ad esempio si usa la query XPath seguente con il metodo Add, vengono raccolti solo i messaggi WaAppAgent:\nI contatori delle prestazioni devono essere aggiunti in modo esplicito. La difficoltà nell'impostazione di tali contatori consiste nel fatto che il funzionamento non corretto di uno dei contatori si ripercuote su quello di tutti i contatori del ruolo specifico. Nella finestra di output dell'emulatore di calcolo viene visualizzato l'errore seguente:\nI ruoli Web e di lavoro possono usare più linguaggi. Per tutti i tipi di ruolo, questi sono i contatori delle prestazioni di base consigliati. Il nome del processo nell'esempio seguente (WaWorkerHost) deve essere modificato in WaIISHost per un ruolo Web. Il codice specifico per un ruolo di lavoro che non esegue codice .NET è disponibile in Appendice C: esempio di codice per un ruolo di lavoro:\nPer un ruolo Web o un ruolo di lavoro che esegue codice in linguaggio .NET, sono disponibili contatori aggiuntivi che devono essere monitorati. Anche in questo caso, il nome del processo nell'esempio seguente (w3wp) deve essere modificato in WaWorkerHost se il ruolo è di lavoro e in WaIISHost se si usa un ruolo Web in modalità IIS completa. I contatori delle prestazioni per un ruolo Web che esegue codice in linguaggio .NET sono disponibili in Appendice B: esempio di codice per un ruolo Web:\nLa stringa WaIISHost deve essere modificata in w3wp se non viene usata la modalità IIS completa. Come indicato in precedenza, il valore ScheduledTransferPeriod determina se e quando i contatori vengono archiviati in modo permanente.\nI ruoli Web di Azure vengono eseguiti in IIS con registrazione abilitata per impostazione predefinita e vengono scritti in formato W3C con codifica UTF-8 nella cartella delle risorse per l'applicazione (ad esempio, C:\_Resources\_directory\_c5c31518818e46569fa68f0809b5a6aa.fm_WebRole.DiagnosticStore\_LogFiles\_Web) con Aggiornamento file di registro impostato su Ogni ora. È presente un file di log per sito. Se si accede in modalità remota a una delle istanze e si apre Gestione Internet Information Services, è possibile visualizzare le impostazioni seguenti:\nLe opzioni di registrazione predefinite possono essere modificate per soddisfare le esigenze specifiche dell'utente. Lo stratagemma consiste nel fatto che tutte le modifiche dovranno essere incorporate in un'attività di avvio in modo che al riavvio di ogni istanza le modifiche non vadano perse. Per registrare solo errori, ad esempio, è possibile usare Appcmd.exe che fa parte di IIS7 in un'attività di avvio che contiene il comando seguente:\nTraccia delle richieste non riuscite\nSe si dispone di un ruolo Web, si desidera certamente raccogliere i log delle tracce delle richieste non riuscite (in precedenza buffering delle richieste non riuscite o FREB, Failed Request Buffering). Questa operazione viene eseguita nel file Web.config aggiungendo le righe seguenti alla sezione <system.webServer> in modo analogo al seguente:\nIn questo modo vengono registrati gli errori relativi a ogni richiesta che supera i 15 secondi o con codice di stato compreso tra 400 e 599 (elemento failureDefinitions). Una volta creato, il log FREB viene automaticamente archiviato in modo permanente.\nPuò essere opportuno inoltre raccogliere altri file scritti nell'istanza, in particolare file di agente guest. Tali file possono fornire informazioni sulle interazioni tra l'agente guest e il controller di infrastruttura di Azure. A tale scopo, è necessario impostare una directory che verrà copiata da Diagnostica di Azure:\nLa stessa avvertenza si applica qui in relazione alla situazione che si può verificare se la configurazione non riesce. Per eseguire il test nell'emulatore di calcolo, è necessario creare questa cartella e verificare che più ruoli non eseguano questo codice per evitare una violazione della condivisione. Questo errore non si verifica nella configurazione cloud perché ogni istanza è separata.\nRisoluzione dei problemi relativi a WAD\nOra che la configurazione è completata, è necessario eseguirne il test sia nell'emulatore di calcolo che nella distribuzione in Azure. Se i dati di diagnostica non vengono visualizzati, controllare gli elementi elencati di seguito.\nVerificare i BLOB nel contenitore BLOB wad-control-container nell'account di archiviazione di diagnostica. Il BLOB da cercare è quello denominato con <ID distribuzione>/<Nome ruolo>/<Istanza ruolo>, ad esempio 3981bcff0eb743ddb9b7574a8821e955/WebRole1/WebRole1_IN_0.\nAprire il file XML e verificare che sia configurato nel modo previsto. Se viene visualizzato <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes> per un'origine dati specifica, la diagnostica non è configurata per trasferire alcun dato.\nSe sono presenti più istanze e qualche istanza sta trasferendo dati di diagnostica a differenza di altre, confrontare i file XML per verificare che tutte le istanze siano configurate in modo corretto.\nSe si configura la diagnostica dopo la distribuzione e il funzionamento relativo si interrompe in modo casuale, la causa può essere il riciclo del ruolo o il riavvio dell'istanza. Quando un'istanza viene riavviata, le impostazioni di post-distribuzione personalizzate vanno perdute e viene usata la diagnostica configurata nel codice. Uno dei vantaggi principali correlati all'uso del file con estensione wadcfg è che la configurazione non viene sovrascritta al momento del riciclo del ruolo.\nVerificare i log nella tabella WADDiagnosticInfrastructureLogsTable nell'account di archiviazione di diagnostica. È possibile applicare un filtro in base all'ID distribuzione, ad esempio ID distribuzione uguale a 'bd9e149f76e8413aba8865c77326e449'. Cercare eventuali eccezioni o messaggi di errore che potrebbero indicare i motivi per cui i dati di diagnostica non vengono trasferiti.\nSe l'informazione Diagnostics.Trace non viene raccolta, verificare che DiagnosticMonitorTraceListener sia configurato nel file web.config o app.config. Il file è configurato per impostazione predefinita nei progetti cloud, ma talvolta può subire modifiche e di conseguenza le istruzioni di traccia non vengono raccolte dalla diagnostica.\nUn problema comune è rappresentato dall'esecuzione non corretta di query sull'archiviazione di diagnostica e di conseguenza non viene restituito alcun risultato e si presuppone che i dati di diagnostica non vengano acquisiti. Eseguire le query sulle tabelle di diagnostica, applicando filtri su ID distribuzione e verificare se i dati vengono trasferiti in modo corretto o meno. Gli errori relativi alle query si possono verificare in genere qualora non si applichi un filtro a ID distribuzione e non si seguano i token di continuazione.\nSe dopo la distribuzione l'istanza non si avvia, verificare che l'account di archiviazione configurato nel file ServiceConfiguration.cscfg non sia impostato su "UseDevelopmentStorage=true". Se si usa una versione di Strumenti di Azure per Visual Studio 2011 successiva ad agosto 2011, verrà visualizzato un messaggio di avviso. In caso contrario, è necessario usare RDP nell'istanza e verificare che il file di configurazione del ruolo si trovi nella cartella C:\_Config.\nQuando si è connessi all'istanza, è necessario inoltre verificare che DiagnosticsAgent.exe e MonAgentHost.exe siano in esecuzione. In tal caso, è possibile installare e collegare WinDBG per verificare se vengono generate eccezioni.\nÈ inoltre possibile controllare che i dati di diagnostica vengano scritti in locale. Per l'ambiente di sviluppo, il file con estensione tsf files viene scritto nella directory seguente:\nIn un'istanza in esecuzione i file vengono scritti nella directory seguente:\nPer leggere tali file, attualmente è necessario creare un caso di supporto tecnico e inviarli a Microsoft.\nSe sono presenti più istanze e solo alcune di esse non trasferiscono i dati di diagnostica in modo corretto, provare a ricreare l'immagine del ruolo nel portale di gestione. Questa soluzione deve essere usata come ultima risorsa per non perdere la possibilità di determinare la causa radice per cui si è verificato il problema.\nÈ probabile che i dati di diagnostica più importanti siano i messaggi di traccia che gli sviluppatori aggiungono al codice. I dati di sistema, infatti, possono restituire eccezioni o registrare messaggi di errore. È possibile tenere traccia persino di specifiche chiamate a sistemi dipendenti. La procedura consigliata consiste nell'aggiungere un messaggio di traccia durante la chiamata a un sistema dipendente che può non riuscire; ad esempio, a un servizio di autenticazione di terze parti.\nIl framework ETW associa un elemento TraceEventType a ogni evento:\nErrore irreversibile o arresto anomalo dell'applicazione\nProblema non critico che può indicare problemi più seri in futuro\nTraccia di debug (ad esempio informazioni dettagliate di flusso di esecuzione, parametri e così via)\nAvvio di un'operazione logica\nArresto di un'operazione logica\nDopo aver definito un piano per instrumentare il codice, è possibile aggiungere lo spazio dei nomi System.Diagnostics e successivamente i messaggi di traccia, in modo analogo al codice C# seguente:\nPoiché Azure è stato avviato per essere eseguito in modalità IIS completa (SDK 1.3), il codice dell'applicazione Web viene eseguito in un dominio di applicazione e in un processo diversi da RoleEntryPoint. Questo significa che i messaggi di traccia non vengono visualizzati nell'emulatore di calcolo a meno che non si aggiunga un altro listener di traccia al file Web.Config in Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener:\nPer applicazioni più complesse, la disponibilità di una metodologia EventId consente di filtrare i log in modo più efficiente e di risolvere pertanto i problemi in modo più rapido. Se si usa il metodo WriteLine di C#, EventId è sempre uguale a 0. Per specificare un oggetto EventId, è necessario usare il metodo TraceEvent, in cui l'elemento traceType è nella posizione indicata nella tabella seguente:\nI messaggi di traccia vengono archiviati in modo permanente nella tabella WADLogsTable. A ogni evento registrato, Azure associa automaticamente un timestamp, un conteggio (che fornisce un intervallo più dettagliato con una granularità di 100 nanosecondi) e informazioni sulla distribuzione, sul ruolo e sull'istanza del ruolo. In questo modo è possibile circoscrivere i log a istanze specifiche. Il messaggio viene archiviato in un formato XML analogo al seguente:\nIl livello corrisponde all'elemento TraceEventType. Nella tabella precedente si nota che il livello 3 corrisponde a Warning. Se non è specificato alcun elemento TraceEventType o se si usa Trace.WriteLine, il livello viene impostato su 5 (Verbose).\nNella maggior parte dei casi, la registrazione standard è sufficiente. Per tipi di registrazione più dettagliati, è possibile creare un listener di traccia personalizzato:\nEsempio di tecnologia di listener di traccia personalizzato\nScrittura di listener di traccia .NET\nInformazioni sulla classe TraceListener\nAzure Table Query è un progetto CodePlex di ruoli Web che consente di eseguire query su WADLogsTable tramite una query LINQ query.\nIl motivo per cui è opportuno raccogliere i dati di diagnostica è la possibilità di averli disponibili quando si verifica un problema. È pertanto importante verificare il funzionamento corretto di ogni elemento prima che il problema si verifichi, in modo analogo a come è necessario verificare che un backup dei dati funzioni correttamente. Questa esigenza comporta non solo la visualizzazione dei dati di diagnostica durante la fase di test dell'applicazione e la verifica periodica del funzionamento, ma anche la creazione di una linea di base in modo che sia possibile rilevare le prestazioni anomale quando si verificano.\nTutti i dati di Diagnostica di Azure vengono memorizzati nell'account di archiviazione specificato all'avvio di WAD. Per visualizzare tali dati, è possibile usare Esplora server di Visual Studio oppure uno dei numerosi storage explorers.\nL'oggetto BLOB wad-control-container contiene la registrazione dell'infrastruttura di diagnostica e consente di visualizzare se i dati vengono trasferiti da una determinata istanza. L'identità dell'oggetto BLOB è nella forma seguente:\nTale identità è divisa in tre parti:\nIl numero lungo rappresenta l'ID distribuzione - 0aef2b51ad1d49ef915dd41d3ca01f24\nNome ruolo - WorkerRole1\nNome istanza - WorkerRole1_IN_0\nQuando sono presenti più istanze, il suffisso in base zero viene incrementato, ad esempio WorkerRole1_IN_1 rappresenta la seconda istanza.\nNella tabella seguente viene indicata la posizione in cui ogni log viene scritto.\nFormato di Archiviazione di Azure\nLog di Azure generati dal codice\nÈ necessario aggiungere il listener di traccia al file web.config o app.config. I file vengono archiviati in WADLogsTable.\nLog di IIS 7.0\nSolo ruoli Web. Archiviati in un contenitore BLOB nel percorso wad-iis-logfiles\_<ID distribuzione>\_<nome ruolo Web>\_<istanza ruolo>\_W3SVC1.\nLog di Infrastruttura diagnostica Windows\nInformazioni sul servizio stesso di diagnostica. Archiviati nella tabella WADDiagnosticInfrastructureLogs.\nLog delle richieste non riuscite\nSolo ruoli Web. Abilitati tramite le opzioni di traccia nelle impostazioni system.WebServer nel file web.config. Archiviati in un contenitore BLOB nel percorso wad-iis-failedreqlogfiles\_<ID distribuzione>\_<nome ruolo Web>\_<istanza ruolo>\_W3SVC1.\nAbilitati tramite la modifica di DiagnosticMonitorConfiguration.WindowsEventLog durante la configurazione iniziale. Archiviati nella tabella WADWindowsEventLogs. Contatori delle prestazioni\nAbilitati tramite la modifica di DiagnosticMonitorConfiguration.PerformanceCounters. Archiviati nella tabella WADPerformanceCounters. Nell'esempio di codice il ruolo di lavoro imposta un contatore delle prestazioni.\nAbilitati dalla chiamata a CrashDumps.EnableCollection. Archiviati in un contenitore BLOB nel percorso wad-crash-dumps. Poiché la maggior parte delle eccezioni viene gestita in ASP.NET, questa funzionalità in genere è utile solo per un ruolo di lavoro.\nLog degli errori personalizzati\nPer un esempio sull'uso di questi log, vedere il blog di Neil Mackenzie. Quando i dati dei dump di arresto anomalo del sistema vengono trasferiti nell'archiviazione permanente, vengono archiviati nel contenitore BLOB wad-crash-dumps. I log IIS vengono trasferiti nel contenitore BLOB wad-iis-logfiles, mentre le richieste non riuscite vengono archiviate nel contenitore BLOB wad-iis-failedreqlogfiles.\nI registri eventi vengono trasferiti nella tabella WADWindowsEventLogs nell'archiviazione permanente, mentre i contatori delle prestazioni vengono trasferiti nella tabella WADPerformanceCounters in base all'intervallo specificato. Nella tabella WADDiagnosticInfrastructureLogs sono contenuti log relativi all'infrastruttura di diagnostica e i listener di traccia sono disponibili nella tabella WADLogsTable.\nGestione della diagnostica\nIl salvataggio permanente di tutti i file di log descritti nell'archiviazione di Azure comporta un costo in termini economici e di tempo. La soluzione ideale è quella di abilitare la traccia nel momento esatto in cui è necessario risolvere un particolare problema. Quando si modificano dinamicamente le impostazioni di diagnostica, è necessario ricordare di ripristinare manualmente le impostazioni originali o di modificare queste ultime se alcuni elementi devono essere sempre presenti. Questo passaggio, eseguito in modo consapevole, è particolarmente importante se non si usa un file con estensione wadcfg perché, nel caso in cui l'istanza venga riavviata, le nuove impostazioni verranno sostituite con le impostazioni di diagnostica configurate nel codice.\ncmdlet di PowerShell per Azure consentono di gestire numerosi aspetti dei servizi di Azure in esecuzione, ad esempio la diagnostica. I cmdlet vengono eseguiti nel computer locale e usano le API di gestione e di diagnostica di Azure per connettersi tramite Internet al servizio, fornendo informazioni e modificando parametri.\nWindows PowerShell viene installato con Windows 7 e rappresenta la versione più evoluta dei cmdlet di Gestione servizio installati con lo strumento di gestione di Azure (MMC). Di seguito vengono elencati alcuni dei cmdlet più importanti:\nGet-DiagnosticConfiguration - Ottiene la configurazione del buffer per il nome buffer specificato (Logs, Directories, PerformanceCounters, WindowsEventLogs o DiagnosticInfrastructureLogs).\nPer modificare la configurazione per un ruolo, usare il cmdlet Set-DiagnosticConfiguration.\nStart-OnDemandTransfer - Avvia un trasferimento su richiesta del buffer dei dati specificato. In questo modo i dati vengono spostati nell'archiviazione di Azure (tabella o archiviazione BLOB).\nNel blog di David Aiken è disponibile uno script per eliminare alcuni file di log (file di log IIS e file XML wad-control-container). Il cmdlet Clear-Container deve essere chiamato per ogni contenitore. È inoltre necessario verificare che i trasferimenti pianificati non si sovrappongano all'eliminazione nonché definire una strategia per i log archiviati in tabelle, ad esempio contatori delle prestazioni, registri eventi e così via. Alcuni utenti scaricano tutti i log dall'archiviazione di Azure e li inseriscono in un database di SQL Server in modo da non incorrere più in costi di archiviazione e da essere in grado di eseguire query sui dati più complesse.\nGrazie alla conoscenza delle risorse di diagnostica di Azure, gli sviluppatori possono compilare applicazioni compatibili tramite le procedure di progettazione consigliate descritte di seguito.\nModalità per stabilire l'integrità dell'applicazione\nL'integrità di un'applicazione deve essere misurata in relazione a una linea di base. Il semplice fatto che la home page venga visualizzata non significa necessariamente che l'applicazione sia integra. Per creare una linea di base completa rispetto alla quale valutare l'integrità, è necessario inoltre conoscere l'integrità e le prestazioni della logica di business.\nIl passaggio successivo consiste nel comprendere come ottenere e mantenere l'integrità. L'elemento base su cui si basa l'integrità è la puntualità dei pagamenti relativi ad Azure. Una sottoscrizione non pagata determina progressivamente conseguenze negative, che provocano in definitiva l'eliminazione dell'applicazione.\nPer ogni sottoscrizione, un servizio ospitato di Azure è caratterizzato da quattro livelli che possono influire sull'integrità dell'applicazione.\nUn'istanza ad esempio può non essere eseguita in modo corretto a causa di un errore hardware o essere riavviata a causa di un aggiornamento software. Questa situazione non provoca tuttavia un errore del ruolo a meno non si disponga di un'unica istanza configurata. In modo analogo, ogni servizio ospitato si trova in un'area particolare, ad esempio Stati Uniti centro-meridionali. Queste informazioni critiche determinano se l'applicazione è interessata da un evento di interruzione del servizio. Gli errori ai livelli inferiori possono provocare errori a livello del servizio ospitato se in fase di progettazione dell'applicazione non è stata incorporata la ridondanza.\nLa maggior parte delle applicazioni Azure richiede architetture più complesse rispetto a quelle indicate nel diagramma precedente. L'applicazione in uso probabilmente ha un aspetto analogo al seguente:\nLa natura di un ambiente distribuito introduce più punti di errore possibili e la possibilità di documentare tali percorsi critici rende più efficiente la risoluzione dei problemi. In relazione al diagramma precedente, ad esempio, può essere utile conoscere il modo in cui eseguire il test se si verifica un errore durante il controllo di accesso.\nPer comprendere gli errori che si sono verificati in un'applicazione, è necessario monitorarne e registrarne lo stato. In generale, è opportuno registrare quattro categorie di informazioni relative all'applicazione:\nInformazioni a livello di codice - Eccezioni, valore delle variabili chiave e qualsiasi informazione necessaria per eseguire il debug dell'applicazione.\nProcesso aziendale - Controllo necessario per la sicurezza, il rilevamento delle modifiche e la conformità.\nStabilità del sistema - Prestazioni, scalabilità, velocità effettiva, latenze.\nConvalida dei presupposti aziendali - Valutazione sulla corrispondenza tra l'uso effettivo dell'applicazione e quello previsto.\nAccelerare il ripristino\nLa caratteristica fondamentale degli umani è quella di bloccarsi in caso si verifichi un problema di grave entità. Formazione ed esercizio consentono di superare questo istinto naturale ed è per questo motivo che si praticano esercitazioni antincendio e che alcune linee aeree promuovono corsi di sicurezza in caso di incidente. La maggior parte delle grandi aziende investe un importo significativo del proprio budget per la pianificazione del ripristino di emergenza. Per informazioni sulle procedure consigliate, leggere l'articolo relativo all'implementazione IT del ripristino di emergenza nei data center Microsoft. In questo ambito vengono semplicemente evidenziate le tecniche per velocizzare la risoluzione dei problemi. La consapevolezza che l'applicazione è compilata in modo da semplificare la risoluzione del problemi può ridurre la tensione quando si verifica un problema e diminuire contemporaneamente il tempo necessario per ripristinare l'operatività del sito. L'analisi dei vantaggi in termini di costo determina il livello di tolleranza di errore del sistema. Può essere utile ad esempio valutare il costo aggiuntivo relativo a un backup a caldo fornito da Gestione traffico per ridurre il tempo di inattività.\nGestione traffico di Azure (attualmente in versione CTP)\nGestione traffico di Azure permette di gestire e distribuire il traffico in ingresso nei servizi di Azure ospitati, in esecuzione sia nello stesso data center che in data center diversi in tutto il mondo. Questo componente consente inoltre di configurare un servizio di failover in modo che se si verifica un'interruzione nel servizio principale, il traffico viene inviato al servizio successivo nell'elenco. È disponibile anche software di terze parti, ad esempio Akamai o Limelight, che offre soluzioni di bilanciamento del carico.\nDi seguito viene indicato un piano in cinque passaggi per accelerare il processo di risoluzione dei problemi.\nIl primo passaggio del piano prevede di rilevare i problemi non appena si verificano. Più rapidamente si rileva un problema, più rapidamente è possibile iniziare a implementare una procedura di emergenza ed è per questo motivo che il monitoraggio è un fattore chiave.\nIl secondo passaggio consiste nel rilevare se l'origine del problema risiede nella piattaforma Azure o nell'applicazione. Il primo elemento da esaminare è il dashboard servizi di Azure. Tale sito richiede che si conoscano tutti i servizi usati dall'applicazione e il data center in cui il servizio è distribuito. Viene rilevata solo la riduzione di un servizio che influisce sull'applicazione.\nUn modo per monitorare gli eventi dei servizi della piattaforma Azure consiste nell'effettuare una sottoscrizione a tutti i feed RSS per l'applicazione. Se ad esempio l'applicazione era ospitata nel data center degli Stati Uniti centro-settentrionali, è possibile effettuare una sottoscrizione a questo feed RSS.\nArchiviazione di Azure usa domini di errore (rack, switch di rete, unità di alimentazione) per limitare l'impatto dei guasti hardware. Secondo un preconcetto comune sull'archiviazione di Azure, per le repliche di dati dell'utente al di fuori di un'unica posizione, ad esempio Stati Uniti centro-meridionali, viene eseguito il failover in un'altra replica. Se si verifica un problema in una determinata posizione, l'accesso ai dati ne risentirà. Nel blog del team di archiviazione vengono forniti tutti i dettagli sulla nuova funzionalità di replica geografica.\nIl terzo passaggio prevede la localizzazione del problema. Questo passaggio è probabilmente quello più difficile in un'applicazione complessa che usa più servizi di Azure. La creazione di un servizio senza stato consente di isolare le parti diverse dell'applicazione. Se tutti i servizi dipendenti sono in esecuzione normalmente, è necessario determinare l'integrità dei servizi di calcolo in uso. A tale scopo, nel portale di gestione aprire la sezione Servizi ospitati, account di archiviazione e CDN e scegliere la distribuzione desiderata. Nella finestra delle proprietà vengono visualizzate informazioni analoghe alle seguenti:\nIn questo caso è possibile notare che negli ultimi otto giorni la distribuzione dell'utente è stata eseguita regolarmente come evidenziato dall'intervallo di tempo trascorso tra l'ora di completamento dell'ultima operazione e l'ultimo aggiornamento. Se invece si nota che la distribuzione si è interrotta o è stata riavviata di recente, è possibile determinare con precisione il punto in cui iniziare a cercare. Se tale punto sembra essere un evento di un servizio che influisce su tutta la distribuzione in un data center specifico, contattare immediatamente Microsoft al numero (866) 676-6546.\nIl quarto passaggio consiste nell'eseguire operazioni standard di risoluzione dei problemi, ad esempio la verifica dei file di log o dei registri eventi, il collegamento di un debugger o l'uso di strumenti diversi, come Procmon o Network Monitor, per capire se è possibile trovare indicazioni del problema. Il primo elemento da esaminare in una distribuzione di servizi ospitati di Azure è il registro eventi dell'applicazione. Verificare che non siano presenti eccezioni generate dall'applicazione. Questa verifica può sembrare non necessaria perché attualmente tutto il supporto è gratuito, ma spesso è possibile trovare e risolvere i problemi più rapidamente di un tecnico specializzato Microsoft che non conosce l'intero ambito dell'applicazione. Se l'imperativo è l'operatività del sito, eseguire una ricerca preliminare è l'alternativa migliore.\nIl quinto passaggio prevede di contattare il supporto Microsoft. Per velocizzare la risoluzione del problema, è necessario fornire l'ID federato (Windows Live ID) associato al proprietario dell'account della sottoscrizione. È necessario inoltre fornire il risultato dell'analisi eseguita sull'origine del problema e gli errori presenti nei file di log diversi. Il tecnico del supporto Microsoft può richiedere di essere aggiunto come co-amministratore della sottoscrizione in modo da visualizzare il portale di gestione esattamente come l'utente.\nLe prestazioni vengono valutate a seconda dell'osservatore. Qual è la soglia oltre la quale le prestazioni diventano inaccettabili? Come si stabilisce il periodo di timeout di una pagina? Anche se si stabilisce un tempo di caricamento massimo, non è possibile garantire che le pagine verranno caricate per tutti clienti. Il routing DNS e l'affidabilità di rete sono due fattori fondamentali per stabilire i tempi di caricamento delle pagine. Può verificarsi ad esempio il caso in cui il provider di servizi Internet di un cliente di Memphis (Tennessee) invia prima a San Antonio (Texas) il traffico diretto a Chicago. Una discussione dettagliata delle prestazioni non rientra nell'ambito del presente documento. Per procedure consigliate per lo sviluppo di Azure, vedere l'articolo sulla guida relativa all'elasticità e alle prestazioni di SQL Azure sul sito TechNet. Prima di avviare una procedura di risoluzione dei problemi sulle prestazioni, è necessario stabilire una linea di base. Per questo motivo la raccolta di dati sulle prestazioni su un lungo periodo di tempo è un aspetto fondamentale. Una volta stabilita la linea di base, è possibile rilevare tendenze e anomalie.\nNella piattaforma Azure sono disponibili contratti di servizio che definiscono i livelli di disponibilità e di connettività per i diversi servizi. Cosa sono i contratti di servizio? Può accadere che il provider di servizi Internet comunichi all'utente che non può usare a livello aziendale la connessione di cui dispone perché il pacchetto acquistato non prevede un contratto di servizio. L'affidabilità è analoga alle prestazioni in quanto dipende in modo significativo dalla connessione di rete sottostante del cliente e può variare a seconda dell'osservatore. I collegamenti indicati in precedenza forniscono informazioni sulle prestazione della connessione di rete di cui si dispone.\nSpesso si ritiene erroneamente che i contratti di servizio della piattaforma Azure garantiscano gli stessi livelli di servizio anche all'applicazione. Innanzitutto, alcuni utenti non leggono la frase che afferma:\nPer il calcolo, Microsoft garantisce che, quando si distribuiscono due o più istanze di ruolo in domini di errore e di aggiornamento diversi, i ruoli con connessione Internet disporranno di connettività esterna per almeno il 99,95% del tempo.\nIn questa frase manca un qualificatore aggiuntivo di due parole: "due o più istanze di ruolo per ruolo". In altre parole, se si dispone di un ruolo Web e di un ruolo di lavoro, ciascuno con un'istanza, l'applicazione non sarà disponibile ogni volta che viene eseguito un aggiornamento del sistema operativo host o che viene eseguita una riparazione del sistema. Il servizio di calcolo di Azure usa domini di errore per garantire l'ottemperanza al contratto di servizio.\nUn altro preconcetto è legato al fatto che se si sceglie una versione di un sistema operativo specifica, l'aggiornamento del sistema operativo non provocherà alcuna interruzione. Questa condizione è vera per i sistemi operativi guest in esecuzione nell'istanza, ma non lo è per il sistema operativo host installato nel computer fisico in esecuzione nel data center.\nPer ottimizzare l'affidabilità, è necessario monitorare il sito sia internamente tramite i dati di Diagnostica Microsoft Azure che esternamente tramite gli strumenti Gomez di Compuware o Pingdom. È inoltre necessario verificare di disporre delle patch di sicurezza più recenti e di aver definito un piano per la verifica delle modifiche del codice.\nQuando si crea una nuova applicazione con Visual Studio, il comportamento predefinito prevede di impostare la versione del sistema operativo guest nel file ServiceConfiguration.cscfg in modo analogo al seguente:\nQuesta è una buona opzione perché l'utente riceverà gli aggiornamenti automatici, aspetto che rappresenta uno dei vantaggi chiave delle strutture PaaS. L'opzione è poco meno che ottima perché non si usa la versione del sistema operativo più recente. Per usare la versione del sistema operativo più recente (Windows Server 2008 R2), l'impostazione deve essere analoga alla seguente:\nSfortunatamente, molti clienti decidono di fermarsi a una versione particolare del sistema operativo nella speranza di aumentare il tempo di attività evitando gli aggiornamenti del sistema operativo guest. Questa è una strategia ragionevole solo per i clienti aziendali che eseguono sistematicamente il test di ogni aggiornamento nell'ambiente di gestione temporanea e quindi pianificano uno scambio di indirizzo VIP per le applicazioni di importanza cruciale in fase di produzione. Per tutti gli utenti che non eseguono il test di ogni aggiornamento del sistema operativo guest, la mancata configurazione degli aggiornamenti automatici comporta rischi per l'applicazione Azure.\nVerifica e rilascio\nQual è il piano da seguire quando è necessario aggiornare il servizio, soprattutto in caso di emergenza? Questo passaggio, spesso ignorato, può rappresentare la differenza tra la condizione di inattività del sito e la possibilità di affrontare un problema di entità minore nell'ambiente di gestione temporanea. Mentre per la pianificazione iniziale di un'applicazione Azure e il successivo rilascio viene in genere spesa una notevole quantità di tempo e di energia, molte volte si presuppone che operazioni di test estese non siano necessarie per gli aggiornamenti perché la soglia per la correzione di una modifica è minore rispetto a un prodotto preconfezionato. Sebbene le regressioni possano essere corrette rapidamente, sfortunatamente possono anche causare problemi estremamente gravi.\nOgni modifica a un'applicazione in produzione deve essere testata prima della distribuzione definitiva. Considerate le possibili conseguenze di un errore, il maggior tempo speso è un buon investimento. Per altre informazioni, leggere la pagina relativa alla panoramica dell'aggiornamento di un servizio di Azure.\nGrazie per il tempo dedicato alla lettura degli argomenti discussi nel presente documento. Sono graditi commenti e suggerimenti sui consigli adatti alle vostre esigenze. Il costo correlato al servizio inattivo deve essere valutato in relazione al costo della raccolta di dati di diagnostica e il calcolo deve essere effettuato prima della distribuzione in produzione. Il lavoro necessario per sviluppare applicazioni Azure affidabili non è nuovo né rivoluzionario né impegnativo dal punto di vista tecnico, ma richiede semplicemente che progettisti e sviluppatori prendano in considerazione i potenziali problemi che possono verificarsi nelle applicazioni e applichino le procedure consigliate nel presente documento.\nChristian, Tom, "Help with Azure role stuck in Initializing/Busy/Stopped state", Blog, 25 febbraio 2011.\nCross, Andy, "Tracing to Azure Compute Emulator SDK V1.3", Blog, 22 gennaio 2011.\nHaley, Jason, "How To: Query Azure Log Tables with LINQPad", Blog, 28 gennaio 2010 - 15.09.\nHardin, David, "Configuring WAD via the diagnostics.wadcfg Config File", Blog, 29 marzo 2011.\nKelly, Mike, "Take Control of Logging and Tracing in Azure", MSDN Magazine, giugno 2010.\nMackenzie, Neil, "Custom Diagnostics in Azure", Blog, 8 dicembre 2009.\nMakogon, David, "Azure Tip of the Day: Separate Diagnostic Storage Account", Blog, 15 agosto 2010.\nMarx, Steve, "Capturing Filtered Windows Events with Azure Diagnostics", Blog, 21 aprile 2010.\nMladenov, Toddy, "Collecting Event Logs in Azure", Blog, 2 maggio 2010.\nMyers, Walter, "Setting Up Performance Counters In Your Azure Web and Worker Roles", Blog, 31 gennaio 2011.\nNakashima, Jim, "Using IntelliTrace to debug Azure Cloud Services", Blog, 7 giugno 2010.\nO’Neil, Jim, "500 and Other Errors in Azure Deployments Blog", Blog, 11 aprile 2011 - 4.47\nStiefel, Michael, "Why Did My Azure Application Crash? Using the Azure Diagnostics API to Find Code Problems", Blog, 8 settembre 2011.\nWasham, Michael, "Managing Log Files with Azure PowerShell Cmdlets 2.0", Blog, 20 settembre 2011.\nWilliamson, Kevin, " Azure Role Architecture", Blog, 5 maggio 2011.\nPortale di gestione di Azure http://manage.windowsazure.com.\nPortale di Azure http://www.microsoft.com/windowsazure/\nCluster logico di computer che forniscono un ambiente di esecuzione dei ruoli in una macchina virtuale.\nTraccia delle richieste non riuscite, in precedenza Failed Request Buffering (buffering delle richieste non riuscite)\nIl portale di gestione di Azure è un portale di amministrazione per la gestione, la distribuzione e il monitoraggio dei servizi Azure. L'indirizzo di accesso al portale di gestione è http://manage.windowsazure.com.\nAcronimo di REpresentational State Transfer, una modalità di progettazione software che usa un'architettura client-server senza stato in cui i servizi Web vengono visualizzati come risorse e possono essere identificati dai relativi URL.\nContratto di servizio Macchina virtuale\nEmulazione software di un computer che esegue una partizione isolata di un computer reale.\nUn ruolo Web è un ruolo personalizzato per la programmazione di applicazioni Web come supportate da IIS 7 e da ASP.NET.\nRuolo di lavoro\nUn ruolo di lavoro è utile per lo sviluppo generalizzato e consente di eseguire attività di elaborazione in background per un ruolo Web.\nQuesta appendice contiene il codice necessario per configurare Diagnostica di Azure. Il metodo RoleEntryPoint.OnStart viene chiamato per dare l'opportunità di personalizzare l'avvio dell'istanza del ruolo. È possibile fornire una propria implementazione di OnStart per eseguire il codice necessario per configurare WAD per il ruolo.\nQuesta appendice contiene il codice necessario per configurare Diagnostica di Azure in un ruolo di lavoro.\nNota Questo file di configurazione è per uso locale con l'emulatore di calcolo.\nEsempio di un file diagnostics.wadcfg per un ruolo Web.\nConfigurazione predefinita scritta per l'oggetto BLOB wad-control-container.


Fino al prossimo 24 maggio 2020 sarà possibile visitare presso il Museo Civico Archeologico di Bologna: ETRUSCHI. Viaggio nelle terre dei Rasna, una mostra promossa e progettata dall’Istituzione Bologna Musei, in collaborazione con la Cattedra di Etruscologia e Archeologia Italica dell’Alma Mater Studiorum Università di Bologna, realizzata da Electa e posta sotto l’Alto Patronato del Presidente della Repubblica Italiana.\nSull’ambizioso progetto espositivo – che intende condurre il visitatore alla scoperta delle terre dei ‘Rasna’, come gli Etruschi chiamavano sé stessi – avrò modo di parlarvi presto. Lunedì 20 gennaio, infatti, invitata da Electa, sarò al museo di Bologna per visitare la mostra e provare a coglierne gli aspetti, i temi, gli oggetti, gli spunti che potrebbero, in particolare, catturare l’attenzione di un bambino/a e farlo appassionare alla storia di questa incredibile civiltà. L’invito, pertanto, è a seguirci il giorno 20 gennaio sui canali social di Archeokids (instagram, facebook e twitter), per fare, assieme a me, un viaggio esplorativo alla scoperta degli Etruschi. A seguire verrà pubblicato qui sul blog il resoconto dettagliato del blogtour.\nIntanto, per le famiglie con bambini che intendono a breve visitare la mostra, vi segnalo che l’offerta didattica ideata dal Museo per l’occasione, declinata in relazione alle diverse fasce d’età e alle esigenze o preferenze degli utenti, è assai ricca e propone oltre alle tradizionali visite guidate, anche visite animate, che stimolano la partecipazione dei più piccoli con quiz, giochi e letture, e laboratori didattici finalizzati alla rielaborazione in chiave ludica di alcuni aspetti peculiari della civiltà etrusca.\nMuseo Civico Archeologico Bologna. Vista dell’entrata del museo. (Fonte: Wikipedia)\nPer scoprire meglio come è nato il progetto didattico associato alla mostra e quali sono le sue finalità e i suoi punti di forza, ho posto alcune domande in merito alla responsabile dei servizi educativi del Museo bolognese: la dott.ssa Anna Dore. Le sue parole mi saranno senza alcun dubbio utili nel provare a visitare la mostra con gli occhi di una bambina, meravigliandomi e lasciandomi sorprendere da quegli oggetti o dettagli che spesso sfuggono alla vista distratta degli adulti.\nAttività didattica al Museo Civico Archeologico di Bologna. (Fonte: sito web del museo)\nL’offerta didattica del Museo legata alla mostra sugli Etruschi è estremamente ricca e articolata, con attività pensate per un’utenza che spazia dai 4 ai 15 anni e oltre. Può illustrarci il lavoro di progettazione che una tale offerta presuppone? Quali sono le figure professionali che hanno ideato un tale progetto didattico?\nPer la mostra “Etruschi. Viaggio nelle terre dei Rasna” l’offerta didattica è stata progettata dal concessionario della mostra, Mondadori Electa, che si è avvalso della professionalità di Aster Archeologia, Storia e territorio srl. La proposta è stata poi sottoposta alla supervisione scientifica dei servizi educativi del Museo Civico Archeologico e al confronto con i curatori. Le persone che hanno ideato il progetto sono archeologi con grande esperienza nella mediazione museale e nella didattica dell’archeologia per le scuole.\nCome per ogni intervento di mediazione culturale, l’elemento fondamentale è una buona sinergia fra i responsabili scientifici e i responsabili della progettazione didattica. In base a questa e all’approfondita conoscenza del progetto scientifico da parte dei mediatori, è possibile identificare gli approcci tematici e metodologici più utili per le diverse fasce di pubblico.\nTra le modalità di accesso alla mostra previste per ogni tipo di utenza, vi è anche quella della visita animata. Qual è l’approccio adottato in questo tipo di visita che la rende più interessante e coinvolgente rispetto ad una comune visita guidata?\nLe visite animate prevedono un momento dedicato alla visita ai materiali esposti in mostra, selezionati secondo il tema proposto, accompagnato o concluso da un’attività ludica, attraverso la quale stimolare i ragazzi, con il gioco e la verifica, a misurare lo stato delle proprie conoscenze.\nQuali sono, a suo parere, gli elementi della cultura etrusca che possono risultare maggiormente utili ai bambini e ai ragazzi per una riflessione sul mondo odierno?\nFra i temi che sottendono il percorso espositivo ha un notevole peso quello del rapporto con le culture altre, della mobilità delle persone, dei reciproci influssi delle culture, tema estremamente attuale, che i ragazzi vivono anche nella loro quotidianità. Un altro aspetto è quello del rapporto con il territorio e il paesaggio.\nIl percorso espositivo dedicato agli Etruschi raccoglie circa 1400 oggetti provenienti da più di 60 musei, italiani e non. Quali sono i reperti che, presumibilmente, attireranno più di altri l’attenzione dei bambini e dei ragazzi, soprattutto i più piccoli?\nLa scelta del comitato scientifico della mostra è stata quella di non privilegiare i capolavori, quanto un tessuto armonico e robusto di contesti e oggetti capaci di raccontare i diversi aspetti di un popolo; credo quindi che gli approcci saranno anche molto personali, guidati dalle singole curiosità e propensioni. Sicuramente di grande effetto i volti di persone, divinità, esseri fantastici, come l’Acheoloo che della mostra è il simbolo. Ma forse qualcuno sarà attratto dai grandi elmi dei primi guerrieri etruschi, o elementi meno appariscenti, come le piccole bambole offerte alla divinità in un santuario di Capua.\nRelated tags : #EtruschiBologna AnnaDore Bologna didattica etruschi


giovedì 04 Ottobre 2018 - 18:42\nSembrava un banale incidente: una caduta dalle scale, qualche costola rotta. Invece, Pietro Vella, vigile del fuoco, si è spento la scorsa notte all’ospedale Civico. L’incidente si era verificato martedì, durante il turno di lavoro, nei locali della caserma di via Scarlatti (alle spalle del Teatro Massimo).\nVella, 61 anni, assistente amministrativo contabile, era caduto dalle scale del comando provinciale: costole fratturate e un polmone lesionato. Poi il ricovero all’ospedale Civico, nel reparto Medicina d’urgenza. Quindi l’improvviso peggioramento fino alla morte.\n“Ieri sera intorno alle 20 mi ha mandato un messaggio e ci siamo sentiti al telefono – racconta un amico -. Gli ho dato quei consigli che si possono dare in questi casi. Stamattina ho saputo che Pietro è morto”. In caserma tutti conoscevano Pietro Vella. I colleghi adesso non si danno pace: “Era una persona tranquillissima, il destino è crudele. Caro Pietro, ricorderemo di te nei tanti anni passati insieme il tuo sorriso e la tua disponibilità”.