透過mod_status模組就能夠即時地取得Apache伺服器運作的相關資訊，但是該模組是以文字的型式來輸出相關資訊，使用上不夠直覺，所以這裡將示範如何使用pimped-apache-status，改以圖形模式來輸出mod_status模組的相關資訊，讓管理者一目了然。
挾其開源碼授權及效能優異的特性，Apache早已成為市占率最高的網站伺服器。除了提供網站服務功能外，更提供了許多的模組，讓管理者能更方便地擴充或管理。在本文中，將說明如何利用mod_status模組來即時取得Apache伺服器運作的相關資訊，除此之外，由於原生的mod_status模組是以文字型式輸出相關資訊，因此這裡也會介紹另一個開源碼軟體（pimped-apache-status），利用圖形模式來輸出mod_status模組的相關資訊。
安裝mod_status模組
mod_status是一個Apache伺服器（以下簡稱為網站伺服器）所提供的原生模組，主要的功能在於以文字的型式顯示網站伺服器的相關資源和服務的使用狀態，讓網站管理者可即時地掌握網站伺服器目前的服務狀態。該模組主要提供下列資訊供管理者參考：
‧基本資料：提供如網站伺服器啟動或重新啟動的時間，以及其已持續運作的時間等資訊。
‧網站伺服器的個別進程（Process）與線程（Thread）的服務狀態：提供網站伺服器所產生的進程和線程等狀態。
‧網站伺服器的資源使用狀態：提供網站伺服器個別進程所使用的CPU百分比、總計使用的CPU總百分比。
‧網站伺服器服務使用者要求（Request）的統計以及相關資訊：提供當下正在處理的使用者要求數，以及每個進程已服務的使用者要求數和其平均處理數值。
在簡單說明mod_status模組的功能之後，接下來安裝mod_status模組。在一般情況下，該模組通常內建於Apache伺服器，並不需要特別安裝此模組。可以利用下列指令來檢查網站伺服器是否支援此模組：
httpd -M | grep status
如果，有如下列字樣的輸出：
status_module (shared)
表示網站伺服器可支援mod_status模組，但為了安全起見，通常此模組預設是關閉的，因此使用者僅須啟用此模組功能即可。
啟用設定如下，在httpd.conf（網站伺服器的主要組態檔）設定如下的設定（其中#為註解符號）：
#載入mod_status模組 LoadModule status_module modules/ mod_status.so #設定該模組的網站路徑，使用者使用此路 徑，即可取得mod_status模組的輸出 SetHandler server-status #使用該模組 #為了安全起見，可設定此選項，來限制連線 的來源 #此選項即表示僅允許YOURHOSTNAME的主機 來連線 Require host
在設定完成並重啟網站伺服器後，即可利用如「http://<網站伺服器>/server-status」來取得該模組的輸出，應可看到如圖1所示的輸出。
圖1 連結「http://<網站伺服器>/server-status」來取得模組的輸出。
為了更方便地使用，mod_status模組提供下列選項來產生輸出：
http:// <網站伺服器>/server-status? notable
以上選項是表示不以表格（Table） 型式來產生輸出。
http:// <網站伺服器>/server-status? refresh=秒數
以上是設定重新整理的時間間隔，單位為秒。例如設定為5，就表示每5秒重新顯示mod_status模組的輸出。
http:// <網站伺服器>/server-status? auto
這表示設定產生簡潔的輸出，此類的輸出通常是用來產生程式解析。
判讀輸出資訊代表意義
在正常產生相關輸出後，接下來說明輸出資訊的相關意義，首先介紹網站伺服器的基本資訊。
如圖2所示，(A)區段為表示伺服器的基本資訊，包含伺服器的版本及建立時間等資訊，另外一個比較特別的是提供「Server MPM」工作模式資訊，其中MPM為多進程處理模式（Multi-Processing Module）的簡寫，使用者可根據本身的硬體規格來選擇適當的MPM模式，藉此充分地發揮主機硬體效能，目前提供Prefork、Worker、Even等工作模式，相關說明如下所述：
圖2 網站伺服器的基本資訊說明。
Prefork
這是Apache伺服器最早期所支援的多進程（Porcess）處理模式，此模式並未使用到線程（Thread）處理模式，算是個古老又穩定的處理模式。在這個模式下，網站伺服器在啟動後會預先在系統上建立多個子進程，來等待使用者端請求（Request），藉此減少頻繁建立及銷毀進程的時間，而且每個進程在同個時間只能單獨處理一個連線，所以處理請求的效率較高。並且以單一進程來個別獨立處理不同的使用者端請求，一旦有使用者要求出現問題，並不會影響到其他進程所服務的使用者要求。
但相對於使用線程服務，使用進程服務，所需要消耗的系統資源較高，因此若要採用此種工作模式，其主機需要較高的硬體設備，才能應付建立進程所需要的損耗。
簡而言之，Prefork模式的優點在於相對單純穩定，並且個別的進程運作，並不會互相影響，但其缺點是進程需要占用更多的系統資源，並且單一進程在同一個時間內僅能服務一個使用者要求，也因此，無法有效地同時處理頻繁的使用者要求。
所以，網站伺服器開始使用消耗系統資源較少的線程服務來處理使用者的要求，希望能夠同時處理更多的使用者端請求。
Worker
Worker是一種多進程和多線程的混合工作模式，在網站伺服器啟動後，同樣地在系統上預先建立多個子進程。與Prefork工作模式不同的是，此模式會在每個子進程內新建多個線程，然後利用線程來服務使用者端請求，因此能夠更有效率地服務使用者端請求（一個進程可同時服務多個使用者要求），如此即可在同時間服務多個使用者要求。但也因為在同一個進程內可能會處理多個不同的使用者要求，因此當某個進程發生問題時，就可能會影響該進程內所有的使用者要求。
既然線程比進程的服務效率高，為何不全用線程就好，還要與進程混合使用，最主要的考量點其實是穩定性。
如果全部都使用線程的話，假設某個線程出現問題，那很有可能會影響到其所屬的父進程，進而造成網站伺服器完全無法服務使用者要求。但若折衷地採用多進程和多線程的混合使用，當某個進程內的線程發生問題則僅會影響該進程，而伺服器仍可利用其他進程來繼續服務，不致於讓整個服務中斷。但Prefork與Worker工作模式均存在Keep-alive問題，也因此有了Event工作模式。
Event
就如同Worker運作模式，Event運作模式也是利用線程和進程的方式來服務使用者要求。與Worker運作模式較為不同的是，Event運作模式在於解決了Keep-alive在長時間連接時占用線程資源被浪費的問題。
Keep-alive是一種保持連線持續存在的機制，這是用來解決系統重新建立連線的問題。如果未使用此機制，使用者端每次對伺服器的請求，都需要再重新建立連線，系統將會耗費太多的資源在建立連線上。一個連線被建立後，即可暫時保留此連線（可設定逾時時間，逾時即關閉此連線），後續的使用者端請求即可利用此已存在的連線繼續傳輸資料，藉此避免掉重新建立連線的成本。
但相對地，如果Keep-alive的保存時限設定過長，卻可能在系統上保持了許多長時間未使用的連線，進而造成系統資源的浪費。而Event運作模式與Worker模式最大的不同點，即是在於利用專門監督的線程來管理Keep-alive類型的連線，避免Keep-alive連線長時間占用系統資源的問題。在簡單說明圖2中(A)區段的資訊後，接著繼續來說明(B)區段資訊，常用的輸出說明如下所述：
Current Time:
以上是表示目前網站伺服器上的時間。
Restart Time:
表示上次重新啟動網站伺服器的時間。
Parent Server Config. Generation:
以上代表網站伺服器在啟動時，父進程會重讀組態配置文件，如果文件的組態有被更動，便會強制重啟所有子進程，此組態即是記錄這個重啟次數。
Server uptime:
表示網站伺服器在啟動後，持續運作的時間。
Server load:
則表示目前網站伺服器的負載情況。
Total accesses: - Total Traffic: kB
表示到目前為此，網站伺服器所接收及回覆的數據量。
CPU Usage: u.06 s.34 cu0 cs0 - .533% CPU load
代表網站伺服器上CPU資源的使用狀況。
173 requests/sec - 1365 B/second - 7.7 kB/ request
表示網站伺服器上處理使用者要求的平均處理時間。
接下來是顯示網站伺服器上的進程資訊（例如ID、PID），說明進程與線程及相關連線等資訊，如圖3所示。
圖3 顯示網站伺服器上的進程資訊。
然後，顯示的是計分表（ScoreBoard）資訊，mod_status模組利用類似計分表的模式來動態呈現伺服器目前即時的服務狀態並以計分表保留字（ScoreBoard Key）來代表各個狀態，如圖4所示。
圖4 顯示計分表（ScoreBoard）資訊。
其中計分表保留字，如下所述：
* _：表示網站伺服器正在等待使用者端的連線。
* S：表示網站伺服器正在啟動中。
* R：表示網站伺服器正在讀取使用者要求。
* W：表示網站伺服器正在回覆使用者要求，並送出回應（Response）。
* K：表示網站伺服器處於保持連線（Keep-alive）的狀態。
* D：代表網站伺服器正在查詢DNS紀錄。
* C：表示網站伺服器正在關閉連線。
* L：表示網站伺服器正在寫入紀錄（Log）。
* G：表示網站伺服器進入正常結束程序中。
* I：表示網站伺服器正在處理閒置程序。
最後則是mod_status模組顯示網站伺服器所有的進程及使用者要求的相關資訊，如圖5所示。
圖5 顯示網站伺服器所有的進程及使用者要求的相關資訊。
其中，標題欄的意義說明如下：
Srv：表示子進程的數目及其產生的世代數。例如3-1表示有3個子程序為第1個世代。
PID：該進程的ID。
Acc：分別表示此子進程所處理的使用者要求數。
M：表示該進程目前的狀態。
CPU：表示該進程所耗用的CPU資源狀況。
SS：距離上次處理要求的時間。
Req：表示處理最新的使用者要求所耗費的時間。
Conn：代表本次連線所傳送的連線數。
Child：表示由該子進程所傳送的數據量。
Slot：代表由該Slot所傳送的數據量。
Client：表示使用者端的IP位址。
VHost：表示伺服器主機或虛擬主機的IP。
Protocol：所使用的HTTP通訊協定。
Request：用戶端所提出的要求訊息。
雖然mod_status模組輸出相當豐富的資訊，但畢竟以文字型式方式呈現，會讓管理者無法有效直覺地取得相關資訊，因此接著介紹一套以圖形模式呈現mod_status模組輸出的套件pimped-apache-status（官方網址為https://github.com/axelhahn/pimped-apache-status），讓管理者能夠更方便地閱讀mod_status模組所輸出的資訊。
安裝pimped-apache-status
pimped-apache-status是一套以PHP語言（必須為PHP 5以上的版本，並且須支援Curl）所撰寫的網頁程式，主要是用來擷取mod_status模組輸出的資訊，並以圖形化的方式呈現其輸出的資訊，在此假設已安裝好運作PHP的環境，並且網站伺服器已啟用mod_status模組。接下來，先安裝此套件。
首先至官方網站取得最新的版本，在解壓縮後，將原始碼搬移至網站根目錄（DocumentRoot）上，接著便可以瀏覽器進行設定。設定過程很簡單，僅須設定使用者帳號和密碼即可，可利用網址「http://<網站伺服器>/admin/」進行設定，首先設定使用者帳號及密碼，如圖6所示。
圖6 透過瀏覽器進行設定。
輸入管理者帳號和密碼後，如果一切順利，應該可看到如圖7所示之輸出。
圖7 成功登入後，以圖形化的方式呈現輸出資訊。
至此，就完成安裝pimped-apache-status套件了！管理者可利用此網頁程式，更方便地取得相關資訊。
＜本文作者：吳惠麟，多年資安經驗，喜好利用開源碼建構相關解決方案，著有「資訊安全原理與實驗」等書。＞