Export OpenTelemetry client spans for the native remote cache
维护者通常 1 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- rust
- 领域
- backend, observability
调研方向
Read crates/vt_remote_cache/src/lib.rs for the HTTP transport and crates/vt/src/session/cache/remote.rs for how RemoteClients is composed for a run. The issue describes a focused draft across these boundaries: the session owns the optional exporter lifetime, while the transport handles tracing and W3C propagation. Check the existing tests around both entry points; done means configured OTLP export and traceparent propagation work, spans flush after success or failure, and collector outages do not fail the run. Pull request #907 is already open.
由索引模型根据 Issue 内容生成。
描述
Written by an AI agent (Codex) on behalf of @jasonkuhrt.
Problem
Users with an instrumented remote cache server cannot connect its requests to the vp run clients that made them. Native cache fetch, store and blob-download requests currently have neither exported OpenTelemetry client spans nor propagated W3C trace context, so those callers are missing from trace-based service maps.
Proposed capability
Allow vp run to export its native remote-cache HTTP client spans through standard OTLP/HTTP configuration. For example, with a collector configured in the command's environment:
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 \
OTEL_SERVICE_NAME=build-client \
vp run build --remote-cache read-write
The instrumented cache server should receive a traceparent identifying the exported client span. A tracing backend can then connect the caller to its cache server.
The proposed behavior is opt-in when an OTLP endpoint is configured, honors the standard service/resource/header/protocol variables and export opt-outs, and flushes at session completion, including a failed task. A normal cache miss remains successful cache behavior. Exported attributes exclude cache credentials, keys, payloads and error-response contents; an unavailable collector must not fail the task run.
Current implementation
The HTTP transport lives in crates/vt_remote_cache/src/lib.rs; RemoteClients in crates/vt/src/session/cache/remote.rs composes it for a run. The current transport calls reqwest directly without an OpenTelemetry tracer or W3C propagation.
A focused draft implementation follows those boundaries: the session owns the optional SDK/exporter lifetime, and the remote-cache transport accepts a tracer for its HTTP operations. It does not change cache keys, payloads or authentication. Existing internal Rust performance tracing is a separate capability.
- 主要语言
- Rust
- 星标
- 480
- 派生
- 50
- 平均合并
- 1 天 5 小时
- 30 天内合并 PR
- 63
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
voidzero-dev/vite-task 的其他 Issue
-
难度 5/5 一周以上 新手友好度 35/100
voidzero-dev/vite-task#921 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 56/100
voidzero-dev/vite-task#910 · 1 条评论 ·
维护者通常 1 天内回复
-
Automatic output tracking misses files a task renames into place, so a cache hit restores nothing未关闭
难度 4/5 3-5 天 新手友好度 48/100
voidzero-dev/vite-task#908 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 56/100
voidzero-dev/vite-task#905 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 55/100
voidzero-dev/vite-task#904 ·
维护者通常 1 天内回复
查看 voidzero-dev/vite-task 的全部 Issue
相似的 Issue
-
good first issue help wanted
难度 2/5 1-3 小时 新手友好度 72/100
servo/rust-smallvec#827 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
nowledge-co/hawdb#1400 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
calcit-lang/caps#16 ·
-
难度 2/5 1-3 小时 新手友好度 85/100
penso/herdr-gpui#934 ·
维护者通常 1 天内回复
-
🎉 Add Bossanova未关闭
难度 2/5 1-3 小时 新手友好度 70/100
jaywcjlove/awesome-mac#4096 ·
维护者通常 1 天内回复