Go 分布式事务监控为什么不能只靠日志打点
日志能记录发生了什么，但没法告诉你「事务是否真正一致」。云原生环境下服务跨节点、跨协议（HTTP/gRPC）、跨数据库，context.WithValue 传的 traceID 在中间件或异步任务里极易丢失，导致链路断裂；更麻烦的是，事务提交失败可能发生在下游服务已返回成功之后——日志里全是 "200 OK"，实际数据已不一致。
真正要监控的不是「调用链是否完整」，而是「每个参与方的事务状态是否最终收敛」。这意味着必须在事务边界处埋点：开始、预提交、确认/回滚、超时清理，且所有埋点需绑定同一 traceID 和 globalTxID。
- 别在 HTTP handler 入口就打「事务开始」日志——此时 DB 事务甚至还没启
- 避免用
time.Now().UnixNano()做事件时间戳，容器内时钟漂移会导致上下游时间乱序 - gRPC 客户端拦截器里获取
metadata.MD中的trace-id比从context.Context解包更可靠
用 go.opentelemetry.io/otel + 自定义 Span 属性实现事务状态追踪
OpenTelemetry 的 Span 本身不带事务语义，但你可以把关键状态塞进 Span.SetAttributes。重点不是加多少标签，而是加哪些能区分「事务生命周期阶段」的属性：
-
txn.state = "started"：DBBegin()后立即设置 -
txn.phase = "prepare"：TCC 模式下 Try 成功后、Confirm 前 -
txn.global_id = "tx-7f8a9b2c"：全局唯一，由协调者生成并透传到所有参与者 -
txn.timeout_at = "1672531200"：Unix 秒级时间戳，用于告警未完成事务
示例：在 GORM 回调中注入 Span 属性
立即学习“go语言免费学习笔记（深入）”；
db.Callback().Create().After("gorm:create").Register("txn:span", func(scope *gorm.Scope) {
span := trace.SpanFromContext(scope.DB.Context())
span.SetAttributes(attribute.String("txn.state", "committed"))
})
为什么 Saga 模式下必须单独监听补偿动作失败
Saga 不是「自动回滚」，而是「显式补偿」。监控系统如果只盯主流程成功与否，会漏掉最关键的异常：补偿失败。比如订单服务调用库存服务扣减成功，但后续退款补偿时库存服务不可用——此时订单已取消，库存却没加回，数据永久不一致。
必须为每个补偿操作注册独立监控指标和告警：
- 补偿函数名必须带
Compensate后缀（如CompensateInventoryRelease），便于 Prometheus 抓取 - 补偿失败时，除了打
error日志，还要调用meter.RecordBatch上报compensate_failed_total{service="order",step="inventory"} - 不要复用主流程的
traceID——补偿是新请求，应生成新traceID并通过parent_id关联原始事务
etcd 作为事务协调器时的 Watch 监控盲区
很多团队用 etcd 的 Watch 实现分布式锁和事务协调，但 etcd client 的 Watch 默认不保序、不重连、不兜底——网络抖动时可能丢掉 "COMMIT" 或 "ABORT" 事件，监控系统就永远卡在「pending」状态。
必须做三件事：
- 启用
WithProgressNotify()，定期收WatchResponse.ProgressNotify == true确认连接活性 - 对每个事务 key 设置 TTL，并用
Get(ctx, key, WithRev(rev))定期轮询兜底，防止 Watch 断连后状态滞留 - etcd 返回的
ErrCompacted错误必须重试，否则会错过 compact 范围内的事务变更
事务协调状态不能只存在 etcd，也要写入本地内存缓存（如 sync.Map），Watch 失败时 fallback 到缓存+轮询，避免监控毛刺变成持续告警。
事务一致性监控最难的不是埋点，而是定义「什么是最终一致」——不同业务对「允许延迟多久」「可接受哪种不一致」的答案完全不同。监控策略得跟着业务 SLA 走，而不是套模板。
