日志、指标、链路三件套：拆解炬鲸 OBSERVE 的核心能力

日志、指标、链路是三套不同的数据，但排查问题时它们指向同一件事：系统哪里出了问题。这篇拆解炬鲸 OBSERVE 三大核心能力，并给出几个能直接抄的配置建议。

日志检索：把排查时间从小时压到分钟

故障排查的第一站通常是日志。炬鲸 OBSERVE 的日志检索同时支持全文搜索、字段过滤和类 SQL 聚合。下面这条语句按主机聚合 ERROR 日志数量，一眼看出问题集中在哪台机器：

SELECT host, count(*) AS cnt
FROM logs
WHERE level = 'ERROR' AND service = 'order-service'
GROUP BY host ORDER BY cnt DESC

检索语法同时兼容 Lucene 风格，level:ERROR AND service:order* 可以直接用。聚合可以按任意字段下钻——按主机、按错误类型、按发布标签——把"发生了什么"变成"具体发生在哪"。跨度超过一天的查询会自动提示采样，先看 1% 再逐级放大，避免一次全量扫描拖垮集群。

有两个细节值得单独说。一是日志上下文：点开任意一条 ERROR，能还原它前后各 50 行。二是 trace_id 关联：只要日志里带了 trace_id，就能从一条报错直接跳到对应的调用链，日志和链路不再割裂。

监控告警：能降噪的告警才有人看

告警系统最大的问题不是漏报，而是刷屏和误报，最后演变成"没人看"。炬鲸 OBSERVE 兼容 Prometheus 指标模型，PromQL 可以直接写进告警规则。除了常规阈值判断，几个能显著减少无效告警的能力值得用起来：

• 持续检测：指标连续 N 个周期满足条件才触发，过滤瞬时毛刺；
• 分级与路由：P0/P1/P2 分级，P0 走电话短信，P2 只进工作群；
• 静默与抑制：发版窗口静默，同一集群的磁盘告警合并成一条。

一个典型配置：CPU 使用率连续 3 个周期超过 90% 才通知值班。告警正文里直接附上最近 15 分钟的指标曲线，接电话的人不用先开电脑，省掉每次故障的一次往返。

链路追踪：回答"这次请求慢在哪"

链路追踪的价值不在"有 trace"，而在能快速回答"这次请求慢在哪"。炬鲸 OBSERVE 完整兼容 OpenTelemetry 协议，标准 agent 或 SDK 就能完成埋点。trace 视图按服务、接口、耗时排序，火焰图能定位到具体的 SQL 或下游 HTTP 调用。采样策略建议：正常流量 10% 采样，错误与慢请求 100% 保留，配合尾采样保住每个"结局不好"的请求。

三者打通才是完整的可观测性

日志、指标、链路单独用都有盲区：指标告诉你"出事了"，日志告诉你"是什么错"，链路告诉你"哪一步慢"。炬鲸 OBSERVE 把它们打通，一条告警带出关联的指标曲线、日志片段和 trace 链接。这种关联，正是监控堆栈和可观测平台的分水岭。