How to generate real-world load tests using Grafana Cloud k6 and production telemetry

标题：如何使用 Grafana Cloud k6 和生产遥测生成真实世界的负载测试

URL 来源：https://grafana.com/blog/how-to-generate-real-world-load-tests-using-grafana-cloud-k6-and-production-telemetry/

发布时间：2026-06-03

Markdown 内容： 对许多开发团队来说，负载测试通常始于一组假设。

你选择 100 个虚拟用户，因为听起来合理。你以 30 秒的速度增加负载，因为教程是这么展示的。你设置 500 毫秒的阈值，因为觉得是一个不错的指标。测试通过了，你发布了版本，但生产环境在周二下午 6 点崩溃，因为你的合成负载从未反映真实用户如何与你的应用互动。

好消息是，如果你正在使用 Grafana Cloud，你已经拥有运行真实负载测试所需的数据。你的仪表板记录了用户的行为，包括请求速率、延迟分布以及随时间变化的流量模式。信号已经存在，你只需要将其连接到测试配置中。

使用生产遥测数据来构建测试，使结果更加有意义。你不再针对假设的负载进行验证，而是针对系统已经经历的模式进行测试，从而获得更可靠的基准、更合理的阈值，并减少生产环境中的意外情况。

本文将逐步介绍如何实现这一点：从 Grafana Cloud 中提取真实的遥测信号，并将其转化为一个 Grafana Cloud k6 测试场景，该场景反映生产环境（而不是假设）。

VU 数量并不是唯一开始的地方

虚拟用户（VU） 数量是 Grafana Cloud k6（由 k6 OSS 支持的全托管性能测试平台）运行测试的重要部分。然而，VU 数量并不总是你首先要调整的参数。当你目标是测试服务在已知请求速率下的表现时，到达速率执行器能更直接地表达你的意图。

你可能更关心的是 _到达速率_，即系统每秒处理的请求数。VU 数量是到达速率和响应时间的产物。如果你的 p95 延迟翻倍，你需要两倍的 VU 来维持相同的吞吐量。从 VU 开始，你调整的是错误的变量。

这种区别通常体现在 API 测试与网站测试之间。通常来说，模拟一定数量的“真实用户”，包括他们的操作、暂停时间以及这些行为如何转化为后端容量，与在 API 端点上模拟特定吞吐量之间存在差异。尽管底层测试本质上是相似的，但你如何推导出这些流量水平取决于你所使用的遥测数据类型。例如，分析和模拟完整的用户会话更符合 Grafana Cloud Frontend Observability，而下面描述的指标则专注于推导出你的 API 端点的流量水平。

k6 提供了两种执行器类型，它们直接映射到真实流量的工作方式：

• constant-arrival-rate：每秒固定数量的迭代次数，无论每次迭代需要多长时间。当你希望保持稳定的请求速率并观察在该压力下的延迟时使用此选项。

• ramping-arrival-rate：根据你定义的阶段，随时间变化的到达速率。当你需要模拟具有特定形状的流量时使用此选项，例如早晨的逐渐上升、傍晚的高峰、中午的低谷。

这两种执行器都需要真实的数字才能发挥作用。下面是获取这些数字的方法。

**步骤 1：找到你的实际请求速率**

打开 Grafana Cloud，并使用以下查询对你的 Prometheus 或 Mimir 数据源进行查询。替换为你的服务名称：

sum(rate(http_server_requests_total{app="leaderboard-api"}[$__rate_interval]))

在具有代表性的窗口内查看该数据。一个完整的周比单天更合适。你关注的是以下两件事：

1. 正常运行期间的基准速率（每秒请求数）

1. 峰值速率，即你实际观察到的最高持续负载

这个峰值数字就是你的负载测试目标。不是猜测或仅仅是平均值的两倍，而是系统实际处理（或需要处理）的峰值。

如果你的基准速率是 120 req/s，峰值速率是 340 req/s，你现在就有了可以使用的实际数字。

**步骤 2：获取你的延迟基准**

这个值将成为你的阈值。运行以下查询以获取正常生产负载下的 p95 延迟：

histogram_quantile(
 0.95,
 sum(rate(http_server_request_duration_seconds_bucket{app="leaderboard-api"}[5m])) by (le)
)

这个值将成为你在 Grafana Cloud k6 脚本中的检查项，例如：http_req_duration: ["p(95)<280"]。

无论这个查询返回什么值，比如 280ms，这就是你的阈值。如果负载测试使 p95 超过 280ms，测试应该失败。

在此过程中，也获取一下 p99 值。p95 和 p99 之间的差距可以告诉你有关尾部延迟行为的一些信息，这些信息在负载情况下会变得重要。

**步骤 3：了解你的流量模式**

有效的流量建模不仅仅是模仿 24 小时的周期；它应基于你想要回答的具体性能问题来建模你的测试配置。拉取你的请求速率面板，观察线条的形状，然后选择以下四种客户建模模式之一来指导你的 stages 数组：

• 恒定负载：在基线之上保持一个较小的百分比较长时间，以验证系统在稳定状态下的稳定性。

• 压力测试：逐步增加负载级别，以确定延迟或错误率突然激增的确切崩溃点。

• 峰值测试：快速达到观察到的峰值并维持较短时间，以测试系统在处理突发流量时的表现。

• 耐力测试：在很长一段时间内保持基线负载，以发现资源泄漏或随时间推移的性能下降。

例如，一个旨在找到系统崩溃点的 压力测试 可能使用如下阶段设置：

stages: [
  { target: 60, duration: "5m" },   // 基线的 50%
  { target: 120, duration: "5m" },  // 基线
  { target: 240, duration: "5m" },  // 基线的 2 倍
  { target: 340, duration: "5m" },  // 观察到的峰值
  { target: 0, duration: "5m" },    // 逐步降低并冷却
]

在这种情况下，你不是凭空捏造这些数据，而是从仪表板上读取的。

**步骤 4：在 Grafana Cloud k6 中整合所有内容**

以下是一个使用真实数据构建的完整场景配置示例，而不是基于假设：

import http from "k6/http";
import { check } from "k6";

export const options = {
  scenarios: {
    realistic_load: {
      executor: "ramping-arrival-rate",

      // 从 Grafana 中观察到的峰值并发量得出
      preAllocatedVUs: 50,
      maxVUs: 200,

      // 从你的流量模式面板得出
      stages: [
        { target: 120, duration: "5m" },   // 上升到基线（req/s）
        { target: 340, duration: "10m" },  // 推动到观察到的峰值
        { target: 120, duration: "5m" },   // 返回基线
      ],
    },
  },

  thresholds: {
    // 从生产环境的 p95 延迟得出 —— 不是虚构的
    http_req_duration: ["p(95)<280"],

    // 从 Grafana 中观察到的错误率得出
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("https://your-service.example.com/api/health");
  check(res, { "status 200": (r) => r.status === 200 });
}

该配置中的每一个数字都来自仪表板查询。当同事问你为什么选择这些值时，你有明确的答案。

**步骤 5：在 Grafana Cloud 中闭合反馈回路**

运行测试并将结果发送到 Grafana Cloud k6。现在打开你之前获取基线的相同 Grafana Cloud 仪表板，并为测试运行的时间添加一个 注释。

你现在看到的是在负载测试期间的相同面板，该测试被设计为与生产环境条件相匹配，显示了请求率、p95延迟和错误率。如果测试揭示了问题，你已经知道该去哪个仪表板。调试上下文是内置的。

这就是可观测性和测试循环应该呈现的样子：生产数据指导测试设计，测试结果反馈到你的可观测性堆栈中。双方都不是孤立的。

[一种更简单的方法：使用Grafana Assistant生成脚本](https://grafana.com/blog/how-to-generate-real-world-load-tests-using-grafana-cloud-k6-and-production-telemetry/#a-simpler-way-generate-your-script-with-grafana-assistant)

虽然手动计算所有值（请求率、p95延迟、阶段）可以提供最大的控制和准确性，但实现一个生产就绪的脚本还有更简单的方法。

Grafana Assistant，Grafana Cloud中的AI代理，包含了一个k6脚本编写功能，允许你使用自然语言生成性能测试。该功能通过将生产环境中观察到的指标（如面板中识别出的确切请求率和延迟阈值）直接转换为有效的k6配置，自动化了性能工程中的繁重工作。你不需要手动解析Prometheus查询并将值硬编码到脚本中，只需让Assistant根据你服务的现有流量模式生成测试即可。

Grafana Assistant分析你的服务上下文，包括相关的指标、日志和追踪，以复制观察到的行为，如早晨的上升或晚间的高峰。

通过自动将这些真实世界的流量模式映射到k6的到达率执行器和定义的阶段，Assistant显著减少了手动工作量，同时确保了更高的生产条件一致性。这确保了你的测试不仅在语法上是正确的，而且基于系统每天实际面临的压力。

要了解更多关于Assistant中k6脚本编写的信息，请查看我们的博客文章和技术文档。

[总结：这对左移测试意味着什么](https://grafana.com/blog/how-to-generate-real-world-load-tests-using-grafana-cloud-k6-and-production-telemetry/#wrapping-up-what-this-all-means-for-shift-left-testing)

左移测试是一种方法，它在开发流程的早期阶段进行测试，以便在问题影响用户之前发现它们。虽然你可以将这种方法应用于负载测试，但如果测试是基于假设进行的，这种方法并不能真正帮助你。

然而，通过高保真度进行左移测试意味着你的预生产测试能够反映出生产工作负载实际施加的压力。这需要真实的数据，Grafana Cloud 可以为你提供这些数据，而 k6 则为你提供用于处理这些数据的测试框架。

_Grafana Cloud_ _是开始使用 k6 和性能测试的最简单方式。我们提供一个慷慨的永久免费层级，并为每种使用场景提供相应的计划。_ _立即免费注册！_

标签