高可用架構若無精細監控，前期投入極易功虧一篑。本文基於《MySQL性能調優與架構設計》第 18 章，構建「採集-分析-存儲-處理」四層監控架構，詳細列舉主機/數據庫健康狀態、性能指標 50+ 關鍵監控點及計算公式，並對比 Nagios、MRTG、Cacti 三大開源工具優劣，助力構建生產級監控體系。
+----------------+ +----------------+ +----------------+ +----------------+
| 信息採集層 | --> | 信息分析層 | --> | 信息存儲層 | --> | 信息處理層 |
| (主動輪詢/被動推送) | | (實時判斷/告警) | | (時序數據/RRD) | | (趨勢圖/容量規劃) |
+----------------+ +----------------+ +----------------+ +----------------+
↑ ↓
└---------------------- 告警通知 (郵件/短信/IM/Webhook) ---------------┘
| 指標 | 採集方式 | 異常閾值建議 |
|---|---|---|
| 網絡連通性 | Ping / Telnet 3306 / SSH 試連 | 連續 3 次失敗告警 |
| 系統日誌錯誤 | sec / logwatch 監控 /var/log/messages | 關鍵字：error, fail, disk, memory, kernel panic |
| 磁碟空間 | df -h 解析各分區使用率 | > 80% 預警, > 90% 嚴重 |
| 內存使用 | free -m 解析 Mem/Swap | 可用內存 < 10% 或 Swap 使用 > 50% |
| 進程數 | ps -ef | grep mysqld | wc -l | mysqld 進程數 ≠ 1 (含 mysqld_safe) 即異常 |
| 指標 | 檢測命令/SQL | 關鍵判斷邏輯 |
|---|---|---|
| 服務端口 3306 | telnet host 3306 或 nc -z host 3306 | TCP 三次握手成功 = 存活 |
| Socket 文件 | mysql -S /tmp/mysql.sock -e "SELECT 1" | 實際連接驗證，非僅文件存在 |
| mysqld/mysqld_safe 進程 | ps -ef | grep -E "mysqld$|mysqld_safe" | grep -v grep | 進程存在且非僵屍狀態 |
| Error Log 異常 | sec/logwatch 監控 log_error 路徑 | 匹配 ERROR, WARNING, Assertion, Signal |
| 復制狀態 | SHOW SLAVE STATUS\G | Slave_IO_Running=Yes 且 Slave_SQL_Running=Yes；Seconds_Behind_Master 非 NULL |
核心指標均源自 SHOW GLOBAL STATUS 與 SHOW GLOBAL VARIABLES，注意均為累計值，需按時間差計算速率。
uptime 取 1/5/15 分鐘值，超過 CPU 核心數持續高位 → CPU 瓶頸。top -bn1 / vmstat 1 5 解析 us/sy/id/wa/st，關注 wa (iowait) > 20% 疑似磁碟瓶頸。iostat -xmt 1 觀察 %util、await、svctm、r/s、w/s、rkB/s、wkB/s。vmstat 1 觀察 si/so 持續非零 → 內存壓力大。ifstat -i eth0 1 / sar -n DEV 1 / 交換機 SNMP 監控。| 指標 | 計算公式 | 關鍵狀態變量 | 健康基線 |
|---|---|---|---|
| QPS | Questions/Δt (5.1.30-) 或 Queries/Δt (5.1.31+) | Questions, Queries | 業務基線 ± 30% |
| TPS | (Com_commit+Com_rollback)/Δt (含 XA: +Com_xa_commit+Com_xa_rollback) | Com_commit, Com_rollback | 業務基線 ± 30% |
| Key Buffer 命中率 | (1-Key_reads/Key_read_requests)*100% (讀) / (1-Key_writes/Key_write_requests)*100% (寫) | Key_read*, Key_write* | > 95% (MyISAM) |
| InnoDB Buffer Pool 命中率 | (1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests)*100% | Innodb_buffer_pool_read* | > 99% |
| Query Cache 命中率 | Qcache_hits/(Qcache_hits+Qcache_inserts)*100% | Qcache_hits, Qcache_inserts | > 80% (若啟用 QC) |
| Table Cache 使用率 | Open_tables/Opened_tables*100% | Open_tables, Opened_tables | > 80% (調整 table_open_cache) |
| Thread Cache 命中率 | (1-Threads_created/Connections)*100% | Threads_created, Connections | > 90% (調整 thread_cache_size) |
| 表鎖爭用率 | Table_locks_waited/Table_locks_immediate*100% | Table_locks_* | < 1% (高則優化 SQL/引擎/邏輯) |
| InnoDB 行鎖 | 關注 Innodb_row_lock_waits, Innodb_row_lock_time_avg, Innodb_row_lock_time_max | Innodb_row_lock_* | waits 低、avg 時間短 |
| 復制延遲 | Seconds_Behind_Master (Slave 執行) | Seconds_Behind_Master | < 1s (同城), < 10s (跨城) |
| 臨時表磁碟化率 | Created_tmp_disk_tables/Created_tmp_tables*100% | Created_tmp_* | < 10% (調大 tmp_table_size/max_heap_table_size) |
| Binlog Cache 磁碟化 | Binlog_cache_disk_use > 0 → 增大 binlog_cache_size | Binlog_cache_* | = 0 |
| InnoDB Log 等待 | Innodb_log_waits > 0 → 增大 innodb_log_buffer_size | Innodb_log_waits | = 0 |
| 工具 | 定位 | 強項 | 弱項 | 適用場景 |
|---|---|---|---|---|
| Nagios | 監控平台 | 插件生態豐富、被動/主動雙模、多級告警、Downtime 維護窗口、Web UI 完善 | 無性能趨勢圖、大規模輪詢性能瓶頸、配置文件繁瑣 | 健康狀態告警主力、中小規模集群 |
| MRTG | 流量/性能趨勢繪圖 | SNMP 採集、RRDTool 存儲、HTML 靜態圖輸出、配置簡單 (腳本返回值即可) | 無告警功能、單圖僅 2 條曲線、無多用戶權限 | 網絡/磁碼/CPU/QPS 等單指標趨勢圖 |
| Cacti | 全功能監控+繪圖 | PHP+MySQL 架構、SNMP 採集、RRDTool 存儲、單圖無限曲線、多用戶權限、模板機制強 | 告警功能弱於 Nagios、大規模採集器性能需優化 | 大規模集群性能趨勢+多部門自助監控 |
實踐組合：Nagios 做健康告警 + MRTG/Cacti 做性能趨勢，或直接上 Prometheus + Grafana + Alertmanager 現代化棧（本書未覆蓋但強烈推薦）。
Round Robin Database：環狀存儲，固定空間自動覆蓋舊數據，內建統計聚合 (AVERAGE/MAX/MIN/LAST)，天生適合監控時序數據存儲與繪圖，僅支援數值類型。
check_mysql_health、check_replication、check_innodb_metrics、check_disk、check_load、check_mem、check_swap。監控不直接提升性能，但能將「發現問題時間」壓縮到分鐘級甚至秒級，間接大幅提升可用性。健康狀態監控保底線，性能指標監控防患未然，趨勢分析支撐容量規劃。工具選型以開源為主，核心在於指標體系完整性、告警收斂準確性、數據留存可查詢性。建議新項目直接採用 Prometheus 生態，存量系統按上述指標體系補齊即可。
