Titpea
按操作看，而不是按请求
分段上传、重试、列举，以及 SlateDB、Iceberg、Delta Lake 的步骤。
运行它，看它发出的请求
输入一条命令，它的终端和它的 S3 请求并排出现。你的真实密钥不会交给它。
改动带来了什么
对比两次运行：请求、等待、费用和发现，前后一目了然。
时间花在了哪里
按请求类型看等待、同时在途的请求，以及这次运行花了多少钱。
把请求读成它们做了什么
发现，附带修法
热点键、先 HEAD 再 GET、孤立文件：修好各能省多少。
在 CI 里守住预算
运行超出预算或基线时，sonde check 让任务失败。
在另一个存储上重放
把一次会话在别的端点上重演，逐条比较应答。
生产日志也能读
S3 访问日志、CloudTrail 和 HAR 文件，用同样方式解读。
你的存储桶
浏览十万以上对象，找出未完成的上传和它们的费用。
v12.0.0 2026年11月9日 发布说明 ›
开始使用
Linux 和 macOS 的终端版；桌面应用在 Releases 下载，或 brew install --cask hxddh/sonde/sonde-app。
-
安装终端版
curl -fsSL https://raw.githubusercontent.com/hxddh/sonde/main/install.sh | sh
数据的去向
- 凭证在 Rust 里解析；被录制的程序拿到的是一次性密钥和本地端点，由 sonde 用真实凭证签名。
- 请求只发往你的 S3 端点，扮演角色时还有 STS。没有遥测，只在你要求时检查更新。
- 会话、请求日志和审计日志留在 sonde 的数据目录；签名、令牌和密钥在记录生成时就被抹掉。
- 默认只读；任何删改都要先试运行、再输入确认，并写进审计日志。
常见问题
需要改代码吗？
一般不用。sonde run 用环境变量和一次性密钥把程序指向本地端点，再用你的真实凭证给每个请求重新签名。已用 boto3、JavaScript v3、Go v2、Java v2 的 AWS SDK 和 object_store 验证过；不读这些环境变量的客户端，需要手动设置端点。
支持哪些存储？
任何兼容 S3 的端点都行，例如 AWS、Cloudflare R2、MinIO、Ceph RGW、阿里云 OSS、Tigris 和 Wasabi。它的 40 项兼容性探测会把各端点的差异排成一张表。
重放会对另一个存储做什么？
它把同样的请求写到新的 replay-<时间>/ 前缀下，已有的东西一概不碰；存储桶级别的改动会跳过。它会先征得同意，结束后删掉自己写的内容，除非你加 --keep。
没有账号能先试试吗？
可以：sonde demo 在内置的存储上运行，应用启动时也连着同一个演示端点。
sonde