MongoDB 事务监控：为什么 db.currentOp() 默认“看不见”活跃事务？
如果你曾尝试用 db.currentOp() 来排查一个卡住的事务，结果很可能是一头雾水。默认情况下，这个命令几乎看不到事务内部的细节——因为事务中的操作被统一打包成了 "op": "command"，而识别事务身份的关键字段，比如 "lsid" 和 "txnNumber"，根本不在默认的输出列表里，必须手动指定才能显示出来。
更关键的是，从 MongoDB 6.2 版本开始，db.currentOp() 已被标记为弃用。现在，正确的方法是直接使用底层的 $currentOp 聚合阶段，并配合过滤和投影操作。
为什么 db.currentOp() 默认查不到事务细节
这事儿得从设计初衷说起。db.currentOp() 诞生时，MongoDB 还没有多文档事务（那是4.0之后的事了）。它的设计目标是监控“操作层”，比如一个个独立的查询、插入或更新命令。
然而，事务启动后，其内部的所有读写操作都会被“打包”归并。你在 currentOp 的结果里，只会看到一个代表事务整体的 command 操作，例如 "command": {"commitTransaction": 1}。至于事务内部到底执行了哪条 find 或 update 语句，默认视图下是完全隐藏的。
- 在 6.2+ 版本中，
db.currentOp()本质上是在调用$currentOp聚合阶段，但这个阶段默认不会展开事务的上下文信息。 - 即便你加上
{"active": true}过滤条件，也只能看到提交或中止事务的命令本身，无法得知它具体锁住了哪些文档，或者卡在哪一行代码上。 - 识别同一个事务的核心字段——逻辑会话 ID (
"lsid") 和事务序列号 ("txnNumber") ——并不在基础输出字段中，必须通过手动投影 ($project) 才能调取出来。
如何用 $currentOp 聚合阶段查真实事务状态
要绕过限制，看到全貌，就得直接使用聚合管道来调用 $currentOp。请注意，这需要你拥有 inprog 权限，并且在 Atlas 的 M0、M2、M5 等免费集群上是无法执行的。
- 查询所有活跃的事务会话：可以使用以下聚合命令，它筛选出运行时间大于0秒且包含事务标识的操作，并投影出关键字段。
db.adminCommand({ aggregate: 1, pipeline: [ { $currentOp: { allUsers: true } }, { $match: { "secs_running": { $gt: 0 }, "lsid": { $exists: true }, "txnNumber": { $exists: true } } }, { $project: { "lsid": 1, "txnNumber": 1, "secs_running": 1, "ns": 1, "command": 1, "waitingForLock": 1, "locks": 1 } } ], cursor: {} }) - 聚焦未提交的事务：如果想排除那些已经处于提交或中止命令阶段的事务，可以在匹配条件中加上：
{"command.commitTransaction": { $exists: false }, "command.abortTransaction": { $exists: false }}。 - 定位阻塞源头：结合锁信息分析非常有效。如果看到
"waitingForLock": true并且"locks"字段显示为{ "Global": "w", "Database": "w" }，通常意味着这个事务正持有写锁，并可能因此阻塞了其他操作。
db.currentOp() 还能用吗？哪些场景别踩坑
平心而论，在特定场景下它仍可临时一用，但你必须清楚它的局限和可能遇到的“坑”。
- 在本地开发环境或社区版中，使用
db.currentOp({"active": true, "secs_running": {$gt: 5}})确实能快速揪出运行缓慢的事务命令。但它的短板也很明显：你无法通过结果直接追溯到是哪个应用连接发起的这个事务。 - 在 Atlas 云服务中，权限是分层的。M10 及以上规格的集群支持
$currentOp，但 M0、M2、M5 等免费或基础套餐明确禁用了此命令——此时直接运行db.currentOp()会报错Command currentOp not allowed。 - 使用
db.currentOp({ "$ownOps": true })这个选项时，它只显示当前 Shell 会话自身的操作。这对于排查由其他应用程序发起的、陷入僵局的长事务来说，完全没有帮助。 - 还有一个常见的误解：不要指望通过
"query"字段来判断事务内部在做什么。在事务中，查询语句会被压缩在"command"对象里，原始的过滤条件并不会展开显示。
真正要监控事务，得靠组合手段
说到底，无论是旧的 db.currentOp() 还是新的 $currentOp，单靠数据库层面的一个命令都是不够的。在生产环境中进行有效的事务监控，需要一套组合拳，把不同层面的数据串联起来：
- 应用层埋点：最直接的线索来自应用本身。在代码中开启事务时，就应当记录日志，包含逻辑会话 ID (
lsid.id) 和事务开始时间。例如，在 PyMongo 中，可以通过session._server_session.session_id获取到会话ID。 - 数据库层抓取：利用
$currentOp聚合命令，实时抓取数据库中的lsid、txnNumber和secs_running（运行时间）等信息。然后，将这些信息与应用层的日志进行关联比对，就能勾勒出事务的完整生命周期。 - 基础设施层观测：配合使用像
mongostat --host xxx --port xxx这样的工具，观察输出中的txn列，它表示每秒的事务数。这个指标的突然飙升，往往是事务堆积或出现瓶颈的强烈信号。
最后，提一个极易被忽略的细节：lsid 的格式问题。它在 MongoDB Shell 中显示为 BinData(4, "...") 这样的二进制数据，但在 Python/PyMongo 中却是一个字典结构。如果在应用日志和数据库监控工具之间直接比对字符串，会发现永远对不上。正确的做法是进行 Base64 解码后，再比对其内部的 UUID 值，这才是跨系统追踪同一事务的关键。
