前文我們聊到了haproxy的代理配置段中比較常用的配置指令的用法以及說明，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/12770930.html；今天我們來說說haproxy的狀態頁的配置，以及基於cookie實現的會話保持配置；

　　haproxy和nginx一樣，都有一個狀態頁，這個頁面對於運維人員來說是一個比較重要的頁面，裡面包含了haproxy代理的後端伺服器的各種指標，通常我們要了解後端主機是否健康，當前負載情況，我們可以通過狀態頁去了解；haproxy的狀態頁配置起來很簡單，用stats enable指令去開啟即可；

　　stats enable：開啟狀態頁；該指令可以配置在frontend或者listen或者backend，如果定義在backend中，那麼我們必須要用前端去呼叫該banckend才能夠看到狀態頁，所以通常我們都定義在listen中或者frontend中；具體示例如下

　　示例：定義在backend中

　　提示：定義在backend中必須要用frontend去呼叫該backend；

　　示例：定義在frontend中

　　示例：定義在listen中

　　提示：以上三種方式都不影響訪問狀態頁面，推薦配置在fonrtend或listen中；

　　配置好stats enable引數後，重啟haproxy，我們就可以通過瀏覽器訪問haproxy所在主機的對應埠，我這裡監聽在81埠上，所以訪問http://192.168.0.22:81/haporxy?stats就可以訪問到狀態頁；如下

　　提示：之所以訪問/haproxy?stats這個uri才能夠訪問到狀態頁，是因為我們沒有在配置檔案中明確指定把狀態頁繫結到那個uri上，預設情況不指定就是這個/haproxy?stats，當然我們如果要指定需要用stats uri <prefix>來指定對應的rui即可，如下

　　 stats uri <prefix>：自定義stats page uri，預設值：/haproxy?stats

　　示例：更改狀態也都uri

　　提示：以上配置表示訪問狀態頁，的uri為/admin??status

　　測試：用瀏覽器訪問81埠上的/admin??status這個uri看看是否能夠訪問到狀態頁？

　　提示：可以看到我們更改了uri後，預設的uri就不可以訪問了，必須鍵入我們指定uri才可以被訪問到，這在一定程度上降低了任何人訪問狀態頁的風險；

　　stats auth <user>:<passwd>：配置狀態頁面認證的賬號和密碼，可使用多次；預設：no authentication，表示不驗證

　　示例：配置狀態頁只允許admin使用者訪問並且密碼為admin123.com

　　提示：以上配置表示開啟狀態頁的認證功能，並且新增admin為使用者名稱，admin123.com為密碼

　　測試：現在我們訪問狀態頁，看看是否需要驗證？

　　提示：可以看到我們現在訪問狀態頁，需要我們提供使用者名稱和密碼了，這相對於前面的配置，對於狀態頁的獲取更加安全了；

　　stats realm <realm>：設定認證時彈出輸入使用者名稱密碼的提示資訊；

　　tats refresh <delay>：設定自動重新整理時長；

　　示例：

　　提示：以上配置表示設定彈出輸入使用者名稱和密碼的提示，設定自動重新整理時長為每4秒自動重新整理一次

　　測試：重啟haproxy，看看對應配置是否生效

　　提示：可以看到我們配置的輸入使用者名稱和密碼提示的字串和自動重新整理頁都實現了，這裡說一下，設定提示字串需要把空白字元通過“\”轉義，否則不會生效，加引號好像都不可以；

　　stats admin { if | unless } <cond>：啟用stats page中的管理功能

　　示例：配置可以在狀態頁管理後端主機的許可權；通常會通過後面的acl去控制，我這裡為了演示方便，就用TRUE這個內建的ACL

　　提示：以上配置表示開啟狀態頁管理功能，在條件為真的情況下，if TRUE表示一直為真，這意味著只要登入狀態頁，就有管理後端主機的許可權；

　　測試：

　　提示：可以看到我們可以把後端主機的狀態任意調整；

　　stats hide-version：隱藏版本

　　示例：隱藏haproxy狀態也的版本資訊

　　測試：登入狀態頁看看是否還有版本資訊？

　　到此狀態頁的配置相關指令說完了，接下來我們來說說狀態頁裡邊的內容；

　　提示：pid = 11712 (process #4, nbproc = 4) #pid為當前pid號，process為當前程序號，nbproc和nbthread為一共多少程序和每個程序多少個執行緒（多執行緒需要在1.7以上的版本才支援）；uptime = 0d 0h08m17s #啟動了多長時間；system limits: memmax = unlimited; ulimit-n = 8035表示系統資源限制：記憶體/最大開啟檔案數/；maxsock = 8035; maxconn = 4000; maxpipes = 0表示最大socket連線數/單程序最大連線數/最大管道數maxpipes；current conns = 1; current pipes = 0/0; conn rate = 1/sec；表示當前連線數/當前管道數/當前連線速率；Running tasks: 1/8; idle = 100 %表示執行的任務/當前空閒率；

　　active UP：綠色表示線上伺服器； backup UP：天藍色表示標記為backup的伺服器；active UP, going down：淡黃色表示監測未通過正在進入down過程；backup UP, going down：深紫色表示備份伺服器正在進入down過程；active DOWN, going up：黃色表示down的伺服器正在進入up過程；backup DOWN, going up：淺紫色表示備份伺服器正在進入up過程；active or backup DOWN：粉紅色表示線上的伺服器或者是backup的伺服器已經轉換成了down狀態； not checked：灰色表示標記為不監測的伺服器（沒有對它做健康狀態監測）；active or backup DOWN for maintenance (MAINT) ：棕色表示active或者backup伺服器認為下線的；active or backup SOFT STOPPED for maintenance ：深藍色表示active或者backup被認為軟下線(人為將weight改成0)；

　　提示：session rate(每秒的連線會話資訊)中的指標有cur,max,limit;其中cur表示每秒的當前會話數量；max表示每秒的最大會話數量；limit表示每秒新的會話限制量；sessions(會話資訊)，cur:表示當前會話量；max:表示最大會話量；limit: 表示限制會話量；Total:表示總共會話量；LBTot:表示選中一臺伺服器所用的總時間；Last：表示和伺服器的持續連線時間；Bytes(流量統計)：In表示網路的位元組輸入總量；Out表示網路的位元組輸出總量；Denied(拒絕統計資訊)：Req表示拒絕請求量；Resp表示拒絕恢復量；Errors(錯誤統計資訊)：Req表示錯誤請求量；conn表示錯誤連線量；Resp表示錯誤響應量；Warnings(警告統計資訊)：Retr表示重新嘗試次數；Redis表示再次傳送次數；Server(real server資訊)：Status表示後端server的狀態，包含UP和DOWN；LastChk表示持續監測後端伺服器的時間，其中L4OK表示基於4層tcp檢查OK，L7OK表示基於7層應用層檢查OK；Wght表示權重；Act表示活動連結數量；Bck表示備份的伺服器數量；Chk表示心跳監測時間；Dwn表示後端伺服器連線後都是DOWN的數量；Dwntme表示總的downtime時間；Thrtle表示server的狀態；

　　瞭解了上面的狀態頁資訊說明後，接下來我們來聊一聊haproxy基於cookie做會話保持；

　　首先我們要清楚什麼叫cookie?它的主要作用是幹什麼的？眾所周知http是無狀態的，所謂無狀態就是前一秒客戶端訪問服務端，後一秒同一客戶端訪問服務端，服務端是無法判斷是不是同一客戶端；就相當於服務端沒有任何能力記住客戶端；這樣一來就存在一個問題；如果是一需要驗證的網站，如果服務端不能辨別客戶端身份，這意味著它不能夠辨認到底是哪個客戶端登入了，這樣一來使用者每重新整理一次網頁，服務端就會要求客戶端重新登入；這很顯然不是正常的邏輯；為了解決這樣的問題，服務端每當客戶端登入的時候，就會檢查請求報文中是否攜帶cookie資訊；如果沒有攜帶cookie服務端在響應客戶端的時候就會在響應報文中新增一個set-cookie的首部，意思是告訴客戶端，這是你的cookie；客戶端拿到服務端的響應的同時，它會自動的把服務端發來的cookie儲存到一個特定的地方，下次客戶端再次訪問服務端的時候，就會把上次伺服器傳送過來的cookie資訊帶上去訪問伺服器；這樣一來服務端收到客戶端的請求，一看請求報文中的cookie資訊，服務端就知道這個請求是那個使用者傳送過來的；這樣一來服務端就通過cookie來辨認客戶端了；這也是cookie的主要作用；通常情況下儲存在客戶端的叫cookie;在服務端一側類似cookie的功能的東西我們叫session；通常兩者通過某些資訊來對應的；比如在客戶端cookie資訊裡記錄了服務端上的session的號碼；當客戶端再次訪問服務端時，就會把cookie中的資訊傳送給服務端；服務端收到客戶端傳送過來的cookie就會去找對應的session；從而實現了，服務端知道對應客戶端上次的操作；cookie是有時限性的；通常在有效的時間內去訪問服務端，服務端都能夠準確的辨認客戶端；過期以後，服務端會重新給客戶端傳送cookie資訊；

　　從上面的描述，我們不難理解，cookie就是用來讓服務端辨識客戶端的一種機制；而對於haproxy來講，基於cookie來做會話保持的原理就是通過對後端伺服器響應報文中的cookie資訊中新增(或覆蓋的方式)一個鍵值對，在客戶端下次訪問時，檢查對應cookie首部的資訊，從而讓haproxy能夠判斷把該請求排程在那個後端伺服器上；通常我們會在server上設定一個cookie的值，在listen或backend中設定一個cookie的鍵，明確說明以怎樣的方式設定cookie的鍵；通過listen或backend中設定的cookie的鍵結合server後面的cookie的值組成的cookie資訊，從而實現不同的cookie資訊排程到不同的server上去；

　　示例：

　　提示：以上cookie COOKIE insert nocache表示在後端伺服器響應報文首部中新增一個cookie的名稱為COOKIE，而對應cookie的值就來源於後面server中的cookie的值；nocache表示該cookie不被共有快取系統快取；

　　測試：重啟haproxy，用瀏覽器訪問看看響應首部有什麼變化

　　提示：可以看到當客戶端第一次訪問時，響應首部set-Cookie中就會設定一個COOKIE=web1的值；這個值就是我們剛才在haproxy配置的，從這個值上看，我們本次訪問被排程到web1上了，之後我們再次訪問時，就不會被排程到其他伺服器上，在cookie過期之前始終都會被排程到web1上響應；這是因為下次我們訪問時，會自動把這個cookie資訊攜帶上；如下

　　提示：正是因為我們攜帶的cookie資訊是COOKIE=web1和haproxy上的web1上的cookie的值相同，所以我們只要攜帶COOKIE=web1就會被排程到web1上；

　　用curl 模擬cookie資訊訪問不同後端伺服器

　　提示：通過不同的cookie資訊，就可以訪問到不同後端server了；這樣就實現了基於cookie資訊來把相同cookie的請求傳送給同一後端server的目的；實現了會話保