4. 慢查询日志的采集与存储：日志采集工具(Filebeat/Fluentd)、集中存储(Elasticsearch/Loki)
在生产环境中，Go 服务通常以多实例、多集群的方式部署。慢查询日志如果只写在本地磁盘，排查问题时需要逐台登录服务器，效率极低。本章将讲解如何构建一套可靠的“采集 → 传输 → 集中存储”管道，让慢查询日志成为可检索、可聚合的资产。
4.1 日志采集架构总览
一个完整的慢查询日志采集系统包含三个核心环节：采集端（Agent）、缓冲/传输（Broker）、存储端（Storage）。Go 服务产生的慢查询日志首先写入本地文件，由轻量级采集 Agent 读取并转发到中央存储。
架构要点：Go 服务本身不直接发送日志到远端，而是写入本地文件。这样做的好处是：服务进程不依赖网络，即使存储端宕机，服务仍可正常运行，日志不会丢失。
4.2 采集工具对比：Filebeat vs Fluentd
Filebeat 和 Fluentd 是当前最主流的两种轻量级日志采集器。下表从多个维度对比它们在慢查询日志场景下的表现：
| 对比维度 | Filebeat | Fluentd |
|---|---|---|
| 资源占用 | 极低（Go 编写，约 10-30MB 内存） | 中等（Ruby/C 混合，约 50-150MB 内存） |
| 部署方式 | 单一二进制，无外部依赖 | 需要 Ruby 运行时或 td-agent 包 |
| 日志读取 | 基于文件系统 inode，支持多行合并 | 基于 tail 插件，支持正则多行 |
| 输出目标 | 原生支持 ES、Logstash、Kafka | 丰富的插件生态（ES、S3、MongoDB 等） |
| 数据过滤 | 基础字段处理（drop、rename、add） | 强大的 filter 链，支持 Lua 脚本 |
| 适用场景 | 纯日志采集，追求极简和低资源 | 需要复杂路由、转换、缓冲的场景 |
推荐选择：对于 Go 慢查询日志这种结构相对固定、数据量大的场景，Filebeat 是更优选择。它资源占用低，配置简单，且与 Elasticsearch 原生集成。如果团队已有 Fluentd 生态或需要复杂的日志预处理，则选择 Fluentd。
4.3 Filebeat 配置实战
以下是一个针对 Go 慢查询日志的 Filebeat 配置示例，包含多行合并、字段添加和输出到 Elasticsearch：
# filebeat.yml
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/go-app/slow-query.log
# 多行合并：以时间戳开头的行为新事件开始
multiline.type: pattern
multiline.pattern: '^\d{4}-\d{2}-\d{2}'
multiline.negate: true
multiline.match: after
# 添加自定义字段
fields:
service: go-order-service
env: production
fields_under_root: true
output.elasticsearch:
hosts: ["http://es-cluster:9200"]
index: "slow-query-%{+yyyy.MM.dd}"
# 性能调优
worker: 4
bulk_max_size: 2048
flush_interval: 5s
# 注册表文件位置，用于记录读取偏移量
filebeat.registry.path: /var/lib/filebeat/registry
关键配置说明：
- multiline：Go 慢查询日志通常跨多行（如 SQL 语句、堆栈），必须配置多行合并规则，否则一条慢查询会被拆成多条记录。
- registry.path：Filebeat 通过注册表文件记录已读取的文件偏移量。确保该路径持久化，否则重启后会重复读取。
- bulk_max_size：根据 ES 集群写入能力调整，避免触发 ES 的 bulk 队列限制。
4.4 集中存储方案：Elasticsearch vs Loki
集中存储是慢查询日志系统的核心。Elasticsearch 和 Loki 是两种主流的日志存储方案，它们在设计哲学上存在根本差异：
| 对比维度 | Elasticsearch | Loki |
|---|---|---|
| 存储模型 | 倒排索引，全文检索 | 仅索引元数据（标签），日志内容压缩存储 |
| 查询语言 | Query DSL / KQL | LogQL（类 PromQL） |
| 资源消耗 | 高（内存和磁盘需求大） | 低（与 Prometheus 类似） |
| 索引速度 | 中等，需要 mapping 和分词 | 极快，无需分词 |
| 全文搜索 | 强大，支持模糊、短语、高亮 | 仅支持精确匹配和正则 |
| 与 Grafana 集成 | 需额外配置 | 原生集成，无缝对接 |
| 适用场景 | 需要复杂搜索、聚合分析 | 快速查看、基于标签过滤 |
4.5 存储方案选型建议
针对 Go 慢查询日志的典型使用场景，给出以下选型建议：
- 场景一：需要全文搜索 SQL 语句 —— 选择 Elasticsearch。慢查询日志中经常需要搜索特定的表名、索引名或 SQL 片段，ES 的全文检索能力不可或缺。
- 场景二：快速查看某段时间内所有慢查询 —— 选择 Loki。如果团队已经使用 Grafana 监控，Loki 可以无缝集成，通过标签（如 service、env）快速过滤，查看日志内容。
- 场景三：需要聚合分析（如按 SQL 指纹分组统计） —— 选择 Elasticsearch。ES 的聚合功能可以对慢查询进行分组、排序、统计，快速定位 TOP N 慢 SQL。
- 场景四：资源受限，仅做日志归档 —— 选择 Loki。Loki 的存储成本远低于 ES，适合长期保存大量日志。
混合架构：大型团队可以采用“双写”策略：Filebeat 同时将日志发送到 ES（用于实时分析和搜索）和 Loki（用于长期存储和 Grafana 展示）。这样既能享受 ES 的搜索能力，又能利用 Loki 的低成本存储。
4.6 存储索引与生命周期管理
无论选择 ES 还是 Loki，都需要合理规划索引策略和生命周期，否则存储成本会快速膨胀。
| 管理项 | Elasticsearch | Loki |
|---|---|---|
| 索引划分 | 按天创建索引（slow-query-2025.01.15） | 按时间段划分 chunk，自动管理 |
| 分片数 | 建议 1-3 个分片，避免过多小分片 | 无需手动配置 |
| 副本数 | 生产环境至少 1 个副本 | 通过 replication_factor 控制 |
| 保留策略 | ILM（Index Lifecycle Management）：热-温-冷-删 | 配置 retention period，自动删除过期数据 |
| 压缩 | 默认 best_compression | 默认 gzip 压缩 |
4.7 本章小结
慢查询日志的采集与存储是 Go 慢查询复盘的基础设施。核心要点总结如下：
- 采集端：优先选择 Filebeat，资源占用低，配置简单，原生支持多行合并。
- 传输层：如果日志量极大（>100MB/s），建议引入 Kafka 作为缓冲，防止存储端压力过大导致数据丢失。
- 存储端：根据查询需求选择 ES（全文搜索、聚合分析）或 Loki（快速过滤、低成本存储），也可采用混合架构。
- 运维要点：配置多行合并规则、注册表持久化、索引生命周期管理，确保系统稳定可靠。