Flink Trace Reporter实战：用OpenTelemetry构建流式计算全链路可观测性

凌晨两点半，线上Flink CDC作业的背压报警又响了。Metrics面板上Source算子的繁忙度从15%一路冲到95%，下游MySQL的写入延迟从200ms涨到2.3秒。盯着监控曲线我只有一个感觉：这类指标只能告诉我"出问题了"，却始终无法回答"问题发生的那次处理到底经历了什么、卡在哪一步"。于是我开始认真研究Flink的Trace Reporters，用OpenTelemetry把作业运行时的链路信息串起来。这篇文章把配置模型、过滤规则和落地中的坑全部整理出来，给同样在流式计算可观测性上挣扎的人一条可以直接参照的路。

1. 被噪音淹没的Flink排障现场：Trace是怎么补上这块短板的

1.1 Metrics只能告诉你"哪里高"，Trace才能告诉你"谁等了谁"

Flink自带的Metrics体系已经很成熟了，CPU、内存、吞吐、延迟、背压、Checkpoint耗时都有对应的指标。但Metrics的本质是"聚合后的数值"，它描述的是一个算子在某个时间窗口内的平均表现，把成千上万次处理的细节浓缩成一个点。比如背压指标从20%涨到90%，你能确定是下游Sink变慢了，但没法知道是网络抖动、连接池等待还是某一段序列化逻辑卡住了。

Trace的建模方式和Metrics完全不同。它把一次完整的处理过程拆成若干span，每个span带开始时间、结束时间、父子关系，可以精确还原一次操作从进入Source到流出Sink的完整调用链。传统的RPC调用链天然适合这么建模，Flink这种流式计算虽然不是一个请求对应一条链路，但作业启停、Task部署、Checkpoint周期、窗口触发、算子内的事件处理，这些同样可以用span来记录起止时间和依赖关系。

两年前我排一个Checkpoint超时问题，当时Metrics显示Checkpoint的duration直逼超时阈值，间隔也在缩短。看了所有指标都不知道是哪一步慢，后来给Checkpoint相关流程埋了trace，一查就发现是一个外部状态后端的快照在某个TaskManager上阻塞了整整7秒。这个例子让我彻底明白，Metrics和Trace不是替代关系，而是互补关系。

1.2 Trace Reporter在整条链路中的位置

Flink本身没有把"Trace Reporter"做成独立的能力，它是借用了metrics reporter这套插件化扩展机制。Flink的conf/flink-conf.yaml里有一系列以metrics.reporter.<name>开头的配置，用来声明"往哪里上报、按什么频率上报"。社区里常用的PrometheusReporter、InfluxDBReporter都是这样挂上去的。Trace Reporter的思路也一样：用同样的扩展点，实现一个reporter，但它导出的不是聚合指标，而是OpenTelemetry格式的span数据。

数据链路大概是这样的：

• JobManager和TaskManager进程内有一个基于OpenTelemetry SDK的reporter实例
• reporter收集作业运行时的span，通过OTLP协议发送给OpenTelemetry Collector
• Collector做过滤、采样、批处理后，导出到Jaeger、Grafana Tempo或云厂商的trace后端

这里最关键的一点：把trace上报能力"伪装"成一个reporter，意味着不需要改动Flink核心代码，只靠配置和jar包就能接入。对于已经有一套Flink集群的团队来说，切入成本低得多。

1.3 什么场景真正值得上Trace Reporter

不是所有Flink作业都需要全套trace，但下面这几类场景收益特别明显。

第一类是Flink CDC和复杂事件处理作业。CDC作业往往要跨多张表、多个数据库实例，数据在Source算子里经历了快照读取、增量解析、schema变更处理，任何一个环节抖动都可能导致延迟。没有trace时，你看到的是端到端延迟在涨，有trace后能顺着链路看到具体是binlog读取慢了还是sink写慢了。

第二类是长链路实时数仓作业。一条数据从ODS到DWD到ADS，经过十几跳算子。Metrics只能告诉你哪个算子的繁忙度不高但数据积压，Trace可以直接展示每条链路在哪个节点耗时最多。

第三类是排查"偶发慢"的场景。如果所有指标都正常，但业务反馈偶发延迟毛刺，这时候全量聚合的Metrics基本无能为力。只有采样下来的trace能在事后回放那个时间点，看那一条链路到底发生了什么。

2. 配置模型逐层拆解：从reporter根节点到factory参数

2.1 metrics.reporter的配置树长什么样

Flink的reporter配置在flink-conf.yaml里，层级结构固定为metrics.reporter.<name>.<parameter>。root是固定的metrics.reporter前缀，<name>是你给这个reporter起的名字，可以同时挂多个，比如同时配prom和otel两个。<parameter>是该reporter自身的配置项。

一个典型的多reporter配置看起来是这样：

yaml复制metrics.reporters: prom,otel

metrics.reporter.prom.factory.class: org.apache.flink.metrics.prometheus.PrometheusReporterFactory
metrics.reporter.prom.port: 9249

metrics.reporter.otel.factory.class: io.otel4flink.OpenTelemetryMetricReporterFactory
metrics.reporter.otel.endpoint: http://collector:4317
metrics.reporter.otel.interval: 30 SECONDS

metrics.reporters这个顶层配置是reporter列表，用逗号分隔。这个列表非常容易忘，只配了下面各reporter的参数，结果重启后集群一个reporter都没有加载。这是第一个需要注意的地方。

以io.otel4flink.OpenTelemetryMetricReporterFactory为代表的trace报告器，在Flink的配置体系里就是一个普通reporter，只是它拿到运行数据后不输出到Prometheus这种指标系统，而是转成span输出到OTLP endpoint。所以理解这套配置树，就算你换一个实现，也能快速上手。

2.2 factory.class与Flink的类加载机制

每个reporter都必须指定factory.class，这个类必须实现org.apache.flink.metrics.reporter.MetricReporterFactory接口。Flink启动时用反射方式加载这个类，调用它的createMetricReporter方法拿到reporter实例。这意味着你要想自定义一个trace reporter，核心工作就是写这个工厂类和对应的reporter实现。

这里有个非常实际的坑：jar包位置决定了能不能被加载。Flink的类加载策略是分层的，flink/lib目录下的jar优先级很高，会被JobManager、TaskManager的父类加载器加载；而用户作业打包的jar是动态加载到用户类加载器中的，reporter的加载时机比用户作业早得多，配置解析阶段就需要factory类。所以reporter的jar必须放到flink/lib目录下，而不是塞进作业jar里。我之前见过有人把reporter依赖打进作业jar，结果作业能提交，但是所有的配置都被静默忽略了，查了半天日志才在TaskManager的启动日志里看到ClassNotFound。

如果你在容器化环境部署Flink，还要注意镜像构建时是否真的把jar打进了指定路径，以及是否因为镜像分层导致旧版本jar覆盖了新版本。

2.3 parameters透传：参数怎么拧到你的Reporter里

在reporter设计上，Flink的MetricReporterFactory接口只要求实现createMetricReporter(MetricConfig config)方法，其中MetricConfig提供的是该reporter节点下的所有配置项。具体来说，metrics.reporter.otel节点下的所有<key>=<value>，都会作为MetricConfig的键值对传给工厂方法。

所以一套成熟的trace reporter实现，都会在factory.class之外提供一系列自定义参数，常见的包括：

• endpoint：OTLP gRPC或HTTP的接收地址
• interval：span导出的周期
• sampler：采样器类型，如traceidratio、parentbased_always_on
• service.name：上报到后端的服务名，用来区分不同作业/集群
• timeout：导出超时时间

配置在flink-conf.yaml中直接平铺即可：

yaml复制metrics.reporter.otel.factory.class: io.otel4flink.OpenTelemetryMetricReporterFactory
metrics.reporter.otel.endpoint: http://otel-collector:4317
metrics.reporter.otel.sampler: traceidratio
metrics.reporter.otel.sampler.ratio: 0.2
metrics.reporter.otel.service.name: flink-dw-prod

值得留意的是，sampler.ratio这种带点号的子参数并不是Flink规定的，而是具体实现自定义的，它读取sampler后再读sampler.ratio。所以配置前最好翻一下对应实现的文档或源码。不同版本的otel4flink参数名可能存在差异，我习惯做法是拿到jar后先jar tf看一眼包里的类，再grep一下参数常量，完全不用凭记忆猜。

2.4 一份能直接上手的完整配置示例

把前面这些组合起来，给出一份我实际用过的配置形态，可以直接对照着改：

yaml复制metrics.reporters: otel

metrics.reporter.otel.factory.class: io.otel4flink.OpenTelemetryMetricReporterFactory
metrics.reporter.otel.endpoint: http://otel-collector.observability:4317
metrics.reporter.otel.interval: 15 SECONDS
metrics.reporter.otel.sampler: traceidratio
metrics.reporter.otel.sampler.ratio: 0.1
metrics.reporter.otel.service.name: flink-realtime
metrics.reporter.otel.headers: Authorization=Bearer ${OTEL_TOKEN}

同时建议显式配置Flink的scope格式，因为reporter输出的span名称和标签会参考scope变量。如果scope配置太乱，上报到后端后你会看到一堆类似localhost:8081的采样点，没法按作业名聚合。

yaml复制metrics.scope.jm: "flink.jm.<host>"
metrics.scope.tm: "flink.tm.<host>"
metrics.scope.job: "<job_name>"
metrics.scope.task: "<job_name>.<task_name>"
metrics.scope.operator: "<job_name>.<operator_name>"

scope配置看起来只是给指标命名用的，但用trace之后，job_name会作为span的attribute传到后端。想按作业筛选，这一行必须配好。我见过太多人没配这个，导致后端的trace和作业名对不上，排查时一脸懵。

3. 过滤规则：从全量上报到精准采样的三层配置

3.1 为什么全量trace会拖垮你的集群

很多人第一次配好trace，打开后端页面看到海量span，第一反应是兴奋，第二反应就是恐慌。全量上报在真实生产环境根本不可持续。Flink集群里TaskManager数量动辄几十上百，每个TM每15秒就会生成一批span。如果完全不过滤，一天下来的数据量轻松超过几十GB，后端存储成本、查询性能都会出问题。

另一个容易被忽略的问题是：全量上报会让Collector的batch处理失去意义。batch处理器本来是为了把大量小span合并成大请求再导出，但如果每个导出周期都有几万个span，batch会一直在"攒满"状态，频繁触发导出，对下游后端造成压力。后端在高峰期会明显变慢，trace查询响应从毫秒级变成秒级。

trace这种东西一定要在源头控制，能少则少。宁可采样后丢掉一些偶发细节，也不要让全量数据把整个链路压垮。

3.2 第一层过滤：客户端采样器

客户端采样发生在span创建阶段，是控制数据量最有效的一层。OpenTelemetry标准里主要分两类：确定性采样和概率采样。always_on是全采，always_off是全不采，这两个主要用于测试环境。生产环境最常见的是traceidratio，它按照traceId的哈希值计算是否采样，比例可配。

为什么强调要用traceidratio而不是自己对每个span独立随机数采样？因为traceId是贯穿整条链路的核心标识。如果TaskManager A上的span被随机数决定保留，而TaskManager B上的同一个traceId对应的span被随机数决定丢弃，那这条trace在后端就变成了一条断链，要么只有上半截，要么只有下半截。traceidratio的优点是，同一个traceId永远得到同一个采样决定，从而保证整条链路的一致性和完整性。

配置方式在reporter参数里直接指定：

yaml复制metrics.reporter.otel.sampler: traceidratio
metrics.reporter.otel.sampler.ratio: 0.1

0.1意味着大约10%的trace会被保留。一开始建议从0.1甚至0.05开始，观察后端数据量和排查需求，不够再往上调。采样率不是越高越好，保持足够定位问题的最小值才是正确的思路。

3.3 第二层过滤：scope维度裁剪

客户端采样是"随机丢"，scope过滤是"定向丢"。Flink的指标和trace都带有scope上下文，比如哪个Job、哪个Task、哪个Operator。基于scope可以做定向裁剪，把明显不需要关心的span全部过滤掉。

在实现上，这取决于你用的trace reporter是否支持按scope做正则匹配或前缀匹配。大多数实现会让reporter在生成span时附带scope的字符串属性，比如flink.job_name、flink.operator_name。然后配置一个或多个过滤规则。常见需求包括：

• 过滤掉心跳、心跳连接等系统级span
• 过滤掉Source算子空闲等待的span
• 过滤掉某些特定作业名的全量span
• 只保留flink.operator_name里包含Sink的span

这类配置同样在flink-conf.yaml中声明，比如：

yaml复制metrics.reporter.otel.scope.include: ".*(Sink|Window).*"
metrics.reporter.otel.scope.exclude: ".*Heartbeat.*"

用的时候要小心正则表达式对性能的影响。如果匹配规则特别复杂，每个span都要跑一遍正则，在高吞吐作业下会带来额外开销。建议规则尽量简单，能写成前缀或后缀匹配就不要写复杂的通配符。

3.4 第三层过滤：Collector侧Filter与TailSampling

前两层都发生在Flink进程内，属于"事前的头采样"。第三层放在OpenTelemetry Collector上，属于"事后"处理。Filter Processor可以按span属性、名称、服务名等条件精准丢弃，TailSampling Processor则可以做更智能的尾采样决策。

Filter Processor的典型用途是，在已经有traceidratio概率采样后，再把明显没有价值的span清掉。例如所有状态为OK且耗时小于100ms的span，对排查问题几乎没有贡献，可以丢弃。配置方式用OTTL语句编写：

yaml复制processors:
  filter/drop_ok:
    traces:
      span:
        - 'status.code != STATUS_CODE_ERROR and attributes["flink.operator_name"] == "Source: ..."'

TailSampling和前面的概率采样不同，它不是立即决定是否保留，而是把一批span在内存中缓存几秒钟，等完整链路聚合之后再决定是否导出。这非常适合"只保留错误链路"和"只保留慢链路"的场景——直接按status_code或latency做策略，保留下来的每一条trace都是真正值得看的。

Collector侧配置样例：

yaml复制processors:
  tailsampling:
    decision_wait: 10s
    policies:
      - name: error-traces
        type: status_code
        status_code:
          status_codes:
            - ERROR
      - name: slow-traces
        type: latency
        latency:
          threshold_ms: 2000

注意decision_wait不是越大越好。它代表Collector需要在内存中缓存等待的时间，太大内存压力会上升，太小可能导致链路还没聚合完就开始决策。实际经验是10秒左右对大多数Flink作业足够。

3.5 三层过滤规则对比与适用场景

实际项目里我习惯的搭配是：客户端traceidratio开到0.1，Collector端用Filter去掉低价值span，再用TailSampling只保错误和慢请求。三层配合下来，后端一天的trace数据能压缩到原来的五十分之一左右，但关键问题的定位能力反而提升了。

4. OpenTelemetry Collector落地：从gRPC端点到数据链路验证

4.1 OTLP链路选型：为什么建议让TaskManager直连Collector

把span从Flink进程送到后端，通常有两种拓扑：让reporter直连Collector，或者先发给某个统一网关再转发。在Flink集群里，我强烈建议直连。原因很实际：Flink的TaskManager本身数量多，每个TM都需要独立上报，如果中间再加网关，网关的带宽、稳定性就成了单点，反而破坏了Flink分布式扩展的初衷。

OTLP协议支持gRPC和HTTP两种传输方式，默认端口是4317和4318。gRPC的二进制编码效率高、流式传输能力强，适合Flink这种高吞吐场景；HTTP在穿透网络代理、调试时更方便。生产环境我推荐用gRPC，配置也简单：

yaml复制metrics.reporter.otel.endpoint: http://otel-collector.observability:4317

注意这里的地址要填可达的服务名或IP，千万别用localhost。因为reporter是运行在每个TaskManager里的，如果配成localhost，只有本机有Collector才能通。我之前犯过这个错，单机测试配localhost一切正常，上了集群后一半TM连不上Collector，报错全是connection refused。

4.2 Collector处理器编排顺序：内存、过滤、尾采样、batch的先后逻辑

Collector的pipeline处理器顺序直接影响效果和稳定性，从长年到实战，我给出的推荐顺序是：

1. memory_limiter放最前面，防止上游数据暴涨打爆Collector内存
2. filter紧随其后，尽早丢弃无用span
3. tailsampling在filter之后，针对剩余span做聚合决策
4. batch放最后，把保留下来的span合并成更大的导出请求
5. batch之后才是exporter

为什么batch要放后面？因为tail sampling需要缓存并等待完整链路，如果batch在前，它会把span提前打包发出去，TailSampling就看不到完整链路。反过来，tail sampling处理完的span通常是比较零散的，此时再batch，能显著减少导出请求数量。

一份完整的Collector配置：

yaml复制receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  filter/drop_noise:
    traces:
      span:
        - 'name == "Heartbeat"'
        - 'attributes["flink.task_name"] == "Source: parse-binlog" and attributes["status"] == "OK"'
  tailsampling:
    decision_wait: 10s
    policies:
      - name: error-traces
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: slow-traces
        type: latency
        latency:
          threshold_ms: 2000
  batch:
    timeout: 5s
    send_batch_size: 8192

exporters:
  otlp/backend:
    endpoint: jaeger.observability:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, filter/drop_noise, tailsampling, batch]
      exporters: [otlp/backend]

这个配置里filter/drop_noise把Heartbeat和特定Source算子的OK span全部丢弃，tailsampling只保留错误和慢于2秒的trace，batch的timeout设成5秒。整套下来，对后端存储的冲击非常小。

4.3 数据链路验证的完整排查清单

配置好之后别急着说"我完成了"，先按下面这套流程验证：

第一步，看Collector是否正常接收。Collector默认有自监控指标，可以暴露Prometheus风格的metric。查otelcol_receiver_accepted_spans和otelcol_receiver_refused_spans，前者持续增长说明数据进来了，后者增长说明有数据被拒绝。

第二步，看是否有导出错误。otelcol_exporter_sent_spans和otelcol_exporter_send_failed_spans这两个指标能清晰反映导出是否成功。如果send_failed_spans不断上涨，多半是后端地址、TLS或者鉴权问题。

第三步，在后端页面上按service.name搜索。如果能看到span列表，说明链路已经通了。此时建议选一条完整的trace，点击查看它的span瀑布图，检查是否存在大量断链。遇到断链，优先排查客户端采样配置，确认是不是用了非traceidratio的独立随机采样。

还有一个经常被忽略的点：Collector自身的时区、span时间戳的时区。OTLP传输的时间戳是Unix纳秒，没有时区概念，但如果你在后端看到的时间整体偏移8小时，通常是Jaeger或Tempo的UI时区设置问题，不是数据链路问题。可以查原始span的startTimeUnixNano，对比一下，避免瞎调Collector。

5. 生产环境避坑实录：六个故障的完整排查链路

5.1 坑一：reporter配置了但完全没生效

现象：flink-conf.yaml配好了，Collector也起来了，但后端一条span都没有。查JobManager日志看不到任何reporter相关的报错，像是被静默忽略了一样。

排查链路是这样走的：先确认metrics.reporters顶层列表是否包含自己起的name。忘了加列表是大坑，配置了各自的reporter参数但没在顶层声明，Flink根本不会加载。再检查factory.class指向的类到底在不在classpath里，重点是TaskManager的classpath，不是客户端提交机的classpath。因为reporter在TM内初始化，很多人在客户端本地测试时classpath正常，上集群后TM镜像里没打jar，就会出现这种"配置了但没生效"的诡异现象。

解决方式：确认jar放进flink/lib，然后重启TM。验证办法也简单，看TM启动日志里有没有类似"Loading reporter: otel"的日志行，没有就说明reporter根本没被加载。

5.2 坑二：endpoint不可达导致TaskManager反复重启

现象：配置完Trace后，集群开始出现TaskManager逐个重启，每次重启间隔不规律，日志里全是Connection refused，指向一个无法访问的地址。

这个坑的破坏性很大，因为reporter初始化是TM启动流程的一部分。如果reporter启动时去做一次网络探活或握手，而endpoint不可达，初始化就会抛异常。异常一路抛上去，TM就起不来。我排查时发现有人把endpoint写成了collector:4317，但Kubernetes里Service的端口名映射写错了，导致Service存在但端口不通。另一次是直接配了外网域名，该域名在机房网络里根本不解析。

排查顺序：先确认endpoint在TM所在节点能通，用telnet或nc -vz测端口，再确认Collector的接收端真的监听了4317端口。如果endpoint没问题，再看reporter实现是否允许初始化失败后降级。如果实现不支持，要么修好网络，要么在reporter层加一个更温和的初始化策略，不要因为trace的故障影响核心作业。

5.3 坑三：概率采样导致trace链全部断裂

现象：后端有数据，但大量span找不到parent，整个trace页面全是孤立的span，几乎拼不出一条完整的调用链。查日志没有报错，采样率也调低过，仍然断裂。

根因是采样器类型选错了。有人配的是sampler: always_on然后又在Collector端用概率采样，或者自己写了个"每个span按50%概率保留"的逻辑。这种span级独立采样在分布式场景下必然导致链路断裂：同一traceId在TM A上的span被保留，在TM B上的span被丢弃，后端就永远拼不出完整链路。

解决方式：客户端一定用traceidratio，保证同一traceId采样决策一致。如果你的场景要求更高的采样率但存储有限，优先通过Collector的Filter把低价值span清掉，而不是在客户端做span级独立采样。这里有个简单的心法：采样必须在trace级别做决策，不能在span级别做独立决策。

5.4 坑四：Collector默认batch配置导致导出延迟暴涨

现象：后端的trace查询经常显示最新数据延迟到几十秒甚至分钟级，但Collector的CPU和内存都不高，导出也没有报错。

原因大部分出现在batch处理器配置不合理。如果timeout设得太长且send_batch_size太大，Collector会一直憋着buffer等攒满再导出，数据在Collector侧滞留时间就长了。我见过把send_batch_size设成100万、timeout设成30秒的配置，结果一条trace从产生到落地要好几分钟，完全失去实时性。

修法：把timeout调到3到5秒，send_batch_size调到几千的级别。同时观察otelcol_exporter_sent_spans，如果每批数据量接近batch大小且发送频率非常稳定，说明batch配置合理；如果频繁出现很小的batch，说明timeout太短，网络开销变大。平衡点根据后端吞吐和链路数量来微调。

5.5 坑五：OTel SDK版本与Flink依赖的gRPC冲突

现象：接入Trace后，部分作业启动时出现NoSuchMethodError或AbstractMethodError，指向gRPC或Netty相关类。错误出现时机不固定，有时在TM启动，有时在作业提交。

这是典型的依赖冲突。Flink内部有一些shaded和repackage过的框架，比如Netty、gRPC相关库被嵌入在flink-shaded系列里。如果你的Trace Reporter依赖的OpenTelemetry SDK版本和Flink集群已有的传输层版本不兼容，启动时类加载器加载了错误的类，就会出现这种诡异异常。

排查链路：先把异常栈完整打出来，看是哪个类、哪个方法找不到。接着用mvn dependency:tree分析你自己的jar里带了哪些传递依赖，重点看io.grpc、io.netty和io.opentelemetry相关版本。最稳妥的方式是让你自己的reporter jar里的OTel依赖relocate到内部命名空间，打成一个fat jar，避免和Flink自身的类发生碰撞。这属于常见的"fat jar relocation"策略，用Maven shade plugin配置即可。

5.6 坑六：只盯着trace，忘了它带来的额外开销

现象：接入Trace后作业吞吐率下降了5%到10%，部分状态密集型算子延迟上升。检查业务代码没有变更，把Trace关掉后指标恢复。

Trace不是免费的。每个span的创建、attributes写入、序列化、网络导出都有CPU和内存开销。在Flink这种高吞吐场景下，如果配置了全量采样、还往span里塞大量自定义属性，开销会被放大。

排查和优化方法：先看采样率是否过高，建议从0.05开始。再看是否所有算子都生成了不必要的span，可以通过scope过滤把纯转发算子的span排除掉。最后检查塞进span的attributes，千万别把业务数据结构整个塞进去，这会让序列化开销暴涨。如果确实需要保留大对象现场，建议只保留一个对象存储的引用ID，必要时再通过日志系统去查完整内容。

6. 这样调优才不亏：容量估算、采样策略与后续演进

6.1 trace的容量模型：一个span到底吃掉多少存储

估算trace的存储需求，核心是算清楚"一天会产生多少span，每个span平均多大"。一个标准的OTLP span，序列化后通常包含traceId、spanId、parentSpanId（均为8到16字节）、名称、开始时间、结束时间、少量attributes。加上传输格式的开销，单个span大概是0.5到2KB。

如果一个集群每秒产生500个span，每个平均1KB，一天的原始数据量大约是500乘86400秒再乘1KB，约41GB。这套估算方法可以作为容量参考，实际使用中要在这个基础上考虑索引膨胀和副本倍数。

不要小看这个数字。很多团队只配了客户端全采，Collector又不加tail采样，跑几天后后端存储告警。容量估算不是用来精确预测的，而是让你在配置采样率之前就有心理预期，避免上线一周后被迫救火。

6.2 生产环境推荐的配置组合

根据踩坑总结，我倾向于这样配置一个中等规模Flink集群的Trace链路：

客户端侧：

yaml复制metrics.reporter.otel.factory.class: io.otel4flink.OpenTelemetryMetricReporterFactory
metrics.reporter.otel.endpoint: http://otel-collector.observability:4317
metrics.reporter.otel.interval: 15 SECONDS
metrics.reporter.otel.sampler: traceidratio
metrics.reporter.otel.sampler.ratio: 0.1
metrics.reporter.otel.service.name: flink-realtime-${JOB_NAME}

Collector侧：

yaml复制processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  filter/drop_noise:
    traces:
      span:
        - 'name == "Heartbeat"'
  tailsampling:
    decision_wait: 10s
    policies:
      - name: error-traces
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: slow-traces
        type: latency
        latency:
          threshold_ms: 2000
  batch:
    timeout: 5s
    send_batch_size: 8192

这样配合下来，客户端的traceid ratio已经控制了大部分数据量，Collector再按错误和慢链路过滤，留在后端的都是高价值数据，存储成本可控，定位问题的效率也最高。这套组合我在多个生产环境验证过，效果稳定。

6.3 后续演进：社区方向与自定义埋点

Flink社区对OpenTelemetry的集成一直在推进，未来版本可能自带更完善的OTel支持，让reporter机制不再只是一个借道的实现。但不管社区怎么演进，理解这套配置模型和过滤链路都是有价值的——你自定义的业务埋点最终大概率也要汇入同一条OTLP链路。

如果你希望在业务代码里做更细粒度的自定义埋点，推荐直接用OpenTelemetry API，在Flink算子内创建Span，手动设置attributes和事件。这样可以在关键业务逻辑处补充系统级reporter覆盖不到的细节。比如在窗口触发时记录窗口内的数据条数，在状态后端读写时记录耗时。这部分信息会让trace真正意义上贴近业务。

后续还可以把traceId注入到日志系统中，实现日志与trace的关联。通过MDC把当前traceId写入日志上下文，在出问题时就能从一条日志直接点进对应的完整链路，排障体验会再上一个台阶。这个工作花不了多少时间，收益却立竿见影。

我在实际落地过程中最大的体会是：Trace这东西，不是接完就结束了，它是一个持续调优的过程。刚开始全量上，被数据量打脸，然后逐步加过滤、加采样，最后沉淀出适合自己业务的那套组合。熬过最开始那一两周的阵痛期，后面每次排查问题，你都会感谢当时把这条链路搭起来的自己。