一、为什么需要采集MySQL慢查询日志
1.1 实际业务痛点
做开发或运维的同学应该都遇到过这种情况：用户反馈某个功能加载慢，查应用日志找不到问题，查接口耗时却指向数据库，这时候MySQL慢查询日志就是核心线索。比如电商的订单查询接口，偶尔出现3秒以上的响应，排查半天可能发现是某个没加索引的SQL执行了10秒，要是靠手动翻几GB的日志找，花几小时都未必找得到，这时候用Filebeat就轻松很多。
1.2 适用的业务场景
不管是中小团队的日常性能排查，还是大团队的数据库监控，Filebeat采集慢查询日志都很实用：比如给商品搜索模块找慢SQL、给后台报表系统定位查询慢的SQL、给集群环境区分不同节点的慢日志，这些场景都能用到。
二、前期准备：开启MySQL慢查询日志
2.1 MySQL慢查询的配置示例（技术栈：MySQL 5.7）
要让Filebeat采集到有用的日志，首先得在MySQL里开启慢查询，配置非常简单，直接改MySQL的配置文件my.cnf即可，示例带详细注释：
[mysqld]
# 开启慢查询日志，1代表开启，0代表关闭
slow_query_log = 1
# 记录执行时间超过1秒的SQL，可根据业务调整，设太小会生成大量日志，设太大漏过慢SQL
long_query_time = 1
# 慢查询日志的保存路径，要和后续Filebeat配置里的路径一致
slow_query_log_file = /var/log/mysql/mysql-slow.log
# 不记录管理类SQL（比如show status这类），减少日志冗余
log_slow_admin_statements = 0
改完配置后重启MySQL生效，生成的慢日志就是Filebeat要采集的目标文件。
三、Filebeat的安装与基础配置
3.1 安装Filebeat（技术栈：Filebeat 7.17）
Filebeat是轻量型日志收集工具，资源占用极低，安装步骤很简单，以Linux系统为例，用解压包直接部署即可：
# 下载对应版本的安装包，这里用7.17版本（长期维护的稳定版）
wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.17.12-linux-x86_64.tar.gz
# 解压到当前目录
tar -zxvf filebeat-7.17.12-linux-x86_64.tar.gz
# 进入解压后的目录
cd filebeat-7.17.12-linux-x86_64
3.2 启用MySQL模块的基础配置
Filebeat的优势是有预制的模块，不用自己写复杂的日志解析规则，直接开启MySQL模块就能自动解析慢日志，基础配置如下（修改filebeat.yml文件）：
# 配置Filebeat的模块，开启MySQL的慢日志采集
filebeat.modules:
- module: mysql
slowlog:
enabled: true # 启用MySQL慢日志模块
# 替换成你自己服务器上的慢日志路径，和MySQL配置里的路径一致
var.paths: ["/var/log/mysql/mysql-slow.log"]
# 配置输出，这里先输出到本地文件方便测试，后续可改输出到Elasticsearch等
output.file:
path: "/tmp/filebeat_output" # 输出文件的保存目录
filename: "mysql_slow_logs" # 输出文件的名称
rotate_every: 1 # 每天生成一个新文件，避免单个文件过大
四、Filebeat自动解析慢查询日志的原理
很多同学担心“解析规则太复杂不会写”，Filebeat的MySQL模块已经把慢日志拆成了结构化数据，比如把原本一大段杂乱的日志，自动拆成query_time（执行时间，单位秒）、sql_text（具体的SQL语句）、user_host（执行SQL的用户和IP）、db（执行的数据库名）等字段，就像提前把乱衣服整理成了分类好的抽屉，不用自己再手动整理。比如原本的慢日志是这样的：
# Time: 2024-05-20T12:34:56.789+08:00
# User@Host: root[root] @ localhost [127.0.0.1] Id: 12345
# Query_time: 10.234567 Lock_time: 0.000123 Rows_sent: 100 Rows_examined: 10000
SET timestamp=1716180896;
SELECT * FROM orders WHERE user_id = 123456;
模块解析后，每条日志就变成了带结构化字段的JSON，后续可以直接用这些字段过滤和分析。
五、自定义字段扩展：适配业务需求
5.1 自定义字段的两种方法
默认的解析字段可能满足不了业务需求，比如我们需要区分生产/测试环境、对应哪个业务线，这时候可以加自定义字段，有两种常用方法，推荐用add_fields处理器，灵活又直观，示例配置如下（修改filebeat.yml）：
# 先保留之前的MySQL模块配置，再添加处理器来扩展自定义字段
processors:
# 给生产环境的日志加环境标记，这里的条件是日志路径包含"production"，可根据实际修改
- add_fields:
when:
regexp:
log.file.path: "/var/log/mysql/production"
fields:
environment: "production" # 自定义环境字段，值为生产
business_line: "order_system" # 自定义业务线字段，对应订单业务
# 给测试环境的日志加对应标记
- add_fields:
when:
regexp:
log.file.path: "/var/log/mysql/test"
fields:
environment: "test"
business_line: "user_system"
加完后启动Filebeat，输出的日志里就会带上environment和business_line字段，后续排查时直接筛选“environment:production”就能只看生产环境的慢SQL，非常方便。
5.2 测试自定义字段是否生效
启动Filebeat后，用命令查看输出的日志文件，比如：
tail -f /tmp/filebeat_output/mysql_slow_logs
打开日志后找一条慢SQL，看有没有environment和business_line字段，如果有说明配置生效了，要是没生效可以检查路径是否匹配、处理器的语法有没有写错。
六、技术优缺点与注意事项
6.1 优缺点分析
这个方案的优点很明显：一是轻量，Filebeat本身占用的CPU和内存不到10%，比Logstash这类工具省资源；二是开箱即用，不用自己写解析规则，减少出错概率；三是自定义灵活，想加什么业务字段都可以。缺点也有：一是依赖MySQL的慢日志格式，要是MySQL版本太老，慢日志格式和预制规则不匹配，解析会出错；二是自定义复杂规则（比如根据SQL类型加标签）需要额外写条件，不如手动解析灵活，但对于大多数中小团队足够用了。
6.2 关键注意事项
有几个点要特别注意：一是不要把long_query_time设得太小，不然慢日志会生成得特别多，磁盘很快被占满，一般设1秒比较合适；二是Filebeat运行的用户要对慢日志文件有读取权限，比如Linux上用root用户启动，不然会采集失败；三是自定义字段不要和模块自带的字段重名，比如模块已经有environment字段，就不要再自定义同名的，不然会覆盖原有字段，导致后续分析出错；四是要根据MySQL版本选择对应的Filebeat版本，比如MySQL8.0最好用Filebeat7.12以上的版本，避免解析不兼容。
七、总结
用Filebeat采集MySQL慢查询日志，再结合模块自动解析和自定义字段扩展，是中小团队排查数据库性能问题的低成本方案，不用搭建复杂的ELK集群也能实现日志的结构化分析，能大幅减少排查慢SQL的时间，提升开发和运维的效率。对于刚接触日志收集的同学来说，这个方案门槛很低，照着示例配一遍就能用，完全不用害怕复杂的规则和配置。
评论
围绕“Filebeat采集MySQL慢查询日志，模块自动解析与自定义字段扩展”参与讨论