rate(mysql_global_status_questions[2m])
当然上面是总量，我们可以分别从监控读、写指令的分解情况，从而更好地理解数据库的工作负载、找到可能的瓶颈。通常，通常，读取查询会由 Com_select 指标抓取，而写入查询则可能增加三个状态变量中某一个的值，这取决于具体的指令：
Writes = Com_insert + Com_update + Com_delete
下面我们通过命令获取插入的情况：
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE “Com_insert”;
±--------------±------+
| Variable_name | Value |
±--------------±------+
| Com_insert | 10578 |
±--------------±------+
从MySQLD Exporter的/metrics返回的监控样本中，可以通过global_status_commands_total获取当前实例各类指令执行的次数：
# HELP mysql_global_status_commands_total Total number of executed MySQL commands.
# TYPE mysql_global_status_commands_total counter
mysql_global_status_commands_total{command=“create_trigger”} 0
mysql_global_status_commands_total{command=“create_udf”} 0
mysql_global_status_commands_total{command=“create_user”} 1
mysql_global_status_commands_total{command=“create_view”} 0
mysql_global_status_commands_total{command=“dealloc_sql”} 0
mysql_global_status_commands_total{command=“delete”} 3369
mysql_global_status_commands_total{command=“delete_multi”} 0
慢查询性能
=========
查询性能方面，慢查询也是查询告警的一个重要的指标。MySQL还提供了一个Slow_queries的计数器，当查询的执行时间超过long_query_time的值后，计数器就会+1，其默认值为10秒，可以通过以下指令在MySQL中查询当前long_query_time的设置：
MariaDB [(none)]> SHOW VARIABLES LIKE ‘long_query_time’;
±----------------±----------+
| Variable_name | Value |
±----------------±----------+
| long_query_time | 10.000000 |
±----------------±----------+
1 row in set (0.00 sec)
#当然我们也可以修改时间
MariaDB [(none)]> SET GLOBAL long_query_time = 5;
Query OK, 0 rows affected (0.00 sec)
然后我们而已通过sql语言查询MySQL实例中Slow_queries的数量：
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE “Slow_queries”;
±--------------±------+
| Variable_name | Value |
±--------------±------+
| Slow_queries | 0 |
±--------------±------+
1 row in set (0.00 sec)
MySQLD Exporter返回的样本数据中，通过mysql_global_status_slow_queries指标展示当前的Slow_queries的值：
# HELP mysql_global_status_slow_queries Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_slow_queries untyped
mysql_global_status_slow_queries 0
同样的，更具根据Prometheus 慢查询语句我们也可以查询倒他某段时间内的增长率：
rate(mysql_global_status_slow_queries[5m])
连接数监控
=========
监控客户端连接情况相当重要，因为一旦可用连接耗尽，新的客户端连接就会遭到拒绝。MySQL 默认的连接数限制为 151。
MariaDB [(none)]> SHOW VARIABLES LIKE ‘max_connections’;
±----------------±------+
| Variable_name | Value |
±----------------±------+
| max_connections | 151 |
±----------------±------+
当然我们可以修改配置文件的形式来增加这个数值。与之对应的就是当前连接数量，当我们当前连接出来超过系统设置的最大值之后常会出现我们看到的Too many connections(连接数过多)，下面我查找一下当前连接数：
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE “Threads_connected”;
±------------------±------+
| Variable_name | Value |
±------------------±------+
| Threads_connected | 41 |
±------------------±------
当然mysql 还提供Threads_running 这个指标，帮助你分隔在任意时间正在积极处理查询的线程与那些虽然可用但是闲置的连接。
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE “Threads_running”;
±----------------±------+
| Variable_name | Value |
±----------------±------+
| Threads_running | 10 |
±----------------±------+
如果服务器真的达到 max_connections 限制，它就会开始拒绝新的连接。在这种情况下，Connection_errors_max_connections 指标就会开始增加，同时，追踪所有失败连接尝试的Aborted_connects 指标也会开始增加。
MySQLD Exporter返回的样本数据中：
# HELP mysql_global_variables_max_connections Generic gauge metric from SHOW GLOBAL VARIABLES.
# TYPE mysql_global_variables_max_connections gauge
mysql_global_variables_max_connections 151
#表示最大连接数
# HELP mysql_global_status_threads_connected Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_threads_connected untyped
mysql_global_status_threads_connected 41
#表示当前的连接数
# HELP mysql_global_status_threads_running Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_threads_running untyped
mysql_global_status_threads_running 1
#表示当前活跃的连接数
# HELP mysql_global_status_aborted_connects Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_aborted_connects untyped
mysql_global_status_aborted_connects 31
#累计所有的连接数
# HELP mysql_global_status_connection_errors_total Total number of MySQL connection errors.
# TYPE mysql_global_status_connection_errors_total counter
mysql_global_status_connection_errors_total{error=“internal”} 0
#服务器内部引起的错误、如内存硬盘等
mysql_global_status_connection_errors_total{error=“max_connections”} 0
#超出连接处引起的错误
当然根据prom表达式，我们可以查询当前剩余可用的连接数：
mysql_global_variables_max_connections -mysql_global_status_threads_connected
查询mysq拒绝连接数：
mysql_global_status_aborted_connects
缓冲池情况
=========
MySQL 默认的存储引擎 InnoDB 使用了一片称为缓冲池的内存区域，用于缓存数据表与索引的数据。缓冲池指标属于资源指标，而非工作指标，前者更多地用于调查（而非检测）性能问题。如果数据库性能开始下滑，而磁盘 I/O 在不断攀升，扩大缓冲池往往能带来性能回升。
默认设置下，缓冲池的大小通常相对较小，为 128MiB。不过，MySQL 建议可将其扩大至专用数据库服务器物理内存的 80% 大小。我们可以查看一下：
MariaDB [(none)]> show global variables like ‘innodb_buffer_pool_size’;
±------------------------±----------+
| Variable_name | Value |
±------------------------±----------+
| innodb_buffer_pool_size | 134217728 |
±------------------------±----------+
MySQLD Exporter返回的样本数据中，使用mysql_global_variables_innodb_buffer_pool_size来表示。
# HELP mysql_global_variables_innodb_buffer_pool_size Generic gauge metric from SHOW GLOBAL VARIABLES.
# TYPE mysql_global_variables_innodb_buffer_pool_size gauge
mysql_global_variables_innodb_buffer_pool_size 1.34217728e+08
Innodb_buffer_pool_read_requests记录了正常从缓冲池读取数据的请求数量。可以通过以下指令查看
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE “Innodb_buffer_pool_read_requests”;
±---------------------------------±------------+
| Variable_name | Value |
±---------------------------------±------------+
| Innodb_buffer_pool_read_requests | 38465 |
±---------------------------------±------------+
MySQLD Exporter返回的样本数据中，使用mysql_global_status_innodb_buffer_pool_read_requests来表示。
# HELP mysql_global_status_innodb_buffer_pool_read_requests Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_innodb_buffer_pool_read_requests untyped
mysql_global_status_innodb_buffer_pool_read_requests 2.7711547168e+10
当缓冲池无法满足时，MySQL只能从磁盘中读取数据。Innodb_buffer_pool_reads即记录了从磁盘读取数据的请求数量。通常来说从内存中读取数据的速度要比从磁盘中读取快很多，因此，如果Innodb_buffer_pool_reads的值开始增加，可能意味着数据库的性能有问题。可以通过以下只能查看Innodb_buffer_pool_reads的数量：
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE “Innodb_buffer_pool_reads”;
±-------------------------±------+
| Variable_name | Value |
±-------------------------±------+
| Innodb_buffer_pool_reads | 138 |
±-------------------------±------+
1 row in set (0.00 sec)
MySQLD Exporter返回的样本数据中，使用mysql_global_status_innodb_buffer_pool_read_requests来表示。
# HELP mysql_global_status_innodb_buffer_pool_reads Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_innodb_buffer_pool_reads untyped
mysql_global_status_innodb_buffer_pool_reads 138
通过以上监控指标，以及实际监控的场景，我们可以利用PromQL快速建立多个监控项。可以查看两分钟内读取磁盘的增长率的增长率：
rate(mysql_global_status_innodb_buffer_pool_reads[2m])
简单的告警规则
===========
除了相关模板之外，没有告警规则那么我们的监控就是不完美的，下面列一下我们的监控告警规则。
groups:
- name: MySQL-rules
rules:
- alert: MySQL Status
expr: up == 0
for: 5s
labels:
severity: warning
annotations:
summary: “{{$labels.instance}}: MySQL has stop !!!”
description: “检测MySQL数据库运行状态”
- alert: MySQL Slave IO Thread Status
expr: mysql_slave_status_slave_io_running == 0
for: 5s
labels:
severity: warning
annotations:
summary: “{{$labels.instance}}: MySQL Slave IO Thread has stop !!!”
description: “检测MySQL主从IO线程运行状态”
- alert: MySQL Slave SQL Thread Status
expr: mysql_slave_status_slave_sql_running == 0
for: 5s
labels:
severity: warning
annotations:
summary: “{{$labels.instance}}: MySQL Slave SQL Thread has stop !!!”
description: “检测MySQL主从SQL线程运行状态”
- alert: MySQL Slave Delay Status
expr: mysql_slave_status_sql_delay == 30
for: 5s
labels:
severity: warning
annotations:
summary: “{{$labels.instance}}: MySQL Slave Delay has more than 30s !!!”
description: “检测MySQL主从延时状态”
- alert: Mysql_Too_Many_Connections
expr: rate(mysql_global_status_threads_connected[5m]) > 200
for: 2m
labels:
severity: warning
annotations:
summary: “{{$labels.instance}}: 连接数过多”
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
总目录展示
该笔记共八个节点（由浅入深），分为三大模块。
高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。
一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。
高可用。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。
篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）
由于内容太多，这里只截取部分的内容。
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新**
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-0we6bxWM-1712018649647)]
总目录展示
该笔记共八个节点（由浅入深），分为三大模块。
高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。
一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。
高可用。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。
篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）
[外链图片转存中…(img-KakfMZt1-1712018649648)]
[外链图片转存中…(img-5vhTcuFp-1712018649648)]
由于内容太多，这里只截取部分的内容。
7397
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
