北京
周三下午三点，一个普通的HTTP请求返回了200 OK，响应内容也完全合理，看起来没什么问题。但如果你看一眼日志，整个请求花了10秒。10秒对于一次AI生成摘要来说不算特别慢，可问题在于——这10秒里，模型到底卡在哪一步，没人知道。这就是我最近构建的一个小Agent遇到的情景，也是我动手接入OpenTelemetry和SigNoz的直接原因。
这个Agent结构非常简单：你给它一个话题，它会先把话题拆成三个子问题，每个子问题单独调一次LLM获取答案，最后再调一次LLM把三个答案合并成一段摘要。后端用FastAPI，模型选的是OpenAI的gpt-4o-mini。一个请求下来，总共要跑5次LLM调用。功能上它完全满足了需求，可工程师的本能告诉我，这里面有“隐藏的排队”——5次调用真的是一个接一个串行执行的吗？每次调用各自消耗了多少token？如果能把调用改并发，响应时间能缩短多少？普通的HTTP日志只给了一个整体耗时，里面的细节全是一片黑盒。而tracing的用处就在这里：让你像拆钟表一样，看到一次请求内部的每一步。
我决定自托管的SigNoz来做这件事，因为想让整套遥测链路都在自己的机器上跑起来。运行环境是Windows下的WSL 2，起初我还以为随便装个Docker就能直接用，结果Ubuntu终端里敲docker直接抛出一句“The command 'docker' could not be found in this WSL 2 distro.” Docker Desktop把它的引擎藏在另一个独立的WSL发行版里，并没有自动接进Ubuntu。折腾几分钟后，我选择了更简单的路线：直接在Ubuntu里原生安装Docker。
curl -fsSL https://get.docker.com | shsudo usermod -aG docker $USER接下来wsl --shutdown再重新打开Ubuntu，执行docker ps，终于看到了一张干干净净的空表格——这说明Docker守护进程真的连上了。
随后按照SigNoz当前的安装流程，用Foundry CLI来拉起整套栈。官方早已废弃了旧的install.sh脚本，现在只需要一条命令：
curl -fsSL https://signoz.io/foundry.sh | bash再新建一个casting.yaml描述安装配置，执行foundryctl cast -f casting.yaml，等几分钟镜像拉取完毕，docker ps一出一张完整的健康列表：SigNoz控制台暴露在8080端口，OpenTelemetry Collector监听4317和4318端口。唯一的小瑕疵是signoz-mcp容器显示unhealthy，但这只是健康检查的界面问题，不影响实际功能。
至此，整套系统的拓扑就清晰了：FastAPI Agent运行在WSL 2里，通过OpenTelemetry SDK把trace数据以OTLP协议推到localhost:4318，Colletor收到后再写入ClickHouse存储，SigNoz UI从ClickHouse读取数据，提供trace、metrics、dashboard和告警。当我在浏览器打开SigNoz界面时，工作区空空荡荡，提示“你还没发送任何数据”。这个状态正好符合预期，还不到接入真实应用的时候。
在给真正的Agent插装之前，我先验证遥测管道本身是否畅通。我随手用脚本生成了几条测试trace，确认它们能成功穿过Collector、落进ClickHouse并在UI上完整展示。这一步看似多余，却帮我提前排查掉了WSL 2与Docker之间的网络连通性问题，也让我对后续的插装工作有了完全的信心。至于Agent内部的那5次LLM调用到底有没有串行等待、token消耗的分布是怎样的，那就是下一步通过插装要揭开的真问题了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
