日志、指标、链路三合一：炬鲸 OBSERVE 如何做统一可观测

三套割裂的工具为什么不够用

大部分运维团队手里是三套独立的工具：ELK 管日志、Prometheus 管指标、Jaeger 管链路。查一次线上故障要在三个界面来回切：先在告警面板看到 CPU 和错误率飙升，再切到日志系统按时间翻日志，最后猜测是不是某个下游调用变慢，打开链路工具碰运气找 trace。链路里好不容易定位到一条 trace，想回到日志里找上下文，发现两个系统的标签对不上，只能手动复制 trace ID 再模糊搜索。时间全耗在「对齐数据」上，而不是解决问题上。

炬鲸 OBSERVE 的思路很简单：把这三类数据放进同一个数据模型，用统一的时间轴和标签体系串起来，让排障从「三屏切换」变成「一屏下钻」。

统一数据模型怎么落地

平台内部把所有观测数据统一成带标签的事件流。日志、指标、链路共享同一套标签：service、instance、environment、tenant。一条 trace 关联的日志可以直接通过 trace_id 标签取到，不需要二次搜索；指标和日志通过 host + service 对齐，告警触发时能直接下钻到对应时间窗口的日志。

采集端统一走 OpenTelemetry Collector：日志用 filelog receiver，指标用 prometheus receiver，链路用 otlp receiver，输出到同一个后端。精简配置如下：

receivers:
  otlp:
    protocols: { grpc: {}, http: {} }
  filelog:
    include: [/var/log/app/*.log]
  prometheus:
    config:
      scrape_configs:
        - job_name: app
          static_configs:
            - targets: [localhost:8080]
exporters:
  otlphttp:
    endpoint: https://ob.jjhub.cn/otel
service:
  pipelines:
    traces:  { receivers: [otlp], exporters: [otlphttp] }
    logs:    { receivers: [filelog, otlp], exporters: [otlphttp] }
    metrics: { receivers: [prometheus, otlp], exporters: [otlphttp] }

三个关联查询入口

1. 告警详情页：点开一条告警，能看到触发时刻的指标曲线、相关日志，以及覆盖该时间段的 trace 列表。
2. 链路详情页：选中一个 span，右侧直接列出它输出的日志行，不用手动复制 trace ID。
3. 日志详情页：日志若携带 trace_id，显示「查看链路」按钮，一键跳到对应 trace 的火焰图。

这三个入口背后是同一套标签索引，单次关联查询的延迟通常在百毫秒级，不会因为数据量大而明显变慢。

落地建议

不建议一上来就把三套老系统全换掉。可以从一个核心服务开始，先把日志和链路接进来，跑两周确认关联查询能覆盖 80% 的日常排障场景，再逐步迁移指标。迁移期间保留旧工具的只读访问作为兜底。

注意顺序：先定标签规范，再上平台。关联查询的价值只有在标签统一之后才会显现，标签各写各的，数据再多也串不起来。