用error_fingerprint替代原始堆栈可提升查询与聚合效率，需在采集端结构化解析后哈希生成，并建立复合索引；聚合须按时间窗口（如分钟级）统计频次，避免全量统计；重型字段应拆分存储以防超16MB文档限制。
错误日志建模：用error_fingerprint代替原始堆栈
直接存完整stackTrace字段，等于把MongoDB当文件系统用——查得慢、索引无效、聚合卡死。真实生产中，90%的错误类型其实由少数几十个“指纹”覆盖（比如NullPointerException在UserServiceImpl.java:42抛出）。所以第一件事是预处理：把每条错误日志提取成一个确定性哈希值或结构化标识。
- 推荐做法：在采集端（如Filebeat + Logstash 或自研Agent）用正则/AST解析提取
exceptionType、className、methodName、lineNumber，拼接后做SHA-256，存为error_fingerprint字符串字段 - 不推荐：客户端用
JSON.stringify(error)再hash——不同环境堆栈顺序/路径可能微变，导致同一错误生成多个指纹 - 必须加索引：
db.errors.createIndex({ error_fingerprint: 1, timestamp: -1 })，否则按指纹查最近10次报错会全表扫
聚合统计出现次数：用$group + $sum，但别漏掉时间窗口
只跑db.errors.aggregate([ { $group: { _id: "$error_fingerprint", count: { $sum: 1 } } } ])，得到的是历史总次数，对告警和根因分析毫无意义。错误爆发一定是突发的，关键在“单位时间内的频次跃升”。
- 按分钟聚合示例：
db.errors.aggregate([ { $match: { timestamp: { $gte: ISODate("2026-03-13T06:00:00Z") } } }, { $group: { _id: { fp: "$error_fingerprint", minute: { $dateToString: { format: "%Y-%m-%d %H:%M", date: "$timestamp" } } }, count: { $sum: 1 } } } ]) - 注意
$dateToString格式必须固定，否则同分钟数据会被拆成多组；若用$dateTrunc（5.0+），需确认集群版本，低版本会报错 - 如果要实时看“过去5分钟错误TOP10”，聚合结果务必加
{ $sort: { count: -1 } }和{ $limit: 10 }，否则网络传输大量无用数据
为什么不能把所有错误字段都嵌入主文档？小心maxDocumentSize越界
MongoDB单文档硬限制16MB，而Java Full GC日志+完整堆栈+请求上下文（headers、body）轻松超2MB。一旦某次OOM错误带了100MB堆dump片段，写入直接失败，且错误静默丢失——驱动报BsonSerializationException，但日志里可能只显示“write concern timeout”。
- 正确分层：主文档只保留
error_fingerprint、timestamp、service、traceId、count（本次采样计数）等轻量字段 - 重型内容（原始堆栈、request body、env vars）单独存进
error_details集合，用error_id引用，查问题时再按需$lookup - 验证手段：
Object.bsonsize(doc)在shell里试一试，超过8MB就该拆了
聚合管道里$facet能一次拿齐指标，但别在高吞吐场景滥用
想同时拿到“TOP5错误指纹”、“每分钟错误趋势”、“各服务错误分布”，用$facet确实省事。但它的本质是内存内并行执行多个子管道，数据量一大就OOM。
- 适用场景：后台报表、离线分析，QPS
- 线上告警接口必须拆开：单独聚合
error_fingerprint频次走一个轻量管道，趋势统计走另一个，避免单次查询拖垮整个mongod进程 - 替代方案：用
$bucketAuto替代手动分时间段分组，自动按数量均衡分桶，比$dateToString更省内存（尤其当时间跨度大、空档多时）
最容易被忽略的是指纹生成逻辑的一致性——采集端、重试补偿流程、离线补录脚本，三处代码必须用同一套规则提取和哈希。曾经有团队在补录脚本里忘了trim空格，导致2000条相同错误被算作37个不同指纹，监控面板上全是“新错误”。
