Jaeger agent 上报口
Jaeger 的 span 上报分两跳：客户端 SDK 用 UDP 6831（thrift compact 编码，6832 为 binary）把 span 发到就近的 jaeger-agent，agent 再批量转发给 collector 的 14268（HTTP）或 14250（gRPC）。UDP 没有重传与确认，丢包只会表现为调用链「随机断节」，而不会报错。
基本信息
| 服务 | Jaeger agent（负责接收端） |
|---|---|
| 协议 | UDP（6831 compact / 6832 binary） |
| 默认端口 | 6831、6832（collector 14268/14250，UI 16686） |
| 客户端配置 | JAEGER_AGENT_HOST / JAEGER_AGENT_PORT |
| 暴露面 | 仅内网采集段 |
典型使用场景
- 应用与 agent 同宿主机部署，SDK 只向 localhost 发 span，避免跨机 UDP 丢包
- K8s 用 DaemonSet 部署 agent，承接节点上所有 Pod 的 6831 上报
- 排障期临时调低采样率，减少 agent 转发队列压力
- 老版本语言 SDK 不支持直连 collector 时，用固定远端 agent 兜底
- 灰度对比两套采样配置时，先在同一条 6831 链路上观察丢包
监听与流量核对
监听与流量核对
ss -lunp | grep -E '683[12]' # UDP 必须用 -u 查
ss -lntp | grep 14268 # collector 侧对照
tcpdump -nn udp port 6831 -c 5 # 看有没有 span 进来
# 客户端: JAEGER_AGENT_HOST=jaeger-agent JAEGER_AGENT_PORT=6831排障与核对
| 检查项 | 做法 | 异常表现 |
|---|---|---|
| 监听 | ss -lunp | grep 6831 | 用 -lntp 查不到 UDP，误判服务没起 |
| 数据流入 | tcpdump -nn udp port 6831 | 界面缺链路：先确认 agent 是否收到包 |
| 转发 | agent 日志 + collector 侧计数 | agent 收到、collector 没有：转发队列满导致丢包 |
| 编码 | SDK 编码方式与 6831/6832 对应 | 编码选错时 agent 直接丢弃，日志只有一行反序列化失败 |
6831 与 6832 的差别只在 thrift 编码：compact 更省带宽，binary 兼容老客户端。客户端端口配错时不会收到明确错误，只会「追踪数据全丢」，因此上线前用 tcpdump 验证一次最省事。
UDP 上报没有鉴权：同网段任何主机都能向 6831 注入伪造 span，污染调用链、误导容量与故障判断。
为什么需要 agent 这一跳
agent 的设计目的是就近接收、批量转发：客户端 SDK 只管往本地 UDP 口丢报文，编码转换与采样决策集中到一处置。代价是它成了链路上的第一道瓶颈——agent 转发队列满时会先丢数据，而客户端一侧完全无感，故障表现只是「追踪缺了一截」。
采样率、编码方式与队列大小都随版本变化，升级 agent 或客户端 SDK 前先确认两侧对 6831/6832 的支持范围。K8s 环境普遍把 agent 做成 DaemonSet，配合 hostPort 或 hostNetwork 让本地 UDP 上报稳定可达。