炬鲸 OBSERVE v3.0 发布：日志动态采样、告警升级策略与 OTel Collector 原生接入

v3.0 是一个以「降本」和「降噪」为主线的大版本：存储更省、告警更准、接入更简单。做这个版本的直接原因是两个长期痛点——日志全量存储的成本随业务增长线性上涨，告警数量随服务增多而逐渐失控。下面是本次更新的完整内容。

日志动态采样：按价值决定存多少

以前日志要么全存、要么全丢，全存贵，全丢又不敢。v3.0 引入动态采样：默认全量接收，但根据日志的「价值」自动决定保留策略——错误日志全保留，正常请求日志在高吞吐时段自动降采样。采样在写入前完成，存储成本可下降 30%–50%，同时保证排障时错误日志一条不少。

采样规则可以按 level、service、错误率组合配置，例如：

sampling:
  rules:
    - match: level >= "ERROR"
      keep: 1.0
    - match: service == "gateway" AND level == "INFO"
      keep: 0.1
      window: high_qps

采样在采集端完成，配置下发后即时生效，无需重启应用。

以一个日增 500GB 日志的集群为例，INFO 类日志占比通常超过 70%，启用采样后存储日增量可降到 300GB 以下，按年折算成本下降明显。落地建议分两步走：先在预发环境观察一周，确认采样前后的错误日志覆盖率不变，再按服务灰度开启；对合规要求严格、需要长期归档的日志，可对该类字段单独豁免采样，避免误丢。

告警升级策略：把通知发给对的人

新增多级告警升级：规则触发后先发到值班群，N 分钟未确认自动升级到电话，仍未处理则升级到主管。支持按时间段配置不同的升级路径，夜间走电话、白天走群。配合已有的静默窗口，告警从「谁都能看到」变成「该知道的人一定会知道」，避免深夜告警被值班群的消息洪流淹没。配置示例：

escalation:
  - level: P1
    steps:
      - { after: 0m, channel: group }
      - { after: 5m, channel: phone }
      - { after: 30m, channel: manager }

升级策略默认带有去重和合并：同一告警在升级周期内重复触发不会重复通知，避免告警风暴反过来淹没升级通道。

OTel Collector 原生接入

不再需要自建 sidecar 或改应用代码，直接配置 OpenTelemetry Collector 的 exporter 指向炬鲸，日志、指标、链路一次上报。内置推荐配置模板，采集、转换、导出三段式配置开箱即用，接入时间从小时级缩短到分钟级。支持常见的 receivers（OTLP、Prometheus、Filelog）、processors（批处理、内存限制、属性处理）和 exporters，可直接复用社区 Collector 的既有配置，把 exporter 目标指向炬鲸即可。

其他改进与修复

• 索引字段管理界面：可视化管理字段索引，无需改配置文件；
• 查询性能：百万级日志聚合查询耗时下降约 40%；
• 修复：多行日志偶发错位、达梦连接池泄漏、时区显示偏移等 12 个问题。

兼容性与已知限制

v3.0 与 v2.x 的 API 和告警规则格式保持兼容，旧配置无需改动即可继续使用。已知限制：动态采样目前仅支持按 level 和 service 维度配置，按 trace 采样率的联动策略将在 v3.1 提供；GMTLS 网关场景下，部分老版本采集 agent 需先升到 3.0.1 才能正常握手。升级前请对照官方兼容性矩阵确认版本。

升级说明

从 v2.x 升级到 v3.0，需要先把采集端 agent 升到 3.x，再滚动升级服务端，支持在线升级、数据不中断。升级过程建议安排在业务低峰，全程通过平台自身的监控页面观察各组件健康度，异常时可随时回滚到 v2.x 的配置快照。升级前建议先在预发环境验证采样策略，避免误删历史日志。完整升级步骤见官方文档。

v3.0 的重点就一句话：用更少的钱存下更值得存的日志，用更少的通知命中更该处理的人。