共用方式為

實驗室1.1重現和疑難解答當機問題

適用於： .NET Core 2.1、.NET Core 3.1、.NET 5

本文介紹在Linux中重現 .NET Core 當機問題的程式。 本文也會討論如何檢查 Nginx 工具和系統記錄，以取得當機的徵兆和指示。

必要條件

遵循這些疑難解答實驗室的最低需求是讓 ASP.NET Core 應用程式示範低 CPU 和高 CPU 效能問題。

您可以在因特網上找到數個範例應用程式來達成此目標。 例如，您可以下載並設定 Microsoft的簡單 webapi 範例 ，以示範不想要的行為。 或者，您可以使用 BuggyAmb ASP.NET Core 應用程式作為範例專案。

如果您已遵循此系列先前的部分，您應該已準備好進行下列設定：

  • Nginx 已設定為裝載兩個網站：
    • 第一個會使用 myfirstwebsite 主機標頭 （http://myfirstwebsite） 接聽要求，並將要求路由傳送至在埠 5000 上接聽的示範 ASP.NET Core 應用程式。
    • 第二個會使用 buggyamb 主機標頭 （http://buggyamb） 接聽要求，並將要求路由傳送至接聽埠 5001 的第二個 ASP.NET Core 範例 Buggy 應用程式。
  • 這兩個 ASP.NET Core 應用程式都應該以重新啟動伺服器或應用程式停止回應時自動重新啟動的服務執行。
  • Linux 本機防火牆已啟用並設定為允許 SSH 和 HTTP 流量。

注意

如果您的設定尚未就緒，請移至「第2部分建立並執行 ASP.NET Core應用程式」。

若要繼續此實驗室，您必須至少有一個問題 ASP.NET 在 Nginx 後方執行的 Core Web 應用程式。

此實驗室的目標

本文是兩個實驗室部分中的第一個。 實驗室工作分成如下：

  • 第 1 部分：您將重現當機問題、檢查 Nginx 和系統記錄來搜尋損毀徵兆和指標，然後產生損毀傾印檔案進行疑難解答。 最後，您將從 Ubuntu 管理員 apport 所產生的當機報告收集系統產生的核心傾印檔案。

  • 第 2 部分：您將安裝和設定 lldb，以與名為 SOS 的 .NET Core 調試程序擴充功能搭配使用。 您也會分析 lldb 中的傾印檔案。

重現當機問題

當您瀏覽至網站 URL http://buggyamb/，然後選取 [問題頁面 ] 連結時，您會看到一些問題案例的連結。 有三個不同的當機案例。 不過，在此實驗室中，您只會針對第三個當機案例進行疑難解答。

網站當機信息的螢幕快照。

選取任何連結之前，請選取 [預期的結果]，並確認您的應用程式如預期般運作。 您應該會看到類似下面的輸出。

輸出信息的螢幕快照。

頁面應該會快速載入（不到一秒），並顯示產品清單。

若要測試第一個「緩慢頁面」案例，請選取 [慢速 ] 連結。 頁面最終會顯示與 [預期結果] 頁面相同的輸出，但呈現速度會比預期慢得多。

在重現當機問題之前，請記下 Buggy 應用程式的進程識別碼。 您將使用這項資訊來確認應用程式重新啟動。 systemctl status buggyamb.service執行 命令以取得目前的 PID。 在下列結果中，執行服務之進程的 PID 為 2255。

服務信息的螢幕快照。

選取 [ 當機 3 ] 連結。 頁面會載入並顯示下列訊息：

Crash3 資訊的螢幕快照。

此訊息會詢問用戶考慮下列問題：此頁面是否會造成程序當機？ 執行相同的 systemctl status buggyamb.service 命令，您應該會看到相同的 PID。 這表示未發生當機。

選取 [預期的結果]，然後選取 [ 緩慢]。 雖然您應該會在選取 [預期的結果] 之後看到正確的頁面，但選取 [緩慢 ] 應該會產生下列錯誤訊息。

慢速命令的螢幕快照。

即使您在網頁上選取任何其他連結，您也會在短時間內遇到相同的錯誤。 10-15 秒之後，所有項目都會再次開始回應。

若要檢查 PID 是否已變更，請再次執行 systemctl status buggyamb.service 。 此時，您應該注意到程式似乎已停止，因為 PID 已變更。 在上一個範例中，進程 PID 是 2255。 在下列範例中，它會變更為 2943。 顯然，該網站做出了良好的承諾，以崩潰這個過程。

服務 2943 資訊的螢幕快照。

針對重現的步驟進行疑難解答

以下是重現步驟的摘要：

  1. 選取 [ 當機 3]。 頁面正確載入，但會傳回令人困惑的訊息，指出進程將會當機。
  2. 選取 [ 緩慢]。 您會收到「HTTP 502 - 不正確的閘道」錯誤訊息，而不是產品數據表。
  3. 問題開始之後，接下來 10-15 秒沒有頁面轉譯。
  4. 10-15 秒之後，應用程式會開始正確回應。

「HTTP 502 - 不正確的閘道」錯誤訊息本身不會告訴您太多。 不過，它應該提供第一個線索：這是 Proxy 錯誤，而且如果 Proxy 無法與 Proxy 後方執行的應用程式通訊，就會發生此錯誤。 在建議的設定中，Nginx 會作為 ASP.NET Core 應用程式的反向 Proxy 運作。 因此，來自 Nginx 的這個錯誤表示在轉送傳入要求時無法連線到後端應用程式。

確認 Nginx 正常運作

在繼續之前，您可能想要檢查 Nginx 是否正常運作。 此步驟並非必要，因為您知道應用程式正在當機。 不過，您仍然可以藉由檢查 Nginx 記錄來驗證 Nginx 的狀態。 您稍早在<安裝和設定 Nginx>一節中練習了類似的疑難解答步驟。

Nginx 有兩種記錄：存取記錄和錯誤記錄檔。 這些會儲存在 /var/log/nginx/ 資料夾中。

記錄信息的螢幕快照。

存取記錄就像 IIS 記錄檔一樣。 開啟並檢查它們，就像您在上一節中所做的一樣。 記錄不會顯示您在網站頁面上瀏覽嘗試期間所遇到的「HTTP 502」回應狀態代碼以外的任何新資訊。

使用 cat /var/log/nginx/error.log 命令檢查錯誤記錄檔。 此記錄更有説明且更清楚。 它顯示 Nginx 能夠處理要求，但在傳送最終回應之前，Nginx 與 Buggy 應用程式之間的連線已關閉。

錯誤信息的螢幕快照。

此記錄清楚地指出您看到的內容不是 Nginx 問題。

使用 journalctl 命令檢查系統記錄

如果 ASP.NET Core 應用程式當機，徵兆應該會出現在某處。

因為 Buggy 應用程式是以系統服務的形式執行，因此其作業會記錄在系統記錄檔中。 系統記錄檔就像 Windows 中的系統事件記錄檔。 命令 journalctl 可用來檢視及作業系統記錄。

您可以執行 命令， journalctl 而不切換以查看所有記錄。 不過，輸出將會是大型檔案。 瞭解如何篩選內容是符合您最大的利益。 例如，如果您執行下列命令：

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

以下是可用的參數：

  • -r：以反向順序列印記錄，以便先列出最新的記錄。
  • --identifier：請記住 SyslogIdentifier=buggyamb-identifier 測試應用程式服務檔案中的這一行。 （您可以使用這個來強制記錄只顯示套用至有問題的應用程式的專案。
  • --since：顯示在指定前一個期間記錄的資訊。 範例：--since "10 minute ago" 或 --since "2 hour ago"。

命令有數個實用的參數 journalctl 可協助您篩選記錄。 若要熟悉此命令，建議您執行 man journalctl來諮詢說明頁面。

執行 journalctl -r --identifier=buggyamb-identifier --since today -o cat。 您應該注意到會產生一些警告訊息。

cat 命令的螢幕快照。

若要查看詳細數據，請使用箭頭鍵向下捲動。 您會發現例外狀況 System.Net.WebException 。

Webexception 信息的螢幕快照。

如果您仔細檢查記錄，您會看到發生問題的程式代碼檔名和行號。 在此實驗室中，我們將假設此資訊無法使用。 這是因為在真實世界中，您可能無法擷取這類資訊。 因此，目標是繼續分析損毀傾印，以瞭解損毀的原因。

當機後取得核心傾印檔案

當進程終止時，請回想一些重要系統行為：

  • 根據預設，會產生核心傾印檔案。
  • 核心傾印會命名為 core ，並建立於目前工作資料夾或 /var/lib/systemd/coredump 資料夾中。

雖然預設行為是讓系統產生核心傾印檔案，但此設定可以在 中 /proc/sys/kernel/core_pattern 覆寫，直接將產生的核心傾印檔案傳送到另一個應用程式。 當您在此系列中的上一個部分中使用 Ubuntu 時，您已瞭解 apport 會在 Ubuntu 中管理核心傾印檔案產生。 檔案 core_pattern 會覆寫為管線將核心傾印傳送至 apport。

核心信息的螢幕快照。

Apport 會使用 /var/crash 資料夾來儲存其報表檔案。 如果您檢查此資料夾，您應該會看到當機後已產生的檔案。

varcrash 信息的螢幕快照。

不過，這不是核心傾印檔案。 這是報表檔案，其中包含數個資訊片段以及傾印檔案。 您必須解除封裝此檔案，才能取得核心傾印檔案。

在您的主資料夾下建立傾印資料夾。 系統會指示您將在那裡擷取報表。 解除封裝 apport 報表檔案的命令為 apport-unpack。 執行以下命令：

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

此命令會 建立 /dumps 資料夾。 此命令 apport-unpack 會建立 /dumps/dotnet 資料夾。 結果如下。

sudo 命令的螢幕快照。

在 ~/dumps/dotnet 資料夾中，您應該會看到傾印檔案。 檔案名為 CoreDump，且應該大約是 191 MB。

傾印命令的螢幕快照。

擷取自動產生的核心傾印檔案可能是一個繁瑣的程式。 在下一個實驗室中，您會看到使用 createdump更輕鬆地擷取核心傾印檔案。

下一步

實驗室 1.2 在 lldb 調試程式中開啟和分析系統產生的核心傾印檔案，您將瞭解如何在 lldb 調試程式中開啟此傾印檔案，以執行快速分析。

  • Last updated on