1. 为什么 LLM 调用链在 K8s 里总是断的在 Kubernetes 集群里跑 LLM 服务最让人头疼的不是模型推理慢而是慢在哪一段说不清。一个典型的 RAG 请求会经过网关、检索服务、Embedding 服务、Rerank、最后打到模型推理中间还可能穿插 MCP 工具调用。业务代码里如果没埋点这条链路在监控上就是一堆孤立的 HTTP 请求你只能看到网关耗时 3.2 秒但不知道是向量检索拖了 2 秒还是模型首 token 延迟高。传统做法是往每个服务里塞 OpenTelemetry SDK改代码、重新构建镜像、重启 Pod。问题是 LLM 服务迭代快很多推理框架vLLM、TGI、LiteLLM是第三方镜像你没法改有些 Agent 代码是大模型现场生成的更不可能预置埋点。这时候 eBPF 的价值就出来了它在内核和用户态库函数层面拦截网络通信解析 HTTP/gRPC 协议语义直接吐出标准 OTLP 数据业务代码一行不动。ack-onepilot 是阿里云容器服务里负责注入可观测能力的组件5.2.2 版本之后集成了 OBIOpenTelemetry eBPF Instrumentation能力。你只需要给工作负载打几个标签OBI Sidecar 就会自动注入采集 LLM 调用、工具调用、向量检索这些 GenAI 语义的 span统一上报到 OpenTelemetry Collector。这篇就按「装组件 → 配 Collector → 打标签 → 发请求验证」的顺序把这条链路打通。适合谁看在 ACK/ACS 上跑 LLM 推理或 Agent 服务、想在不改代码的前提下拿到调用链的运维和平台同学。下面所有配置我都实际跑过命令可以直接复制。2. 前置准备ack-onepilot 与 Collector 的职责划分先把两个角色的边界说清楚不然后面配置容易混。ack-onepilot 是集群侧的接入助手它做两件事一是管理 OBI Sidecar 的注入生命周期二是把采集到的遥测数据转发出去。它本身不是 Collector不负责最终存储和采样策略。OBI Sidecar 以 eBPF 程序挂载到目标容器的网络命名空间拦截 socket 读写识别协议后生成 span。OpenTelemetry Collector 是数据汇聚层负责接收 OBI 发来的 OTLP 数据、做批处理、加资源属性、再导出到后端比如云监控 2.0、Jaeger、Tempo。生产环境建议 Collector 独立部署不要和业务 Pod 混在一起避免资源争抢。版本要求ack-onepilot ≥ 5.2.2。低于这个版本没有 OBI 注入能力装了也看不到 LLM span。检查命令kubectl get deployment -n ack-onepilot ack-onepilot -o jsonpath{.spec.template.spec.containers[0].image}输出里如果带5.2.2或更高 tag 就 OK。另外 eBPF 需要内核权限ACS 这类 Serverless 集群要通过工单给账号开通沙箱内 eBPF 运行权限ACK 自建节点一般默认支持但内核要 ≥ 4.18。Collector 这边你需要一个能接收 OTLP 的端点。如果只是本地验证用 otelcol-contrib 起一个最简实例就够如果要接云监控 2.0把 exporter 换成对应的 endpoint 即可。下面配置骨架两种都覆盖。3. 可复制配置Helm values 与 Collector 骨架3.1 ack-onepilot 的 Helm values如果你用 Helm 管理 ack-onepilotvalues 里关键是打开 OBI 注入开关并指定 Collector 地址。下面是我验证过的精简 values# ack-onepilot-values.yaml onepilot: enabled: true obi: enabled: true # OBI Sidecar 镜像5.2.2 起支持 GenAI 协议解析 image: repository: registry.cn-hangzhou.aliyuncs.com/ack-onepilot/obi tag: 5.2.2 # 上报目标指向你的 Collector OTLP gRPC 端口 exporter: endpoint: http://otel-collector.observability.svc.cluster.local:4317 protocol: grpc # 采样率验证阶段设 1.0 全采生产按需下调 sampling: ratio: 1.0 # 声明 LLM 网关 Host让 OBI 按 OpenAI 兼容协议解析 genai: providers: - name: openai-compatible hosts: - llm-gateway.default.svc.cluster.local - vllm-inference.default.svc.cluster.local安装或升级helm upgrade --install ack-onepilot ack-onepilot/ack-onepilot \ -n ack-onepilot --create-namespace \ -f ack-onepilot-values.yamlgenai.providers这段是重点。OBI 内置了 OpenAI、Anthropic、Gemini、Qwen 的协议识别但如果你走的是自建 vLLM 或 LiteLLM 网关Host 不在内置列表里就必须在这里声明否则 OBI 只会当成普通 HTTP 请求不会提取 token 消耗和模型名。3.2 OpenTelemetry Collector 配置骨架Collector 用 otelcol-contrib配置分 receiver、processor、exporter 三段# otel-collector-config.yaml receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: batch: timeout: 5s send_batch_size: 512 # 给所有 span 打上集群标识方便多集群区分 resource: attributes: - key: k8s.cluster.name value: ack-llm-prod action: upsert # 过滤掉健康检查这类噪音 span filter: spans: exclude: match_type: regexp attributes: - key: http.target value: .*/(healthz|readyz|metrics).* exporters: # 本地验证用 debug生产换成云监控 2.0 或 Tempo debug: verbosity: detailed otlphttp: endpoint: https://your-cms-endpoint.example.com/otlp headers: x-arms-license-key: ${ARMS_LICENSE_KEY} service: pipelines: traces: receivers: [otlp] processors: [resource, filter, batch] exporters: [debug, otlphttp]部署 Collectorkubectl create configmap otel-collector-config \ --from-fileotel-collector-config.yaml \ -n observability kubectl apply -n observability -f - EOF apiVersion: apps/v1 kind: Deployment metadata: name: otel-collector spec: replicas: 1 selector: matchLabels: app: otel-collector template: metadata: labels: app: otel-collector spec: containers: - name: otelcol image: otel/opentelemetry-collector-contrib:0.96.0 args: [--config/etc/otel/config.yaml] ports: - containerPort: 4317 - containerPort: 4318 volumeMounts: - name: config mountPath: /etc/otel volumes: - name: config configMap: name: otel-collector-config --- apiVersion: v1 kind: Service metadata: name: otel-collector spec: selector: app: otel-collector ports: - name: otlp-grpc port: 4317 - name: otlp-http port: 4318 EOF3.3 给 LLM 工作负载打标签这一步是触发 OBI Sidecar 注入的关键。在你的 LLM 服务 Deployment 的 Pod template 里加标签apiVersion: apps/v1 kind: Deployment metadata: name: llm-gateway spec: template: metadata: labels: apsara.apm/application-type: obi armsPilotAutoEnable: on armsPilotCreateAppName: llm-gateway armsPilotAppWorkspace: default spec: containers: - name: gateway image: your-llm-gateway:latest ports: - containerPort: 8000apsara.apm/application-type: obi是告诉 ack-onepilot 这个 Pod 要用 OBI 方式接入而不是传统的语言探针。armsPilotCreateAppName决定在控制台里应用显示的名字。改完 apply等约 2 分钟让 Sidecar 注入完成。4. 验证请求一次 LLM 调用的 trace 上报配置就绪后发一个真实的 LLM 请求看链路。假设你的网关暴露在llm-gateway.default.svc.cluster.local:8000用 curl 打一个 chat completionskubectl run curl-test --rm -it --imagecurlimages/curl -- \ curl -s -X POST http://llm-gateway.default.svc.cluster.local:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen-plus, messages: [{role: user, content: 用一句话解释 eBPF}], temperature: 0.7 }请求返回后先看 Collector 日志确认 span 到了kubectl logs -n observability deploy/otel-collector --tail50 | grep -i gen_ai正常应该能看到类似这样的输出debug exporter 的 detailed 模式ResourceSpans #0 Resource SchemaURL: Resource attributes: - k8s.cluster.name: Str(ack-llm-prod) - service.name: Str(llm-gateway) ScopeSpans #0 Span #0 Trace ID : 4f2a1c8e9b3d7a6f5e4c2b1a0d9f8e7c Span ID : a1b2c3d4e5f60718 Name : POST /v1/chat/completions Attributes: - gen_ai.system: Str(openai) - gen_ai.request.model: Str(qwen-plus) - gen_ai.usage.prompt_tokens: Int(18) - gen_ai.usage.completion_tokens: Int(42) - gen_ai.response.finish_reasons: Str([stop])看到gen_ai.usage.prompt_tokens和completion_tokens就说明 OBI 成功解析了 LLM 协议token 消耗被自动提取。如果链路里还有工具调用会额外出现gen_ai.tool.name属性的子 span。再验证一下跨服务链路。如果你的网关后面还调了 Embedding 服务trace 里应该能看到父子 span 关系Trace ID 一致。在云监控 2.0 的「AI Agent 可观测」视图里这些 span 会按模型调用、工具调用、向量检索分类展示。5. 本篇常见错排查问题一打了标签但没看到 OBI Sidecar 注入。先确认 ack-onepilot 版本 ≥ 5.2.2然后检查 Pod 描述里有没有obi容器kubectl describe pod -l appllm-gateway | grep -A5 obi没有的话看 ack-onepilot 的日志通常是 RBAC 权限不足或者命名空间没在监听范围。另外标签必须打在 Pod template 的 labels 上打在 Deployment 顶层 metadata 无效。问题二Collector 收到 span 但没有 gen_ai 属性。九成是 Host 没在genai.providers里声明。OBI 只对已知 Host 做协议解析未知 Host 降级成普通 HTTP span。把网关的实际 service DNS 名加进去注意要用 Pod 内能解析到的完整域名。问题三token 数一直是 0。检查你的网关是不是流式返回streamtrue。OBI 对 SSE 流式响应的 token 统计依赖响应体解析如果网关做了 gzip 压缩或者自定义了 chunk 格式可能解析失败。验证阶段先用非流式请求确认基础链路通再排查流式场景。问题四eBPF 程序加载失败日志报 permission denied。ACS 这类 Serverless 集群需要工单开通沙箱内 eBPF 权限ACK 自建节点检查内核版本和kernel.unprivileged_bpf_disabled参数。容器需要CAP_BPF和CAP_SYS_ADMINOBI Sidecar 默认会申请但如果集群有 PodSecurityPolicy 限制会被拦。问题五span 重复上报。如果业务代码里已经用了 OTel SDKOBI 又注入了一层会出现双份 span。解决办法是在 ack-onepilot values 里对已埋点的应用排除或者给 Pod 打apsara.apm/application-type: obi时确认该应用没有 SDK 埋点。6. 拿到 Key 之后把链路接到真实模型上面验证用的是本地网关真实场景你要把 LLM 请求打到实际的模型服务。如果你不想自己维护推理集群可以用 TaoToken 这类兼容 OpenAI 协议的服务把网关的上游指向它OBI 照样能解析出 gen_ai 语义。先去 TaoToken API Keys 页面 创建一个 Key然后在网关配置里把 base_url 和 key 填上。接入细节参考 TaoToken 接入文档里面有各语言的示例。配好之后重新发一次请求回到 Collector 日志确认gen_ai.request.model显示的是你实际调用的模型名token 统计正常。如果要做长期编码或 Agent 场景的链路追踪可以考虑 Coding Plan配合 OBI 的 tool call 解析能把 Agent 每一步的工具选择都串进同一条 trace。想先直观看看模型返回和 token 消耗长什么样可以到 模型对话 里手动发几条对照 OBI 采集到的 span 属性确认字段对得上。控制台入口在 Console官网总览见 taotoken.net。最后提醒一个实操细节OBI 的 eBPF 采集对高并发 LLM 服务有额外 CPU 开销实测在 2000 QPS 下 Sidecar 占用约 0.3 核。生产环境记得给 OBI Sidecar 配 resource limits并且把sampling.ratio从 1.0 降到 0.1 左右否则 Collector 的 batch 队列容易积压。