MySQL 是个服务,所以我们可以借用 Google 四个黄金指标的思路来解决问题。
1、延迟
应用程序会向 MySQL 发起 SELECT、UPDATE 等操作,处理这些请求花费了多久,是非常关键的,甚至我们还想知道具体是哪个 SQL 最慢,这样就可以有针对性地调优。
- 在客户端埋点。即上层业务程序在请求 MySQL 的时候,记录一下每个 SQL 的请求耗时,把这些数据统一推给监控系统,监控系统就可以计算出平均延迟、95 分位、99 分位的延迟数据了。不过因为要埋点,对业务代码有一定侵入性。
- Slow queries。。MySQL 提供了慢查询数量的统计指标:
show global status like 'Slow_queries'; SHOW VARIABLES LIKE 'long_query_time';
-
通过 performance schema 和 sys schema 拿到统计数据。比如 performance schema 的 events_statements_summary_by_digest 表,这个表捕获了很多关键信息,比如延迟、错误量、查询量。
2、流量
统计 SELECT、UPDATE、DELETE、INSERT 等语句执行的数量。如果流量太高,超过了硬件承载能力,显然是需要监控、需要扩容的。这些类型的指标在 MySQL 的全局变量中都可以拿到。
show global status where Variable_name regexp 'Com_insert|Com_update|Com_delete|Com_select|Questions|Queries';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Com_delete | 2091033 |
| Com_delete_multi | 0 |
| Com_insert | 8837007 |
| Com_insert_select | 0 |
| Com_select | 226099709 |
| Com_update | 24218879 |
| Com_update_multi | 0 |
| Empty_queries | 25455182 |
| Qcache_queries_in_cache | 0 |
| Queries | 704921835 |
| Questions | 461095549 |
| Slow_queries | 107 |
+-------------------------+-----------+
12 rows in set (0.001 sec)
这些指标都是 Counter 类型,单调递增,另外 Com_ 是 Command 的前缀,即各类命令的执行次数。整体吞吐量主要是看 Questions 指标,但 Questions 很容易和它上面的 Queries 混淆。从例子里我们可以明显看出 Questions 的数量比 Queries 少。Questions 表示客户端发给 MySQL 的语句数量,而 Queries 还会包含在存储过程中执行的语句,以及 PREPARE 这种准备语句,所以监控整体吞吐一般是看 Questions。
流量方面的指标,一般我们会统计写数量(Com_insert + Com_update + Com_delete)、读数量(Com_select)、语句总量(Questions)。
3、错误
错误量这类指标有多个应用场景,比如客户端连接 MySQL 失败了,或者语句发给 MySQL,执行的时候失败了,都需要有失败计数。
- 在客户端采集、埋点,不管是 MySQL 的问题还是网络的问题,亦或者中间负载均衡的问题或 DNS 解析的问题,只要连接失败了,都可以发现。缺点就是会有代码侵入性。
- 从 MySQL 中采集相关错误,比如连接错误可以通过 Aborted_connects 和 Connection_errors_max_connections 拿到。
4、饱和度
首先我们要关注 MySQL 所在机器的 CPU、内存、硬盘 I/O、网络流量这些基础指标。
MySQL 本身也有一些指标来反映饱和度,比如刚才我们讲到的连接数,当前连接数(Threads_connected)除以最大连接数(max_connections)可以得到连接数使用率,是一个需要重点监控的饱和度指标。
此文章为8月Day6学习笔记,内容来源于极客时间《运维监控系统实战笔记》,推荐该课程。