面向银行、证券和保险的可观测性方案：审计日志不可篡改留存、交易链路秒级告警、日志与链路联动定位故障，以及多中心灾备下的统一监控。
金融系统的可观测性，难点不在技术栈，而在约束。第一是监管：审计日志要按监管要求留存数年且不可篡改；第二是交易链路对时延极度敏感，一个慢 SQL 可能直接造成资损；第三是灾备，同城双活、异地多中心是常态，监控本身也要跟着跨中心部署。下面按这三个约束展开一套落地思路。
审计日志的第一要求不是"查得快"，而是"留得住、改不了、对得上"。炬鲸 OBSERVE 的做法是把审计日志单独走一条管道：写时追加、只读保留、定期计算哈希链并归档到对象存储。任何一次修改都会被哈希链暴露。
audit:
retention_days: 1825 # 五年
append_only: true
hash_chain: sha256
archive:
type: oss
bucket: audit-archive配合平台的分级权限，审计日志的查看权限只开放给合规和审计岗位，普通运维看不到，从源头切断"内部篡改"的可能。
交易链路对告警时延的要求是秒级。靠人盯盘不现实，正确做法是给核心链路设黄金指标（延迟、错误率、吞吐），用滑动窗口做连续检测，一旦跌破阈值立刻分级通知。比如把"下单接口 P99 延迟连续 5 秒超过 200ms"设为 P0，触发后直接走电话，而不是等 5 分钟的聚合周期。
sum(rate(order_api_latency_seconds_bucket{le="0.2"}[30s]))
/ sum(rate(order_api_latency_seconds_count[30s])) < 0.99这条 PromQL 表达的是"过去 30 秒内 99% 的请求在 200ms 内完成"，低于 0.99 就说明有请求慢下来了，配合告警引擎的静默期和分组，避免瞬间重复轰炸。
交易故障最怕"告警响了，但不知道错在哪一层"。炬鲸 OBSERVE 把 Trace 和日志通过 traceId 关联，告警触发后点进 Trace，能一路看到从网关、交易服务到账务系统的每一跳耗时，再顺着异常 Span 打开对应日志，直接看到 SQL 和堆栈。一个原本要跨三个团队排查半小时的故障，通常能缩短到十分钟以内。
同城双活、异地多中心的架构下，监控平台自身如果只在单中心部署，切换时就会"灯下黑"。建议每个中心部署一套采集端，数据汇聚到主中心的同时保留本地缓存，主中心故障时从中心自动接管查询和告警，保证切换期间监控不断档。采集端的缓存也顺带解决了跨中心专线抖动时的数据丢失问题。