如何檢測 Web 服務請求丟失問題

問題描述

最近偶爾有使用者反饋某些 HTTP 介面出現超時問題，而 web 服務端的 Trace 監控沒有出現 http 返回值為 503 等異常情況。出現這種情況一般是web容器出現問題，客戶端連線不上來。本文將主要介紹如何去監控這類問題。

我們是用典型的 Web 服務架構，應用透過域名訪問到我們的 LVS（Linux Virtual Server）機器，LVS 後面對應了多臺 Web 伺服器。

考慮到無法對 LVS 進行跟蹤，而 Web 伺服器（Tomcat 上出現堆積，無法評估影響範圍）。考慮再三後，我們準備在Tomcat 和 LVS 上加一個 Nginx，用於追蹤使用者訪問的真實情況。Nginx 是一款自由、開源的高效能 HTTP 伺服器。透過 Nginx 程式碼，我們可以掌握第一手的使用者訪問的真實情況，本來是打算透過 Nginx 的 Access 日誌來做統計， 後來參考 阿里雲鏈路追蹤的文件，用鏈路追蹤可以把 HTTP 的埋點和 Tomcat 連起來看，可以更詳情地發現問題。

環境準備和問題復現
編譯安裝 Nginx 和 Jaeger Agent，具體的安裝過程可以參考 阿里雲鏈路追蹤文件。
測試環境：需要重現超時問題，寫了一個小程式，開啟 200 個執行緒，每個執行緒連續向服務傳送 500 個請求。總共提交 100000 個請求。

排查過程

排查的主題思路， 對比 Web 服務端資料和 Nginx 服務端的鏈路統計資料，如果兩種的請求數不一致，那可以確定有請求丟失。再根據鏈路上的詳情資料來確定丟失請求的原因。

1、Web 服務端資料統計

傳送請求後，發現 web 服務端一共處理 98717 個請求，比客戶端少了 1283 個請求。

2、Nginx 服務端統計

檢視 Nginx 的請求，一共有 100000 個請求，說明 Nginx 收到了全部請求，但是進入到 Web 服務上處理的只有 98717 個請求（透過 javax.servlet.Filter 埋點來監控）。

3、問題分析

檢查 Nginx 服務，發現 Nginx 的有些請求的 HTTP 的返回碼 499。如下圖所示：

對比正常的 HTTP 鏈路，發現 Nginx 的請求的 HTTP 的返回碼 499，只有一個 Span 就返回了，而 HTTP 返回碼為 200 的，可以看到完整的呼叫鏈路(鏈路上除了 Nginx 的 Span，還有 Web服務的 Span），如下圖展示：

我們可以這樣來解釋這個問題，客戶端流量進入 Web 伺服器，如果 Web 伺服器處理不過來（超出可承受的最大流量或者 Web 伺服器本身可能出現 FullGC，OOM，死鎖，執行緒池慢問題）， 那客戶端設定超時的請求將會出現 499，未進入 javax.servlet.Filter 處理，Web 服務端看不到任何訪問記錄。

那是不是可以認為出現 HTTP 返回值為 499 的請求都是服務端處理失敗的請求？

4、進一步排查

我們撈取下 Nginx 上返回 499 的請求，總共 2719條，大於 Web 服務丟失的 1283 個請求。這個資料對不上，是什麼原因呢？我們在仔細檢視了下資料，有 Nginx 返回 499 的請求，但是 Web 服務返回了 200。這些請求進入 Web 服務處理程式，但是 Web 服務還沒返回就超時了。如果沒有 Tracing 把上下文連結起來，我們很難透過 Nginx 日誌或者 Web 服務日誌來解釋這個問題（一個請求，Nginx 返回 499，而 Web 服務返回 200），如下圖所示：

把 Nginx 和 Web 容器服務（Tomcat）的鏈路打通，我們可以檢視 HTTP 請求每個環節的狀態，很方便地定位問題。

總結

針對這種 Web 服務無響應的問題，可以透過加一層代理（Nginx程式碼），很好的排查問題。同時也很好統計 Web 伺服器造成多少請求失敗，影響多少使用者。對故障定級，影響面可以進行準確的評估。

推薦產品  Tracing Analysis

• 登入鏈路追蹤控制檯，在概覽頁面上開啟 檢視 Token 開關。
• 單擊需要使用的鏈路資料採集客戶端（Jaeger 或 Zipkin）按鈕。
• 在下方表格中相應地域的 相關資訊 Trace 列中，單擊接入點資訊末尾的複製按鈕。

提示：如果應用部署於阿里雲生產環境，則選擇內網接入點，否則選擇公網接入點。對於 Zipkin，一般情況下請使用 v2 版接入點，v1 版接入點僅限對 Zipkin 十分了解的高階使用者使用。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。