一、当监控遇上业务：为什么阈值配置不能一刀切？
某在线教育平台的DBA凌晨两点接到告警："CPU使用率超过85%！"，赶到公司发现是视频课程转码程序突然读取全量用户数据。这个案例揭示了三个核心问题：
- 离线业务突然运行：非业务高峰时段的阈值报警可能徒增误报
- 硬件配置差异化：4核机器与64核集群的CPU告警线必然不同
- 业务优先级差异：支付核心库与日志从库的响应延迟容忍度天差地别
groups:
- name: mysql_alerts
rules:
- alert: HighQPS_CoreDB # 核心交易库的QPS告警
expr: rate(mysql_global_status_questions[5m]) > 5000
for: 2m
labels:
severity: critical
annotations:
summary: "核心数据库突发高负载 (实例 {{ $labels.instance }})"
description: "每秒查询量持续2分钟突破5000，当前值: {{ $value }} QPS"
- alert: HighQPS_LogDB # 日志从库的QPS告警
expr: rate(mysql_global_status_questions[5m]) > 15000
for: 5m
labels:
severity: warning
annotations:
summary: "日志从库查询超阈值 (实例 {{ $labels.instance }})"
description: "每秒查询量持续5分钟突破15000，当前值: {{ $value }} QPS"
二、不同业务场景的"警戒线"
场景1：电商大促中的库存服务
关键指标组合：
-- 每秒事务数监控（技术栈：Percona Monitoring Plugins）
SELECT (VARIABLE_VALUE - @prev_commit) / TIMESTAMPDIFF(SECOND, @prev_time, NOW())
FROM information_schema.GLOBAL_STATUS
WHERE VARIABLE_NAME = 'COM_COMMIT'
-- 阈值设置逻辑：
-- 日常阈值：200 TPS
-- 大促阈值：调整至800 TPS（需提前进行压力测试验证）
场景2：金融行业的实时清算系统
必须严格控制的指标：
# 死锁监控脚本（技术栈：Percona Toolkit + Zabbix）
pt-deadlock-logger --user=monitor --password=xxx --interval 5 \
| awk 'BEGIN {count=0} {count++} END {if(count>2) exit 1}'
# 预警设置：
# 五分钟内超过2次死锁立即告警
# 与事务回滚率指标联动分析（回滚率>0.1%时触发人工核查）
场景3：社交媒体的评论服务
突发热点事件的应对方案：
# 自适应阈值算法示例（技术栈：Python + Prometheus Client）
def adaptive_threshold(current_qps):
baseline = get_7d_avg() # 获取七日同期平均值
deviation = current_qps / baseline
if deviation > 3.5: # 瞬时流量激增超过3.5倍
activate_sla_breach_plan() # 触发扩容预案
adjust_alert_threshold(baseline * 4) # 临时调高阈值
三、监控工具Prometheus VS Zabbix
Prometheus方案示例：
# prometheus.yml配置片段
scrape_configs:
- job_name: 'mysql'
static_configs:
- targets: ['mysql01:9104', 'mysql02:9104']
params:
collect[]:
- global_status
- innodb_metrics
- slave_status
Zabbix方案缺陷验证：
/* 传统监控易漏重要指标验证 */
SELECT
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'Innodb_row_lock_current_waits') AS current_locks,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'Innodb_row_lock_time_avg') AS avg_lock_time
-- 多数Zabbix模板未内置这两个关键InnoDB锁指标
-- 需要手动扩展监控项
四、配置阈值的黄金法则
基线比绝对值更重要：用移动平均算法消除周期性波动
# 动态基线计算示例 def dynamic_baseline(): daily_data = get_24h_metrics() hour = datetime.now().hour # 排除异常点后计算同时间段均值 return trimmed_mean([d for d in daily_data if d.hour == hour])指标间要建立关联性检查
-- 连接数与线程运行状态联合分析 SELECT MAX_CONNECTIONS AS max_conn, COUNT(*) AS active_conn, SUM(STATE = 'Sending data') AS busy_threads FROM information_schema.PROCESSLIST -- 当活跃连接超过max_conn的70%且繁忙线程占比>30%时触发告警硬件规格决定阈值范围
# 根据CPU核数自动调整阈值 cpu_cores=$(grep -c ^processor /proc/cpuinfo) alert_cpu=$((cpu_cores * 85)) # 每个核心85%使用率
五、血泪经验：那些年我们踩过的坑
案例1：某P2P公司按照官方建议设置wait_timeout=300，结果因PHP框架缺陷导致连接池泄漏，阈值报警完全失效。最终解决方案：
# mysql_alert_rules.conf
[connection_usage]
metric_name = mysql_global_variables_max_connections
current_used = mysql_global_status_threads_connected
alert_expr = (current_used / metric_name) > 0.7
案例2：忽略复制延迟与磁盘IOPS的关联性，导致主从切换失败。改进后的复合检查策略：
-- 主从复制健康检查增强版
SELECT
SLAVE_IO_RUNNING,
SLAVE_SQL_RUNNING,
SECONDS_BEHIND_MASTER,
(SELECT VARIABLE_VALUE
FROM information_schema.GLOBAL_STATUS
WHERE VARIABLE_NAME = 'Innodb_data_pending_fsyncs') AS pending_fsyncs
-- 当延迟>30秒且pending_fsyncs>100时升级告警等级
六、技术选型的平衡之道
Prometheus方案优势：
- 动态服务发现能力适应云环境
- PromQL支持复杂时序数据分析
# 预测磁盘耗尽时间
predict_linear(mysql_disk_free_bytes[6h], 3600*24) < 0
传统方案的生存空间：
# Shell监控脚本在老旧系统中的应用
check_mysql_health() {
qps=$(mysql -e "SHOW GLOBAL STATUS LIKE 'Questions'" | awk 'NR==2{print $2}')
[ $qps -gt 10000 ] && send_alert "QPS异常增高：当前值 ${qps}"
}
七、智能化监控的三个方向
基于机器学习的异常检测
from sklearn.ensemble import IsolationForest # 使用历史数据训练异常检测模型 model = IsolationForest(contamination=0.01) model.fit(historical_metrics) anomalies = model.predict(current_metrics)可观测性数据的深度融合
// APM与数据库监控关联分析 { "trace_id": "x1y2z3", "db_call": { "query": "SELECT * FROM orders", "duration": "2.3s", "mysql_status": { "lock_wait_time": "1.8s", "buffer_pool_usage": "92%" } } }混沌工程与监控验证
// 模拟网络延迟的混沌测试 func injectLatency(duration time.Duration) { cmd := exec.Command("tc", "qdisc", "add", "dev", "eth0", "root", "netem", "delay", "500ms") _ = cmd.Run() time.Sleep(duration) // 测试后验证监控系统是否及时告警 }
评论