?? 歡迎大家來到景天科技苑??

🎈🎈 養成好習慣，先贊后看哦~🎈🎈

🏆 作者簡介：景天科技苑
🏆《頭銜》：大廠架構師，華為云開發者社區專家博主，阿里云開發者社區專家博主，CSDN全棧領域優質創作者，掘金優秀博主，51CTO博客專家等。
🏆《博客》：Python全棧，前后端開發，小程序開發，人工智能，js逆向，App逆向，網絡系統安全，數據分析，Django，fastapi，flask等框架，云原生k8s，Prometheus監控，linux，shell腳本等實操經驗，網站搭建，數據庫等分享。

所屬的專欄：Prometheus監控系統零基礎到進階
景天的主頁：景天科技苑

Prometheus如何監控Haproxy

1、監控案例介紹

1.1 監控場景描述

在前?的章節中，我們已經學習了如何使用 Prometheus 結合node_exporter 來監控系統資源的CPU、內存、磁盤、網絡等，
同時我們還通過“監控的方法論”找出了不同資源的重要的指標，并編寫PromQL查詢表達式和告警規則。
但是，系統資源的監控只是監控的一部分。因此我們還需要關注運行在這些節點上的應用程序。
接下來，我們將深入探討如何通過應用程序暴露的指標來直接監控它們，或者通過 Exporter 來間接收集不同應用的指標數據。
同時我們還會逐一介紹每個應用的關鍵性能指標，并講解如何利用PromQL 對這些指標進行查詢。
此外，我們對應的PromQL制作為告警規則，以便在系統出現異常時，能第一時間進行通知。
我們先看下監控案例的場景

有些應用程序自帶metrics，像Haprox，RabitMQ，kubernetes等，
有些需要我們借助exporter進行暴露metrics，很多應用都有對應的exporter
有些需要服務發現，
有些需要push數據給網關，
還有些黑盒監控，如何通過http探測網站，通過tcp去探測相關服務
我們針對不同類型，都有詳細講解如何監控。
1、應用自帶Metrics如何監控：
2、應用無法自帶Metrics，借助Exporter如何監控；
3、黑盒監控BlackBox；
4、PushGateway如何使用；
掌握這些監控的資源的重要指標，以及PromQL的查詢表達式編寫，PromQL告警規則文件；

告警：
AlertManager

圖形：
Grafana

1.2 監控環境規劃

2、Prometheus監控Haproxy

從 HAProxy 2.0 版本開始，HAProxy 內置了對 Prometheus 的支持。
這意味著 HAProxy 能夠直接提供兼容Prometheus的指標格式，無需依賴任何額外的 exporter 。（安裝Haproxy、然后修改stats，配置對外輸出metrics接口）

2.1 安裝并配置Haproxy

1、使用yum安裝Haproxy，centos7默認安裝的是1.5版本，無法安裝2.0以上的版本。我們使用功能rocketlinux9.5系統可以yum安裝

yum install haproxy -y

看下systemd配置文件

2、配置Haproxy的stats功能
先將源文件備份

cat /etc/haproxy/haproxy.cfg

globalmaxconn 100000 # Haproxy支持最大的會話數，如果default沒有配置則使用global# uid 99# gid 99user haproxygroup haproxydaemonlog 127.0.0.1 local2 infopidfile /var/lib/haproxy/haproxy.pidstats socket /var/lib/haproxy/haproxy.sock mode 600 level admin # 定義sock位置及權限
defaultsoption http-keep-aliveoption forwardformaxconn 5000 # Haproxy支持的最大會話數，默認是100000retries 3 # 連接后端服務器失敗的次數如果超過這里設置的值，haproxy會將對應的后端服務器標記為不可用mode httptimeout connect 300stimeout client 300stimeout server 300s
# 打開負載均衡的狀態頁面
frontend statsbind *:9999stats enablestats uri /haproxy-statusstats auth jingtian:123456# Prometheus metrics 的路徑http-request use-service prometheus-exporter if { path /metrics }# 允許每秒通過haproxy的新會話數限制為 100 個。如果超過這個數值，額外的新會話將被延遲或拒絕rate-limit sessions 100
# 定義負載均衡配置
frontend javabind *:80mode httprate-limit sessions 100default_backend javaserver
backend javaserverbalance roundrobinserver web1 127.0.0.1:8080 checkserver web2 127.0.0.1:8080 check
# 定義負載均衡配置
frontend webbind *:81mode httprate-limit sessions 200default_backend webservers
backend webserversbalance roundrobin# 后端支持最大的并發連接數（會話數）fullconn 1000server web3 10.10.0.30:9090 checkserver web4 127.0.0.1:8080 check

3、啟動Haproxy

systemctl enable haproxy.service --now

查看運行狀態

我們看到haproxy開啟了兩個負載均衡組，分別為80和81兩個端口號
一個haproxy可以有很多個負載均衡組

4、檢查Haproxy的狀態頁面
http://10.10.0.31:9999/haproxy-status
剛進去需要先登錄

5、檢查Haproxy的metrics接口是否能暴露指標
http://10.10.0.31:9999/metrics

能訪問這個metrics獲取數據，依托于這個配置

2.2 配置Prometheus，將Haproxy納入監控

1、編輯Prometheus配置文件，將Haproxy服務納入監控
vim prometheus.yml

  - job_name: "haproxy"static_configs:- targets: ["jingtian02:9999"]

2、重新加載Prometheus配置文件

curl -X POST http://localhost:9090/-/reload

3、檢查Prometheus的Status->Targets頁面，驗證Haproxy是否已經成功納入監控中

在prometheus查詢中，輸入haproxy，可以查到相關指標

并且可以查詢到結果

2.3 Haproxy常用指標

對于 HAProxy，通常會使用 RED 方法，監控：請求速率（Rate）、請求失敗數（Errors）、請求延遲（Duration）
但是Haproxy作為負載均衡，他又分為了前端和后端：
Frontend 在 HAProxy 中指的是客戶端連接到的部分，它負責接收來?客戶端的請求并將它們轉發到相應的 backend 集群。
通常監控 frontend 以下信息：

新建連接的速率
每秒的請求速率
當前活動連接數
響應時間
會話錯誤和拒絕

Backend 是由一個或多個服務器組成的集群，這些服務器用于處理frontend轉發過來的請求。通常監控 backend 以下信息：
會話數、當前活動連接
后端服務器的響應時間
后端服務器錯誤和超時等
后端服務器的健康狀態（比如是否在線、是否繁忙等）

1、haporxy fronted 連接與會話相關指標

haproxy_frontend_limit_session_rate 這個是需要在配置haproxy的配置文件中配置的

案例1：查詢最近5分鐘，Haproxy前端新建連接數的速率

rate(haproxy_frontend_connections_total[5m])

案例2：查詢最近5分鐘，Haproxy前端當前平均活躍的會話數，占總會話數上限的比率。 gauge類型的數據求一段時間的平均數可以用avg_over_time
計算公式：（ 當前活躍的會話數 / 會話數的限制 * 100 ）

avg_over_time(haproxy_frontend_current_sessions[5m]) / haproxy_frontend_limit_sessions * 100

案例3：查詢最近5分鐘，haproxy前端平均每秒的新建最大的會話速率，占比總限制的新建會話比率。
計算公式：（ 每秒新建的最大會話速率 / 每秒新建會話速率限制 * 100）

avg_over_time(haproxy_frontend_max_session_rate[5m]) / haproxy_frontend_limit_session_rate * 100

2、haporxy fronted http請求與響應相關指標

案例1：查詢 HAProxy 前端最近1分鐘的 HTTP 每秒請求速率。

rate (haproxy_frontend_http_requests_total[1m])

案例2：查詢 HAProxy 前端最近1分鐘，最?的新建請求數量。

max_over_time(haproxy_frontend_http_requests_rate_max[1m])

案例3：查詢 HAProxy 前端最近1分鐘，HTTP每秒的錯誤請求速率

rate(haproxy_frontend_request_errors_total[1m])

案例4：查詢 最近5分鐘，HTTP 響應錯誤（4xx 和 5xx）占總請求比率，計算公式：（4xx|5xx的響應碼增長率 / 總的請求數 ）
我們先看下響應狀態碼都是什么樣的

然后看下4xx 5xx響應速率和最近5分鐘請求總數

可以看到上面是多的一方，并且多了code，所以要去除code，并且使用功能group_left，哪邊是多的一方，group_哪邊
ignoring或group_left都必須放在 加減乘除 操作符的右側

rate(haproxy_frontend_http_responses_total{code=~"4xx|5xx"}[5m])
/ ignoring(code)group_left
rate(haproxy_frontend_http_requests_total[5m]) * 100

3、HaproxyBackend 相關指標

后端限制最大會話數

案例1：計算最近5分鐘，當前后端平均每秒的活躍的會話數，占總會話數限制的比率。
計算公式：（ 當前并發活躍的會話數 / 最大限制的會話數 * 100 ）

avg_over_time(haproxy_backend_current_sessions[5m]) / haproxy_backend_limit_sessions * 100

案例2：計算最近5分鐘，后端4xx響應的錯誤率：計算公式：（ 后端4xx響應數 / 后端總請求數 * 100 ）

rate(haproxy_backend_http_responses_total{code="4xx"}[5m]) / ignoring(code) rate(haproxy_backend_http_requests_total[5m]) * 100

案例3：計算最近5分鐘，后端5xx響應的錯誤率：計算公式：（ 后端5xx響應數 / 后端總請求數 * 100%）

rate(haproxy_backend_http_responses_total{code="5xx"}[5m]) / ignoring(code) rate(haproxy_backend_http_requests_total[5m]) * 100

4、Haproxy監控狀態相關指標

后端活躍的服務器數量

只有一個后端服務不是失敗的，其他的都檢測失敗

案例1：查詢Haroxy運行了多長時間，計算公式：（ (當前時間 - haproxy運行時間) / 小時 ）
time()得到的是當前的時間戳

(time() - haproxy_process_start_time_seconds ) / 3600

案例2：檢查后端的活躍服務器小于1

haproxy_backend_active_servers < 1

案例3：查詢Haproxy后端服務器是否有檢測失敗的

haproxy_server_check_failures_total == 1

2.4 Haproxy告警規則文件

1、編寫告警規則文件

cat /etc/prometheus/rules/haproxy_rules.yml

groups:
- name: "Haproxy告警規則"rules:- alert: Haproxy前端活躍會話數過高expr: |avg_over_time(haproxy_frontend_current_sessions[5m])/haproxy_frontend_limit_sessions * 100 > 80for: 5mlabels:severity: warningannotations:summary: "實例:{{ $labels.instance }} Haproxy前端活躍會話數占限制比率過高"description: "Haproxy前端'{{ $labels.proxy }}' 活躍會話數占限制的會話數比率超過了80%，當前值為{{ $value }}%。"- alert: Haproxy前端新建會話速率過高expr: |avg_over_time(haproxy_frontend_max_session_rate[5m])/haproxy_frontend_limit_session_rate * 100 > 80for: 5mlabels:severity: warningannotations:summary: "實例:{{ $labels.instance }} Haproxy前端新建會話速率占限制比率過高"description: "Haproxy前端'{{ $labels.proxy }}' 每秒新建的會話速率占限制比率已經超過80%，當前值為{{ $value }}%。"- alert: Haproxy前端HTTP響應4xx\5xx錯誤率過高expr: |rate(haproxy_frontend_http_responses_total{code=~"4xx|5xx"}[5m])/ignoring(code)group_leftrate(haproxy_frontend_http_requests_total[5m]) * 100 > 20for: 5mlabels:severity: criticalannotations:summary: "實例:{{ $labels.instance }} Haproxy前端HTTP響應錯誤率過高"description: "Haproxy前端'{{ $labels.proxy }}' 的 {{ $labels.code }}狀態碼占總請求的比率已經超過20%，當前錯誤率為{{ $value }}%。"- alert: Haproxy后端活躍會話數占限制比率過高expr: |avg_over_time(haproxy_backend_current_sessions[5m])/haproxy_backend_limit_sessions * 100 > 80for: 5mlabels:severity: warningannotations:summary: "實例:{{ $labels.instance }} Haproxy后端活躍會話數占限制比率過高"description: "Haproxy后端'{{ $labels.proxy }}' 活躍會話數占總會話數限制的比率超過了80%，當前值為{{ $value }}%。"- alert: Haproxy后端4xx錯誤率過高expr: |rate(haproxy_backend_http_responses_total{code="4xx"}[5m])/ignoring(code) rate(haproxy_backend_http_requests_total[5m]) * 100> 10for: 5mlabels:severity: warningannotations:summary: "實例:{{ $labels.instance }} Haproxy后端4xx錯誤率過高 "description: "Haproxy后端'{{ $labels.proxy }}' 的4xx響應錯誤率超過了10%，當前錯誤率為{{ $value }}%。"- alert: Haproxy后端5xx錯誤率過高expr: |rate(haproxy_backend_http_responses_total{code="5xx"}[5m])/ignoring(code) rate(haproxy_backend_http_requests_total[5m]) * 100> 10for: 5mlabels:severity: criticalannotations:summary: "實例:{{ $labels.instance }} Haproxy后端5xx錯誤率過高 "description: "Haproxy后端'{{ $labels.proxy }}' 的5xx響應錯誤率超過了10%，當前錯誤率為{{ $value }}%。"- alert: Haproxy后端無活躍服務器expr: haproxy_backend_active_servers < 1for: 5mlabels:severity: criticalannotations:summary: "實例:{{ $labels.instance }} 后端無活躍服務器"description: "Haproxy '{{ $labels.proxy }}' 后端活躍服務器數量小于1，這意味著整個后端服務不可用，立即檢查后端服務器狀態。"- alert: Haproxy后端服務器檢測失敗expr: haproxy_server_check_failures_total == 1for: 5mlabels:severity: warningannotations:summary: "實例:{{ $labels.instance }} 后端服務器檢測失敗"description: "Haproxy '{{ $labels.proxy }}' 后端的 '{{ $labels.server }}' 實例檢測失敗，可能存在連接問題或服務不穩定。"

重新加載prometheus配置

curl -X POST http://localhost:9090/-/reload

查看告警

2.5 Grafana導入Haproxy圖形

導入haproxy的Grafana模板。ID為 12693 這個模板提供了 HAProxy 性能和狀態的圖表，包括請求數、響應時間、錯誤計數等。

在Grafana 儀表盤-新建-導入

輸入12693，點擊加載

選擇數據源prometheus，點擊導入

如果想看下某個圖形，表達的是什么數據，可以點擊右上角三個點，點擊編輯

可以看到PromQL語句