狀況描述

前段時間，一個系統進行版更，版更後隔天監控系統 (Checkmk) 發出了 AP 主機 thread 數量過多 (Number of threads) 的告警。

版更前的 thread 數量在上班時間大約落在 400 至 600 間，版更後相同時間卻落在 4000 至 6000 之間，甚至更多，系統的反應也比以往要慢上許多。
　
　

釐清原因

版更後有狀況，通常第一時間都會回頭檢視這次版更了哪些東西，這次的版更有幾個項目：

1. 修正 1 個 Defect
2. AP 主機作業系統升級
3. 為開放外網改變系統佈署架構
   在 DMZ ¹ 中增設一台 Web Server，透過轉發到特定服務的方式指向真正的 AP 主機。
4. 改變驗證機制
   為了提升安全性與可維護性，登入驗證機制改用 OAuth 2.0 的認證授權方式。

逐一釐清每一項調整的嫌疑 (好像偵探)
第 1、2 項因為掌握度算高，很快被排除在外，第 3 項的釐清是先觀察監控系統，發現放在 DMZ 的 Web Server thread 數量很穩定的少，相比於 AP 主機的數量，由此可推斷造成 thread 飆高的原因不在外部了，那麼，就只剩第 4 項了，使用者在系統的請求，應該會觸發驗證 Token 有效的檢查機制，而驗證是否有效需連線到身份證別主機，觀察網路連接應該可以發現一些端倪。

主機是 Linux 主機，透過幾個指令判斷兇手應該就是它

• 找出 AP Server 的 process
  系統用的是 tomcat，習慣上我會直接下指令尋找 tomcat 的 process id

  ps aux | grep tomcat

  從前述指令得到的 output 結果，第 2 個欄位就是 process id，以下將得到的結果以 $pid 表示

• 觀察 tomcat 的網路連接狀況

  netstat -p | grep $pid

  得到的 output 結果是 tomcat 當下所有的網路連接狀況，從輸出結果中觀察到有不少連接到身份識別主機的連線
  　
  
  　
  為了有更切確的數據能驗證想法，利用指令將輸出結果作個 summary
  　

  netstat -p | grep $pid | grep 'https' | awk '[print $5 "\t" $6}' | uniq -c | sort -nk1 -r

  　
  從輸出結果發現連接身份識別主機有 3000 多個連線
  
  　
  上述的指令使用到 pipe (|)，簡單理解就是將 pipe 前指令的輸出扔給 pipe 後的指令當作輸入，主要目的是為了將前一個指令的輸出整理一番：

  1. 查出 tomcat 的網路連接
  2. 過濾出包含 https 關鍵字的結果
  3. 印出前一個輸出結果的指定欄位值
  4. 去除重複列並標示出現次數
  5. 依照指定欄位倒序排序

當時站台線上人數只有 95 人左右，但是有這麼多與身份識別主機的連線，大致可以推測每個 request 都去跟身份識別主機驗證 token 是否有效，但是數量多到讓人覺得怪，難道每個使用者手速飛快？

該系統是使用 Java 開發的系統，要驗證 token 是否有效應該會經過驗證的 Filter ² 進行檢查，針對這個驗證的 Filter 也會設定有哪些類型的資源需要檢查，實際檢查該系統的 web.xml 檔案

<filter-mapping>
<filter-name>AuthenticationFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

　
確實有一個驗證的 Filter，名為 AuthenticationFilter，而底下的那行 url-pattern 設置為 /*，這代表所有的資源 都要經過驗證，包含圖檔、載入的 js 與 css，想像一下，使用者開啟一個畫面，背後代表的可能是 request 20-30 個資源，每個資源都會去跟身份識別系統確認一次。

查到這個階段，大約已可以確定問題就在這個設定了，那麼，該怎麼解決這個問題呢？

　
　

解決方法

解決的方式其實不難，主要是把應該經過驗證的資源明確下來，將 url-pattern 的 /* 調整為明確的資源類型，那麼，需要經過驗證的資源是什麼呢？

一般來說程式類的檔案會有商業邏輯、資料庫存取等處理，大多是需要經過驗證的，再者可能是一些需要登入狀態才能存取的附加檔案，實際的設定需要和該系統負責人員討論。

<filter-mapping>
<filter-name>AuthenticationFilter</filter-name>
<url-pattern>/*.jsp,/files/*</url-pattern>
</filter-mapping>

　
調整後重啟服務，觀察一陣子，thread 數下降許多且穩定

　
　

後記

工作中多少會遇上一些系統問題需要排除，往往解決問題後，以口頭或訊息的方式經驗分享，花愈多時間，留在心裡 (腦裡) 的時間愈長，但其實時間久了還是會忘記，更不用說只是聽分享但沒有實際操作的人了，也因此觸發了寫這篇筆記的開關，將釐清問題的思路和手法記錄下來。

解決技術問題後，更需要做個整理，對外，將問題排除前後的狀況作個對比，將相關的資訊傳達給提報問題的人；對內，分享釐清問題、找出根因的手法，與開發團隊復盤檢視有沒有可以優化的點，發起改善計畫與執行，形成團隊好的循環。