炬鲸 OBSERVE v2.3.0 发布：日志聚类、告警降噪与冷热分层

新增：日志自动聚类

大促或故障期间，日志量会短时间暴涨，错误日志里混杂着几十种不同的报错。人工一条条翻不现实，v2.3.0 的日志聚类会自动把相似的报错归成一类，按出现次数排序，直接告诉你“这段时间最值得看的是哪几类问题”。

聚类基于日志模板（把变量部分提取成通配符）+ 词法相似度双重匹配。比如下面三条会归成一类：

ERROR [order] create order 1000231 failed: timeout
ERROR [order] create order 1000234 failed: timeout
ERROR [order] create order 1000239 failed: timeout

模板提取后变成 ERROR [order] create order * failed: timeout，同类报错点击即可展开原始日志，不用先猜关键字再搜。对于偶发的单条报错，聚类会把它们归入“其他”桶，避免淹没真正的高频问题。

新增：告警降噪

告警风暴是运维的头号痛点。一个数据库宕机可能连锁触发几十条告警，真正的根因被淹没在刷屏里。

v2.3.0 引入两层降噪：

• 关联聚合：把时间窗口内同一服务、同一类指标的告警合并成一条，附上告警次数和峰值
• 根因推断：对常见链路（如 DB 连接池耗尽 → 上游接口超时 → 订单服务报错）做规则匹配，把下游告警标记为“疑似由 X 引起”，一条主告警带若干关联告警

配合已有的动态基线，告警信噪比明显提升。降噪后的推送支持邮件、Webhook 和企业微信，聚合告警会附带一条“查看全部关联告警”的链接，不会漏掉细节。

新增：冷热分层存储

日志量增长后，存储成本是大头。但实际查询里，超过 90% 的检索落在最近 7 天，一个月前的日志很少被碰。

冷热分层把这部分成本省下来：

• 热层：最近 7 天，SSD，全字段索引，毫秒级检索
• 温层：7–30 天，普通盘，部分字段索引
• 冷层：30 天以上，压缩归档，按需解冻查询

分层规则按服务、按 namespace 可配置：

storage:
  tiers:
    - name: hot
      retention: 7d
      storage_class: ssd
      full_index: true
    - name: warm
      retention: 30d
      storage_class: hdd
    - name: cold
      retention: 0          # 0 表示永久保留
      storage_class: archive
      compressed: true

历史日志不用删，成本却大幅下降。冷层数据依然可查询，只是首次查询要等解冻，适合合规留痕和低频回溯。切到冷层后，单条日志的查询延迟会从毫秒级升到秒级，所以默认热层的 7 天窗口建议别改小，日常排查体验不受影响。

优化与修复

• 链路追踪水合（hydration）性能提升约 35%，大跨度 Trace 展开更流畅
• 日志检索在百万级结果集上的分页延迟降低
• 修复了告警规则在跨时区场景下触发时间偏移的问题
• 修复了部分场景下日志采集端心跳上报失败导致的误下线
• 修复了多租户下配额统计在月末结算时偶发不准确的问题

上手建议

三项新功能都可以在控制台直接开启，不需要改采集端：日志聚类在「日志检索」页右上角一键切换；告警降噪在告警规则的高级选项里勾选「自动聚合」；冷热分层在「存储管理」里为每个 namespace 配置分层规则。建议先给日志量最大的服务开冷热分层，收益最明显；日志聚类和告警降噪则建议全量开启，它们只影响展示和通知，不改变数据本身。

如果聚类结果不符合预期，可以调「聚类粒度」：粒度越细，类分得越多；越粗，越容易把不同报错并进一类。拿不准就先用默认值观察两天。

升级说明

升级方式：私有化部署用户联系交付团队获取 ARM/x86 双版本安装包，SaaS 用户已自动更新。升级前建议先备份配置与索引 mapping，回滚步骤详见交付文档。

兼容性说明：本次为小版本升级，API 与存储格式向下兼容，v2.2.x 的告警规则与看板可直接沿用。若你在 v2.2 用过旧版固定阈值告警，建议借这次升级一并切换到动态基线，告警误报率通常能明显下降。