Lab 1.1 Riprodurre e risolvere un problema di arresto anomalo

Si applica a: .NET Core 2.1, .NET Core 3.1, .NET 5

Questo articolo presenta il processo di riproduzione del problema di arresto anomalo di .NET Core in Linux. Questo articolo illustra anche come controllare lo strumento Nginx e i log di sistema per individuare i sintomi e le indicazioni dell'arresto anomalo.

Prerequisiti

Il requisito minimo per seguire questi lab per la risoluzione dei problemi consiste nell'avere un'applicazione ASP.NET Core per illustrare problemi di prestazioni a cpu bassa e CPU elevata.

È possibile trovare diverse applicazioni di esempio per raggiungere questo obiettivo su Internet. Ad esempio, è possibile scaricare e configurare l'esempio webapi semplice di Microsoft per illustrare il comportamento indesiderato. In alternativa, è possibile usare BuggyAmb ASP.NET'applicazione Core come progetto di esempio.

Se sono state seguite le parti precedenti di questa serie, è necessario avere la configurazione seguente pronta per procedere:

• Nginx è configurato per ospitare due siti Web:
  • La prima è in ascolto delle richieste usando l'intestazione host myfirstwebsite (http://myfirstwebsite) e le richieste di routing alla demo ASP.NET'applicazione Core in ascolto sulla porta 5000.
  • Il secondo è in ascolto delle richieste usando l'intestazione host buggyamb (http://buggyamb) e le richieste di routing alla seconda applicazione buggy di esempio ASP.NET Core in ascolto sulla porta 5001.
• Entrambe le applicazioni core ASP.NET devono essere eseguite come servizi che vengono riavviati automaticamente quando il server viene riavviato o l'applicazione smette di rispondere.
• Il firewall locale Linux è abilitato e configurato per consentire il traffico SSH e HTTP.

Note

Se la configurazione non è pronta, passare a "Parte 2 Creare ed eseguire ASP.NET app core".

Per continuare questo lab, è necessario avere almeno un problema ASP.NET'applicazione Web Core in esecuzione dietro Nginx.

Obiettivo di questo lab

Questo articolo è la prima delle due parti del lab. Il lavoro del lab è suddiviso nel modo seguente:

• Parte 1: Si riprodurrà il problema di arresto anomalo, controllare Nginx e i log di sistema per cercare i sintomi e gli indicatori di arresto anomalo del sistema e quindi risolvere i problemi generando un file di dump di arresto anomalo del sistema. Infine, si raccoglierà il file di dump di core generato dal sistema dal report di arresto anomalo generato da Ubuntu Manager, apport.

• Parte 2: Si installerà e si configurerà lldb per lavorare insieme a un'estensione del debugger .NET Core denominata SOS. Si analizzerà anche il file di dump in lldb.

Riprodurre un problema di arresto anomalo

Quando si passa all'URL del sito, http://buggyamb/e si seleziona il collegamento Pagine dei problemi, verranno visualizzati i collegamenti ad alcuni scenari di problema. Esistono tre diversi scenari di arresto anomalo del sistema. Tuttavia, per questo lab si risolverà solo il terzo scenario di arresto anomalo.

Prima di selezionare un collegamento, selezionare Risultati previsti e verificare che l'applicazione funzioni come previsto. Verrà visualizzato un output simile al seguente.

La pagina deve essere caricata rapidamente (in meno di un secondo) e visualizzare un elenco di prodotti.

Per testare la prima "pagina lenta", selezionare il collegamento Lento . La pagina visualizzerà infine lo stesso output della pagina Risultati previsti, ma il rendering sarà molto più lento del previsto.

Prima di riprodurre il problema di arresto anomalo, prendere nota dell'ID processo dell'applicazione buggy. Queste informazioni verranno usate per verificare che l'applicazione si riavvii. Eseguire il systemctl status buggyamb.service comando per ottenere il PID corrente. Nei risultati seguenti il PID del processo che esegue il servizio è 2255.

Selezionare il collegamento Crash 3 (Arresto anomalo 3 ). La pagina carica e visualizza il messaggio seguente:

Questo messaggio chiede all'utente di considerare la domanda seguente: la pagina causerà l'arresto anomalo del processo? Eseguire lo stesso systemctl status buggyamb.service comando e dovrebbe essere visualizzato lo stesso PID. Ciò indica che non si è verificato un arresto anomalo.

Selezionare Risultati previsti e quindi lente. Anche se la pagina corretta dovrebbe essere visualizzata dopo aver selezionato Risultati previsti, selezionare Lento dovrebbe generare il messaggio di errore seguente.

Anche se si seleziona un altro collegamento nella pagina Web, si verifica lo stesso errore per un breve periodo di tempo. Dopo 10-15 secondi, tutto inizierà a rispondere come previsto.

Per verificare se il PID è stato modificato, eseguire systemctl status buggyamb.service di nuovo. Questa volta, si dovrebbe notare che il processo sembra essere stato arrestato perché il PID è cambiato. Nell'esempio precedente il PID del processo era 2255. Nell'esempio seguente viene modificato in 2943. A quanto pare, il sito web ha fatto bene sulla sua promessa di arrestare il processo.

Risoluzione dei problemi relativi alla procedura di riproduzione

Ecco un riepilogo dei passaggi di riproduzione:

1. Selezionare Arresto anomalo 3. La pagina viene caricata correttamente, ma restituisce un messaggio confuso che suggerisce che il processo si arresta in modo anomalo.
2. Selezionare Lento. Viene visualizzato un messaggio di errore "HTTP 502 - Gateway non valido" anziché la tabella del prodotto.
3. Dopo l'avvio del problema, nessuna delle pagine esegue il rendering per i successivi 10-15 secondi.
4. Dopo 10-15 secondi, l'applicazione inizia a rispondere correttamente.

Il messaggio di errore "HTTP 502 - Gateway non valido" da solo non indica molto. Tuttavia, dovrebbe fornire un primo indizio: si tratta di un errore del proxy e può verificarsi se un proxy non riesce a comunicare con l'applicazione in esecuzione dietro il proxy. Nell'installazione proposta, Nginx funziona come proxy inverso per l'applicazione ASP.NET Core. Pertanto, questo errore da Nginx indica che non è stato in grado di raggiungere l'applicazione back-end quando ha inoltrato le richieste in ingresso.

Verificare che Nginx funzioni correttamente

Prima di continuare, è possibile verificare se Nginx funziona correttamente. Questo passaggio non è obbligatorio perché si sa che l'applicazione si arresta in modo anomalo. Tuttavia, è comunque possibile verificare lo stato di Nginx controllando i log Nginx. La procedura di risoluzione dei problemi è stata praticata in precedenza nella sezione "Installazione e configurazione di Nginx".

Nginx include due tipi di log: log di accesso e log degli errori. Questi vengono archiviati nella /var/log/nginx/ cartella .

I log di accesso sono esattamente come i file di log iis. Aprire ed esaminarli, proprio come hai fatto nella sezione precedente. I log non mostrano nuove informazioni diverse dal codice di stato della risposta "HTTP 502" già rilevato durante i tentativi di spostamento nelle pagine del sito.

Esaminare i log degli errori usando il cat /var/log/nginx/error.log comando . Questo log è più utile e chiaro. Mostra che Nginx è stato in grado di elaborare la richiesta, ma la connessione tra Nginx e l'applicazione buggy è stata chiusa prima dell'invio della risposta finale.

Questo log indica chiaramente che ciò che viene visualizzato non è un problema Nginx.

Controllare i log di sistema usando il comando journalctl

Se l'applicazione ASP.NET Core si arresta in modo anomalo, i sintomi dovrebbero apparire da qualche parte.

Poiché l'applicazione buggy è in esecuzione come servizio di sistema, l'operazione viene registrata nei file di log di sistema. I file di log di sistema sono come i registri eventi di sistema in Windows. Il journalctl comando viene usato per visualizzare e modificare i log di sistema.

È possibile eseguire il journalctl comando senza opzioni per visualizzare tutti i log. Tuttavia, l'output sarà un file di grandi dimensioni. È particolarmente interessante imparare a filtrare il contenuto. Ad esempio, è possibile eseguire il comando seguente:

journalctl -r --identifier=buggyamb-identifier --since "10 minute ago"

Sono disponibili i seguenti switch:

• -r: stampare i log in ordine inverso in modo che il più recente sia elencato per primo.
• --identifier: tenere presente la SyslogIdentifier=buggyamb-identifier riga nel file del servizio dell'applicazione di test. È possibile usare questa opzione per forzare i log per visualizzare solo le voci che si applicano all'applicazione problematica.
• --since: mostra le informazioni registrate nel periodo precedente specificato. Esempio: --since "10 minute ago" o --since "2 hour ago".

Sono disponibili diverse opzioni utili per il journalctl comando che consentono di filtrare i log. Per acquisire familiarità con questo comando, è consigliabile consultare la pagina della Guida eseguendo man journalctl.

Eseguire journalctl -r --identifier=buggyamb-identifier --since today -o cat. Si noti che vengono generati alcuni messaggi di avviso.

Per visualizzare i dettagli, scorrere verso il basso usando i tasti di direzione. Si troverà un'eccezione System.Net.WebException .

Se si esaminano attentamente i log, verranno visualizzati il nome del file di codice e il numero di riga in cui si è verificato il problema. Per questo lab si presuppone che queste informazioni non siano disponibili. Ciò è dovuto al fatto che, in scenari reali, potrebbe non essere possibile recuperare questo tipo di informazioni. Pertanto, l'obiettivo è continuare analizzando un dump di arresto anomalo del sistema per apprendere la causa dell'arresto anomalo del sistema.

Ottenere un file di dump di base dopo un arresto anomalo

Ricordare alcuni dei comportamenti del sistema chiave quando un processo viene terminato:

• Per impostazione predefinita, viene generato un file di dump principale.
• Il dump principale è denominato core e viene creato nella cartella di lavoro corrente o nella /var/lib/systemd/coredump cartella .

Anche se il comportamento predefinito è per il sistema per generare un file di dump principale, questa impostazione può essere sovrascritta in /proc/sys/kernel/core_pattern per inviare direttamente il file di dump principale risultante in un'altra applicazione. Quando si usa Ubuntu nelle parti precedenti di questa serie, si è appreso che apport gestisce la generazione di file di dump di base in Ubuntu. Il core_pattern file viene sovrascritto per inviare tramite pipe il dump principale all'apport.

Apport usa la /var/crash cartella per archiviare i file di report. Se si esamina questa cartella, verrà visualizzato un file già generato dopo un arresto anomalo.

Tuttavia, questo non è il file di dump principale. Si tratta di un file di report che contiene diverse informazioni insieme al file di dump. È necessario decomprimere questo file per ottenere il file di dump principale.

Creare una cartella dumps nella home cartella. Verrà richiesto di estrarre il report. Il comando per decomprimere il file di report di apport è apport-unpack. Esegui questo comando:

sudo apport-unpack /var/crash/_usr_share_dotnet_dotnet.33.crash ~/dumps/dotnet

Questo comando crea la cartella /dumps . Il apport-unpack comando creerà la cartella /dumps/dotnet . Ecco il risultato.

Nella cartella ~/dumps/dotnet dovrebbe essere visualizzato il file di dump. Il file è denominato CoreDump e dovrebbe essere di circa 191 MB.

L'estrazione del file di dump di core generato automaticamente può essere un processo complesso. Nel lab successivo si noterà che è più semplice acquisire i file di dump di base usando createdump.

Passaggi successivi

Lab 1.2 Aprire e analizzare i file di dump di base generati dal sistema nel debugger lldb, si vedrà come aprire questo file di dump nel debugger lldb per eseguire un'analisi rapida.