企业官网建设流程全解析

OpenTelemetry 全链路追踪 AI Agent：Jarvis Registry 可观测性配置指南（Grafana + Prometheus + Tempo）

【免费下载链接】jarvis-registryConnect any AI copilot or autonomous agent to your enterprise tools — through a single, secure MCP/Agent gateway with built-in identity, access control, and full observability.项目地址: https://gitcode.com/gh_mirrors/ja/jarvis-registry

Jarvis Registry是一个企业级 MCP/Agent 网关，让任意 AI 助手或自主 Agent 安全地连接企业内部工具。它内置了基于OpenTelemetry的全链路追踪能力：平台服务（Registry、MCP 网关、Auth Server）输出平台指标，AI Agent 输出LLM 调用链路（Traces），全部经 OTel Collector 汇聚后，默认落地到Grafana + Prometheus + Tempo这套自托管参考栈，开箱即可在浏览器里查看调用率、p95 延迟和 Token 用量。

为什么 AI Agent 需要全链路追踪 🕵️

传统的"看 CPU、看日志"对 AI 系统远远不够。你更关心的问题通常是：

• 哪个LLM 模型被调用了多少次？
• 每次请求消耗了多少输入/输出 Token（直接关联成本）？
• 请求p95/p99 延迟是否劣化？
• 认证、OAuth 回调、工具执行等平台侧操作是否正常？

Jarvis Registry 用两类互补信号回答这些问题：

两条链路统一使用OTLP协议上报，后端可换可加（New Relic、Datadog、Splunk、Langfuse 等），且无需改一行应用代码。

架构上，所有遥测数据都汇聚到一个厂商中立的 OTel Collector，再由它分发到各家后端——这是你切换或叠加可观测性平台的"唯一接缝"。

快速启动：docker compose 一键拉起 Grafana 全家桶 🚀

观测栈的所有组件（Collector、Tempo、Prometheus、Grafana）都已写在 docker-compose.yml 中，属于fullprofile，随主栈一起启动：

docker compose --profile full up -d

启动后直接访问对应端口即可：

各服务通过环境变量OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318自动把数据上报给 Collector，OTEL_SERVICE_NAME（如mcp-gateway-registry、auth-server）区分来源。

数据怎么流：Collector 的三条管道

核心配置在 config/otel-collector-config.yaml，逻辑非常简单——Collector 监听 OTLP 的 gRPC/HTTP 端口，经batch处理器后分发：

• logs→debug导出器（打印到容器日志，便于排查）
• metrics→prometheus导出器（暴露在8889端口，供 Prometheus 抓取）
• traces→otlp_http/tempo（本地 config/tempo.yaml 定义的本地存储，保留 24 小时）+otlp_http/langfuse（可选的云端链路后端）

Prometheus 侧由 config/prometheus.yml 定义抓取任务：每 10 秒抓取一次otel-collector:8889。Grafana 的数据源和仪表盘均为自动预配置（provisioning）：

• 数据源：config/grafana/datasources/prometheus.yml 同时注册了 Prometheus 与 Tempo，并开启Traces to Metrics 跳转和Service Map 服务拓扑图
• 仪表盘：config/grafana/dashboards/dashboard.yml 自动加载 config/grafana/dashboards/ 目录下的全部 JSON 面板

也就是说，你只需要启动容器，不用手动在 Grafana 里建数据源、导面板。

平台指标：Registry、网关与认证服务在忙什么 📊

指标由两个声明式 YAML 驱动，新增指标只需改配置：

• Registry 侧：config/metrics/registry.yml
  • 计数类：注册表操作、MCP 服务器请求、工具发现 / 工具执行、资源访问、Prompt 执行、认证请求、Workflow 运行与工具调用
  • 延迟直方图（可算 p50/p95/p99）：注册表操作、工具执行、认证请求、Workflow 运行等
• Auth 侧：config/metrics/auth_server.yml
  • 认证请求、Token 生成/刷新/吊销、OAuth 回调与授权、会话创建与校验及其延迟

指标实现位于 registry/src/registry/utils/otel_metrics.py 与 auth-server/src/auth_server/utils/otel_metrics.py，按 service 名分桶上报。

AI Agent 链路追踪：看清每次 LLM 调用的成本与延迟 🤖

Agent 侧统一采用OpenLLMetry作为唯一插桩层，输出厂商中立的OpenTelemetry GenAI 语义约定（gen_ai.*属性），任何遵循约定的 Agent 都能"零配置"出现在仪表盘里。

参考仪表盘按Agent + AI 提供商 + 模型三个维度拆解 LLM 行为：调用率（req/s）、p95 延迟、输入/输出 Token 用量——这正是成本归因和性能排查最需要的视角：

要让 Agent 接入，只需两个环境变量：

• OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental— 启用最新 GenAI 约定，Token 落到gen_ai.usage.input_tokens / output_tokens
• OTEL_EXPORTER_OTLP_ENDPOINT— 指向 OTel 网关/Collector；未设置时遥测自动失效（no-op），本地开发与 CI 完全不受影响

Grafana 仪表盘：MCP 网关分析一览 📈

除了 LLM 视角，MCP Gateway - Analytics Dashboard把平台侧活动整合在同一屏：实时协议活动（Initialize / Tools List / Tool Call 速率）、认证成功/失败流、认证成功率、活跃 MCP 服务器数、每小时工具执行量、最热门工具，以及 P95/P99 协议延迟分析：

更多内置面板可在 config/grafana/dashboards/ 中查看，覆盖认证服务、MCP 分析、Registry、Workflow 等视角。

隐私与安全：遥测不泄露 Prompt 内容 🔒

默认情况下 LLM 插桩可能把完整 Prompt 和回复文本写入 Span 属性。Jarvis 在源头就关闭了这一点：

• TRACELOOP_TRACE_CONTENT=false— 只记录元数据（模型、Token 数、延迟），丢弃gen_ai.input.messages、gen_ai.output.messages等内容字段

内容在离开 Agent 前就被剥离，永远不会到达 Collector 或任何下游后端，而 Token 统计不受影响，用量与成本视图照常工作。

传输层面，平台指标走集群内网；Agent 链路经外部网关进入时，默认使用TLS + Bearer Token认证，若 Agent 与网关在同一 VPC（如 Bedrock AgentCore、Azure Container Apps、Cloud Run + VPC 连接器），可改用内网负载均衡器，让端点完全不对公网暴露。

常用配置与文档速查 📁

小结 ✅

Jarvis Registry 的可观测性设计可以概括为一句话：OTLP 统一上报、Collector 统一分发、Grafana 全家桶统一展示。你只需docker compose --profile full up -d一条命令，就能获得从平台指标到 AI Agent LLM 调用的全链路追踪能力；而接入 New Relic、Datadog、Grafana Cloud 等其他后端，也只需在 Collector 里加一个 exporter——应用代码零改动。

【免费下载链接】jarvis-registryConnect any AI copilot or autonomous agent to your enterprise tools — through a single, secure MCP/Agent gateway with built-in identity, access control, and full observability.项目地址: https://gitcode.com/gh_mirrors/ja/jarvis-registry