跳转到内容
Telemetry
浏览文档
指南更新于 2026年7月28日由 Telemetry 编辑团队和产品团队审核阅读约需 4 分钟

让编程智能体使用这篇文档

打开 Claude Code、Codex、Cursor 或其他编码代理的集中提示包,然后将其适应此处介绍的工作流程。

本页内容
  1. 跑步前要回答的问题
  2. 安全性和范围
  3. 运行有界线束
  4. 脚本发送什么
  5. 再现性记录
  6. 改进实验而不隐藏失败
  7. 您可以负责任地主张什么

Telemetry 数据摄取与查询性能基准测试

有用的基准是在公开条件下进行的可重复测量,而不是单个快速屏幕截图。本指南为公共日志和查询 API 提供了有界客户端工具,并解释了其数字可以证明什么和不能证明什么。

在准确的脚本、环境、事件形状、行计数、时间、结果和限制保留在一起之前,Telemetry 不会发布此工具的性能声明。

跑步前要回答的问题

选择一个问题:

  • 该客户需要多长时间才能提交已知的合成批次?
  • 在启用实时数据的情况下,查询读取刚刚提交的运行的速度有多快?
  • 有效负载宽度如何改变客户端观察到的摄取时间?
  • 查询时间窗口、所选列和分组基数如何影响响应时间?

不要将所有这些混合到一个“速度”数字中。除了服务时间之外,客户端挂钟测量还包括网络距离、TLS、本地调度和序列化。

安全性和范围

随附的线束将合成行写入 telemetry_benchmark_events。它拒绝运行,除非:

  • TELEMETRY_API_KEY在执行时被设置;
  • --confirm-write 存在;
  • 请求的行数在 1 到 10,000 之间。

使用专门的测试团队或API密钥。该脚本不会删除行。应用表的正常保留策略或稍后通过批准的数据管理流程删除测试数据。

环境变量对于网站和应用程序是可选的。仅当有人有意执行基准测试脚本时才需要它。

运行有界线束

从这个存储库:

TELEMETRY_API_KEY="YOUR_TEST_KEY" \
  node scripts/benchmark-telemetry-api.mjs \
  --confirm-write \
  --rows 500 \
  --batch-size 100

输出是一个 JSON 文档,其中包含:

  • 不透明的 run_id
  • UTC 开始和结束时间;
  • 请求的行数和批量大小;
  • 总负载字节数;
  • 客户观察到的摄取墙时间;
  • 每个客户端挂钟秒计算的行数;
  • 客户端观察到的查询墙时间;
  • 该运行的查询结果。

如果您想在不提交诊断数据的情况下比较本地运行,请将输出重定向到 agent_space/

node scripts/benchmark-telemetry-api.mjs \
  --confirm-write \
  --rows 500 \
  --batch-size 100 \
  > agent_space/benchmark-500.json

脚本发送什么

每行都使用确定性形状:

{
  "run_id": "unique-per-run",
  "sequence": 42,
  "event_name": "benchmark_request_completed",
  "route": "/synthetic/orders",
  "region": "test-west",
  "status_code": 200,
  "latency_ms": 47,
  "payload_size_bytes": 768,
  "success": true
}

使用确定性公式,值会因序列而异。因此,运行包含成功和失败的行以及有限的延迟值,而没有随机的客户数据。

验证查询为:

SELECT
  COUNT(*) AS rows_observed,
  SUM(CASE WHEN success THEN 1 ELSE 0 END) AS successful_rows,
  AVG(latency_ms) AS average_synthetic_latency_ms,
  MAX(sequence) AS maximum_sequence
FROM telemetry_benchmark_events
WHERE run_id = 'RUN_ID';

latency_ms 是一个合成有效载荷场。不代表Telemetry业务时延。由线束测量的查询和摄取墙时间是单独的字段。

再现性记录

为每个结果保留此上下文:

领域 为什么这很重要
脚本提交 识别准确的发生器和计时器
UTC 时间戳 主播服务版本及外部条件
客户端区域和运行时 解释网络和本地差异
API产地 将生产、登台和本地测试分开
行数和批量大小 更改请求计数和有效负载大小
事件图式 影响序列化宽度和表格形状
表状态和保留 会影响查询扫描工作
SQL 和实时选项 定义测量的查询
热身策略和重复 区分冷行为和方差
中值和尾值 避免选择有利的运行

为了比较结果,请替换候选者,而不是运行 A 的所有试验,然后运行 B 的所有试验。外部负载可能会随着时间的推移而漂移。

改进实验而不隐藏失败

单独运行一个小的热身并标记它。然后收集足够的重复来报告中位数加上高百分位或完整分布。保持超时明确并将超时计为结果而不是删除它们。

一次更改一个变量:

  1. 修复行数并改变批量大小;
  2. 修复批量大小并改变有效负载宽度;
  3. 修复摄取条件并比较选择性查询与广泛查询;
  4. 修复查询并比较热间隔与空闲间隔。

如果发生速率限制或付费专区响应,请记录 HTTP 状态并停止。不要将客户端重试时间解释为原始摄取性能。

您可以负责任地主张什么

一个可以辩护的说法是狭隘的:

在记录的 UTC 时间的指定客户端环境中,此提交按公开批次提交了公开数量的合成行。测量的客户端墙时间分布附加到运行工件。

这不是通用吞吐量保证、服务器端容量限制或竞争对手比较。生产工作负载结果需要具有代表性的模式、并发性、保留性、查询模式、区域和协调的测试环境。

使用 遥测成本与数据量管理 测量收集量,并在基准暴露拒绝或丢失事件时使用 事件摄取故障排除

相关产品功能

对结构化事件表运行只读 DataFusion SQL 并重用结果。

内容责任与技术参考

Telemetry 编辑团队负责维护本文;产品团队审核功能行为、示例和适用范围。

查看编辑规范