事件驱动下的可观测性

解决什么问题：异步系统中看不到调用堆栈—— 事件驱动可观测性通过关联 ID、Consumer Lag、事件追踪重新建立可见性。

业务问题

真实场景

场景 1：异步订单处理失败

问题：
  - 用户下单 5 分钟后还没看到结果
  - 同步系统能查堆栈
  - 事件驱动系统：事件在哪？哪个环节失败？
  
无观测性的痛苦：
  - 不知道事件是否发出
  - 不知道哪个消费者处理慢
  - 不知道失败原因
  
有观测性的能力：
  - 用关联 ID 追踪所有事件
  - 看到 Consumer Lag
  - 看到每个服务的处理时间

Bellemare Ch 14 原话：

"Event-driven microservices have unique observability challenges... There is no synchronous call stack to follow... You must design observability into your system from the start."

失败模式

失败模式	后果
无关联 ID	事件无法追踪
无 Consumer Lag 监控	处理慢发现不了
无 Schema 兼容性监控	破坏性变更上线才知

控制论视角

Ch 4 §4.6："反馈环路" + Ch 15："测量的连续性"

事件驱动可观测性 = Ch 15 测量的连续性
  - 关联 ID = 测量的"路径"
  - Consumer Lag = 测量的"延迟"
  - Schema 状态 = 测量的"完整性"
  
观测性 = 控制律的"眼睛"
  - 没有观测 = 控制律瞎了
  - 不完整观测 = 控制律只能看到部分

核心概念

3 类监控

事件驱动特有的监控：
  1. 事件流层面：Consumer Lag / 事件速率 / DLQ
  2. 服务层面：处理时间 / 成功率 / 重试次数
  3. 业务层面：业务指标（订单数/金额/异常）

关联 ID（Correlation ID）

作用：
  - 贯穿所有事件的唯一标识
  - 跨服务追踪
  - 跨工作流追踪
  
实施：
  - 请求入口生成 ID
  - 放入所有事件 metadata
  - 日志、追踪、监控都带 ID

Consumer Lag

定义：消费者落后于生产者的程度
  
指标：
  - Lag 数量（未消费事件数）
  - Lag 时间（最老未消费事件距今多久）
  
意义：
  - Lag 增长 = 处理慢
  - Lag 归零 = 处理正常
  - Lag 长期高 = 容量不足

Schema 兼容性监控

监控项：
  - 当前 schema 版本数
  - 兼容性检查通过率
  - 未注册的 schema（隐患）
  
告警：
  - 检测到破坏性变更
  - Schema 注册失败

分布式追踪

挑战：异步调用无堆栈

方案：
  - 关联 ID 贯穿事件
  - OpenTelemetry / Jaeger / Zipkin
  - 事件 metadata 带 trace_id
  
可视化：
  - 时间线：每个事件处理时长
  - 因果图：事件与服务关系

工程实践

实战 1：关联 ID 实施

class EventPublisher:
    def publish(self, event, correlation_id):
        event.metadata["correlation_id"] = correlation_id
        event.metadata["trace_id"] = self.get_trace_id()
        self.broker.publish(event)

class EventConsumer:
    def process(self, event):
        correlation_id = event.metadata["correlation_id"]
        with self.tracer.span(f"process-{event.type}"):
            self.business_logic(event)

实战 2：Consumer Lag 告警

# Prometheus 告警
- alert: KafkaConsumerLagHigh
  expr: kafka_consumer_lag > 10000
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Consumer {{ $labels.consumer }} lag is high"

实战 3：事件流可视化

工具：
  - Kafka UI / AKHQ
  - Confluent Control Center
  - Grafana + Kafka Exporter
  
可视化内容：
  - Topic 流量图
  - Consumer 速率
  - Lag 趋势
  - Schema 演化历史

反模式 vs 正模式

反模式	正模式
无关联 ID	强制关联 ID
只看 CPU/Memory	看 Consumer Lag / 事件速率
失败后再查	实时监控 + 提前告警
无 Schema 监控	Schema Registry + 兼容性检查

性能指标

指标	衡量	健康值
Consumer Lag	未消费事件数	< 10000
关联 ID 覆盖率	带 ID 的事件比例	100%
追踪采样率	被采样的请求比例	> 10%
告警响应时间	从异常到告警	< 1min

边界判断

何时必须

• 任何事件驱动微服务
• 多消费者
• 跨服务追踪

何时可简化

• 单 producer + 单 consumer
• 短期项目

何时升级

当前	升级到	触发条件
日志查问题	关联 ID + 追踪	调试困难
无告警	Consumer Lag 告警	业务受影响
无 Schema 监控	Schema Registry 监控	团队扩大

关键洞察

1. 观测性 = 事件驱动的"神经系统"——没有它，调试全靠猜。
2. 关联 ID 是基础——所有监控、追踪、告警都依赖它。
3. Consumer Lag 是核心指标——它直接反映系统健康。
4. Schema 监控常被忽略——破坏性变更比运行时故障更可怕。
5. 与 cybernetics 同构——Ch 4 §4.6 反馈环 = 观测性，Ch 15 测量累积 = 事件追踪。