1. 系统与MySQL核心监控指标解析
在数据库运维工作中,监控指标就像汽车的仪表盘,能直观反映系统运行状态。对于MySQL数据库而言,监控指标主要分为系统级和数据库级两大类。系统级指标关注服务器资源使用情况,数据库级指标则聚焦MySQL内部运行机制。
1.1 系统级核心监控指标
系统级指标是数据库稳定运行的基石,主要包括:
-
CPU使用率:建议设置阈值告警在70%-80%之间。长期高于此值可能导致查询响应变慢。可以通过
top命令或vmstat 1实时查看CPU负载情况。 -
内存使用:重点关注以下两个指标:
- 物理内存使用率:MySQL实例专用服务器建议保留20%缓冲
- Swap使用量:出现Swap说明物理内存不足,需要立即处理
-
磁盘I/O:关键指标包括:
- IOPS:普通SATA盘约100-200,SSD可达数千
- 磁盘利用率:持续高于70%需要考虑扩容
- 读写延迟:通常应<10ms
-
网络流量:监控进出流量,异常突增可能是攻击或应用BUG导致。
1.2 MySQL数据库级核心指标
数据库级指标反映MySQL内部运行状态,主要包括:
连接相关指标:
- 当前连接数:
show status like 'Threads_connected' - 最大连接数:
show variables like 'max_connections' - 连接失败率:
Aborted_connects/Connections
查询性能指标:
- QPS:每秒查询量,反映数据库负载
- TPS:每秒事务数,OLTP系统关键指标
- 慢查询数:
slow_queries计数器
InnoDB引擎指标:
- Buffer Pool命中率:应>95%
- 脏页比例:
innodb_buffer_pool_pages_dirty - 行锁等待:
innodb_row_lock_waits
2. 监控工具与配置实操
2.1 原生监控工具使用
MySQL自带多种监控方式:
SHOW命令系列:
sql复制SHOW STATUS; -- 查看所有状态变量
SHOW ENGINE INNODB STATUS; -- 详细InnoDB状态
SHOW PROCESSLIST; -- 查看当前连接
Performance Schema:
sql复制-- 启用performance_schema
UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES';
UPDATE setup_consumers SET ENABLED = 'YES';
Sys Schema:
sql复制-- 查看等待事件
SELECT * FROM sys.waits_global_by_latency;
-- 查看内存使用
SELECT * FROM sys.memory_global_by_current_bytes;
2.2 第三方监控方案部署
Prometheus + Grafana方案:
- 安装MySQL exporter:
bash复制wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.14.0/mysqld_exporter-0.14.0.linux-amd64.tar.gz
tar xvfz mysqld_exporter-*.tar.gz
cd mysqld_exporter-*
- 创建监控用户:
sql复制CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'password' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
- 配置exporter:
yaml复制# my.cnf添加
[client]
user=exporter
password=password
- 启动exporter:
bash复制./mysqld_exporter --config.my-cnf=".my.cnf"
- Grafana导入MySQL仪表板(ID:7362)
3. 关键指标告警设置指南
3.1 告警阈值建议
根据生产环境经验,推荐以下告警阈值:
| 指标类别 | 指标名称 | 警告阈值 | 严重阈值 |
|---|---|---|---|
| 系统资源 | CPU使用率 | 70% | 90% |
| 内存使用率 | 80% | 90% | |
| 磁盘空间使用率 | 75% | 90% | |
| MySQL连接 | 连接数使用率 | 70% | 90% |
| 连接错误率 | 1% | 5% | |
| 查询性能 | 慢查询数量(每分钟) | 10 | 50 |
| 查询响应时间P99 | 500ms | 1s | |
| InnoDB | Buffer Pool命中率 | <95% | <90% |
| 脏页比例 | 30% | 50% |
3.2 告警规则配置示例(Prometheus)
yaml复制groups:
- name: mysql-alerts
rules:
- alert: HighCPUUsage
expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage on MySQL server"
description: "CPU usage is {{ $value }}%"
- alert: LowBufferPoolHitRatio
expr: (1 - (mysql_innodb_buffer_pool_reads / mysql_innodb_buffer_pool_read_requests)) * 100 < 90
for: 15m
labels:
severity: critical
annotations:
summary: "Low InnoDB buffer pool hit ratio"
description: "Buffer pool hit ratio is {{ $value }}%"
4. 性能问题诊断与优化
4.1 常见性能问题排查流程
-
连接数暴增:
- 检查
SHOW PROCESSLIST找出异常连接 - 分析应用连接池配置
- 检查是否有连接泄漏
- 检查
-
CPU使用率高:
sql复制-- 查看当前运行查询 SELECT * FROM performance_schema.threads WHERE PROCESSLIST_COMMAND != 'Sleep'; -- 检查锁等待 SELECT * FROM sys.innodb_lock_waits; -
内存不足:
- 检查
innodb_buffer_pool_size设置(建议70-80%物理内存) - 分析内存使用明细:
sql复制SELECT * FROM sys.memory_global_by_current_bytes WHERE current_alloc > 100000000; - 检查
4.2 优化案例:慢查询处理
问题现象:
监控显示慢查询数量突增,CPU使用率升高。
排查步骤:
- 开启慢查询日志:
sql复制SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 'ON';
- 分析慢日志:
bash复制mysqldumpslow -s t /var/log/mysql/mysql-slow.log
- 使用EXPLAIN分析问题查询:
sql复制EXPLAIN FORMAT=JSON
SELECT * FROM orders WHERE create_time > '2023-01-01';
- 优化方案:
- 添加缺失索引
- 重写复杂查询
- 优化JOIN操作
5. 监控系统维护与管理
5.1 监控数据保留策略
- 原始采样数据:保留7天
- 5分钟聚合数据:保留1个月
- 1小时聚合数据:保留1年
- 每日快照数据:永久保留
Prometheus配置示例:
yaml复制remote_write:
- url: "http://victoriametrics:8428/api/v1/write"
queue_config:
capacity: 10000
max_shards: 30
min_shards: 1
max_samples_per_send: 1000
5.2 监控系统高可用保障
-
Prometheus高可用方案:
- 部署2个以上Prometheus实例
- 使用相同的采集配置
- 通过负载均衡提供服务
-
告警去重处理:
yaml复制# Alertmanager配置
route:
group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
receiver: 'slack-notifications'
- 监控系统自监控:
- 监控exporter采集状态
- 监控Prometheus自身资源使用
- 设置监控系统健康检查
在实际运维中,我发现最有效的监控策略是"分层监控":基础资源监控作为第一道防线,数据库指标监控作为第二层,业务指标监控作为最后保障。同时,告警设置要遵循"三次法则"——连续触发三次才真正告警,避免告警风暴。
