Risoluzione dei problemi delle applicazioni

AppFabric fornisce funzionalità per la gestione di servizi WCF e WF di .NET Framework versione 4 con hosting su IIS. Fra le funzionalità disponibili si possono elencare i meccanismi di affidabilità per l'hosting di servizi di flusso di lavoro durevoli, la configurazione semplificata dell'applicazione e gli strumenti per monitorare lo stato dei servizi WCF e WF di .NET Framework 4. In questa sezione viene descritto come utilizzare gli strumenti di monitoraggio per risolvere i problemi dei servizi.

Utilizzo del Dashboard per iniziare a risolvere i problemi dei servizi WCF e WF. Fare clic sull'icona Dashboard nel gruppo AppFabric all'interno di Gestione IIS per visualizzare la pagina Dashboard. Questa pagina composita offre una visualizzazione di riepilogo dello stato delle applicazioni distribuite in un ambito particolare in IIS e fornisce collegamenti per eseguire il drill-down per specifiche informazioni per la risoluzione di problemi. Se le metriche visualizzate dal Dashboard e le pagine correlate non forniscono il livello di informazioni necessario per risolvere il problema, è possibile utilizzare gli strumenti AppFabric per abilitare l'analisi System.Diagnostics in modo da risolvere i problemi di un'applicazione WCF o WF.

Risoluzione dei problemi tramite l'uso del Dashboard

Per le applicazioni distribuite, l'isolamento di un problema non è così semplice come osservare un contatore o utilizzare un singolo strumento. La risoluzione dei problemi in un ambiente di servizi distribuito spesso implica la correlazione di dati provenienti da diversi strumenti o contatori per creare un'immagine realistica della vera causa di un problema. Il Dashboard contiene tre widget, Istanze WF permanenti, Cronologia chiamate WCF e Cronologia istanze WF, che possono essere utilizzati per correlare informazioni per la risoluzione dei problemi delle applicazioni. Gli ultimi due sono metriche cronologiche, ovvero ciò che viene visualizzato è influenzato dal selettore di tempo Periodo di tempo nella parte superiore del Dashboard (Nell'ultimo minuto, Nelle ultime 24 ore e così via).

Quando si apre per la prima volta uno dei tre widget, viene visualizzato un riepilogo di alto livello sullo stato delle metriche corrispondenti. È possibile notare rapidamente la presenza di un problema a quel livello. Ad esempio, il widget Istanze WF permanenti inizialmente mostra lo stato delle istanze di flusso di lavoro dinamiche e durevoli che hanno salvato il loro stato nell'archivio di salvataggio permanente. Viene fornito un riepilogo del numero di istanze permanenti nello stato Attiva, Inattiva e Sospesa. In questo modo è possibile individuare rapidamente se esiste un problema al livello del flusso di lavoro permanente. È possibile fare clic sui collegamenti nella pagina di riepilogo per ottenere ulteriori informazioni su un contatore di riepilogo specifico.

Utilizzo delle metriche delle istanze WF permanenti

Il widget Istanze WF permanenti mostra lo stato delle istanze di flusso di lavoro dinamiche che hanno salvato il loro stato nell'archivio di salvataggio permanente. Viene mostrato il numero di istanze permanenti nello stato Attiva, Inattiva e Sospesa. Ciascuna intestazione e lo stesso contatore di riepilogo rappresentano un collegamento alla pagina Istanze WF permanenti che contiene i dati non elaborati.

Per comprendere meglio il problema durante la risoluzione dei problemi delle istanze sospese, fare clic sul collegamento Istanze sospese sul Dashboard. La pagina Istanze WF permanenti mostra tutte le istanze sospese. Selezionando una di queste istanze, nel riquadro Dettagli nella parte inferiore della schermata vengono inserite informazioni di riepilogo relative all'istanza sospesa. La scheda Errori mostra il motivo per cui l'istanza è stata sospesa. Se occorrono ulteriori informazioni, è possibile fare clic con il pulsante destro del mouse sull'istanza e selezionare l'opzione Visualizza eventi rilevati. Tramite questa azione si passa alla pagina Eventi rilevati che mostra tutti gli eventi rilevati per l'istanza di flusso di lavoro sospesa. Per impostazione predefinita, gli eventi sono ordinati con quelli più recenti in alto.

Utilizzo delle metriche della cronologia chiamate WCF

Il widget Cronologia chiamate WCF visualizza il numero di chiamate WCF ricevute e registrate nell'archivio di monitoraggio. L'intestazione visualizza un conteggio di riepilogo delle chiamate completate, le eccezioni verificatesi o il numero di volte che si è raggiunto un limite. La prima colonna mostra i primi cinque servizi con la maggiore incidenza di chiamate completate. La seconda colonna mostra un'analisi degli errori WCF raggruppati per tipo di errore. La terza colonna mostra i primi cinque servizi con la maggiore incidenza di eccezioni del servizio. Ogni metrica è collegata alla pagina Eventi rilevati, dove è possibile visualizzare i dati non elaborati riepilogati nel Dashboard.

Ad esempio, per ottenere ulteriori informazioni su una chiamata non riuscita, fare clic sul contatore di riepilogo Chiamate non riuscite e passare alla pagina Eventi rilevati. Questa pagina viene popolata con le ultime chiamate WCF non riuscite per l'ambito specificato nella gerarchia IIS. Selezionando uno di questi eventi, il riquadro Dettagli nella parte inferiore della schermata viene completato con i dati corrispondenti. La scheda Errori contiene le informazioni di eccezione relative all'insuccesso. Se occorre ulteriore contesto sulla chiamata non riuscita, è possibile fare clic con il pulsante destro del mouse sull'evento e selezionare l'opzione Visualizza tutti gli eventi correlati. In tal modo si aggiorna la pagina Eventi rilevati che viene popolata con tutti gli eventi correlati al primo.

Utilizzo delle metriche della cronologia istanze WF

Il widget Cronologia istanze WF mostra il numero di istanze di flusso di lavoro attivate, non riuscite e completate. La prima colonna mostra i primi cinque servizi con la maggiore incidenza di attivazioni. La seconda colonna mostra i primi cinque servizi con la maggiore incidenza di istanze non riuscite. La terza colonna mostra quante istanze non riuscite sono state recuperate. Ad esempio, se un'istanza di flusso di lavoro ha riscontrato un errore che ne ha causato la sospensione ed è stata ripresa e completata correttamente in un secondo tempo, l'istanza viene conteggiata sia nella colonna Non riuscita che in quella Recuperata.

La risoluzione dei problemi tramite le informazioni derivanti dal widget Cronologia istanze WF è simile a quella tramite il widget Istanze WF permanenti. Fare clic su una delle intestazioni per passare alla pagina Istanze WF rilevate dove è possibile visualizzare le informazioni di riepilogo relative all'istanza di flusso di lavoro. Tuttavia, poiché il widget Cronologia istanze WF visualizza le istanze di flusso di lavoro già completate, non verranno visualizzate le azioni di controllo istanza presenti nella pagina Istanze WF permanenti. Nella pagina Istanze WF rilevate è possibile fare clic con il pulsante destro del mouse su un'istanza e visualizzarne gli eventi rilevati in modo per esaminare i dati di rilevamento di basso livello per l'istanza.

Risoluzione dei problemi mediante l'analisi System.Diagnostics

AppFabric sfrutta i miglioramenti apportati alle funzionalità di analisi di WCF e di rilevamento di WF in .NET Framework 4 che emettono eventi nel sottosistema Event Tracing for Windows (ETW). ETW fornisce un'infrastruttura rapida di analisi degli eventi. In alcuni scenari, tuttavia, occorre visualizzare tutte le informazioni diagnostiche disponibili. In AppFabric è possibile abilitare la traccia System.Diagnostics al livello di applicazione o di sito. Queste informazioni di analisi vengono scritte su file nel disco e possono essere visualizzate con lo strumento Service Trace Viewer.

Risoluzione dei problemi di un'applicazione ASP.NET distribuita

È possibile utilizzare l'ID attività, come specificato nella precedente sezione Utilizzo delle metriche della cronologia chiamate WCF, per eseguire la ricerca di un ID di istanza permanente e risolvere i problemi di un'applicazione ASP.NET che comunica con i servizi WCF attraverso più server AppFabric. A questo scopo, è necessario impostare il livello di monitoraggio almeno su Monitoraggio End-to-End per configurare l'analisi dell'attività. Di seguito è riportato uno scenario di esempio.

Durante il monitoraggio di un'applicazione Web tramite gli strumenti specifici di ASP e IIS, l'amministratore rileva un aumento degli errori di timeout mentre l'applicazione ASP.NET comunica con un servizio. Dopo aver controllato gli errori, l'amministratore individua l'ID attività attivo nel momento in cui si è verificato l'errore e, utilizzando il Dashboard AppFabric, crea ed esegue una query per tale ID attività. Viene restituito un evento di ricezione sull'istanza Y del servizio X. L'amministratore visualizza il flusso di messaggi associato a tale evento e constata che si tratta di un evento di limitazione relativo al superamento del numero massimo di chiamate simultanee consentito. Analizzando le pagine di riepilogo del servizio, nota che l'opzione "Riscontri accelerazione WCF" è impostata su 20. Da un esame delle chiamate effettuate nelle ultime 24 ore, vede che la limitazione è stata superata negli ultimi 30 minuti. Esamina altri giorni e nota che la stessa situazione si verifica ogni giorno alla stessa ora. Conclude quindi che ogni giorno alla stessa ora il carico aumenta e che è necessario impostare il numero massimo di chiamate simultanee su 25. Osservando con attenzione, l'amministratore rileva che gli eventi di limitazione, così come gli errori di timeout dell'applicazione ASP.NET, si riducono notevolmente durante la chiamata ai servizi WCF.

Processi del servizio SQL Server Agent di Windows

Il servizio SQL Server Agent di Windows monitora le operazioni di SQL Server, automatizza alcuni compiti amministrativi, genera avvisi quando necessario, pianifica ed esegue processi. Un processo di SQL Server rappresenta una serie specifica di operazioni, eseguite in modo sequenziale da SQL Server Agent, che riguardano varie attività correlate al database. Quando AppFabric è configurato per l'utilizzo di SQL Server, utilizza SQL Server Agent per importare eventi nell'archivio dati di Monitoraggio e per eliminare regolarmente i dati meno recenti dall'archivio.

Se SQL Server Agent non è in esecuzione, i processi AppFabric pianificati non possono essere eseguiti nell'installazione SQL Server. Di seguito vengono riportate alcune procedure per assicurarsi che l'esecuzione di questi processi avvenga come pianificato mediante il servizio SQL Server Agent di Windows:

1. Assicurarsi che il servizio SQL Server Agent di Windows sia in esecuzione verificandone lo stato. Fare clic su Strumenti di amministrazione, selezionare Servizi, fare clic su SQL Server Agent (MSSQLSVR) e assicurarsi che lo Stato sia Avviato. In caso contrario, avviare il servizio.

2. Quando si inizializza l'archivio vengono creati quattro processi SQL Server:

   • Microsoft_ApplicationServer_Monitoring_AutoPurge_<nome DB di monitoraggio>

   • Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<nome DB di monitoraggio>

   • Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<nome DB di monitoraggio>

   • Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<nome DB di monitoraggio>

   Se il servizio SQL Server Agent di Windows è avviato e i processi AppFabric non sono in esecuzione, controllare gli errori che si sono verificati durante l'ultima esecuzione del processo.

3. Se le istanze dei processi sono state completate correttamente ma non sono presenti eventi nelle tabelle eventi, esaminare la tabella ASFailedStagingTable nell'archivio dati Monitoraggio. Questa tabella contiene alcune colonne, come ErrorNumber e ErrorMessage, che contribuiscono a chiarire il motivo della mancata riuscita. Se non si è verificato alcun errore, questa tabella è vuota.

L'identità Windows (proprietario) tramite la quale viene eseguito un processo di SQL Server Agent di AppFabric non deve essere quella dell'utente connesso. Il processo deve essere eseguito tramite l'identità dell'account di protezione Windows preconfigurato AS_MonitoringDbJobsAdmin. Nelle condizioni ideali, questo account deve essere un account di dominio. L'account possiede i permessi adeguati nell'archivio di monitoraggio quando si esegue il cmdlet Initialize-ASMonitoringDatabase dopo l'installazione.

Di seguito viene illustrato come SQL Server Agent elabora i diversi proprietari di un processo Server di AppFabric inviato:

• Se il proprietario di un processo di SQL Server Agent è un account di dominio, SQL Server contatta il controller di dominio per verificare che l'account sia valido. In caso affermativo, il processo viene eseguito nell'account di dominio. Diversamente si tenta di eseguirlo in un account locale.

• Se il proprietario di un processo di SQL Server Agent è un account locale sysadmin, SQL Server Agent applicherà priorità adeguata all'identità “RunAs” nel passaggio del processo ed emetterà il comando "Execute user as AS_MonitoringDbJobsAdmin". Ciò significa che il processo viene eseguito nell'identità dell'account AS_MonitoringDbJobsAdmin.

  Nota

  Per visualizzare l'identità “RunAs” per un processo all'interno di SQL Server Management Studio, fare clic con il pulsante destro del mouse sul processo, selezionare Proprietà quindi fare clic sulla scheda Avanzate. Il valore deve essere impostato sull'account AS_MonitoringDbJobsAdmin.

• Se il proprietario di un processo di SQL Server Agent è un account locale diverso da sysadmin, l'identità ”RunAs” fornita nel passaggio del processo viene ignorata. In questo caso, il processo viene eseguito dal servizio SQL Server Agent in qualità di proprietario locale.

• Nello scenario di dominio disconnesso (ad esempio un laptop), se l'identità di un processo di monitoraggio di SQL Server è un utente del dominio, SQL Server Agent tenta di convalidare l'account contattando il controller di dominio. Se il computer dove il processo SQL Server Agent viene eseguito è disconnesso dal dominio, la convalida non riesce. Per ridurre l'impatto di questo errore, sono disponibili due opzioni:

  1. La prima e la più semplice delle due è configurare il processo (ovvero eseguire il cmdlet Initialize-ASMonitoringDatabase) mediante un account utente locale.

  2. La seconda scelta è rappresentata dal fatto che, se un processo è configurato da un proprietario con un account di dominio, l'utente può aggiornare il proprietario del processo in un secondo momento mediante la stored procedure SQL Server sp_update_job.

Una proceduta consigliata è configurare il servizio SQL Server Agent di Windows affinché venga eseguito in un account di accesso locale. In tal modo è possibile eseguire il servizio in un computer AppFabric anche se la connessione di rete è stata terminata. Se questo servizio è in esecuzione tramite un account di dominio e non è possibile accedere al dominio, il servizio SQL Server Agent di Windows non riesce a ottenere le credenziali. Ciò significa che gli eventi di monitoraggio non possono essere spostati correttamente nelle rispettive tabelle finali di destinazione. A causa di questo, nessun nuovo dato verrà visualizzato nel Dashboard.

Processi SQL Server Express

Nonostante le procedure per la diagnosi delle cause di mancata riuscita di un processo siano molto simili a quelle di SQL Server, è necessario esaminare la tabella ASJobsTable per SQL Server Express. Questa tabella è specifica per un'installazione di SQL Server Express e non è presente in un'installazione di SQL Server. All'interno di questa tabella è possibile visualizzare i valori delle colonne LastRunOn e LastRunSuccess nella riga di un processo specifico per determinare se un processo è riuscito o meno.

In SQL Server Express non viene utilizzato il sevizio SQL Server Agent di Windows. Si utilizza invece SQL Service Broker. È presente una capacità temporale nella funzionalità Service Broker con un valore time-out impostato sull'intervallo di esecuzione configurato per il processo Microsoft_ApplicationServer_Monitoring_AutoPurge_<nome DB di monitoraggio>. Quando si raggiunge questo intervallo di time-out, viene inviato un messaggio alla coda processo SQL Server. Il messaggio attiva la procedura archiviata che viene eseguita come parte del processo Microsoft_ApplicationServer_Monitoring_AutoPurge_<nome DB di monitoraggio>. La procedura a sua volta esegue la funzionalità di pulizia automatica sull'archivio di SQL Server Express.

Di seguito vengono riportate alcune query T-SQL che possono essere eseguite per monitorare l'avanzamento della funzionalità di pulizia automatica dell'archivio:

• Mostra i processi attualmente pianificati: SELECT * FROM ASJobsTable

• ricerca nella colonna dialog_timer (ora UTC) per visualizzare la prossima esecuzione del processo pianificata: SELECT * FROM sys.conversation_endpoints

• Mostra il numero delle procedure di attivazione attualmente in esecuzione: SELECT * FROM sys.dm_broker_activated_tasks

• Individua quanti messaggi sono ancora presenti nella coda. Restituisce il valore 0 quando nessun processo è in esecuzione: SELECT * FROM ASScheduledJobQueue

Vedere anche

Altre risorse

Dashboard Page
Persisted WF Instances Page
Tracked WF Instances Page
Tracked Events Page

  2012-03-05