介绍炬鲸 OBSERVE 把日志、指标、链路收进同一数据面的产品设计：类 SQL 日志检索、多维告警治理、原生 OTLP 链路追踪，帮助团队在排障时少切屏、快定位。
排障时最耗时间的往往不是看懂问题，而是来回切系统。指标在监控平台、日志在日志平台、链路在 APM 平台，三者靠时间戳和 traceId 手工对齐，一次故障排查常常要开十几个浏览器标签页。炬鲸 OBSERVE 把日志、指标、链路收进同一套数据面，共用字段索引与标签体系：在告警里点一下就能跳到对应日志，在日志里看到 trace_id 就能展开整条调用链。数据不搬家，人少切屏。
三者的价值在于互相印证：指标告诉你错误率上去了，日志告诉你错在哪个错误码，链路告诉你哪个上游调用引发了它。分散在三个产品里，这条推理链只能靠人肉拼；收进一个平台，它是一条连续的下钻路径。
日志平台最常见的形态是"关键词 + 正则"。字段一多，正则就变成天书。OBSERVE 的日志检索支持类 SQL 语法，结构化字段在采集端解析、写入即索引：
level='ERROR' AND service='order-svc' AND trace_id != ''
| stats count() by host, error_code上面这条能直接回答"哪个节点、哪个错误码在报错"。单日百 GB 日志量下，带条件的查询做到秒级返回；对 message 等非结构化字段仍保留全文检索，二者并存而非二选一。字段解析规则内置了 nginx、Java 异常栈、JSON 日志三类常见模板，也允许自定义 Grok 覆盖冷门格式。两个设计值得一提：字段在写入时即建索引而非查询时现算，这是大流量下过滤仍然快的原因；| stats 聚合在存储端执行，避免把原始行都搬到浏览器。
告警系统最现实的失败不是漏报，是响到麻木。OBSERVE 的告警规则支持按维度聚合拆分，同一条规则按 service 或 host 各自生成独立告警，一处抖动不会刷屏；支持连续 N 个采样点超阈值才触发，过滤瞬时毛刺；支持静默窗口与分级路由，P0 走电话/短信，P2 走 IM，避免所有人被同一批告警反复打扰。告警配置本身走版本管理，谁改了什么、何时生效都有记录。
落到操作上：规则描述的是信号本身（order-svc 按 host 的错误率），平台负责拆组与路由。团队不再写十几条雷同规则，而是每个服务一条规则精调，这才是"值得看的告警"和"被静音的告警"之间的差别。
链路追踪产品最容易做成"只支持自家 SDK"的黑盒。OBSERVE 原生接收 OTLP（OpenTelemetry Protocol），Go/Java/Python/Node.js 用官方 SDK 导出即可接入，无需引入额外依赖。采集侧内置头部采样 + 尾部采样：头部采样按比例控制整体流量，尾部采样保证带 error 的链路 100% 保留，在控制存储成本的同时不漏掉真正的故障证据。三个视图共享同一 trace_id 维度，从链路到日志再到指标是一条连续的下钻路径，而不是三张互不相干的截图。