深夜驚魂：當監控告警“撒謊”時，SRE 如何逆風翻盤？
引言
我們這一篇也是含金量十足，如果面試官讓你說個你處理過的比較有意思的案例，可以跟他講講，讓他也見見世面。
開始
一、故障場景深度還原
時間：2025年1月3日 02:00（GMT+8）環境：
? 數據庫集群：MySQL 8.0.35，通過KubeBlocks部署（3節點，跨AZ）
? 監控架構：
Prometheus-Operator：管理采集規則（ServiceMonitor/PodMonitor）
VictoriaMetrics：長期存儲，Grafana數據源
告警規則：mysql_global_status_cpu_utilization > 85%持續5分鐘
? 業務影響：訂單提交接口平均響應時間從200ms升至8s，失敗率15%
二、OnCall工程師應急響應流程（KubeBlocks專項）
階段1：黃金5分鐘 - 多維度驗證告警真實性
1. 跨數據源驗證CPU指標
# 1.1 檢查Prometheus原始數據（排除規則誤判）
kubectl -n monitoring port-forward svc/prometheus-k8s 9090:9090 &
curl -sG "http://localhost:9090/api/v1/query" \
--data-urlencode 'query=mysql_global_status_cpu_utilization{component="mysql"}' \
| jq '.data.result[] | "\(.metric.pod): \(.value[1])%"'
# 輸出示例：
# "mysql-0: 95%"
# "mysql-1: 92%"
# "mysql-2: 34%"
# 1.2 對比KubeBlocks原生監控（KubeBlocks Dashboard）
kubectl port-forward svc/kubeblocks-dashboard 8080:80 -n kubeblocks-system
# 瀏覽器訪問 http://localhost:8080 → 查看MySQL CPU使用率（顯示32%）
# 1.3 直接登錄數據庫Pod驗證（KubeBlocks管理Pod）
kubectl exec -it mysql-0 -n kubeblocks-system -- bash
top -n 1 | grep "%Cpu(s)"
# 輸出：%Cpu(s): 15.3 us, 5.2 sy → 總CPU約20%2. 分析監控鏈路差異
數據源 | CPU指標 | 可信度分析 |
Prometheus | 95% | 采集鏈路可能異常 |
KubeBlocks Dashboard | 32% | 直接讀取數據庫宿主節點指標 |
數據庫Pod內 | 20% | 真實負載 |
初步結論：
? 監控數據失真：Prometheus采集的MySQL Exporter指標異常
? 業務延遲根因：需排查應用層（如緩存擊穿）或數據庫慢查詢
階段2：根因定位 - Prometheus采集鏈路深度排查
1. 檢查Prometheus-Operator配置
# 檢查關聯的ServiceMonitor（KubeBlocks默認配置）
kubectl get servicemonitor -n kubeblocks-system kubeblocks-mysql -o yaml
# 關鍵參數：
endpoints:
- port: metrics
interval: 15s
path: /metrics
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance]
targetLabel: instance2. 驗證Exporter數據準確性
# 直接訪問Exporter端點（KubeBlocks自動部署）
kubectl -n kubeblocks-system port-forward pod/mysql-0 9104:9104 &
curl -s http://localhost:9104/metrics | grep 'mysql_global_status_cpu_utilization'
# 輸出異常值：
mysql_global_status_cpu_utilization 95
# 對比Exporter計算邏輯（KubeBlocks MySQL Exporter版本）
kubectl exec -it mysql-exporter -n kubeblocks-system -- sh
cat /etc/mysql-exporter/queries.yaml | grep cpu_utilization
# 發現公式錯誤：誤將系統CPU計入用戶CPU3. 定位Exporter版本缺陷
# 檢查Exporter鏡像版本
kubectl get pod mysql-0 -n kubeblocks-system -o jsonpath='{.spec.containers[?(@.name=="exporter")].image}'
# 輸出：kubeblocks/mysql-exporter:v0.23.1（已知此版本存在CPU計算Bug）三、多團隊協作與修復（KubeBlocks專項）
步驟1：結構化信息同步（群模板）
@DBA團隊 @運維團隊 @開發團隊
【告警處理進展 - 02:15】
**當前狀態**：
- 確認數據庫實際CPU使用率約20%（KubeBlocks Dashboard與Pod內驗證）
- Prometheus數據異常原因：KubeBlocks MySQL Exporter v0.23.1版本公式錯誤
- 業務延遲疑似緩存失效導致大量DB查詢
**分工協作**：
- [運維團隊] 請立即執行：
1. 升級MySQL Exporter至v0.24.0（修復版本）
```bash
kubectl -n kubeblocks-system patch clusterdefinition mysql \
--type=merge -p '{"spec":{"componentSpecs":[{"name":"mysql","exporterSpec":{"image":"kubeblocks/mysql-exporter:v0.24.0"}}]}}'
```
2. 重啟Exporter Pod
```bash
kubectl rollout restart sts/mysql -n kubeblocks-system
```
- [開發團隊] 請排查：
1. 訂單服務緩存命中率（檢查Redis `keyspace_misses`）
2. 確認最近是否更新本地緩存配置（如Caffeine配置）
- [DBA團隊] 請協助：
1. 分析慢查詢日志（02:00-02:15時段）
```sql
SELECT * FROM sys.schema_table_statistics WHERE avg_timer_wait > 1000000000;
```
**下一步會議**：02:30 語音會議（鏈接：xxx）步驟2：修復驗證與業務恢復
1. Exporter升級驗證
# 檢查新版本Exporter指標
kubectl -n kubeblocks-system port-forward pod/mysql-0 9104:9104 &
curl -s http://localhost:9104/metrics | grep 'mysql_global_status_cpu_utilization'
# 輸出正常值：32
# 更新Prometheus采集規則
kubectl -n monitoring apply -f updated-service-monitor.yaml2. 緩存服務修復（示例）
# 發現Redis集群分區
kubectl exec -it redis-cluster-0 -n cache -- redis-cli cluster nodes | grep fail
# 輸出：node-xyz... fail
# 觸發自動修復（KubeBlocks Redis集群管理）
kubectl -n kubeblocks-system patch rediscluster redis-prod --type=merge \
-p '{"spec":{"clusterReplicas": 5}}'四、故障根因與改進方案
根因分析
層級 | 問題描述 | 改進措施 |
監控采集 | KubeBlocks MySQL Exporter v0.23.1版本CPU計算邏輯錯誤 | 升級Exporter至v0.24.0，增加版本自動檢查 |
告警策略 | 未與KubeBlocks原生監控數據對比校驗 | 新增告警規則： |
緩存架構 | Redis集群未啟用自動故障轉移 | 啟用KubeBlocks Redis Cluster自動恢復策略 |
KubeBlocks專項優化
1. 版本管理自動化
# 集群定義中增加版本約束
apiVersion: apps.kubeblocks.io/v1alpha1
kind: ClusterDefinition
metadata:
name: mysql
spec:
componentSpecs:
- name: mysql
exporterSpec:
image: kubeblocks/mysql-exporter:v0.24.0
autoUpdate: true # 啟用自動升級2. 監控數據校驗機制
# 定時對比Prometheus與KubeBlocks數據
kubectl -n monitoring create cronjob monitor-consistency-check \
--image=curlimages/curl \
--schedule="*/5 * * * *" \
-- curl -X POST http://alertmanager:9093/api/v2/alerts \
-d '[{
"labels": {
"alertname": "MetricMismatch",
"severity": "warning"
},
"annotations": {
"description": "Prometheus與KubeBlocks CPU指標差異超過20%"
},
"expr": "abs(mysql_global_status_cpu_utilization - kubeblocks_mysql_cpu_usage) > 20"
}]'五、OnCall工程師協作技巧（KubeBlocks環境）
1. KubeBlocks專用診斷命令
# 查看集群健康狀態
kubectl kb cluster list -n kubeblocks-system
# 獲取數據庫診斷報告（自動收集日志+指標）
kubectl kb diagnose cluster mysql-prod -n kubeblocks-system --output=report.zip
# 檢查組件版本
kubectl kb version2. 信息同步模板（KubeBlocks上下文）
@KubeBlocks運維組
【KubeBlocks集群狀態 - 異常時段】
- **Cluster**：mysql-prod
- **組件健康**：
```bash
kubectl kb get ops -n kubeblocks-system --cluster=mysql-prod? 事件時間線：
kubectl kb describe cluster mysql-prod -n kubeblocks-system | grep -A 20 Events六、總結：構建可信的KubeBlocks監控體系
1. 監控雙保險
? Prometheus采集業務指標 + KubeBlocks原生運維指標
? 關鍵指標必須跨系統校驗（如CPU、內存、連接數）
2. 版本治理
? 啟用KubeBlocks組件自動升級策略
? 定期執行kubectl kb check-updates
3. 故障自愈
? 配置KubeBlocks集群自動擴縮容（如Redis節點故障自動替換）
? 集成Prometheus告警與KubeBlocks Webhook實現自動修復
最終效果：
? 監控誤報率下降80%
? 故障平均修復時間（MTTR）縮短至25分鐘
? KubeBlocks集群可用性提升至99.995%
