深夜惊魂：当监控告警“撒谎”时，SRE 如何逆风翻盘？-CSDN博客

本文链接：https://blog.csdn.net/2201_75340297/article/details/146201640

Yorkshire, England

引言

我们这一篇也是含金量十足，如果面试官让你说个你处理过的比较有意思的案例，可以跟他讲讲，让他也见见世面。

好吧，我们直接开始，最后有相关的群，有兴趣可以加入。

开始

一、故障场景深度还原

时间：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分钟 - 多维度验证告警真实性

跨数据源验证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%

分析监控链路差异
数据源 CPU指标可信度分析
Prometheus 95% 采集链路可能异常
KubeBlocks Dashboard 32% 直接读取数据库宿主节点指标
数据库Pod内top命令 20% 真实负载

数据源	CPU指标	可信度分析
Prometheus	95%	采集链路可能异常
KubeBlocks Dashboard	32%	直接读取数据库宿主节点指标
数据库Pod内`top`命令	20%	真实负载

初步结论：

• 监控数据失真：Prometheus采集的MySQL Exporter指标异常
• 业务延迟根因：需排查应用层（如缓存击穿）或数据库慢查询

阶段2：根因定位 - Prometheus采集链路深度排查

检查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: instance

验证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计入用户CPU

定位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：修复验证与业务恢复

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.yaml

缓存服务修复（示例）

# 发现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原生监控数据对比校验	新增告警规则：`abs(prometheus_cpu - kubeblocks_cpu) > 20`触发告警
缓存架构	Redis集群未启用自动故障转移	启用KubeBlocks Redis Cluster自动恢复策略

KubeBlocks专项优化

版本管理自动化

# 集群定义中增加版本约束
apiVersion: apps.kubeblocks.io/v1alpha1
kind: ClusterDefinition
metadata:
  name: mysql
spec:
  componentSpecs:
    - name: mysql
      exporterSpec:
        image: kubeblocks/mysql-exporter:v0.24.0
        autoUpdate: true  # 启用自动升级

监控数据校验机制

# 定时对比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 version

2. 信息同步模板（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监控体系

监控双保险：
- • Prometheus采集业务指标 + KubeBlocks原生运维指标
- • 关键指标必须跨系统校验（如CPU、内存、连接数）
版本治理：
- • 启用KubeBlocks组件自动升级策略
- • 定期执行kubectl kb check-updates
故障自愈：
- • 配置KubeBlocks集群自动扩缩容（如Redis节点故障自动替换）
- • 集成Prometheus告警与KubeBlocks Webhook实现自动修复

最终效果：