日志、指标、链路三源合一：炬鲸 OBSERVE 核心能力拆解

大多数团队的可观测性工具是拼凑出来的：ELK 看日志、Prometheus 看指标、Jaeger 看链路。数据分散在三套系统里，出问题时要在多个页面之间来回切换，关联全靠人肉。炬鲸 OBSERVE 把三类数据收进同一个平台，用统一的数据模型和检索入口把它们打通。

类 SQL 日志检索

日志的价值在于「查得快、查得准」。炬鲸 OBSERVE 的日志检索支持类 SQL 语法，可以直接写 status >= 500 AND service = 'order' 这样的条件，而不是去记各种查询 DSL。常用写法：

level = 'ERROR' AND service = 'payment' AND latency > 1000

• 支持全文模糊搜索（content LIKE '%timeout%'）、数值范围判断、字段存在性判断
• 检索结果一键聚合：按 error_code 分组统计数量、按时间桶画分布曲线
• 展开单条日志可以直接跳转到对应的 Trace，不用再手工猜 trace_id

索引策略上，我们建议对 service、level、trace_id 这三个高频字段建索引。冷热分层默认开启：热数据放 SSD 保留最近 7 天，冷数据落到对象存储，最长保留 365 天，成本可控。

指标采集与告警

指标侧兼容 PromQL。已经跑着 Prometheus 的团队可以零改造地把 remote_write 指到炬鲸 OBSERVE，历史数据不用迁移，两边可以同时写。告警规则和 Prometheus 的 alerting rules 写法一致：

groups:
  - name: order-service
    rules:
      - alert: OrderErrorRateHigh
        expr: sum(rate(order_requests_total{status=~"5.."}[5m])) / sum(rate(order_requests_total[5m])) > 0.05
        for: 5m

通知支持企业微信、钉钉、飞书、邮件和 Webhook。一个容易踩的坑：默认「连续 5 分钟超阈值」会漏掉突发故障。对错误率这类指标建议用 for: 1m 配合分级阈值，CPU 这种缓慢爬坡的指标才适合长持续窗口。

链路追踪

链路追踪回答的是「这次请求到底慢在哪」。炬鲸 OBSERVE 完整支持 OpenTelemetry 协议，Java/Go/Python/Node.js 用对应 SDK 埋点后，Trace 会自动关联日志和指标：点开一个慢 Span，能看到它对应时间段的日志，也能看到这个服务的错误率曲线。

火焰图、上下游依赖拓扑、跨服务耗时排行都是开箱即用。我们更建议团队把精力放在「慢请求抽样」上——按 latency > 500ms 或错误状态抽样，能覆盖 95% 的排查场景，存储成本只有全量的十分之一。

权限与多租户

生产环境绕不开权限。炬鲸 OBSERVE 支持 RBAC 到项目/服务粒度，日志和 Trace 里的敏感字段（手机号、身份证、卡号）自动打码。审计日志独立存储，谁在什么时候查了什么数据，可回溯 180 天。

三类数据打通之后，排查路径变成一条直线：告警 → 指标定位服务 → 日志看上下文 → Trace 看调用链。我们把这一套做成标准产品，就是希望团队别再为「数据到底散落在哪」浪费时间。