慢查询日志持久化
errorHandling 同时覆盖初始化和持久化。throw 模式下,即使配置了 batch,save 也等待直接存储完成;silent/log 保留批处理,初始化失败时结束当次 save。autoCreateIndexes:false 同时跳过 TTL 和唯一索引创建,不删除已有索引;关闭自动创建时应单独部署所需索引。
Storage close() 等待在途初始化,取消其发布迟到 collection 的资格,并且只关闭自己拥有的 client。并发 close 共用清理过程;owned client 关闭失败时保留所有权,供后续 close 重试,清理成功前阻断初始化。成功关闭后的显式新初始化可以开启新一轮生命周期。共享业务连接保持打开。
Manager 的 initialize()、save()、query() 会同步登记接纳。close() 先关闭新操作入口,排空已接纳操作和批量队列,再尝试队列与存储两项清理;清理失败可重试,并阻止新工作,成功后可开启新的生命周期。各种错误处理策略遵从相同顺序。
持久化 firstSeen/lastSeen 使用事件时间的最小值/最大值,不受不同 owner 或批次乱序到达影响。按 avgTimeMs 排序时,在排序、skip、limit 前计算平均值,count 为零时按零处理;其他排序沿用原生 find 路径。既有历史时间错误不会自动重建。
功能概述
配置输入允许省略 batch、filter、advanced 内未指定的字段,合并结果仍为完整配置。批量存储同步抛错或异步拒绝后,后续批次和 close() 仍可继续;失败批次不自动重试。log 策略隔离诊断 sink 的同步异常,silent 不调用 sink,throw 继续抛出原存储错误;不承诺处理异步 sink 的 Promise 拒绝。
什么是慢查询日志持久化存储?
慢查询日志持久化会记录超过 slowQueryMs 阈值的操作,并让你后续查询聚合后的慢查询统计。当前 MongoDB runtime 默认写入 MongoDB,也可以在本地或自定义场景使用 memory 存储。
核心特性
- 简单启用:通过
slowQueryLog: true和slowQueryMs开启。 - 聚合记录:相同
queryHash、database、collection、operation 的记录会 upsert 到同一条统计行。 - 批量写入:默认启用,可配置批量大小、刷新间隔和缓冲上限。
- 自动过期:MongoDB 存储会在
lastSeen上创建 TTL 索引。 - 查询 API:通过
getSlowQueryLogs(filter, options)查询慢查询统计。 - 当前存储后端:
mongodb和memory。
工作原理
快速开始
最简配置(推荐)
自动效果
- 慢查询自动保存到
admin.slow_query_logs集合 - 相似查询按
queryHash、database、collection、operation 聚合 - TTL索引自动清理7天前的数据
- 复用业务连接,无额外连接开销
配置说明
全局慢查询配置
基础配置(在初始化时设置)
配置选项详解
操作级配置
某些操作可以单独配置慢查询阈值:
方式1:通过 options 参数
方式2:使用全局配置
日志格式
JSON 格式(默认)
文本格式
日志输出配置
使用自定义Logger
监听慢查询事件
配置层级
monSQLize 提供三层配置架构,满足不同使用场景:
层级1:零配置(推荐)
默认配置:
enabled: true- 启用storage.type: 'mongodb'- MongoDB runtime 使用 MongoDB 存储storage.useBusinessConnection: true- 复用业务连接storage.database: 'admin'- 存储到 admin 数据库storage.collection: 'slow_query_logs'- 集合名storage.ttl: 604800- 7 天过期batch.enabled: true- 启用批量写入batch.size: 10- 批量大小batch.interval: 5000- 5秒刷新
层级2:基础配置(常用)
层级3:完整配置(高级)
配置参数详解
storage 存储配置
batch 批量配置
filter 过滤配置
API参考
getSlowQueryLogs(filter, options)
查询慢查询日志聚合数据。
参数:
返回值:
使用示例:
使用示例
示例1:零配置启用
示例2:独立连接(隔离资源)
示例3:自定义TTL
示例4:过滤特定集合
示例5:本地分析使用 memory 存储
示例6:实时写入模式
最佳实践
阈值设置建议
根据不同场景选择合适的慢查询阈值:
示例:不同场景配置
监控和分析
1. 实时监控
2. 定期分析
3. 导出慢查询统计
优化建议
1. 创建索引
2. 优化查询条件
3. 使用投影减少数据传输
4. 启用缓存
生产环境最佳实践
1. 合理设置TTL
2. 使用复用连接(默认)
何时使用独立连接:
- 业务库性能极度敏感
- 慢查询日志量很大(>10000条/天)
- 需要独立的权限控制和资源隔离
3. 配置告警
4. 监控存储空间
5. 集成日志系统
故障排查
问题1:慢查询日志未保存
可能原因:
-
未启用功能
-
查询未超过阈值
-
批量队列未刷新
解决方案:
- 检查配置是否正确
- 检查日志输出是否有错误
- 如果启用了批量写入,可在读取最近日志前调用
await msq.getSlowQueryLogManager()?.queue?.flush()
问题2:存储连接失败
错误信息:
可能原因:
- MongoDB连接URI错误
- 网络不可达
- 权限不足
解决方案:
问题3:查询慢查询日志返回空
可能原因:
- 慢查询日志未生成
- 已过期(TTL删除)
- 查询条件不匹配
解决方案:
性能优化
性能影响分析
结论:日志开销取决于采样、存储、序列化和负载。应在目标环境中测量并设置预算,不能默认忽略。
优化建议(性能优化)
-
使用批量写入(默认启用)
-
保留内置聚合键
-
合理设置TTL
-
过滤不重要的集合
附录
A. 数据模型
slow_query_logs 集合结构:
索引: