企业官网建设流程全解析

可观测性这个词被喊了好几年，落到实际系统里，最常见的状态却是三套系统各管各的：Grafana 看指标，ELK 查日志，Jaeger 看链路。OpenTelemetry 和 Micrometer 的深度整合，要解决的就是把这三张皮缝到一块——指标、日志、链路互相能串起来，而不是出了问题以后在三个平台之间来回对时间戳。

我最近把一个订单微服务集群完整切到了这套方案上，Java 服务用 Micrometer 作为指标门面，再通过 OTLP 协议统一推到 OpenTelemetry Collector，Node.js/Nest.js 服务也尽量共用同一条采集链路。整个过程踩坑不少，这篇就是把能直接抄的配置和判断逻辑整理出来。不管你是刚接触可观测性，还是已经用着 Prometheus 但被多语言多集群的指标口径搞得头大，这篇文章都适合你。目标很明确：让你知道为什么这么整合、每一步在解决什么问题，以及出了问题该怎么排。

1. 项目定位与整体设计思路

1.1 三个信号问题的本质

指标、日志、链路，这三类数据本身是不同维度的观测信号。指标回答“系统现在有没有问题”，日志回答“当时到底发生了什么”，链路回答“一个请求穿过了哪些服务、慢在哪一环”。很多团队的问题不在于没有工具，而在于这三类数据是割裂的：指标告警只能告诉你“订单服务超时率增高”，但你没法从这条告警直接跳到具体的慢请求、再看这段请求的日志和跨服务调用关系。

我见过太多事故复盘变成“三个平台来回切”的马拉松。真正高效的可观测性不是多一个面板，而是把三个信号串在一个上下文里。OpenTelemetry 的定位就是标准化的信号采集与传输层，Micrometer 则是 Java 生态里最合适的指标门面。两者深度整合以后，指标的每个数据点都可以携带链路上下文（Exemplar），日志和链路可以共享同一个 trace_id，查询路径从“指标 → 链路 → 日志”一气呵成。

1.2 我为什么坚持用 OTel 做统一数据面

早些年 Java 服务接监控，最常见的套路是 Micrometer 接 Prometheus，Node.js 服务再用自己的 prom-client，两套打点方式、两套命名规范，最后在 Grafana 里手动对齐。这种“能用但别扭”的状态在很多公司持续了很多年，直到服务规模变大才暴露问题：跨语言调用时链路根本对不上，指标口径各说各话，新语言接入的成本更是成倍增长。

OpenTelemetry 的价值恰恰在“标准化”三个字。它定义了统一的 API、SDK、数据模型和传输协议（OTLP），Java、Node.js、Go、Python 都可以通过各自的 SDK 把数据按同一种结构送出来。引入 OTel 以后，Micrometer 的角色就变得清晰了：它继续负责 JVM 生态内的指标采集与聚合，但导出方向不再指向某个厂商网关或 Prometheus 专用格式，而是指向 OTLP。这样一来，指标数据就和 Trace、Logs 走同一条管道，实现真正的“三信号统一”。

1.3 深度整合后的目标架构

我最终落地的架构长这样：Java 服务（Spring Boot）使用 Micrometer 采集 JVM、HTTP、数据库连接池等指标，通过 micrometer-registry-otlp 将指标转成 OTel 模型，推给 OpenTelemetry Collector；同时 Java 服务接入 OTel Java Agent 或 SDK，输出 Trace 和日志关联信息。Node.js/Nest.js 服务则直接使用 OTel Node SDK 采集 Trace 和 Metrics。所有信号统一进入 Collector 的 OTLP Receiver，再由 Collector 做批量、过滤、重命名，分发给后端的 Prometheus（指标）、Tempo/Jeager（链路）和日志系统。

这样设计的好处有三个：第一，所有语言不再关心后端存储是什么，只需认准一个 Collector 地址；第二，命名规范、标签治理、采样策略都集中在 Collector 里改，不用改应用代码；第三，指标、链路、日志在源头就共享了 service.name 和 trace context，天然能串起来。

2. 关键原理：Micrometer 和 OTel 是怎么配合的

2.1 Micrometer 的 Meter 门面到底做了什么

Micrometer 是一个度量库门面，它对上层提供 Counter、Timer、Gauge、DistributionSummary 等 Meter 类型。它的价值不在于“采集”本身，而在于“屏蔽后端差异”。你代码里只写一个 timer 记录接口耗时，底层可以同时输出 Prometheus 格式、InfluxDB 格式，或者 OTLP 格式。这意味着业务代码不应该耦合任何监控后端，Micrometer 负责把打点数据翻译成各后端能理解的结构。

在整合 OTel 时，Micrometer 的作用也很清楚：它先把业务埋点统一成自己的 Meter 模型，然后 micrometer-registry-otlp 在导出时把这些 Meter 翻译成 OTel 的 Metric Data Model。翻译过程中会处理命名转换、标签映射、聚合方式（是 delta 还是 cumulative）、直方图桶边界等一系列细节。很多人以为 Micrometer 只是 Prometheus 的附属品，这是个误解，实际上它的抽象能力正是这次整合的地基。

2.2 OpenTelemetry 的信号模型与 OTLP

OpenTelemetry 把观测数据拆成三个信号：Metrics、Logs、Traces，统一用 Protobuf 定义数据模型，再通过 OTLP 协议传输。OTLP 支持 gRPC 和 HTTP 两种通道，常见端点是 /v1/metrics、/v1/traces、/v1/logs。如果走 HTTP 通道，一个 Collector 地址 4318 端口就能接收全部三种信号，服务端根据 URL 路径区分信号类型，非常方便。

理解 OTel 指标模型要注意几个核心概念：Resource（资源属性，比如服务名、环境、版本）、Scope（产生指标的作用域，通常是某个 SDK 或库）、Metric（指标本身）、DataPoint（具体数据点，每个点自带 attributes 和时间戳）。Micrometer 指标导出后，通常会把应用信息放在 Resource 里，把 meter 名称和 tags 映射成 Metric 和 DataPoint 的 attributes。这个分层结构，比 Prometheus 那种“扁平 label + 名字”的组织方式更适合作跨系统传递。

2.3 Micrometer 指标和 OTel 语义约定的异同

这是整合时最容易被忽略、却又最关键的一点。Micrometer 长期给 Prometheus 输出指标，习惯上是 snake_case 命名，单位会直接拼在名字里（jvm_memory_used_bytes、http_server_requests_seconds）。而 OpenTelemetry 的语义约定推荐的名称偏“域名式”，比如 http.server.request.duration，单位单独用一个字段表示，不再拼在名字里。

很多人切换后最直接的矛盾是：老 Grafana 面板全部失效，因为指标名变了。我个人的建议是两条路选一条走：要么在 Collector 里用 metricstransform processor 把语义约定命名改回旧命名；要么直接改造面板，适应 OTLP 命名。前者的好处是能保住现有看板，缺点是掩盖了新体系真正的目标。我自己的实际选择是：先让数据落库，再逐步迁移面板，而不是一步到位。

下面是一个常见的命名对照表，方便大家心里有数：

2.4 聚合方式与 Exemplar 细节

OTel 指标数据点有一个 Prometheus 里不常细究的概念：Temporality，即时间序列的聚合时序。Delta 表示每个导出周期内新增的量，Cumulative 表示从进程启动开始累计的量。Micrometer 默认按 Cumulative 输出，而很多监控系统（例如某些云端厂商）更希望收 Delta。你需要在接入时就定好这个参数，否则数据到了后端会对不上。

另一个值得重视的是 Exemplar。Exemplar 可以理解为一个直方图桶里的“代表性样本”，它除了记录数值，还能携带当前请求的 trace_id、span_id。这意味着你看到指标异常的瞬间，可以直接从指标数据点跳转到具体某一条链路。Micrometer 的 OTLP Registry 可以将当前 TraceContext 注入到直方图的 Exemplar 中，在 Prometheus 后端开启 Exemplar 存储后，Grafana 面板上就能直接点数据点看链路。这一步是“指标与链路串起来”的关键抓手，后面实操部分我会专门讲怎么落地。

3. Spring Boot 应用侧接入的完整路径

3.1 依赖选型和版本对照

先说版本。Spring Boot 3.x 是目前最省心的选择，因为 actuator 天然集成好了 Micrometer 的自动装配。Micrometer 这边需要额外引入 micrometer-registry-otlp，版本建议和 Spring Boot 管理的 Micrometer 版本保持一致，避免出现 API 不兼容。如果你已经用了 Spring Boot 3.4 及以上，官方还提供了 opentelemetry-spring-boot-starter，它会把指标、链路、日志统一交给 OTel SDK 管理，体验更一致。

如果不想升级 Spring Boot，旧项目也有办法：手动创建一个 OTel MeterRegistry 并注册到 CompositeMeterRegistry，但这一步需要自己处理资源属性和关闭逻辑，维护成本高一些。我的建议是：如果服务将长期演进，尽量往 Spring Boot 3.x 靠。下面是依赖示例：

implementation("io.micrometer:micrometer-registry-otlp:1.13.0") implementation("io.opentelemetry.instrumentation:opentelemetry-spring-boot-starter:2.6.0")

没有引入 OTel Java Agent 时，Micrometer 依靠这个 registry 就能独立完成 OTLP 指标推送。如果还想同时拿到链路追踪，再叠加 OTel Java Agent 或者上面的 Spring Boot starter，二选一即可，不要同时配置相同的功能导致重复导出。

3.2 让 Micrometer 走 OTLP 导出

micrometer-registry-otlp 引入后，Spring Boot 会自动读取 management.metrics.export.otlp.* 配置。最小可用配置如下：

management: metrics: export: otlp: enabled: true url: http://otel-collector:4318/v1/metrics step: 10s aggregation-temporality: cumulative

这里有一个容易踩的坑：如果应用里还保留着 Prometheus 端点，比如 management.metrics.export.prometheus.enabled=true，那么同样的指标就会从两个通路出去，Grafana 里的时间序列会出现重复或者口径打架。我的做法是切到 OTLP 之后直接关掉 Prometheus 暴露，保持单一采集源。

只配 URL 还不够，你必须在指标里带上“服务身份标签”，否则所有 Java 服务推到 Collector 后都长一个样子，没法区分。如果走 Spring Boot 自动装配，可以在配置里指定 Resource 属性：

management: otlp: metrics: export: resource-attributes: service.name: order-service service.version: 1.2.0 deployment.environment: production

如果你的项目用的版本不支持这段属性，也可以在代码里给 MeterRegistry 加 commonTags：registry.config().commonTags("service.name", "order-service")。方式不重要，重要的是每个指标序列都必须带服务标识。这一条直接影响后面所有聚合维度和告警规则。

3.3 OpenTelemetry Collector 配置与流水线

应用侧数据推出来了，Collector 就是所有信号的集散地。Collector 的配置文件分三块：receivers（接收）、processors（处理）、exporters（导出），再通过 pipelines 把它们串起来。最精简的配置如下：

receivers: otlp: protocols: grpc: http: processors: batch: timeout: 5s send_batch_size: 10000 exporters: prometheus: endpoint: 0.0.0.0:9464 resource_to_telemetry_conversion: enabled: true otlp/tempo: endpoint: tempo:4317 tls: insecure: true debug: verbosity: detailed service: pipelines: metrics: receivers: [otlp] processors: [batch] exporters: [prometheus, debug] traces: receivers: [otlp] processors: [batch] exporters: [otlp/tempo, debug]

这里最不起眼却最关键的配置是 prometheus exporter 里的 resource_to_telemetry_conversion。默认情况下，Collector 把指标转成 Prometheus 格式时，不会把 Resource 里的 service.name 变成 label，你会在 Prometheus 里看到一堆没有服务标识的序列，完全没法用。打开这个开关后，service.name、service.version 等资源属性会自动变成时间序列的标签，Grafana 里按服务维度筛选才有意义。

自定义指标名和标签的整理，可以在 processors 里加 metricstransform。举一个实际例子，我为了兼容旧面板，把 OTel 语义约定的 HTTP 指标名改回老名字：

processors: metricstransform: transforms: - include: http.server.request.duration match_type: strict action: update new_name: http_server_requests_seconds

但要注意：这种转换本质上是“妥协”，建议只用于过渡期，不要让 Collector 变成充满历史包袱的“翻译机”。

3.4 数据落地：Prometheus 加 Exemplar 打通链路

指标最终落到 Prometheus 后，想要从指标点直接点进链路，需要前后端都支持 Exemplar。Prometheus 在 2.26 后开始支持 Exemplar 存储，Grafana 面板在查询直方图类型的指标时，如果数据里带了 Exemplar，就能在图上看到铆钉标记，点击就能跳到对应的 Trace 页面。

要让 Exemplar 真的带上 trace_id，需要满足几个条件：指标类型必须是直方图（Timer 会生成 Histogram）；应用侧开启 trace context 注入；Micrometer 的 OTLP 导出要携带 Exemplar 数据点。对应的 Spring Boot 配置参考：

management: metrics: distribution: percentiles-histogram: http.server.requests: true

开启百分位直方图之后，http.server.requests 会生成 _bucket 序列，这些序列的每个桶都能携带 Exemplar。配合 OTel Java Agent 自动注入 trace context，Grafana 里就能实现“看到一个延迟尖刺，点开就是那条慢请求的完整链路”的体验。这个功能看起来很小，但对排障效率的提升是质的飞跃。

4. Nest.js 微服务如何共用同一套采集链路

4.1 Node.js 侧的可观测性现状

Node.js 生态里的可观测性工具不少，但成熟度整体比 Java 生态要散。很多 Nest.js 项目还在手写中间件记录接口耗时，再用 prom-client 手动暴露指标；链路追踪则常常依赖 AWS X-Ray 或者某家 APM 厂商的 SDK。问题在于：这些方案都是“自成体系”，数据格式、传播头部、语义命名各不相同，一旦和 Java 服务混在同一个调用链里，链路对不齐是家常便饭。

OpenTelemetry 的出现对 Node.js 生态是个好事。它提供了完整的 SDK 和自动插桩库，Nest.js 应用可以非常轻量地接入，并且和 Java 服务用同一种 W3C traceparent 头部传播上下文。这意味着一个从 Nest.js 网关发起的请求，经过 Java 订单服务，再调用 Node.js 用户服务，整条调用链可以在同一个 Trace 页面里完整看到。这就是我前面说的“用协议统一，而不是用厂商统一”的价值。

4.2 Nest.js 接入 OTel SDK

Nest.js 接入 OTel 的路径比较清晰：安装 SDK、初始化 tracer、注册自动插桩。我们需要用到以下依赖：

npm install @opentelemetry/sdk-node \ @opentelemetry/auto-instrumentations-node \ @opentelemetry/exporter-trace-otlp-http \ @opentelemetry/sdk-metrics \ @opentelemetry/exporter-metrics-otlp-http \ @opentelemetry/resources \ @opentelemetry/semantic-conventions

在项目启动入口之前注册 SDK，通常新建一个 tracing.ts，在 main.ts 第一行引用：

import { NodeSDK } from '@opentelemetry/sdk-node'; import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node'; import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http'; import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http'; import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics'; import { Resource } from '@opentelemetry/resources'; import { SemanticResourceAttributes } from '@opentelemetry/semantic-conventions'; const sdk = new NodeSDK({ resource: new Resource({ [SemanticResourceAttributes.SERVICE_NAME]: 'nest-user-service', [SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0', 'deployment.environment': 'production', }), traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4318/v1/traces', }), metricReader: new PeriodicExportingMetricReader({ exporter: new OTLPMetricExporter({ url: 'http://otel-collector:4318/v1/metrics', }), exportIntervalMillis: 10000, }), instrumentations: [getNodeAutoInstrumentations()], }); sdk.start();

初始化这段代码要放在应用启动之前，推荐用 import 的方式在最顶部引入，避免 Nest.js 已经创建 HTTP 服务后才注册，导致前几个请求没有被追踪到。

auto-instrumentations-node 包会自动给 HTTP 请求、数据库驱动、消息队列客户端等常用库打点。对 Nest.js 来说，HTTP 层的自动插桩已经覆盖了绝大多数场景，自己需要写业务埋点的时候，再通过 @opentelemetry/api 提供的 trace.getTracer() 去手动创建 Span。

4.3 跨语言 Trace 贯通的关键点

跨语言调用链能否打通，核心不取决于你用什么框架，而取决于流量经过的每个组件是否都遵守同一个传播协议。OTel 默认使用 W3C Trace Context，也就是在 HTTP 请求头里传递 traceparent 和 tracestate 两个头部。Java 侧只要接入 OTel Java Agent，RestTemplate、Feign、Apache HttpClient 这些常见客户端都会被自动插桩，把当前 Span 的上下文写进请求头。Node.js 侧同理，OTel 的 HTTP instrumentation 会自动识别并传播这个头部。

当 Nest.js 服务收到 Java 服务发来的请求时，它识别到 traceparent 头，就知道自己属于哪条 Trace，于是新建的子 Span 会挂到正确的父 Span 下面。这样在 Tempo 或者 Jaeger 里，你就能看到一条完整的调用链：网关（Node.js）→ 订单服务（Java）→ 用户服务（Node.js），每个服务各自的耗时清清楚楚。不需要任何一家 APM 厂商的私有协议参与。

我实际排障中遇到过这样的例子：Java 订单服务通过 Feign 调用 Node.js 用户服务，响应时间突然从 20ms 涨到 2 秒。如果没有跨语言 Trace，排查会先误判成用户服务的问题，折腾半天。看了完整链路后才发现，瓶颈其实在 Java 侧 Feign 连接池等待，Nest.js 服务本身没背锅。这种“上下文贯通”的能力，对微服务排障来说价值无法估量。

4.4 Node 侧指标与 Trace 的关联方式

Node.js 侧写业务指标，不推荐再用 prom-client 那套，直接用 OTel Metrics API 打点更干净。比如要统计一个核心业务方法的调用次数和耗时：

import { metrics } from '@opentelemetry/api'; const meter = metrics.getMeter('nest-user-service'); const requestCounter = meter.createCounter('user.api.requests', { description: 'Total user API requests', }); const requestDuration = meter.createHistogram('user.api.duration', { description: 'User API request duration', });

这些指标会和 Java 服务的指标一起，通过同一套 OTLP 推到 Collector，最终进入同一个 Prometheus。查询 Grafana 面板时，你不再需要区分“这是 Java 指标还是 Node 指标”，只需要按 service.name 过滤。这才是“可观测性统一”在工程上的实际体现。

需要注意的一点是：Node 侧虽然也有 Micrometer 风格的 metric 库，但 Micrometer 本身是 JVM 生态的，没必要在 Node 里模仿它的用法。直接用 OTel API 就是最简路径，因为指标模型已经在底层对齐了。

5. 常见问题与排查技巧实录

5.1 指标重复暴露与命名不一致

我见过最高的频次是：Spring Boot 服务既开着 actuator 的 /actuator/prometheus，又开着 OTLP 导出，两边同时往同一个 Prometheus 推送或被抓取，导致面板上出现两套完全一样的指标，只在某些标签上略有差异。查这种问题直接看目标（targets）或者数据源的 label 集合，凡是看到同一个指标名来自两个 job，基本就是采集链路重复。

解决方式就是二选一。走 OTLP 统一链路就关掉 Prometheus 导出端点，反之则不要接 OTLP。命名不一致的问题，优先用 Collector 的 metricstransform 做过渡映射，同时把老面板逐步迁移到新命名，切记不要长期维护两套别名。

5.2 service.name 和 scope 对齐问题

引入 Micrometer OTLP 后，有一个很隐蔽的问题：每个指标数据点里除了 Resource 里的 service.name，Scope 里也可能出现一个类似 “micrometer” 的标识。如果 dashboard 里误用了 scope 维度来区分服务，会发现所有 Java 服务都叫 “micrometer”，而不是业务服务名。

我的排查经验是：先打开 Collector 的 debug exporter，详细输出一条指标数据，看 Resource 里 service.name 对不对，Scope 里是什么，attributes 里有没有多余内容。很多“找不到服务”的问题，本质上就是 Resource 没配置对。确认 service.name 时，宁可多花十分钟把 Java 服务和 Node 服务的命名规范定死，也不要随手填。

5.3 高基数指标造成的存储增长

从 Prometheus 转到 OTel 后，最容易犯的错误是把 HTTP 请求路径当 attributes 直接打出来。比如把 /api/orders/123 和 /api/orders/456 当成两种不同的标签值，时间序列数量随着请求量无限膨胀。这个问题在 Micrometer 时代也存在，但在 OTel 跨语言场景下更容易被放大，因为 Node 侧也可能输出同样的路径。

解决思路是“低基数原则”：凡是会随请求内容变化的标签值，必须归一化处理。优先使用路由模板（/api/orders/:id），或者在 Collector 里用 metricstransform 把高基数 attribute 改写或删除。如果确实需要知道某个具体路径的粒度，可以考虑抽样记录到日志或链路里，而不是全部塞进指标。时序数据库的存储成本是持续性的，一个设计失误可能每个月都在烧钱。

5.4 OTLP 传输失败与数据丢失

OTLP 发送看起来简单，就是 HTTP POST 或 gRPC，但生产环境里 Collector 挂了、网络抖动、应用启动比 Collector 早，这些情况都会导致数据发不出去。OTel SDK 默认有重试机制，但重试也是有上限的，缓冲区满了之后新数据会被丢弃。

排查手段很简单：先看应用日志里有没有 OTLP export 报错，再看 Collector 的 debug exporter 输出。我的实际做法是给 Collector 加一个健康检查，并在告警规则里盯 Collector 的接收速率，一旦归零立刻告警。还有一点容易被忽略：容器化部署时，应用先启动、Collector 后启动，应用侧会短暂报错，但只要 OTel SDK 的重试机制生效，数据不会丢太多。追求更高的可靠性，可以把导出队列调大、增加本地文件的 fallback exporter 做容错缓解。

下面是一个简化版排查速查表：

5.5 聚合窗口与采集频率的匹配问题

最后一个常坑人的点是 step 和抓取间隔不匹配。Micrometer 默认 step 是 1 分钟，如果你把 Prometheus 的抓取间隔调成 15 秒，同一分钟内 Prometheus 可能抓到多个相同的数据点，或者采集间隔太短导致数据点还没聚合完。OTLP 导出给 Collector 后，Collector 以 batch 形式转给 Prometheus，这时如果 batch 超时设置太短，频繁刷新会带来不必要的开销。

我建议的起步值是：Micrometer 的 step 和 PeriodicExportingMetricReader 的 exportIntervalMillis 都设成 10 秒，Collector 的 batch timeout 设 5 秒，Prometheus 抓取间隔设 15 秒到 30 秒。规则就是下游抓取间隔不要小于上游导出间隔的一半，否则数据会出现“锯齿”或者空洞，导致告警误报。

6. 实操心得与团队落地建议

6.1 先把 Trace 打通，再谈指标统一

如果团队资源有限，我的建议是不要一上来同时折腾三个信号。先做 Trace，因为链路是最能直观反映“调用关系和性能瓶颈”的信号，也是跨语言场景下最容易出成果的一步。等团队习惯了用 Tempo 看跨服务调用链，再逐步把 Micrometer 指标切到 OTLP，最后接日志关联。我见过太多团队一上来就要“全量标准库”，结果连 service.name 都没规范清楚，最后不了了之。

6.2 统一标签和命名规范要趁早

服务名、环境、版本、部署区域，这些资源属性会在你写第一个告警规则、建第一张 dashboard 时变成不可改变的基础。命名规范一旦出现“order_service”和“order-service”混用，后面的疲劳就会成倍增加。我的做法是：建一个简单的规范文档，服务名用小写字母加中划线，环境统一用 development/staging/production，版本号必须带上，然后把这个规范写进所有应用的模板和启动脚本里。

6.3 下一步可以扩展的方向

这套体系跑起来以后，后面可以玩的还有很多：把 OpenTelemetry Collector 部署成 Kubernetes DaemonSet，配合 Target Allocator 做自动服务发现；在 Collector 里做 tail sampling，只保留错误和慢请求的完整链路，控制存储成本；还可以接入持续剖析（Continuous Profiling），把 CPU/内存火焰图和 Trace 关联起来。方向很多，但基础都是先把数据打通，否则上层工具再花哨也是空中楼阁。

我实际把这套东西跑了差不多三个月，最大的感受不是某个配置多高级，而是团队终于开始用同一份数据说话。出了事不再是谁抢着翻自己的平台，而是共同打开一条链路、一张面板，指着同一个指标讨论问题。如果你现在正准备做可观测性改造，我建议先把 service.name 和环境标签统一了，再让所有语言从同一个 Collector 进出，这比选任何一个具体工具都重要。剩下的配置和组件，官网和社区都有大量资料可以查，但方向一旦歪了，后面返工的成本远比想象中高。