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

導讀

『StabilityGuide』是阿里多位阿里技術工程師共同發起的穩定性領域的知識庫開源項目，涵蓋性能壓測、故障演練、JVM、應用容器、服務框架、流量調度、監控、診斷等多個技術領域，以更結構化的方式來打造穩定性領域的知識庫，歡迎您的加入。

@GitHub :

https://github.com/StabilityMan/StabilityGuide

問題描述

最近偶爾有用戶反饋某些 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 服務端的鏈路統計數據，若是兩種的請求數不一致，那能夠肯定有請求丟失。再根據鏈路上的詳情數據來肯定丟失請求的緣由。

一、Web 服務端數據統計

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

 

二、Nginx 服務端統計

查看 Nginx 的請求，一共有 100000 個請求，說明 Nginx 收到了所有請求，可是進入到 Web 服務上處理的只有 98717 個請求（經過 javax.servlet.Filter 埋點來監控）。

三、問題分析

檢查 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 的請求都是服務端處理失敗的請求？

四、進一步排查

咱們撈取下 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 十分了解的高階用戶使用。

本文做者：徐建偉，花名竹影，阿里雲技術專家，多年系統架構，性能調優經驗， 目前主要從事鏈路跟蹤，應用監控相關工做。

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。