OpenTelemetry加持AI项目：监控不再是摆设，实测有坑也有甜头

看到你提到tail-based sampling才解决了存储压力，这个点我特别想追问一下——你们实际调采样策略的时候，是直接按固定比例采样，还是根据trace的某些特征（比如延迟超过某个阈值）动态触发的？我最近也在搭类似的东西，但发现如果单纯用概率采样，高并发下那些偶发的长尾延迟很容易被漏掉，可如果全量采样吧，存储又扛不住。

另外你提到的自动instrumentation省力这块，我有点好奇具体是哪些组件能自动接入？比如LLM推理框架像vLLM或者TGI，它们本身的内部算子（比如attention计算、KV cache管理）能被OTel自动捕获吗？还是说你们主要靠手动打点去补这些AI特有的指标？我之前试过用Python的auto-instrumentation，发现对异步协程的支持有点迷，经常trace断掉，不知道你们有没有遇到类似的情况。

还有个比较实际的问题，你们把prompt输入和token生成耗时放进span里，这些数据量本身就不小，而且prompt文本可能涉及业务敏感信息，你们是怎么处理数据脱敏的？是直接在采集层过滤，还是在打点的时候就只传长度而不传内容？感觉这块要是没处理好，监控反而成了数据泄露的风险点。

这帖子看得我挺有共鸣的，团队今年Q2刚把一套基于vLLM的推理服务从“黑盒”状态拉到了OpenTelemetry体系下，过程中踩的坑和楼主说的几乎一模一样。先说说我这边的一些实操结论，再针对楼主提的两个问题展开聊。

关于楼主的第一个问题，trace上下文传播。这其实是我踩过最深的一个坑。我们用的是Python栈，模型推理部分用的是vLLM，而vLLM内部是异步的，而且对torch的C++ extension做了深度封装。标准OpenTelemetry自动instrumentation在捕捉HTTP/gRPC请求时很顺利，但一旦请求进入vLLM内部的调度器（Scheduler）和执行器（Executor），上下文就断了。因为vLLM内部用的是自己的一套事件循环和协程（asyncio + 自定义的序列化队列），而OpenTelemetry的Python SDK默认的context propagation是基于threading.local的，进到协程里就丢了。

我们的解决方案是两步走。第一步，在vLLM的入口处（即HTTP server的中间件里），手动注入一个自定义的SpanProcessor，把当前trace context序列化成一组唯一的request_id，然后通过vLLM的KV cache中预留的metadata字段传进去。具体做法是：在vLLM的LLMEngine.generate调用的extra_kwargs里塞一个opentelemetry_context字典，然后在内部每个关键步骤（如prefill、decode、sample）的async函数里，通过call_with_context重新绑定上下文。这听起来很暴力，但实测有效，而且性能开销在0.5%以内，因为只是字典的拷贝和查找，不涉及序列化。第二步，我们在vLLM的C++层也打了几个关键的otel span点，通过pybind11暴露出来，用C++的OpenTelemetry SDK（opentelemetry-cpp）直接写span。这样做的好处是，C++层可以拿到更精确的GPU kernel执行时间，而不是靠Python侧估算。但代价是编译时依赖复杂，而且C++ SDK的稳定性和社区活跃度远不如Python版，我们踩过一个bug，高并发下span的end_time会出现负值，后来发现是C++ SDK里一个时间戳精度转换的溢出问题，自己fork修了。

所以楼主的团队用tail-based sampling解决存储压力，这个思路是对的，但我想补充一点：tail-based sampling在AI场景下有一个天然劣势，因为它需要等整个trace完成才能决定是否采样，而LLM推理的trace可能长达几十秒（比如流式输出），这会导致内存中积压大量未完成的trace，如果你的采样决策器是中心化的（如OpenTelemetry Collector的tail_sampling processor），那Collector本身会成为瓶颈，内存占用会随着并发数线性增长。我们的做法是混合采样：首部采样（head-based）对异常请求（比如P99以上的延迟请求）强制全量采样，用Prometheus的histogram统计实时P99，当P99超过某个阈值时，动态调整采样率。具体实现是写了一个自定义的Sampler，定期从Prometheus的HTTP API拉取P99数据，然后调整一个全局的采样比例变量。这个方案比单纯的tail-based更节省内存，而且对异常请求的捕捉更及时。

接下来聊楼主的第二个问题，metrics要不要自定义。我的观点是：绝对要，而且一定要做。OpenTelemetry的metrics规范（metrics API）在AI场景下有几个先天不足。第一，它默认的counter、histogram、gauge是针对IT基础设施设计的，比如请求数、延迟、错误码。但AI独有的指标，比如prompt长度、generated token数、KV cache命中率、batch size动态变化，这些在标准Otel里没有现成的语义约定（semantic convention）。第二，模型幻觉（hallucination）这个指标，本质上是质量指标，不是性能指标，它不应该由OpenTelemetry的metric pipeline来承载，而应该由eval pipeline来做，但eval pipeline的结果需要和trace关联起来。我们团队的做法是：在OpenTelemetry的span上挂自定义属性（attribute），比如每次推理完成后，我们会在LLM的response span上附加llm.prompt.token_count、llm.completion.token_count、llm.kv_cache.hit_ratio这些属性。然后通过一个独立的异步worker，定期把这些span的attribute导出到ClickHouse中，在ClickHouse里做聚合分析。这样既保留了Otel的追踪能力，又绕过了Otel metrics API的局限性。至于模型幻觉，我们走的是另一条路：在推理完成后，把prompt和completion发送到一个独立的“一致性检查服务”（基于另一个小模型或者规则引擎），然后把检查结果作为另一个span（eval span）挂到同一个trace下。这样在Jaeger或Grafana中，可以直观地看到某个推理请求的延迟和它的质量分数是关联的。

再说一个帖子没提到但我认为至关重要的点：OpenTelemetry在AI项目中的agent部署问题。我们用的是Kubernetes，每个推理Pod里都跑了一个Otel Collector sidecar。但vLLM推理Pod通常需要超大内存（比如A100 80G的卡，显存占满），如果再加一个Collector sidecar占内存，虽然Collector本身内存很小（通常几十MB），但一旦开启tail-based sampling，Collector的内存会飙升。更严重的是，如果Collector崩溃，会导致整个Pod的trace丢失，而且Collector重启期间，SDK的span exporter会进入阻塞重试，进而阻塞推理线程（因为Python SDK默认的BatchSpanProcessor是同步队列，队列满时会阻塞）。我们早期就因为这个导致过推理延迟抖动。最终的解决方案是把Collector从sidecar模式改为DaemonSet模式，每个Node上只跑一个Collector，Pod里的SDK通过localhost的gRPC直接上报给本Node的Collector。这样Collector的内存压力分散到Node级别，而且即使Collector挂掉，Pod内的SDK最多丢几个span，不会阻塞推理主流程。这个改动让我们的P99延迟下降了约3%，因为去掉了sidecar的序列化开销和网络往返。

最后聊一下生态空白的问题。楼主说缺少针对AI workload的成熟Exporter和Dashboard，我深以为然。目前社区里有一个叫OpenTelemetry Collector Contrib的仓库，里面有一些AI相关的接收器（比如OpenAI receiver），但质量参差不齐。我们团队自己写了一个自定义Exporter，专门把Otel的trace数据转换成MLflow的格式，这样可以在MLflow的UI里看模型版本和推理性能的关联。具体做法是：在Collector里加一个processor，解析span的resource.attributes，提取出模型名称和版本（这些在Kubernetes Pod的label里），然后通过MLflow的REST API写入。这样每次模型上线新版本，可以自动在Grafana dashboard上看到不同版本的P50/P99延迟对比、token消耗趋势。不过这个Exporter目前还是内部工具，没开源，因为需要和我们的CI/CD流水线深度耦合。我觉得未来半年内，一定会有厂商或者社区推出针对LLM推理的标准化Otel dashboard模板，类似于目前流行的“Four Golden Signals”那种，但指标会变成：每秒token生成速度（TPS）、KV cache命中率、批处理大小、模型加载时间、GPU利用率。这些指标如果能通过Otel collector的prometheusreceiver从nvidia-smi或dcgm-exporter直接拉取，再和推理span关联，那才是真正的“全栈可观测”。

总结一下，OpenTelemetry在AI项目中的价值是毋庸置疑的，它把传统分布式追踪的成熟范式映射到了AI推理这个新领域。但目前的社区工具链还处于“能用但不好用”的阶段，尤其是在上下文传播、自定义指标、和AI特有的eval系统集成这三块，需要大量的定制开发。我的建议是：如果你的团队有基础设施能力，可以大胆投入Otel，但一定要预留20%的开发时间来处理这些“非标准化”的磨皮工作。如果团队人少，建议先用商业化的可观测性平台（如Datadog的LLM Observability或New Relic的AI Monitoring），等Otel生态成熟后再迁移。毕竟，让工程师花时间调采样策略和写自定义Exporter，不如让他们去优化模型本身的推理性能更有价值。

tail-based sampling这个坑我也踩过，而且是线上环境直接炸了存储。当时我们集群峰值QTA大概2000左右，默认的头采样策略直接让ES集群CPU飙到90%，最后也是切了tail-based才稳住。不过这个策略有个副作用，就是那些短生命周期的trace容易被丢掉，尤其是LLM推理里有些prompt很短但token生成慢的case，经常采样不到，排查问题时反而少了关键数据。你们是用的OpenTelemetry Collector自带的tail sampling processor吗？我们后来自己写了个基于概率+延迟阈值的混合策略，才勉强平衡了成本和覆盖度。

另外你说的自动instrumentation确实省力，但LLM场景下有个问题，就是模型推理的span语义不够细。比如我们想区分预填充和解码阶段的耗时，默认的instrumentation只给一个总耗时，最后还得手动在代码里加自定义span。感觉OpenTelemetry的AI领域标准还在演进，社区提案里有人提过llm.inference这种语义约定，但落地还早。

还有个点想聊聊，就是prompt输入和输出token的统计，你们是直接塞span attribute里还是单独走了metric？我们试过放attribute，结果高并发下单个span太大，传输和存储都有压力，后来改成用counter累加token数，结合histogram记录每步延迟，感觉更轻量。不过这样trace和metric就有点割裂了，不知道你们有没有更好的整合方案？

刚好最近也在折腾这个，看到你说用OpenTelemetry做LLM的追踪，想问个具体的问题——你们在instrumentation的时候，对于prompt的输入输出是怎么处理的？我这边试了auto-instrumentation，发现它默认会把完整的prompt文本和生成的token都塞进span的attributes里，但我们的prompt动不动就几千个token，有些时候甚至带着敏感业务信息，直接这么搞存储和隐私都有点绷不住。你们是用了自定义的sanitizer来过滤，还是干脆只保留元数据比如token数量、模型名称这些，放弃了payload级别的追踪？

另外tail-based sampling这块，能分享一下具体的配置经验吗？我在试的时候发现，如果采样率设得太低，一些长尾的慢推理或者异常抛错很容易被漏掉，但设高了存储又扛不住。你们的策略是按照错误码优先级强制采样，还是根据latency的p99动态调整？我目前是直接抄了社区里那个基于baggage传播的filter方案，但总感觉在LLM场景下，像context window超限这种特殊事件不太好靠常规的sampler捕捉到。

还有就是，你们用OpenTelemetry之后，有没有和现有的prometheus或grafana体系做打通？我这边想把trace的延迟数据直接关联到metrics的dashboard上，但发现opentelemetry-collector的prometheus exporter在导出histogram的时候，和原生prometheus client的bucket定义总有点对不上，最后不得不手动写了一个processor来做数据对齐，感觉有点过于折腾了。

tail-based sampling这个坑我也踩过，后来发现把采样率和业务优先级挂钩比单纯调阈值靠谱，比如高价值请求全采，低价值请求按比例降采样。另外你们用自动instrumentation时，prompt长度对span大小的影响处理了吗？我们这边生成trace时payload大了直接爆内存。

这帖子写得挺实在，OpenTelemetry在AI场景下踩的坑我团队基本也都经历过一遍。自动instrumentation确实香，但搞LLM推理的时候，那个span爆炸是真心疼存储成本，特别是流式输出场景下，每个token都给你整个span出来，CPU开销也不小。我们后来也是tail-based sampling+头采样混着用，高吞吐的推理节点走概率采样，关键trace再按规则捞全量。

不过想问问，你们跑LLM的时候，prompt embedding和向量检索那块的链路是怎么接入OpenTelemetry的？这俩环节在咱们这种RAG场景下延迟占比挺高的，但标准instrumentation基本覆盖不到，我们最后是自己写了个custom exporter把向量库的查询耗时和召回率埋进去，跟推理阶段的span做关联。另外token生成耗时那个metric，你们是按TTFT和TPOT分开打的还是揉在一起？我们拆开之后发现TTFT受显存调度影响波动特别大，TPOT反而比较稳。

还有一点想补充，OpenTelemetry那个resource detector默认捞的容器元数据在K8s下有时候不准，特别是pod重启后instance id会变，导致trace断链，我们后来直接关了自带的，自己写了个detector绑deployment和revision。你们有遇到类似问题吗？

这帖子看得我猛点头，我们团队最近也在搞类似的事，LLM推理服务加上OpenTelemetry，确实是把之前一锅粥的监控体系给理清了。你提到的prompt输入和token耗时这些AI特有维度能塞进标准span，这点太香了，以前全靠自己拼日志，排查个性能瓶颈得翻半天ELK，现在好歹有个统一的视图。

不过你讲的那个采样策略坑，我真是感同身受。我们刚开始图省事，直接开了全量采样，结果低峰期还行，一上高并发，Elasticsearch集群直接报警，磁盘IO飙升到吓人。后来也是换了tail-based sampling才稳住，但这里有个新问题：tail-based sampling对服务的延迟容忍度要求挺高的，如果业务对实时性敏感，可能会丢一些关键trace。你们在调这个的时候，是怎么平衡采样精度和存储开销的？比如有没有对特定span（像模型推理那一段）设置更高的采样率？

另外，我还想问一个点：自动instrumentation虽然省力，但在LLM场景下，它能不能自动捕获到模型内部的某些自定义参数？比如我们想追踪某个prompt在不同模型版本下的生成质量差异，OpenTelemetry的自动打点似乎覆盖不到这么细，最后还是得靠手动埋点补充。你们有没有遇到类似的边界情况，怎么处理的？感觉这个领域大家都是摸着石头过河，多交流能少走弯路。

我们也在试OTel做LLM追踪，自动埋点确实香，但那个采样策略真是头疼，高并发下一不小心存储就爆了。想问下tail-based sampling你们具体怎么配的，是直接按trace延迟还是结合token数做了权重？另外遇到个问题，模型推理那一段的span时间戳有时候跟实际对不上，不知道是OTel exporter的batch延迟还是模型框架的bug。

看到你提tail-based sampling，深有同感。我们之前也踩过同样的坑，OpenTelemetry自动instrumentation确实香，但默认的全量采样在LLM推理场景下简直是存储杀手。特别是每个token生成都打一个span，并发一上来，ES集群直接报警。

我后来是这么搞的：用OpenTelemetry Collector的processor配了tail-based sampling，按trace的latency和error来动态采样——慢请求和报错的trace全留，正常响应快的trace按比例采样。再配合给每个span加了个自定义attribute叫“llm.model”，这样能在sampling时按模型版本做差异化，比如大模型全采，小模型抽采。存储压力降了70%，关键链路还没丢。

还有个坑想跟你探讨：OpenTelemetry metric的exponential histogram在LLM场景下，token生成时间的分布其实很稀疏，默认的bucket边界不太对。我手动调了DefaultAggregationTemporality和HistogramBoundaries，把token生成耗时按10ms, 50ms, 100ms, 200ms, 500ms分桶，才看清了真实延迟分布。你们有没有遇到metric聚合不准的情况？

另外，你帖子里提到的“Valu”后面是不是还有内容？是Value Metrics还是Value Stream？很想听听你具体的实践细节，尤其是prompt输入怎么打span的——我们之前试过把整个prompt作为span attribute，结果one.trace太大，直接超了OTLP的默认message size limit，后来改成只记录token数和hash，关键信息才没丢。

tail-based sampling 确实是高并发场景下的必选项，否则存储成本分分钟教你做人。不过我们踩过的另一个坑是 OTEL 的 exporter 背压问题，特别是在 LLM 推理这种长耗时请求里，建议把 batch processor 的 queue size 和 timeout 参数根据 token 生成速率动态调一下。另外想问问，你们在追踪 prompt 输入时，有没有遇到敏感信息泄漏的风险？这块我们目前还在纠结要不要做 scrubbing。

说到采样策略这块我太有同感了，之前我们也是没注意，直接上了默认的head-based，结果高峰期QPS一上来，Jaeger直接撑爆了，存储一天涨了30G。后来换tail-based确实能缓解，但得小心那个延迟策略的配置，我们试过把等待时间设太短，导致一些慢请求的span还没收集全就被丢弃了，反而丢掉了关键的性能瓶颈数据。你们现在用的采样率大概是百分之几？我们最后折中设了10%的head-based + 动态调整的tail-based，才勉强稳住。

另外提一个你们可能也踩过的坑：LLM推理服务里那个token生成阶段的span，如果按默认的instrumentation走，会把每个token生成都当成一个单独的span，结果一个长回复能爆出几百个span，不仅存储扛不住，分析时也根本没法看。我们后来不得不自己写了个processor，把同一次请求的token生成span合并成一个带时序信息的父span，这样既能看出逐token的延迟变化，又不会搞出数据爆炸。

还有一点，prompt输入的结构化存储你们是怎么处理的？我们试过把prompt原文直接塞进span attribute里，结果一遇到长上下文就超了OTel的attribute大小限制，后来只能截断或者用ID外链到对象存储。你们有没有更好的做法？

看到你说到tail-based sampling，真的深有同感。我们之前也是被那个存储压力搞得很头大，特别是LLM推理这种场景，一个请求可能对应几百个token级的span，如果全量采下来，S3账单直接起飞。后来换了tail-based sampling策略，只保留那些有异常或者高延迟的trace，才算是把成本控制住了。

不过我觉得你提到的prompt输入和token生成耗时纳入标准化span这个点，确实是OTel在AI场景下的杀手锏。以前我们用自研的打点，prompt长度和生成首token时间都是分开埋的，想查一个完整请求的端到端链路得拼好几个日志片段，debug效率极低。现在用OTel的attributes把model_name、prompt_tokens、completion_tokens这些直接挂到span上，配合Jaeger或者Grafana Tempo，一眼就能看到是哪个模型在哪些批次上出了瓶颈。

想追问一下，你们在自动instrumentation的时候，有没有遇到Python SDK对某些异步框架支持不太好的情况？比如我们用FastAPI配合asyncio，有些中间件拦截器会漏掉部分span的context传递，导致链路断掉。后来我们是手动加了一些propagation hooks才修好。另外，你们对token级别的span是直接用了OTel的嵌套span，还是单独开了一个新的自定义span类型？我感觉嵌套太深的话，UI上展开看会非常卡，想听听你们的实践方案。

我们最近也在搞LLM推理服务的可观测性，看到你这个贴子直接共情了。OpenTelemetry统一指标确实香，之前我们自己搞prompt日志和token统计，每次排查问题都得翻好几个系统，现在一套span链路能把输入到输出全串起来，找性能瓶颈快多了。

不过你说的采样策略坑我深有体会。上线第一周没注意，结果etcd直接报警，查了一下发现每个请求都打全量span，我们刚起步的服务一天就几百万调用，存储成本直接翻倍。后来换成了tail-based sampling，只保留错误和慢请求的完整链路，正常请求按1%采样，总算稳住了。但有个问题想请教：你们在采样时怎么保证prompt内容不丢？我们有些case需要回溯用户输入，但采样一丢就查不到了，目前只能把prompt单独打到日志里和span关联，感觉又回到了打点时代。

另外自动instrumentation虽然省力，但LLM推理的某些关键节点还是得手动埋点，比如模型加载时间、kv cache命中率这些，不然看不到具体瓶颈。尤其是多轮对话场景，session级别的跟踪很难自动搞定，我们只能通过自定义span来拼接。你们有遇到类似问题吗？方便的话可以分享下tail-based sampling的具体配置参数，我也想对比下我们的阈值设得合不合理。

tail-based sampling确实是个绕不过去的坎，我们当时在推理场景下还踩过另一个坑：LLM的token-by-token输出导致span数量爆炸，后来干脆把流式响应的event单独拆出来做采样策略，不然存储扛不住。另外想问下，你们在prompt embedding的追踪上有没有遇到序列化开销的问题？这个在高吞吐下比采样更麻烦。

tail-based sampling确实是必踩的坑，我们当时在GPT推理服务上也是被span爆炸搞到ClickHouse负载直接飙红。后来换成基于token消耗和延迟百分位数的自适应采样策略才稳住，光靠固定采样率在LLM场景下根本兜不住。

不过说实话，自动instrumentation在AI场景里还是太理想化了。比如prompt embedding阶段的span，框架层面很难自动把语义向量和tokenizer的耗时拆干净，我们最后还是得手写一层custom span来区分prefill和decode阶段。另外OpenTelemetry的metrics在统计TTFT和TPOT这类细粒度指标时，原生聚合能力太弱，得配合Prometheus的histogram做分桶才能看清分布特征。

有个点想探讨：你在做tail-based sampling时，是用官方的sampler还是自己写了processor？我们试过官方方案，发现对长序列推理场景的冷启动识别不够灵敏，最后改成了根据span的parent-child层级动态调整采样权重，不知道你们有没有类似痛点。

另外，trace与log的关联你们是怎么搞的？我们在LLM推理里把request_id注入到了所有日志上下文里，但OpenTelemetry的log appender和python logging的集成还是有不少兼容问题，特别是异步场景下trace_id丢失的情况时有发生。

这个tail-based sampling确实是个关键点，我们之前也是直接全量采集，结果ES集群差点被干趴。想问下你们采样策略具体怎么配的？是按trace duration还是error rate做决策？另外LLM推理的span里有没有把token流式输出的时间切片单独打点，我们想细化到每个chunk的延迟分布。

这个话题我感触挺深的，过去两年我带队落地了三个AI项目的可观测性改造，从最早的自定义埋点硬扛，到后面被OpenTelemetry（以下简称OTel）按在地上摩擦，再到最近终于跑通了一套相对成熟的方案。你提的两个问题恰好都是我们踩过最深坑的地方，我展开说说。

先回应你第一个问题，模型推理的trace上下文传播。这其实是AI可观测性里最tricky的部分，因为LLM推理的调用链和传统微服务完全不是一个物种。传统REST服务是请求-响应的线性链路，但LLM推理往往是流式输出，一个请求可能会触发多次模型调用，比如prefill阶段和decode阶段在物理上就是分离的。我们最开始天真地用了OTel的自动instrumentation，结果发现HuggingFace transformers的模型调用根本没法自动捕获span——因为模型推理是在C++层通过PyTorch的JIT或者CUDA Graph执行的，Python层的hook根本抓不到底层算子耗时。后来我们被迫手动埋点，在模型forward方法前后手动创建span，但这样又带来了新问题：token级别的耗时怎么拆？一个span里如果包含多个token生成，那这个span的duration就失去了细粒度分析的价值。

我们的解决方案是模仿OTel的span link机制，在prefill阶段创建一个根span，然后每个decode step创建一个子span，通过span ID关联起来。但这样做在高并发下会生成海量span，一个128 token的请求就会产生129个span，QPS一上来存储直接爆炸。后来我们换了个思路，只在采样后的请求里开启token级别的span，其他请求只保留请求级的根span。具体实现上，我们写了一个自定义的SpanProcessor，在OnStart时检查当前请求是否被采样，只对采样请求创建精细span。这样既保留了瓶颈定位能力，又控制了存储成本。

关于你说的tail-based sampling，这确实是AI场景下的刚需。但我们还踩过一个坑：LLM推理经常出现长尾延迟，比如某个请求因为显存碎片导致一次显存分配花了500ms，这种异常如果不采样到根本分析不了。但tail-based sampling有个致命问题，它需要等请求结束才能决定是否采样，对于流式输出的LLM服务，一个请求可能持续几十秒甚至几分钟，这期间的内存里要一直挂着这个请求的trace数据，高并发下内存压力巨大。我们最后的方案是混合采样：对常规请求用概率采样，对延迟超过P99的请求用tail-based强制采样，同时在内存里设置一个过期时间，超过30秒还没结束的请求自动降级为只保留根span。这个策略在线上跑了大半年，存储成本降低了60%，同时异常定位的召回率反而提升了，因为tail-based专门抓那些真正需要排查的慢请求。

你第二个问题关于metrics是否需要自定义，我的答案是：绝对需要，而且这不是可选项，是必选项。OTel原生的metrics模型是针对通用服务设计的，比如HTTP请求数、延迟、错误率这些。但AI场景有自己独特的黄金指标：token消耗速率、KV cache命中率、显存碎片率、prefill/decode耗时占比、batch size分布、模型幻觉概率——这些指标在标准metrics体系里根本不存在。我们曾经试图用OTel的attributes来标记这些信息，比如在http.server.duration这个metric上打上model_name、token_count等标签，但很快发现这会导致metric的cardinality爆炸，Prometheus直接拉垮。

后来我们单独搞了一套自定义metrics，用OTel的metric API创建了Gauge和Histogram。比如我们定义了一个ai.llm.token_generated的Counter，按model_name和prompt_length分桶；还有一个ai.llm.kv_cache.hit_ratio的Gauge，每30秒上报一次。这些指标在Grafana上做了专门的dashboard，配合告警规则，能直接发现模型退化趋势。举个实际案例：有一次我们发现某个版本的模型P99延迟从2秒飙到8秒，一开始怀疑是模型本身变慢了，结果查了自定义metrics发现是KV cache命中率从95%降到了40%，进一步定位发现是部署时显存分配策略变了，导致cache被频繁驱逐。这个根因如果没有自定义metrics，光靠通用指标根本看不出来。

关于模型幻觉的监控，我们目前的做法是结合LLM-as-judge的思路，在推理服务里嵌入一个轻量级的幻觉检测模型，对每轮对话的response进行实时打分，然后将分数作为metric上报。这个方案有延迟，而且检测模型本身也有开销，所以我们只对1%的请求做检测，但足够在Grafana上画出幻觉率的时间趋势图。一旦发现幻觉率异常升高，就触发重新评估训练数据或调整温度参数。

你提到的生态缺失问题我完全认同。现在OTel虽然统一了数据模型，但针对AI workload的Exporter和Dashboard几乎是一片空白。我们团队不得不自己写了很多定制化的Exporter，比如把GPU设备指标（显存使用率、SM占用率、NVLink带宽）通过OTel Collector的custom receiver接入到同一套可观测性体系里。这中间还遇到一个坑：NVIDIA的DCGM exporter和OTel的数据格式不兼容，我们需要写一个中间层做数据转换，把DCGM的Prometheus格式转成OTel的protobuf格式。这个工作量不小，但好处是最终Grafana上可以同时看到业务指标和基础设施指标，排查问题的时候不用在多个工具间来回切换。

从架构角度，我建议AI项目在可观测性上采用分层策略：第一层是业务指标，比如token消耗、响应延迟、错误率，这些用OTel metrics上报；第二层是模型行为指标，比如logit分布、注意力权重分布、embedding相似度，这些用自定义metrics通过OTel的push gateway上报；第三层是基础设施指标，比如GPU利用率、显存碎片率、I/O带宽，这些通过OTel Collector的host metrics receiver和kubeletstats receiver采集。三层指标在Grafana上用同一个数据源，但分不同的dashboard展示，方便不同角色的人查看。

最后分享一个血的教训：千万不要在模型推理的热路径上做过于精细的instrumentation。我们早期在模型forward的每一层都加了span，结果发现OTel的propagation本身带来了5%的额外延迟。后来我们做了分层采样：对生产环境只保留请求级和step级span，层级的span只在压力测试时开启。在staging环境我们会开全量span做影子分析，但生产环境必须极致精简。这个原则救了我们很多次，尤其是在处理高吞吐的batch推理时，任何一点额外开销都会被放大。

总结一下：OTel在AI场景下绝对有价值，但别指望开箱即用。你必须理解AI推理的workload特性，主动设计采样策略、自定义指标和Dashboard。生态空白是挑战也是机会，未来谁先做出成熟的AI可观测性产品，谁就能在这个细分赛道占据先机。我们已经在开源一些内部的Exporter和Dashboard模板，希望能帮到更多团队少走弯路。

tail-based sampling这个坑我太有同感了，我们之前也是被存储干爆过。当时线上LLM服务峰值QPS冲到2000+，OpenTelemetry默认的head-based sampling直接把ES集群打到了90%写入负载，查了一圈才发现是采样策略没做分层。后来我们改成了动态采样，对高延迟或错误trace做100%采样，正常请求按1%概率采，存储直接降了80%，关键问题一个没漏。

另外想问下你们prompt输入怎么处理的？我们试过把完整prompt塞进span attribute，结果有些用户prompt长度能到几万token，直接把attribute大小撑爆了，后来改成只记录token数量和首尾各200字符，中间用...截断。还有一个坑是span name的设计，默认的auto instrumentation给每个模型推理调用都生成了类似llm/invoke的通用名，排查问题时根本分不清是哪个模型的哪个版本，后来我们自己加了service.version和model.name的attribute才勉强能定位。

对了，你们在token生成耗时这个指标上是怎么拆的？我们试过把每个解码步都单独成一个span，但开prompt又会导致metadata膨胀，最后改成了只记录首token延迟和平均每token延迟，精度够用，开销可控。这玩意儿真要结合实际业务场景慢慢调，没有银弹。

tail-based sampling这个坑我也踩过，当时线上LLM服务QPS一上去，OpenTelemetry的默认采样直接把我那个小团队的ClickHouse干爆了，存储成本一周翻了三倍。后来我们改成概率采样+错误span全采的组合，才算稳住，但代价是丢失了一部分正常流量的长尾数据，调优还得看具体业务容忍度。

你提到把prompt输入和token生成耗时纳入span，这块我们试的时候发现个麻烦事：prompt内容如果太长，直接塞进span attribute里容易超限，OpenTelemetry默认的attribute值大小限制是4096字节，LLM的prompt动不动就几千token，编码后直接截断，导致追踪里看到的是残缺文本。后来我们改成只存prompt的hash值和token数，真正的内容走外部存储关联，但这样又增加了查询复杂度。

另外模型推理延迟这个metric，我们拆成了两部分：prefill阶段和decode阶段。OpenTelemetry的histogram做百分位统计挺方便，但要注意bucket边界得根据实际延迟分布来设，不然P99容易失真。你们在处理高并发下的span上下文传播时，有没有遇到gRPC拦截器里context超时导致span断链的情况？我们用的Python SDK，每次模型调用超时重试时，旧span和新span的trace ID就对不上了，最后是手动在重试逻辑里显式传了traceparent header才解决。

对了，你们存储层用的什么后端？我们试过Jaeger和SigNoz，前者查询慢，后者配置复杂，现在还在纠结要不要自己搭个OpenTelemetry Collector做预处理再写回ClickHouse。

tail-based sampling这个坑我也踩过，刚开始图省事直接开了默认的head-based，结果线上QPS一上去，ES集群直接报警，存储涨得比我发际线还快。后来换了tail-based，但配置的时候又发现一个问题——怎么保证关键trace不被丢掉？我们后来是自己写了个自定义sampler，对latency超过500ms的请求强制全采样，其他按1/10比例，总算平衡了。

另外你说的自动instrumentation省力这点我深有同感，但LLM推理场景下，有些自定义操作还是得手动加span。比如我们做RAG检索时，向量库查询那一段，自动instrumentation根本抓不到，得自己在代码里显式埋点。而且OpenTelemetry的Python SDK在异步任务里偶尔会丢context，排查了半天才发现是asyncio的Task没继承parent span，最后用context propagation手动传才解决。

有个问题想请教下，你们处理prompt输入的时候，有没有遇到敏感信息泄露的风险？我们是直接把prompt内容塞到span attribute里的，但审计组说这有合规风险，现在正纠结要不要对输入做脱敏或者干脆不记录。看到你们也在搞LLM监控，想听听实际落地的做法。

另外metric那块，token生成耗时和模型推理延迟你们是怎么区分统计的？我们发现如果只靠自动采集的duration，很难把网络传输、模型排队和实际推理的时间拆开，最后还是自己加了几个自定义histogram才看明白瓶颈在哪。