共计 1417 个字符，预计需要花费 4 分钟才能阅读完成。
作者：王春涛
目前是多点 Dmall 数据库架构师，更早是聚美数据库团队负责人，善于高并发下数据库架构，运维保障，数据库平台建设。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
慢查问监控是 MySQL 运维中十分重要的一项，它能够帮忙分析线上数据库性能的抖动或者业务查问响应慢等状况。当集群和实例十分多的状况下，慢查问的收集和存储会变得比拟艰难，而且不太好做到实时的慢查问告警。
罕用计划介绍
1、慢日志收集
通常状况下会采纳通过定时工作的形式应用 pt-query-digest 将每个实例的慢日志收集写入到 MySQL 数据库。因为是定时工作触发，所以并不是实时的进行收集上报。
2、慢日志统计
通过查问 MySQL 数据库能够依据 host、port、user、指纹、工夫范畴等条件进行查问统计
3、慢日志告警
从 MySQL 中查问出慢日志而后匹配到对应的 DBA 和研发人员发送告警。但因为 MySQL 中数据是全量存在的只能依据工夫范畴进行批次查问，告警就无奈做到实时。
pt-query-digest 的办法在采集的时候就曾经不是实时了，再加上告警工作是按工夫范畴进行批次查问所以这套架构下的慢查问监控不能做到实时的监控
上面给大家介绍一下多点数据库实时慢查问监控的实现思路。
多点实时慢查问监控整体架构
如上图，咱们有一个监听 slowlog 的 agent，这个 agent 次要是继续的对慢查问 log 文件进行 tail，将每一个 slowlog 段作为一个 list 的 iterm push 到 redis。每个 agent 能够监听所在机器的所有 MySQL 实例的慢日志，这样就把扩散在各个机器上的日志会集到了一个 redis 中。而后有一个生产端也就是 slowlog 推送服务，从 redis 中 pop 出组装好的慢日志，依据 pop 出的慢日志解析其中的 host，port，dbname 以及 user，匹配到对应的 dba 或研发，将慢日志实时推送给对应的人员。同时依照 host-port 将慢查问存储为文件。这样就造成了一个流式的解决，再加上 redis 的全内存操作，速度极快，齐全能够做到实时。
采集端实现
咱们能够看到慢查问日志个别是一段一段的记录的，所以咱们以 # Time 行开始记录，直到遇到下一个 # Time 将两头的一段作为一个整体 push 到 redis，但这些信息远远不够，还须要额定退出 MySQL 的实例信息，后续才好进行剖析，所以最终到 redis 中的数据应该相似下图
生产端实现
生产端做两件事件，第一将 pop 进去的音讯依据 ip:port 为文件名进行日志归类寄存，以便后续应用 pt-query-digest 对日志文件进行进一步统计分析。第二依据 ip:port 查问到对应的集群负责人和 DBA，将慢查问通过短信或者邮件推送给对应的人员。
前端展现
- 集中寄存的慢日志文件
按集群维度 + 实例维度展现某时间段的慢日志大小，点击剖析按钮可调用 pt-query-digest 对慢日志文件进行剖析，输入后果如下：
- 实时慢 SQL
这个实时信息就是从 redis 中 pop 进去的，能够进行实时的滚动展现，同时能够通过邮件等形式实时推送给订阅者。
预报一波
往年 10 月 24 日下午 14:00-18:00，D+Talks 2021 多点技术大会将拉开帷幕，届时将在会上分享多点的数据库运维平台相干的 topic，和大家一起探讨数据库运维的标准化、自动化方面的一些办法和思路，欢送辨认下图二维码加入线下流动，与行业大咖独特探讨!
