老楊教你快速揪出系統(tǒng)鏈路里的那個(gè)"拖后腿"的家伙
運(yùn)維人對(duì)于自己負(fù)責(zé)的業(yè)務(wù)線架構(gòu)理解決定了自己的薪資和可替代性.
老楊見(jiàn)過(guò)太多的"盲人摸象"式排查。其實(shí)找到系統(tǒng)鏈路中的薄弱環(huán)節(jié)，真的不需要憑運(yùn)氣和直覺(jué)。
今天老楊就來(lái)聊聊如何避免盲人摸象式的排查。
老楊的核心思路
我的核心邏輯很簡(jiǎn)單——先搞清楚調(diào)用關(guān)系，用數(shù)據(jù)定位問(wèn)題區(qū)域，然后從資源和網(wǎng)絡(luò)層面確認(rèn)根因。聽(tīng)起來(lái)簡(jiǎn)單，但魔鬼都在細(xì)節(jié)里。
老楊用的啥工具
說(shuō)實(shí)話，工具選擇這事兒得接地氣：
- 監(jiān)控指標(biāo): Prometheus + Grafana（這個(gè)組合基本是標(biāo)配了）
- 鏈路追蹤: SkyWalking居多（國(guó)內(nèi)用得多，中文文檔也全）
- 日志收集: 有條件上ELK，簡(jiǎn)單場(chǎng)景直接kubectl logs
- 壓測(cè)工具: hey、wrk這些輕量級(jí)的就夠用
- 系統(tǒng)診斷: top、iostat、vmstat、ss這些老朋友
- 數(shù)據(jù)庫(kù)分析: MySQL的慢查詢?nèi)罩九浜蟨t-query-digest
老楊的五步排查法
第一步：把服務(wù)調(diào)用關(guān)系搞清楚
這是最關(guān)鍵的一步。很多人上來(lái)就開(kāi)始瞎猜，其實(shí)你得先知道A服務(wù)到底調(diào)用了哪些下游服務(wù)。
如果你用的是SkyWalking或者Jaeger，它們都有現(xiàn)成的服務(wù)拓?fù)鋱D。我一般會(huì)先用API拉取服務(wù)列表：
# 獲取所有服務(wù)名稱
$ curl -s 'http://jaeger-query:16686/api/services' | jq '.'輸出大概是這樣：
[
"order-service",
"user-service",
"payment-service",
"product-service"
]沒(méi)有鏈路追蹤系統(tǒng)也沒(méi)關(guān)系，在K8s環(huán)境下可以通過(guò)service來(lái)大致了解調(diào)用關(guān)系：
$ kubectl get svc -A -o wide | head -5NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
prod order-svc ClusterIP 10.96.23.12 <none> 80/TCP 120d
prod user-svc ClusterIP 10.96.45.88 <none> 80/TCP 120d
...有了這個(gè)"懷疑名單"，后面的排查就有方向了。
第二步：用指標(biāo)數(shù)據(jù)找熱點(diǎn)
這一步是要找出到底哪個(gè)服務(wù)的延遲異常高或者錯(cuò)誤率飆升。Prometheus在這里就派上用場(chǎng)了。
我經(jīng)常用的一個(gè)查詢是看各服務(wù)的95分位延遲：
$ curl -s 'http://prometheus:9090/api/v1/query?query=histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le,service))'假設(shè)得到的結(jié)果是：
{
"status":"success",
"data":{"result":[
{"metric":{"service":"order-service"},"value":[1620000000,"0.42"]},
{"metric":{"service":"payment-service"},"value":[1620000000,"1.85"]},
{"metric":{"service":"user-service"},"value":[1620000000,"0.10"]}
]}
}一眼就能看出來(lái)，payment-service的95分位延遲是1.85秒，比其他服務(wù)高出太多了。這基本就鎖定了問(wèn)題范圍。
同時(shí)我也會(huì)查一下錯(cuò)誤率：
$ curl -s 'http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{code=~"5.."}[5m])) by (service)'第三步：用鏈路追蹤還原慢調(diào)用的詳細(xì)過(guò)程
有了懷疑目標(biāo)，接下來(lái)就要看具體是哪個(gè)環(huán)節(jié)慢了。鏈路追蹤在這里特別有用，能告訴你時(shí)間都花在哪兒了。
# 查詢payment-service的慢請(qǐng)求追蹤
$ curl -s 'http://jaeger-query:16686/api/traces?service=payment-service&limit=5&duration=300000' | jq '.data[0]'典型的輸出可能是：
{
"traceID":"abcd1234",
"spans":[
{"operationName":"HTTP GET /order","duration":120000, "process":{"serviceName":"order-service"}},
{"operationName":"HTTP POST /payment/charge","duration":110000, "process":{"serviceName":"payment-service"}},
{"operationName":"SELECT FROM payments","duration":105000, "process":{"serviceName":"mysql"}}
]
}這個(gè)追蹤結(jié)果就很清晰了：總耗時(shí)120ms，其中110ms花在payment服務(wù)的charge操作上，而charge操作里又有105ms是在等MySQL的SELECT查詢。問(wèn)題基本定位到數(shù)據(jù)庫(kù)層面了。
第四步：看日志確認(rèn)具體異常
光有數(shù)字還不夠，得看看具體的錯(cuò)誤信息和異常棧。
$ kubectl logs deploy/payment-deployment -n prod --tail 200 | grep -i error經(jīng)常能看到這樣的日志：
2024-12-01T10:12:05Z ERROR PaymentProcessor.java:78 - Timeout when calling db: SELECT * FROM payments WHERE user_id=? (timeout 1000ms)
2024-12-01T10:12:06Z WARN RateLimiter - Connection retry attempt 3/3 failed
...到這里基本就能確認(rèn)是數(shù)據(jù)庫(kù)連接超時(shí)導(dǎo)致的問(wèn)題了。
第五步：從系統(tǒng)資源層面確認(rèn)根因
最后還得確認(rèn)是應(yīng)用邏輯的問(wèn)題，還是底層資源不夠用了。
# 看Pod的資源使用情況
$ kubectl top pod payment-deployment-xxxxx -n prod
# 如果能SSH到宿主機(jī)，看看IO情況
$ iostat -x 1 2假設(shè)得到：
# kubectl top pod輸出
NAME CPU(cores) MEMORY(bytes)
payment-deployment-xxxxx 900m 1.2Gi
# iostat輸出顯示磁盤(pán)IO等待時(shí)間很高
Device r/s w/s await
sda 10.2 85.3 60.32如果看到await這么高（60ms），基本就是磁盤(pán)IO成為瓶頸了?？赡苁菙?shù)據(jù)庫(kù)所在的存儲(chǔ)性能跟不上，或者有其他進(jìn)程在瘋狂寫(xiě)磁盤(pán)。
幾個(gè)常見(jiàn)坑和對(duì)應(yīng)的排查命令
(1) CPU被限流了（很容易被忽略）
這個(gè)問(wèn)題特別隱蔽，容器看起來(lái)CPU使用率不高，但實(shí)際上被cgroup限流了。
# 找到容器ID
$ docker ps --format '{{.ID}} {{.Names}}' | grep payment
c3f2a7b9db9a payment-deployment-xxxxx
# 查看CPU統(tǒng)計(jì)
$ cat /sys/fs/cgroup/cpu,cpuacct/docker/c3f2a7b9db9a/cpu.stat如果看到：
nr_periods 240
nr_throttled 56
throttled_time 48000000nr_throttled大于0就說(shuō)明被限流了。這時(shí)候要么調(diào)整Pod的resource limits，要么考慮換到CPU資源更充足的節(jié)點(diǎn)。
(2) 網(wǎng)絡(luò)延遲和丟包
有時(shí)候問(wèn)題出在網(wǎng)絡(luò)層面，特別是在容器環(huán)境下。
# 從Pod內(nèi)部ping一下下游服務(wù)
$ kubectl exec -it payment-pod -- ping -c 5 mysql-0.mysql.prod.svc.cluster.local
# 測(cè)試網(wǎng)絡(luò)帶寬
$ iperf3 -c 10.10.0.5 -p 5201 -t 10如果ping的時(shí)延超過(guò)幾十毫秒，或者iperf3顯示帶寬明顯偏低，就要懷疑網(wǎng)絡(luò)或者CNI插件的問(wèn)題了。
(3) 數(shù)據(jù)庫(kù)慢查詢
數(shù)據(jù)庫(kù)問(wèn)題基本占了我遇到過(guò)的性能問(wèn)題的一半以上。
# 看看有多少慢查詢
$ mysql -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"
# 用pt-query-digest分析慢日志（這個(gè)工具真的好用）
$ pt-query-digest /var/log/mysql/slow.log | head -50pt-query-digest的輸出特別直觀：
# Query 1: 0.12 QPS, 1.45x concurrency, ID 0x8DFD0D6B15D10734...
# Time range: 2024-12-01T09:00:00 to 2024-12-01T10:00:00
# Response time: 95% 1.2s, 99% 2.5s
SELECT user_id, payment_status FROM payments WHERE created_at > ?一看就知道這個(gè)查詢占用了絕大部分?jǐn)?shù)據(jù)庫(kù)時(shí)間，而且響應(yīng)時(shí)間很高。
寫(xiě)一個(gè)快速診斷的示例腳本
把上面這些檢查項(xiàng)串起來(lái)，寫(xiě)成一個(gè)腳本，這樣每次遇到問(wèn)題都能快速過(guò)一遍：
#!/bin/bash
# quick_diagnose.sh - 老楊的快速診斷腳本
SERVICE_NS=prod
SERVICE_NAME=payment-deployment
PROM_URL=http://prometheus:9090
JAEGER_URL=http://jaeger-query:16686
echo"=== 資源使用情況 ==="
kubectl top pod -l app=${SERVICE_NAME} -n ${SERVICE_NS} || echo"無(wú)法獲取資源信息"
echo -e "\n=== 延遲情況 ==="
curl -s "${PROM_URL}/api/v1/query?query=histogram_quantile(0.95,sum(rate(http_request_duration_seconds_bucket{service=\"payment-service\"}[5m])) by (le))" | jq -r '.data.result[0].value[1] // "無(wú)數(shù)據(jù)"' | awk '{printf "95分位延遲: %.2fs\n", $1}'
echo -e "\n=== 最新錯(cuò)誤日志 ==="
kubectl logs -l app=${SERVICE_NAME} -n ${SERVICE_NS} --tail 20 | grep -i "error\|exception\|timeout" | tail -5
echo -e "\n=== 節(jié)點(diǎn)IO情況 ==="
NODE=$(kubectl get pod -l app=${SERVICE_NAME} -n ${SERVICE_NS} -o jsonpath='{.items[0].spec.nodeName}')
if [ ! -z "$NODE" ]; then
echo"節(jié)點(diǎn): $NODE"
ssh $NODE"iostat -x 1 1" 2>/dev/null || echo"無(wú)法連接到節(jié)點(diǎn)"
fi這個(gè)腳本跑一遍，基本就能對(duì)問(wèn)題有個(gè)大概的了解了。
決策優(yōu)先級(jí)：先修什么后修什么
排查出問(wèn)題后，還要決定先解決哪個(gè)。我一般按這個(gè)優(yōu)先級(jí)：
- 影響面最大的先修：如果錯(cuò)誤率很高，影響大量用戶，這個(gè)優(yōu)先級(jí)最高
- 下游問(wèn)題優(yōu)先于上游：鏈路追蹤顯示是數(shù)據(jù)庫(kù)慢，就先優(yōu)化數(shù)據(jù)庫(kù)，別在應(yīng)用層繞彎子
- 資源瓶頸優(yōu)先于代碼優(yōu)化：CPU、IO、網(wǎng)絡(luò)這些基礎(chǔ)資源問(wèn)題不解決，代碼優(yōu)化效果有限
- 止血優(yōu)先于根治：比如先把超時(shí)時(shí)間調(diào)短、重試次數(shù)減少，避免雪崩，然后再慢慢優(yōu)化
建立長(zhǎng)效機(jī)制，別讓問(wèn)題重復(fù)出現(xiàn)
光解決問(wèn)題還不夠，還得防止類似問(wèn)題再次發(fā)生：
- 設(shè)置監(jiān)控告警：關(guān)鍵服務(wù)的P95延遲、錯(cuò)誤率都要有告警閾值，出問(wèn)題了第一時(shí)間知道。
- 建立SLO：比如訂單服務(wù)的P99延遲不超過(guò)500ms，支付服務(wù)的可用性不低于99.9%。有了具體目標(biāo)，優(yōu)化就有方向了。
- 定期壓測(cè)：每次發(fā)版前，或者定期在低峰期做一次壓測(cè)，確保系統(tǒng)能承受預(yù)期的流量。
- 記錄排查過(guò)程：每次解決問(wèn)題后，都把排查過(guò)程和解決方案記錄下來(lái)。下次遇到類似問(wèn)題，直接參考之前的經(jīng)驗(yàn)。
