OpenTelemetry 统一三大支柱与 Collector 架构

• Correlated Signals 的概念（Trace/Metrics/Logs 关联）
• 排障工作流（Trace→Metrics→Logs）
• 三种信号在排障中的分工

Correlated Signals（关联信号）指把 Trace、Metrics、Logs 三种信号「关联」起来，用一个信号「跳转」到另一个信号，形成「完整排障链路」。实战工作流：① Trace 异常——从 Trace 发现某个请求「慢/错」（span 异常、高延迟）；② 跳转 Metrics 看整体——从出问题的 Trace 跳转到「相关服务的 Metrics」，看「整体情况」：该服务是否整体延迟升高、错误率上升、是否「只是个别请求」还是「整体故障」；用「整体指标」判断「影响范围与趋势」；③ 跳转 Logs 看细节——从 Trace/Metrics 跳到「相关 Logs」，看「具体细节」：错误堆栈、具体参数、上下文信息，定位「根因细节」。工作流设计：① 统一标识——用「trace_id/span_id/时间戳」关联三种信号，支持「跳转」；② 排障路径——「Trace 定位异常请求 → Metrics 看整体影响 → Logs 看根因细节」；③ 工具联动——Grafana（Metrics）+ Tempo（Trace）+ Loki（Logs）联动，或 Jaeger + Prometheus 联动，实现「一键跳转」。价值：① 避免「单信号盲人摸象」——Trace 看单请求、Metrics 看整体、Logs 看细节，三者互补；② 高效排障——从「异常」到「整体」到「根因」的「向导式」排障；③ 减少上下文切换——一个平台跳转。「从 Trace 到 Metrics 到 Logs」是「Correlated Signals 排障」的标准工作流。

Correlated Signals 排障的核心是「三种信号分工 + 关联跳转」。Trace 看单请求、Metrics 看整体、Logs 看细节，用统一标识关联跳转，形成「Trace→Metrics→Logs」的向导式排障。它避免「单信号局限」，提升排障效率。

• TraceContext 传播（关联 trace）
• Exemplar（指标关联 trace）
• LogRecord 中的 trace_id/span_id 注入

OpenTelemetry 通过多种机制把 Trace、Metrics、Logs 关联起来。① TraceContext 传播——trace 的「trace_id/span_id」通过 HTTP 头（traceparent）等「上下文传播」机制在「服务间」传递，让「一条请求的多个 span」串联成「完整 trace」，建立「跨服务关联」；② Exemplar——「指标与 trace 的关联」：Metric 的样本（Exemplar）携带「trace_id/span_id」，把「一个指标值」关联到「产生它的具体 trace/span」，让「指标异常」能跳转到「具体请求」；③ LogRecord 中的 trace_id/span_id 注入——Log 记录时「注入 trace_id/span_id」，让「日志」关联到「具体 trace/span」，从日志跳转到完整请求链路。三种机制：① TraceContext 传播「串联 trace」；② Exemplar 关联「指标到 trace」；③ Log 注入 trace_id/span_id 关联「日志到 trace」。三者共同实现「Correlated Signals」——trace 是「关联枢纽」，metrics 与 logs 通过 trace_id/span_id 关联到 trace。落地：在「采集/埋点」时统一注入 trace_id/span_id，用「关联引擎」支持「跨信号跳转」。这是「OTel 三大支柱统一」的核心机制。

OTel 关联机制的核心是「trace_id/span_id 作为关联枢纽」。TraceContext 传播串联 trace，Exemplar 关联指标到 trace，Log 注入 trace_id 关联日志到 trace。三者共同实现「Trace-Metrics-Logs 关联」，是 Correlated Signals 的基础。

• Agent 与 Gateway 拓扑的分工
• Load Balancing Exporter 的作用
• 大流量场景的工程价值

OTel Collector 的 Agent/Gateway 拓扑与 Load Balancing Exporter 在大流量场景有重要工程价值。① Agent 拓扑——每个节点/应用部署 Agent（DaemonSet/sidecar），负责「本地采集、预处理（采样、批处理、过滤）、转发」，降低「应用侧开销」；② Gateway 拓扑——聚合层（Deployment）接收多个 Agent 的数据，负责「聚合、路由、处理、导出」，集中管理「出口（后端）」，提供「运维集中点」；③ Load Balancing Exporter——在 Gateway 层用「负载均衡」把数据「分发到多个下游/后端」：① 扩展出口吞吐（多个后端分摊）；② 故障转移（后端故障换其他）；③ 按 trace/路由分发（保持 trace 的完整性）。大流量工程价值：① 分流——Agent 预处理减轻负载，Gateway 聚合 + Load Balancing Exporter 分散后端压力，支撑「高吞吐」；② 可扩展——水平扩展 Gateway/后端，应对流量增长；③ 高可用——Load Balancing 提供后端冗余与故障转移；④ 成本控制——Gateway 集中做采样/过滤，控制存储成本。落地：Agent 采集 → Gateway 聚合 → Load Balancing Exporter 分发到多个后端（如 Thanos/Mimir 分片）。价值核心是「用分层拓扑 + 负载均衡支撑大流量、高可用、可扩展的采集管道」。

Agent/Gateway 拓扑 + Load Balancing Exporter 的工程价值是「分层分流 + 负载均衡 + 高可用扩展」。Agent 预处理、Gateway 聚合、Load Balancing 分散后端，支撑大流量与扩展。这是「大流量采集管道」的架构。

• GenAI Semantic Conventions 的内容
• 标准化 LLM 可观测性的作用
• 对团队与工具的价值

OTel GenAI Semantic Conventions 为「LLM 应用的可观测性」定义「标准化的语义约定」，用统一的 span attributes 描述 LLM 调用。内容：① gen_ai.system——LLM 系统（如 OpenAI、Anthropic）；② gen_ai.request.model——请求使用的模型；③ gen_ai.request.temperature 等请求参数；④ gen_ai.response.model、gen_ai.usage.prompt_tokens/completion_tokens（token 用量）；⑤ gen_ai.operation.name——操作类型（如 chat、embedding）。标准化作用：① 统一——不同 LLM 供应商（OpenAI/Anthropic/Azure）的调用被「统一为相同语义」的 span attributes，跨供应商可比较；② 可观测——统一记录「模型、token 用量、延迟」等 LLM 关键指标，支撑「成本、性能、质量」观测；③ 可移植——团队换 LLM 供应商时，观测模型不变，降低迁移成本；④ 生态——第三方工具（LangSmith、LLM 可观测平台）遵循同一约定，数据可互操作。价值：LLM 可观测性标准化让「LLM 调用」像「普通 HTTP」一样「可观测、可比较、可治理」，支撑「成本优化（token 用量）、性能监控（延迟）、质量追踪」。这是「LLM 应用进入可观测性体系」的标准。

GenAI Semantic Conventions 的核心价值是「标准化 LLM 调用语义」。用统一 attribute（gen_ai.system/model/usage）跨供应商统一、支撑成本/性能/质量观测、可移植。它让 LLM 可观测性「标准化、可比较、可治理」。

• 指标（Metrics）的适用场景
• 追踪（Trace）的适用场景
• 日志（Logs）的适用场景

OTel 三大信号各有「适用场景」，需按「需求」取舍。① 指标（Metrics）——适合「聚合、长期、趋势」场景：服务可用性、请求速率、错误率、延迟分布、资源使用率；用「聚合值」看「整体健康与趋势」，存储成本低、适合告警；适合「回答『系统整体如何』」。② 追踪（Trace）——适合「单次请求的完整链路」：跨服务调用、请求经过的每个 span、耗时与错误；用「单请求细节」定位「问题发生在哪个服务/环节」；适合「回答『这个请求为什么慢/错』」；适合「排障、依赖分析」。③ 日志（Logs）——适合「事件详情、错误堆栈、上下文信息」：错误信息、业务事件、调试细节；用「文本详情」看「具体发生了什么」；适合「回答『具体原因是什么、细节如何』」；适合「排障细节、审计」。取舍原则：① 需要「整体趋势/告警」→ 指标；② 需要「单请求链路/依赖」→ 追踪；③ 需要「具体事件/错误细节」→ 日志；④ 高成本考虑——指标最省（聚合）、追踪中（span）、日志最贵（原始文本）；⑤ 通常「组合」——指标看整体、追踪看链路、日志看细节，即 Correlated Signals。取舍的本质是「按『要回答什么问题』选信号」，并考虑「成本」。

三大信号取舍的核心是「按问题选信号」：指标看整体趋势、追踪看单请求链路、日志看事件细节。同时考虑「成本」（指标省、日志贵）。实际排障「组合」三者（Correlated Signals），而非「单选」。

• Agent 与 Gateway 部署模式
• 背压处理
• 路由与过滤

OTel Collector 的部署模式选择影响「采集架构」。① Agent（DaemonSet）——每个节点部署一个 Agent，采集「节点上的应用数据」，做「本地预处理（采样、批处理、过滤）」，降低应用侧开销；适合「采集就近、本地处理」；② Gateway（Deployment）——集中部署的聚合层，接收多个 Agent 的数据，做「聚合、路由、处理、导出」，集中管理「出口后端」；适合「集中运维、统一出口」。③ 背压处理——当「下游（后端）慢/不可用」时，Collector 需「背压处理」：用「持久队列（持久化缓冲）」缓冲数据，避免「数据丢失」；「重试退避」重试失败的导出；「降级」下游不可用时缓存/降级。背压是「采集管道可靠性」的关键。④ 路由与过滤——Collector 支持「路由（routing）」：按「数据特征/标签」把数据路由到不同后端（如按服务发到不同存储）；「过滤（filter）」：按条件丢弃/简化数据，控制「成本与噪音」。落地架构：Agent 采集 → Gateway 聚合 → 路由/过滤 → 导出到后端；配合「持久队列 + 重试」处理背压。价值：Agent/Gateway 分工 + 背压可靠性 + 路由过滤控制，构成「可靠、可扩展、低成本」的采集管道。

Agent/Gateway 部署模式是「分工」——Agent 就近采集、Gateway 集中聚合。背压处理（持久队列 + 重试）保证「下游故障不丢数据」，路由过滤控制「成本与噪音」。三者构成「可靠、可扩展、低成本」的采集管道。

• Semantic Conventions 的作用
• HTTP/数据库/消息队列/FAAS 的标准属性
• 命名规范

OTel Semantic Conventions（语义约定）定义了「各技术栈的可观测性标准属性与命名规范」，让数据「统一、可互操作」。HTTP——http.request.method（请求方法）、http.response.status_code（状态码）、http.route（路由）、url.path、server.address/server.port 等；数据库——db.system（数据库类型）、db.name、db.operation（操作如 SELECT）、db.statement（SQL 语句，可脱敏）、db.collection.name 等；消息队列——messaging.system、messaging.destination.name（队列/主题）、messaging.operation（发送/接收）、messaging.message.id 等；FAAS——faas.trigger（触发方式）、faas.invoked_name、faas.coldstart（冷启动）等。命名规范：① 属性用「点分命名空间」分层（如 http.、db.、messaging.、faas.）；② 属性名小写、下划线分隔；③ 值用「标准类型」；④ 遵循「语义约定」的属性才有「跨工具可比性」。作用：① 统一——不同语言/框架的埋点遵循同一约定，数据可互操作；② 可比较——不同系统的 HTTP 指标属性一致，可比对；③ 工具兼容——第三方工具（Grafana、Jaeger）按约定解析。Semantic Conventions 是「OTel 数据标准化」的根基，让「可观测性数据」成为「标准资产」。

Semantic Conventions 的核心是「标准属性 + 命名规范」。HTTP/数据库/消息队列/FAAS 各有「标准属性名」，用「点分命名空间」分层。它保证「数据统一、可互操作、可比较、工具兼容」，是 OTel 标准化的根基。

• 多集群数据统一（Thanos/Mimir/Cortex 长期存储）
• Grafana 多数据源查询
• 全局 SLO 看板

多集群可观测性数据统一需要「长期存储 + 统一查询 + 全局视图」。① 长期存储——Thanos/Mimir/Cortex 提供「Prometheus 的长期存储与多集群聚合」：① Thanos——把多个 Prometheus 的数据「聚合 + 长期存储（对象存储）」，提供「全局查询」；② Mimir/Cortex——「水平扩展 + 多租户 + 长期存储」的 Prometheus 兼容后端，统一多集群指标；解决「Prometheus 单机存储有限 + 多集群分散」的问题。② Grafana 多数据源查询——Grafana 配置「多数据源」（Thanos/Mimir/Cortex、Loki、Tempo 等），「跨数据源」查询，统一「多集群、多信号的视图」；用「多数据源」+「Prometheus 兼容」统一查询层。③ 全局 SLO 看板——在「统一数据」基础上建「全局 SLO 看板」：把多集群的「SLI 聚合」成「全局 SLO」，展示「全局可用性/延迟/错误预算」，跨集群对比，支撑「全局告警」。落地架构：多集群 Prometheus → Thanos/Mimir 聚合长期存储 → Grafana 多数据源查询 → 全局 SLO 看板与告警。价值：① 统一视图——多集群数据「一处查询、全局可见」；② 长期保留——对象存储长期存储，支撑历史分析；③ 全局治理——全局 SLO 看板支撑「全局可靠性治理」。这是「多集群可观测性」的成熟架构。

多集群数据统一的核心是「Thanos/Mimir/Cortex 聚合长期存储 + Grafana 多数据源查询 + 全局 SLO 看板」。它解决「Prometheus 单机限制 + 多集群分散」，实现「全局统一查询、长期保留、全局治理」。

• resource detection 的作用
• attributes processor 的作用
• 统一注入集群/节点/服务标签

OTel Collector 用 resource detection 与 attributes processor 统一注入「资源维度标签」。① resource detection——「自动检测」采集环境资源信息：从「环境/云/容器」检测「集群、节点、Pod、服务、云 region」等维度，注入为「resource 属性」；如从 K8s 检测 k8s.cluster.name、k8s.node.name、k8s.pod.name、service.name；从云检测 cloud.region；② attributes processor——「操作属性」：对「resource/span/metric/log 属性」做「添加、删除、更新、重命名」；用于「统一注入」自定义标签（如团队、环境、业务维度）或「规范化」已有标签。用法：① 用 resource detection 自动注入「标准资源维度」（集群、节点、服务）；② 用 attributes processor 统一「注入/规范化」业务标签（如 team=xxx、env=prod）；③ 组合——在 pipeline 中「先 resource detection 自动检测，再 attributes processor 规范化」，实现「统一注入维度标签」。价值：① 统一维度——所有数据带「集群、节点、服务」等统一标签，支撑「按维度过滤、聚合、告警」；② 关联——资源标签支撑「跨维度关联」；③ 规范化——统一字段名，避免「各团队标签不一致」。实现「统一注入集群/节点/服务标签」是「多集群/多团队可观测性统一」的基础。

resource detection 自动采集「资源维度」，attributes processor 注入/规范化「标签」。两者组合实现「统一注入集群/节点/服务维度标签」，支撑「按维度过滤、聚合、关联」。这是「多集群可观测性统一」的数据基础。

• 持久队列（可靠性）
• 重试退避（失败重试）
• 导出失败的降级策略

OTel Collector 的可靠性设计保证「下游故障不丢数据」。① 持久队列——用「持久化队列」缓冲待导出数据（queue 处理器或 exporter 的 queue 配置）：数据先入队，异步导出；下游不可用时数据「留在队列」不丢失；可配置「队列大小」；持久队列（写入磁盘）在「Collector 重启」后仍保留数据。② 重试退避——导出失败时「重试」，用「退避（backoff）」策略：初次失败后「等待」再重试，重试间隔「指数退避 + 抖动」，避免「重试风暴」；配置 retry_on_failure、max_elapsed_time 等。③ 降级策略——下游「长期不可用」时处理：① 队列满时「丢弃最旧/告警」；② 启用「降级模式」——缓存/延迟导出；③ 多后端「故障转移」——主后端不可用切到备用；④ 记录「导出失败」告警。落地配置：exporter 配 queue（持久队列）+ retry_on_failure（重试退避）；结合「批处理」缓冲。可靠性设计价值：① 不丢数据——持久队列 + 重试保证「下游抖动不丢数据」；② 不过载——退避防重试风暴；③ 可降级——下游故障时优雅处理。核心是「采集管道的可靠性」——「下游慢/挂」不丢数据、不崩溃。

Collector 可靠性设计核心是「持久队列（缓冲）+ 重试退避（防风暴）+ 降级（优雅处理）」。持久队列保证「重启不丢」，重试退避防「重试风暴」，降级策略处理「长期故障」。它保证「采集管道可靠」。

• Agent 与 Gateway 的职责分工
• 本地缓冲、批量压缩、出口聚合的位置
• 职责划分的优化

OTel Agent 与 Gateway 的职责划分是「就近处理 + 集中处理」的分工。① Agent（本地）——① 本地缓冲：Agent 采集后「本地缓冲」数据，减少对应用的影响；② 批量压缩：Agent 用「批量处理器（batch processor）」聚合数据、压缩（gzip），减少「传输次数与带宽」；③ 就近预处理：采样、过滤、向量化在本地完成，降低「应用侧开销」和「传输量」；Agent 负责「采集端的轻量处理」。② Gateway（出口聚合）——① 出口聚合：Gateway 把「多个 Agent 的数据」聚合，集中处理后「导出到后端」；② 集中处理：路由、过滤、补充资源标签、多后端分发在 Gateway 完成；③ 出口管理：Gateway 统一管理「导出出口」（后端、负载均衡、重试），集中运维；分「出口的集中处理」。职责划分优化：① Agent 做「本地轻量处理」（缓冲、批量、压缩、采样）→ 减少传输与上游开销；② Gateway 做「集中处理」（聚合、路由、过滤、导出）→ 统一出口、集中运维；③ 通过「分层」——Agent 预处理、Gateway 聚合，实现「高效、可扩展、低成本」的采集管道。核心是「Agent 就近处理、Gateway 集中聚合」，各司其职。

Agent 与 Gateway 职责划分是「Agent 就近（缓冲/批量/压缩/采样）、Gateway 集中（聚合/路由/过滤/导出）」。它减少「传输量、上游开销」，实现「出口集中管理」。分层是「高效采集管道」的关键。

• OTel 与 Prometheus 集成（exporter/receiver）
• OTel 与 Jaeger 集成（exporter）
• 配置要点

OTel 与 Prometheus/Jaeger 集成，实现「OTel 数据进入既有观察栈」。① Prometheus 集成——① Receiver：OTel Collector 用 prometheus receiver 抓取 Prometheus 指标（把 Prometheus 指标接入 OTel 管道）；② Exporter：OTel 用 prometheus exporter 把 OTel 指标「输出为 Prometheus 格式」，供 Prometheus 抓取/兼容；配置要点：prometheus exporter 在指定端口暴露 /metrics，支持 resource_to_telemetry_conversion（把资源属性转 label）、metric_to_ottl 等。② Jaeger 集成——用 jaeger exporter 把 OTel「trace」导出到 Jaeger（兼容 Jaeger 后端），配置要点：endpoint（Jaeger 的 OTLP/HTTP/gRPC 地址）、tls（TLS）、timeout。③ 集成价值——OTel 作为「统一采集」，导出到「既有 Prometheus（指标）+ Jaeger（trace）」后端，实现「OTel 埋点 + 既有后端」的渐进迁移，避免「推翻重来」。配置要点总结：① Prometheus exporter（暴露 /metrics 供 Prometheus 抓取）、receiver（抓取 Prometheus 指标）；② Jaeger exporter（导出 trace 到 Jaeger）；③ 用 service.pipelines 配置「metrics/traces」管道，绑定对应 exporter/receiver。集成让「OTel 与既有 Prometheus/Jaeger 共存」，是「渐进式迁移」的关键。

OTel 与 Prometheus/Jaeger 集成的核心是「exporter/receiver 对接」。Prometheus 用 exporter 输出指标、receiver 抓取指标；Jaeger 用 exporter 导出 trace。集成让「OTel 埋点 + 既有后端」共存，是「渐进迁移」路径。

• 采样率控制
• 批处理（batch processor）
• 导出压缩

OTel 成本控制通过「采样率、批处理、压缩」组合降低「出口带宽与存储成本」。① 采样率——降低「采集的数据量」：对 trace 采样（如只保留 10% 的 trace，或「错误全采 + 正常采样」）、对指标降采样；减少「传输与存储」的数据量；② 批处理（batch processor）——合并「多个小数据」为「大批次」再导出：减少「导出次数、网络往返、HTTP 开销」；用 batch 处理器配置 batch_size、timeout，提高「导出效率」；③ 导出压缩——用 gzip 等「压缩」export 的数据：减少「传输带宽」；配置 exporter 的 compression: gzip。组合效果：① 采样减少「数据量」→ 降低「存储成本」；② 批处理提高「导出效率」→ 降低「网络开销」；③ 压缩降低「带宽」→ 降低「传输成本」。落地：① 采样（trace 采样、指标采样）控制数据量；② batch 处理器合并导出；③ exporter 配 gzip 压缩。核心是「在不牺牲『关键可观测性』的前提下，用采样 + 批处理 + 压缩控制成本」。成本控制是「OTel 规模化落地」的关键——数据量大时成本失控。

OTel 成本控制的核心是「采样（减量）+ 批处理（提效）+ 压缩（减带宽）」。采样降存储成本、批处理降网络开销、压缩降带宽。三者组合在「保关键观测」前提下控成本，是规模化落地关键。

• OTLP 指标到 Prometheus 告警的链路
• 链路延迟的来源
• 延迟控制

OTel 指标与告警的衔接指「OTel 采集的指标 → 触发 Prometheus 告警」的链路。链路：① OTel（应用/Collector）采集并生成 OTLP 指标 → ② Collector 导出到 Prometheus（exporter 暴露 /metrics 或 remote write 到 Mimir）→ ③ Prometheus 抓取/存储指标 → ④ Prometheus 告警规则评估 → ⑤ Alertmanager 通知。延迟来源：① OTel 采集→导出延迟（批处理缓冲、采样窗口）；② Prometheus 抓取间隔（scrape_interval）；③ 告警规则的评估间隔（evaluation_interval）；④ 告警的 for 条件（持续时长才触发）。延迟控制：① 缩短「抓取间隔」与「评估间隔」（如 15s/30s）；② 减小「批处理缓冲」延迟（降低 batch timeout）；③ 简化「告警 for 条件」（平衡误报与延迟）；④ 用「remote write 直写」减少「抓取往返」延迟；⑤ 关键告警用「低延迟路径」。平衡：延迟越低、告警越及时，但「抓取频繁/评估频繁」增加「负载与误报」；需「在及时性与稳定性间平衡」。核心是「端到端延迟」= 采集 + 抓取 + 评估 + 告警条件，控制各环节延迟实现「及时告警」。OTel 到 Prometheus 告警的链路是「指标可观测性 → 告警」「最后一公里」，延迟控制保障「及时发现问题」。

OTLP 指标到 Prometheus 告警的链路延迟 = 采集 + 抓取 + 评估 + 告警条件。控制延迟靠「缩短间隔、减小缓冲、remote write、简化 for 条件」，但需平衡「及时性与误报/负载」。核心是「控制端到端延迟」。

• OTLP gRPC/HTTP 的 TLS 配置
• 认证令牌
• 内部网络隔离

OTel 数据传输安全保障「链路传输的数据安全」。① TLS 配置——OTLP gRPC/HTTP 传输用 TLS 加密：receiver/exporter 配置 TLS（tls 段：cert_file、key_file、ca_file、min_version），实现「mTLS（双向认证）」可验证对端；防止「数据被窃听/篡改」。② 认证令牌——用「认证扩展（如 oidc、bearer_token、auth 认证）」在 Collector 之间/与后端之间传递「认证令牌」：receiver 用 auth 验证「请求令牌」，exporter 用 auth 附带「令牌」；防止「未授权写入/读取」。③ 内部网络隔离——把「采集链路」放在「内部网络/私有网络」：① Collector 与后端在「内网/VPC」通信，不暴露公网；② 用「网络策略」限制「谁可以访问 Collector 端口」；③ 分「采集网段」与「应用网段」，隔离「采集流量」；④ 用「服务网格/防火墙」控制访问。落地要点：① OTLP 传输启用 TLS（加密）；② 用认证令牌（auth）控制「访问」；③ 内部网络隔离（内网通信 + 网络策略）限定「访问范围」。三层保障「传输加密、访问认证、网络隔离」，实现「OTel 数据传输安全」。核心是「数据在传输中加密、访问有认证、网络有隔离」。

OTel 传输安全的核心是「TLS 加密 + 认证令牌 + 网络隔离」三层。TLS 加密传输、认证令牌控制访问、内网隔离限定范围。三层保障「传输安全」，是「可观测性数据安全」的一部分。

• 自动插桩（auto-instrumentation）的覆盖与局限
• 手动埋点（manual）的关键场景
• 选择与组合

OTel 的自动插桩与手动埋点需「按场景选择」。① 自动插桩（auto-instrumentation）——用「agent/库」自动注入埋点，覆盖「通用框架」的 HTTP、数据库、gRPC 等调用；优点「零代码、快速覆盖」；局限——① 只覆盖「框架约定的通用路径」，无法覆盖「业务自定义逻辑」；② 无法注入「业务语义」的 span（如「订单创建」「支付」）；③ 无法覆盖「非标准库」/自定义协议；适合「通用框架」的快速覆盖。② 手动埋点（manual）——在「关键业务逻辑」手动添加 span/属性，注入「业务语义」；适合「关键业务场景」：① 核心业务流程（下单、支付、鉴权）——希望追踪「业务链路与语义」；② 自定义逻辑/算法——自动插桩无法覆盖；③ 业务维度指标——需要「业务标签/属性」；④ 性能关键点——需要「精确的 span」；手动埋点提供「业务语义、精确控制」。选择与组合：① 用「自动插桩」覆盖「通用框架」快速起量；② 用「手动埋点」补充「关键业务场景」的语义；③ 组合——自动覆盖「广度」+ 手动覆盖「关键深度」。界定依据：是否能「自动获得有用语义」——通用框架用自动，需要「业务语义/精确控制」用手动。核心是「自动保广度、手动补深度」。

自动插桩「快但泛」（覆盖通用框架无业务语义），手动埋点「慢但准」（注入业务语义）。选择依据是「是否需要业务语义/精确控制」——通用框架用自动，关键业务用手动，组合「自动广度 + 手动深度」。

• resource 属性与 span 属性的命名规范
• 服务名（service.name）规范
• 落地统一命名

OTel 语义约定的落地需「统一命名规范」，保证「数据一致、可检索」。① resource 属性——描述「资源维度」（服务、集群、节点、环境）：service.name（服务名）、service.namespace、service.version、deployment.environment、k8s.cluster.name 等；用「标准 resource 属性」统一「资源维度」；② span 属性——描述「具体操作」：http.request.method、db.system、messaging.system 等，遵循「语义约定」的「点分命名空间」；③ 服务名规范——service.name 是「最关键的资源属性」，需统一：① 跨服务用「一致的服务名」；② 命名规范（如「应用-模块」或「团队-服务」）；③ 避免「别名/重复」导致「同一服务多个名字」；④ 用「resource detection」自动注入 service.name 并「规范化」。落地：① 统一「命名规范」——定义「服务名、资源属性、span 属性」的命名规则；② 用「attributes processor / resource processor」统一注入/规范化；③ 用「collector」在整个管道「统一命名」；④ 建立「命名规范」文档，团队遵循。价值：① 一致——统一命名让「数据可聚合、可检索、可比较」；② 关联——统一的 service.name 支撑「跨服务关联」；③ 可治理——一致命名支撑「统一的可观测性治理」。核心是「用标准命名 + 处理器统一」保证「数据一致」。

语义约定落地的核心是「统一命名」——resource 属性（service.name 等）与 span 属性遵循「点分命名空间」，用 collector 处理器统一注入/规范化。统一的 service.name 特别关键，支撑「聚合、关联、治理」。

• Head-based 与 Tail-based sampling
• 错误采样（全采错误）
• 流量成本控制

OTel 采样策略用于「控制数据量、控制成本」，需按「策略」选择。① Head-based sampling（头部采样）——在「数据产生时（trace 开始）」决定是否采样（基于 trace_id 哈希等），决策「无完整上下文」；实现简单、开销低，但「无法基于完整 trace 决策」（如不知是否包含错误）；② Tail-based sampling（尾部采样）——在「trace 完成后」基于「完整 trace」决策采样（如「含错误的 trace 全采」）；更精准（能保留「有价值」的 trace），但需要「缓冲完整 trace」、开销高、复杂度高。③ 错误采样——「错误/slow 全采」：无论采样率多少，包含「错误/异常」的 trace「全量保留」，保证「排障时能看到错误」；正常 trace 按采样率采样。④ 流量成本控制——通过「采样率 + 错误全采 + 尾采样」控制「trace 数据量」：① 高采样率 → 数据多、成本高、可观测性强；② 低采样率 → 数据少、成本低、可观测性弱；③ 用「错误全采 + 正常采样」在「保关键（错误）」与「控成本（正常）」间平衡。选择：① 简单场景用 Head-based + 错误采样；② 需要「基于完整 trace 决策」用 Tail-based（成本高）；③ 成本控制用「采样率 + 错误全采」。核心是「采样是成本控制的关键，需在可观测性与成本间平衡」。通常「采样正常流量 + 全采错误流量」是「成本与价值的平衡」。

采样策略的核心是「Head（简单低开销）vs Tail（精准高开销）+ 错误全采」。Head-based 决策早、Tail-based 基于完整 trace 更精准。成本控制靠「采样率 + 错误全采」，平衡「可观测性（保错误）与成本（控正常）」。Tail 用「汇聚采集器」支持。

• 迁移路径（双写过渡）
• 数据对齐（指标/trace 对应）
• 采样差异管理

从自建 Prometheus/Jaeger 迁移到 OTel 需「渐进式」路径，避免「大爆炸」。① 双写过渡——迁移期间「双写」：应用同时「保留旧埋点（Prometheus/Jaeger）」与「新增 OTel 采集」，两种数据并跑，对比验证 OTel 数据「正确、完整」后再「切流量」；双写降低「迁移风险」，可「随时回滚」。② 数据对齐——迁移时要「对齐数据」：① 指标对齐——OTel 指标与旧 Prometheus 指标「对应」（同一指标名/语义），对比「数值是否一致」；② trace 对齐——OTel trace 与旧 Jaeger trace「对应」，对比「span 结构、耗时」；③ 标签对齐——OTel 的 resource/span 属性与旧标签「对应」，保证「可比较」；对齐验证「新采集数据正确」。③ 采样差异管理——OTel 与旧系统的「采样策略」可能不同：① 采样率不同导致「数据量/完整性」差异；② 迁移时需「统一采样策略」或「对齐采样设置」，避免「同一请求一个采样一个不采」导致「对比失真」；③ 用「双写 + 对齐采样」保证「对比可靠」。迁移路径：① 双写（OTel + 旧系统并跑）→ ② 数据对齐验证 → ③ 统一采样 → ④ 切流量到 OTel → ⑤ 下线旧系统。核心是「渐进过渡 + 数据对齐 + 采样统一」，降低迁移风险。价值是「平稳迁移到 OTel，不丢数据、可对比、可回滚」。

迁移路径的核心是「双写过渡（降风险）+ 数据对齐（验证正确）+ 采样统一（保证对比）」。渐进式迁移避免「大爆炸」，对齐验证「新数据正确」，采样统一避免「对比失真」。这是「从旧栈迁移到 OTel」的稳健路径。