Redpanda Connect AWS 基准测试框架基于 Terraform 的生产级 Bench 与 Soak 压测体系【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect导读benchmarking/aws是 Redpanda Connect 项目自带的 AWS 基准测试框架它在真实 AWS 基础设施专用的一次性账户上运行生产形态的基准benchmark与浸泡测试soak用于验证 postgres_cdc、mysql_cdc 等连接器在持续写负载、真实复制路径下的吞吐天花板与长时运行稳定性。读完本文你将掌握该框架的端到端流水线、Bench 与 Soak 两种运行画像的差异、场景 YAML 的完整字段含义、GitHub Actions 调度与/soakPR 对比机制以及从笔记本手动跑一次 bench 的全部命令与操作纪律。一、框架定位给连接器做生产形态的压力验证Redpanda Connect 的每个连接器connector在生产中面对的是真实数据库的持续变更流。短小的单元测试无法暴露只有长时间运行才会出现的缺陷——内存缓慢泄漏、静默停滞、日志/指标轮转 bug、复制槽状态异常。benchmarking/aws/README.md明确给出了这个目录的使命Production-shaped benchmarks and soak tests for Redpanda Connect connectors, run on real AWS infrastructure in a dedicated, disposable account.即生产形态真实 RDS、真实 Redpanda 集群、真实逻辑复制路径一次性账户用完即销毁成本可控。当前仓库内的这一子树包含框架核心以及postgres_cdc、mysql_cdc两个栈——它们是浸泡管线CON-179 R6所需的最小集合。README 同时说明sqlserver、oracle、mongodb、dynamodb、iceberg 等其他连接器栈位于原始开发 fork 中后续会各自带场景与测试以独立 PR 的形式并入。二、一次运行做了什么端到端六步流水线根据 README.md一条命令可以把一个场景 YAML 变成完整的压测实验Terraform 建环境VPC、runner EC2、load-gen负载生成EC2、3 节点 Redpanda 集群、源数据库RDS Postgres、结果桶results bucket构建并部署二进制从当前工作树构建redpanda-connect二进制暂存stage到 runner 主机对于/soakA/B 对比则通过--binary传入预构建的 base / pr 二进制种子数据 持续写入向真实源数据库施压持续写负载变更通过真实复制路径Postgres 为逻辑复制被连接器捕获测量broker 侧吞吐视为 ground truth、Connect 自身的滚动统计、/metrics抓取goroutines、RSS、GCsoak 运行还会按分钟向 CloudWatch 上报并派生 backlog 序列结果本地产出 JSON Markdownsoak 运行还会将结果归档到redpanda-connect-bench-soak-archive桶并写入soak-index条目自动拆除teardown 由 runner 的 deferred 逻辑执行孤儿清扫 Lambdaorphan-reaper作为兜底。整个流程由 runner/ 目录下的 Go 编排器驱动provision → stage → seed → sweep/soak → results → teardown它在 Taskfile.yml 中被封装成task aws:bench等命令。三、两种运行画像Bench 找天花板Soak 抓泄漏同一套基础设施支撑两种运行画像二者共享全部流水线区别只在负载形态与时长3.1 Bench短时最大负载 CPU 扫描场景postgres/orders-cdc.yaml目标在最大负载下做 CPU 扫描matrix.cpu_points: [1, 2, 4, 8]找到吞吐天花板手段保持持续重写目标150K writes/sec ≈ 180 MB/s让postgres_cdc输入——而非 producer——成为整个 CPU 扫描过程中的瓶颈每个扫描点之间TRUNCATE保持表大小有界。3.2 Soak长时温和负载耐力跑场景postgres/orders-soak.yaml、mysql/orders-soak.yaml标记soak: true目标以约10–15% 的天花板负载10K writes/sec ≈ 12 MB/s持续90 分钟夜间运行在单一 vCPU 点运行——这不是找天花板而是让短时最大负载扫描永远来不及暴露的 bug 类现形慢泄漏、静默停滞、凭据轮转窗口、增长中的 lag资源小实例即可postgres soak 用db.r6g.xlargec8g.xlarge注意引擎特定的下限如 RDS gp3 在 400 GB 以下禁止设置 provisioned IOPS/throughput。运行规则在 SOAK.md 中有完整操作手册先知道天花板再定 soak 速率——新增连接器进入轮换的第一步就是先跑或找到该连接器的标准 bench 扫描soak 测的是长时间的正确性不是吞吐。3.3 场景 YAML 解剖以 orders-cdc 为例orders-cdc.yaml的字段就是整个框架的配置语言值得逐段拆解区块关键字段含义与要点connector/stackpostgres_cdc/postgres被测试的连接器与对应 Terraform 栈infra.sourceinstance_class: db.r6g.4xlarge源库规格曾从 2xlarge 上调以消除 gp3 节流对 producer 侧的影响实测在 vCPU4 时 Connect 提升 73%storage_gb: 800、iops: 24000、storage_throughput: 1000保证 IOPS 预算与吞吐不成为混淆变量parameters.rds.logical_replication: 1、max_wal_senders: 20启用逻辑复制并放宽 WAL 发送者上限infra.runnerinstance_type: c8g.4xlargerunner 主机的实例类型datasetinitial_rows: 0、row_size_bytes: 1200、tables: [orders]、seeder: cdc-rows-postgres每个扫描点前 TRUNCATE 使种子无意义ensureTable仍会建表workloadwrite_rate_per_sec: 150000、duration: 15m、warmup: 2m写入速率、时长、预热期pipeline.inputdsn: ${POSTGRES_DSN}、tls.skip_cert_verify: trueDSN 由环境变量注入RDS 内部 CA 不在 runner 镜像中且postgres_cdc使用NewTLSField无enabled开关stream_snapshot: false、schema: public、tables: [orders]、slot_name: bench_slot不流式快照只捕获增量复制槽固定命名batching.count: 5000、batching.period: 1s批量攒批配置matrixcpu_points: [1, 2, 4, 8]CPU 扫描点reset两条 SQL见下文reset区块是保证测量正确性的关键orders-cdc.yaml中的两条 SQL 每条都有明确事故背景-- 释放 WAL 游标让下一个扫描点从当前位置开始 SELECT pg_drop_replication_slot(bench_slot) FROM pg_replication_slots WHERE slot_namebench_slot; -- 保持表大小有界避免 Trap 3桶-1 曾踩过 TRUNCATE TABLE orders;3.4 soak 场景的差异点与事故驱动的配置速率与时长write_rate_per_sec: 10000、duration: 90m、warmup: 5m、cpu_points: [2]约 10–15% 的天花板gp3 存储下限RDS gp3 在 400 GB 以下只有固定基线3000 IOPS / 125 MiB/s且根本不允许设置 iops/throughput≥400 GB 时基线为 12000 / 500 且这是合法最小值。场景注释中记录了实测200 GB 6000 IOPS 会报InvalidParameterCombination因此 soak 用 400 GB / 12000 / 500 这一最便宜的合法形状mysql soak 的特殊配置mysql/orders-soak.yaml参数组需binlog_format: ROW、binlog_row_image: FULLmysql_cdc 必需、binlog_checksum: NONE保持 go-mysql 跨版本兼容mysql_cdc需要缓存资源做 binlog 位点检查点soak 特意用内存缓存测量的是单一不间断进程stream_snapshot: false时重启也只会从当前位点继续checkpoint_limit: 10000必须 ≥batching.count5000——默认 1024 会在无待处理数据时放行超大批次把管线串行化成每个 produceack 往返恰好一个 5000 行批次在途reset 中CALL mysql.rds_set_configuration(binlog retention hours, 24)RDS 一旦备份完就会清理 binlog 文件若中途重连超过了清理点检查点位点丢失会以 ERROR 1236 崩溃——这是与连接器 bug 无法区分的基建伪影所以每个会话都要设置postgres soak 的 publication 陷阱reset 中额外执行DROP PUBLICATION IF EXISTS pglog_stream_bench_slot。因为一个存在但已不含该表的陈旧 publication 会让postgres_cdc永远静默流不出数据2026-08-12 实测命中空pglog_stream_bench_slot、0 msg/s、活动槽、18 GB WAL 滞后、零报错publication 名规则为pglog_stream_slot_name。四、调度与 PR 触发GitHub Actions 工作流两个工作流覆盖定时浸泡与合并前对比两种节奏都通过GitHub OIDC认证无存储密钥企业 license 从 Secrets Manager 拉取REDPANDA_LICENSE_SECRET: redpanda-connect-bench/license不会出现在仓库或 workflow secrets 中。4.1 夜间浸泡 soak_nightly.yml调度cron10 8 * * *08:10 UTC避开整点调度高峰仅在默认分支生效功能分支上只能通过workflow_dispatch手动触发轮换矩阵schedule 触发时浸泡列表中每个场景当前为postgres/orders-soak、mysql/orders-soak矩阵max-parallel: 1同时只能一个 bench、fail-fast: false一个连接器红了不影响其他场景继续泡手动 dispatch 只跑输入指定的场景change-gated仅 schedule对比 HEAD 与该场景最后一次 soak-index 条目中的build_sha覆盖internal cmd public go.mod go.sum benchmarking .github/workflowspublic也在 pathspec 中因为cmd/redpanda-connect会导入public/schema与public/components无相关变更则跳过并写入 step summary。失败即放行fails open无历史条目、无 SHA 或 SHA 不可识别都视为运行安全细节scenario 输入先在 plan job 用正则^[A-Za-z0-9][A-Za-z0-9_-]*(/[A-Za-z0-9][A-Za-z0-9_-]*)*$全串匹配做 allowlistsoak job 内再做一次防御性复检——防止把一次 dispatch 扇形成 N 个付费 joba,b注入或引号导致晦涩的 strategy 错误用 bash[[ ~ ]]而非echo | grep避免多行值按行放行后向$GITHUB_OUTPUT写入攻击者控制的行teardown 验证if: always()的步骤用 EC2/RDS 查询确认账户干净EC2 按tag:Projectredpanda-connect-bench 状态过滤RDS 按rpcn-bench前缀过滤避免无关资源造成误报运行日志作为 artifact 保留 30 天事故驱动的细节运行步骤显式shell: bash开启 pipefail——2026-08-17 的失败运行terraform apply 失败但 job 显示成功就是因为默认 shell 无 pipefailtask ... | tee返回的是 tee 的退出码。4.2 PR 对比 soak_pr.yml在 PR 上评论/soak需 write 权限即可触发 base-vs-PR 的 A/B同一套基础设施上分别运行 base 构建与 PR 构建的二进制唯一变量就是二进制结果以 sticky comment 形式回帖。对应的 postgres/orders-soak-pr.yaml 展示了 A/B 场景的写法matrix: cpu_points: [2] # 两个臂只允许在二进制上不同——runner 对 soak A/B 强制执行这一点 arms: - id: base binary: base - id: pr binary: pr该场景刻意与夜间场景命名不同CloudWatch 指标落在没有告警匹配的独立序列且 runner 跳过滚动基线比较器与 soak-index 写入——一次刻意的 A/B 不是夜间基线样本。每臂 30 分钟让整个/soak回合控制在 ~2.5 小时内同时足够让泄漏斜率与停滞从噪声中分离出来。五、从笔记本手动运行命令手册所有命令都在benchmarking/aws下通过 Taskfile.yml 暴露。注意 runner 是独立 Go module其 AWS SDK 依赖不能进入仓库根模块所以不能从仓库根go runTaskfile 用go build到临时目录再运行# 一次性每账户持久化栈看板、告警、reaper、OIDC、归档桶 license 密钥 cd benchmarking/aws task aws:persistent # 会自己构建 cleanup-lambda/bootstrap.zip # 校验场景不产生 AWS 花费 task aws:validate scenariopostgres/orders-cdc # 跑一次 bench约 25 分钟基础设施 扫描约 $2-3 aws-vault exec profile -- env REDPANDA_LICENSE_FILEPATHpath \ task aws:bench scenariopostgres/orders-cdc # 在失败/保留的运行后拆除基础设施 task aws:down scenariopostgres/orders-cdc配套任务task aws:cost-check查询 AWS Cost Explorer 中 bench 项目当日/7 天/本月花费task aws:summary重新生成 docs/benchmark-results/SUMMARY.md 中自动维护的 AWS 部分task aws:test运行本模块单元测试独立 module不归仓库根的task test管task aws:tf-clean清理terraform/下的.terraform/缓存与 lock 文件后端或 provider 配置变化导致 init 混乱时使用。六、血的教训操作纪律每一条都对应一次真实事故README 与 SOAK.md 反复强调以下规则每条背后都曾有真实 incident同时只能有一个 bench所有会话共享同一个 Terraform state 与栈runner 的 pre-flight 在存在 bench EC2 时会拒绝启动--preflightoff是带有强烈警告的覆盖开关。这跨机器生效——笔记本跑的和定时 soak 会互相冲突凭据必须比运行活得久aws-vault exec的静态凭据约 1 小时后失效曾因此毁掉两次笔记本驱动的 soak优先用工作流或使用 SSO 会话型 profile。工作流侧用role-duration-seconds: 144004 小时覆盖约 2h20m 的运行Ctrl-C 只能按一次第二、三次中断会杀掉 deferred teardown留下孤儿资源日志行不是 teardown 证明必须用 EC2/RDS 查询验证工作流自动做这件事从 git worktree 运行如果你可能在拆除前切换分支不要用普通 checkout。七、孤儿清理reaper Lambda 兜底cleanup-lambda/ 是一个独立的 Go module由持久化栈部署每 15 分钟扫描一次销毁任何Projectredpanda-connect-bench且存在超过4 小时的 EC2/RDS/S3/IAM 资源。关键设计它刻意放在会话栈之外——安全网不能和它守护的对象共享生命周期。一个合法超过 4 小时的运行需要先停掉规则再跑aws events disable-rule --name redpanda-connect-bench-orphan-cleanup # ... 跑完记得重新启用设个提醒 aws events enable-rule --name redpanda-connect-bench-orphan-cleanupreaper 的通知经由 cleanup-lambda/sweep.go 的自定义通知信封发出Chatbot 会静默丢弃纯 SNS 文本必须保留这个信封。持久化栈本身因使用独立的 Project 标签而豁免。八、目录布局速查路径角色runner/Go 编排器provision → stage → seed → sweep/soak → results → teardown核心在 main.go、matrix.go、cloudwatch.goscenarios/bench soak PR 对比场景postgres、mysql 各 3 份 YAMLseeders/cdc-rows-postgres、cdc-rows-mysql写负载生成器terraform/shared每会话的 VPC、主机、broker、结果桶terraform/stacks/每会话的 RDS Postgres / RDS MySQLterraform/modules/rds-postgres、rds-mysql、redpanda 等可复用模块terraform/persistent/只应用一次看板、告警、OIDC、reaper、归档桶、Slackcleanup-lambda/孤儿 reaper独立 Go moduleSOAK.mdsoak 操作手册runbookgrafana/soak-dashboard.json可导入的 Grafana 看板九、持久化栈看板、告警、基线比较与 Slack 通知terraform/persistent/只应用一次不属于每次运行的会话生命周期aws:down永远不会拆除它看板 告警main.tf的soak_scenarios变量与alarms.tf为每个场景生成 1 个看板 3 个告警stall / rss-slope / backlog全部汇入 SNS 主题redpanda-connect-bench-soak-alertsSlack 投递slack.tf提交了 workspace/channel ID 作为默认值Slack 是唯一由 Terraform 管理的投递通道——把 ID 置空会让 validation 失败而不是悄悄把主题变成无路由状态。普通task aws:persistent即可保持 Slack 接通三级告警通道运行中的告警是急性通道夜间工作流变红是构建之间的通道/soak评论是合并前的通道归档与滚动基线结果写入redpanda-connect-bench-soak-archive桶soak-index/目录喂给滚动基线比较器——少于 3 次运行条目时仅咨询advisory之后当吞吐 基线的 85% 或 RSS 基线的 130% 时判定 job 失败Grafanasoak-dashboard.json 是基于同一批 CloudWatch 指标的可导入看板connector/scenario 模板下拉、内嵌告警阈值、CloudWatch 告警注解导入时需要账户 605419575229 的 CloudWatch 数据源通过 contenteditable="false">【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Redpanda Connect AWS 基准测试框架：基于 Terraform 的生产级 Bench 与 Soak 压测体系
Redpanda Connect AWS 基准测试框架基于 Terraform 的生产级 Bench 与 Soak 压测体系【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect导读benchmarking/aws是 Redpanda Connect 项目自带的 AWS 基准测试框架它在真实 AWS 基础设施专用的一次性账户上运行生产形态的基准benchmark与浸泡测试soak用于验证 postgres_cdc、mysql_cdc 等连接器在持续写负载、真实复制路径下的吞吐天花板与长时运行稳定性。读完本文你将掌握该框架的端到端流水线、Bench 与 Soak 两种运行画像的差异、场景 YAML 的完整字段含义、GitHub Actions 调度与/soakPR 对比机制以及从笔记本手动跑一次 bench 的全部命令与操作纪律。一、框架定位给连接器做生产形态的压力验证Redpanda Connect 的每个连接器connector在生产中面对的是真实数据库的持续变更流。短小的单元测试无法暴露只有长时间运行才会出现的缺陷——内存缓慢泄漏、静默停滞、日志/指标轮转 bug、复制槽状态异常。benchmarking/aws/README.md明确给出了这个目录的使命Production-shaped benchmarks and soak tests for Redpanda Connect connectors, run on real AWS infrastructure in a dedicated, disposable account.即生产形态真实 RDS、真实 Redpanda 集群、真实逻辑复制路径一次性账户用完即销毁成本可控。当前仓库内的这一子树包含框架核心以及postgres_cdc、mysql_cdc两个栈——它们是浸泡管线CON-179 R6所需的最小集合。README 同时说明sqlserver、oracle、mongodb、dynamodb、iceberg 等其他连接器栈位于原始开发 fork 中后续会各自带场景与测试以独立 PR 的形式并入。二、一次运行做了什么端到端六步流水线根据 README.md一条命令可以把一个场景 YAML 变成完整的压测实验Terraform 建环境VPC、runner EC2、load-gen负载生成EC2、3 节点 Redpanda 集群、源数据库RDS Postgres、结果桶results bucket构建并部署二进制从当前工作树构建redpanda-connect二进制暂存stage到 runner 主机对于/soakA/B 对比则通过--binary传入预构建的 base / pr 二进制种子数据 持续写入向真实源数据库施压持续写负载变更通过真实复制路径Postgres 为逻辑复制被连接器捕获测量broker 侧吞吐视为 ground truth、Connect 自身的滚动统计、/metrics抓取goroutines、RSS、GCsoak 运行还会按分钟向 CloudWatch 上报并派生 backlog 序列结果本地产出 JSON Markdownsoak 运行还会将结果归档到redpanda-connect-bench-soak-archive桶并写入soak-index条目自动拆除teardown 由 runner 的 deferred 逻辑执行孤儿清扫 Lambdaorphan-reaper作为兜底。整个流程由 runner/ 目录下的 Go 编排器驱动provision → stage → seed → sweep/soak → results → teardown它在 Taskfile.yml 中被封装成task aws:bench等命令。三、两种运行画像Bench 找天花板Soak 抓泄漏同一套基础设施支撑两种运行画像二者共享全部流水线区别只在负载形态与时长3.1 Bench短时最大负载 CPU 扫描场景postgres/orders-cdc.yaml目标在最大负载下做 CPU 扫描matrix.cpu_points: [1, 2, 4, 8]找到吞吐天花板手段保持持续重写目标150K writes/sec ≈ 180 MB/s让postgres_cdc输入——而非 producer——成为整个 CPU 扫描过程中的瓶颈每个扫描点之间TRUNCATE保持表大小有界。3.2 Soak长时温和负载耐力跑场景postgres/orders-soak.yaml、mysql/orders-soak.yaml标记soak: true目标以约10–15% 的天花板负载10K writes/sec ≈ 12 MB/s持续90 分钟夜间运行在单一 vCPU 点运行——这不是找天花板而是让短时最大负载扫描永远来不及暴露的 bug 类现形慢泄漏、静默停滞、凭据轮转窗口、增长中的 lag资源小实例即可postgres soak 用db.r6g.xlargec8g.xlarge注意引擎特定的下限如 RDS gp3 在 400 GB 以下禁止设置 provisioned IOPS/throughput。运行规则在 SOAK.md 中有完整操作手册先知道天花板再定 soak 速率——新增连接器进入轮换的第一步就是先跑或找到该连接器的标准 bench 扫描soak 测的是长时间的正确性不是吞吐。3.3 场景 YAML 解剖以 orders-cdc 为例orders-cdc.yaml的字段就是整个框架的配置语言值得逐段拆解区块关键字段含义与要点connector/stackpostgres_cdc/postgres被测试的连接器与对应 Terraform 栈infra.sourceinstance_class: db.r6g.4xlarge源库规格曾从 2xlarge 上调以消除 gp3 节流对 producer 侧的影响实测在 vCPU4 时 Connect 提升 73%storage_gb: 800、iops: 24000、storage_throughput: 1000保证 IOPS 预算与吞吐不成为混淆变量parameters.rds.logical_replication: 1、max_wal_senders: 20启用逻辑复制并放宽 WAL 发送者上限infra.runnerinstance_type: c8g.4xlargerunner 主机的实例类型datasetinitial_rows: 0、row_size_bytes: 1200、tables: [orders]、seeder: cdc-rows-postgres每个扫描点前 TRUNCATE 使种子无意义ensureTable仍会建表workloadwrite_rate_per_sec: 150000、duration: 15m、warmup: 2m写入速率、时长、预热期pipeline.inputdsn: ${POSTGRES_DSN}、tls.skip_cert_verify: trueDSN 由环境变量注入RDS 内部 CA 不在 runner 镜像中且postgres_cdc使用NewTLSField无enabled开关stream_snapshot: false、schema: public、tables: [orders]、slot_name: bench_slot不流式快照只捕获增量复制槽固定命名batching.count: 5000、batching.period: 1s批量攒批配置matrixcpu_points: [1, 2, 4, 8]CPU 扫描点reset两条 SQL见下文reset区块是保证测量正确性的关键orders-cdc.yaml中的两条 SQL 每条都有明确事故背景-- 释放 WAL 游标让下一个扫描点从当前位置开始 SELECT pg_drop_replication_slot(bench_slot) FROM pg_replication_slots WHERE slot_namebench_slot; -- 保持表大小有界避免 Trap 3桶-1 曾踩过 TRUNCATE TABLE orders;3.4 soak 场景的差异点与事故驱动的配置速率与时长write_rate_per_sec: 10000、duration: 90m、warmup: 5m、cpu_points: [2]约 10–15% 的天花板gp3 存储下限RDS gp3 在 400 GB 以下只有固定基线3000 IOPS / 125 MiB/s且根本不允许设置 iops/throughput≥400 GB 时基线为 12000 / 500 且这是合法最小值。场景注释中记录了实测200 GB 6000 IOPS 会报InvalidParameterCombination因此 soak 用 400 GB / 12000 / 500 这一最便宜的合法形状mysql soak 的特殊配置mysql/orders-soak.yaml参数组需binlog_format: ROW、binlog_row_image: FULLmysql_cdc 必需、binlog_checksum: NONE保持 go-mysql 跨版本兼容mysql_cdc需要缓存资源做 binlog 位点检查点soak 特意用内存缓存测量的是单一不间断进程stream_snapshot: false时重启也只会从当前位点继续checkpoint_limit: 10000必须 ≥batching.count5000——默认 1024 会在无待处理数据时放行超大批次把管线串行化成每个 produceack 往返恰好一个 5000 行批次在途reset 中CALL mysql.rds_set_configuration(binlog retention hours, 24)RDS 一旦备份完就会清理 binlog 文件若中途重连超过了清理点检查点位点丢失会以 ERROR 1236 崩溃——这是与连接器 bug 无法区分的基建伪影所以每个会话都要设置postgres soak 的 publication 陷阱reset 中额外执行DROP PUBLICATION IF EXISTS pglog_stream_bench_slot。因为一个存在但已不含该表的陈旧 publication 会让postgres_cdc永远静默流不出数据2026-08-12 实测命中空pglog_stream_bench_slot、0 msg/s、活动槽、18 GB WAL 滞后、零报错publication 名规则为pglog_stream_slot_name。四、调度与 PR 触发GitHub Actions 工作流两个工作流覆盖定时浸泡与合并前对比两种节奏都通过GitHub OIDC认证无存储密钥企业 license 从 Secrets Manager 拉取REDPANDA_LICENSE_SECRET: redpanda-connect-bench/license不会出现在仓库或 workflow secrets 中。4.1 夜间浸泡 soak_nightly.yml调度cron10 8 * * *08:10 UTC避开整点调度高峰仅在默认分支生效功能分支上只能通过workflow_dispatch手动触发轮换矩阵schedule 触发时浸泡列表中每个场景当前为postgres/orders-soak、mysql/orders-soak矩阵max-parallel: 1同时只能一个 bench、fail-fast: false一个连接器红了不影响其他场景继续泡手动 dispatch 只跑输入指定的场景change-gated仅 schedule对比 HEAD 与该场景最后一次 soak-index 条目中的build_sha覆盖internal cmd public go.mod go.sum benchmarking .github/workflowspublic也在 pathspec 中因为cmd/redpanda-connect会导入public/schema与public/components无相关变更则跳过并写入 step summary。失败即放行fails open无历史条目、无 SHA 或 SHA 不可识别都视为运行安全细节scenario 输入先在 plan job 用正则^[A-Za-z0-9][A-Za-z0-9_-]*(/[A-Za-z0-9][A-Za-z0-9_-]*)*$全串匹配做 allowlistsoak job 内再做一次防御性复检——防止把一次 dispatch 扇形成 N 个付费 joba,b注入或引号导致晦涩的 strategy 错误用 bash[[ ~ ]]而非echo | grep避免多行值按行放行后向$GITHUB_OUTPUT写入攻击者控制的行teardown 验证if: always()的步骤用 EC2/RDS 查询确认账户干净EC2 按tag:Projectredpanda-connect-bench 状态过滤RDS 按rpcn-bench前缀过滤避免无关资源造成误报运行日志作为 artifact 保留 30 天事故驱动的细节运行步骤显式shell: bash开启 pipefail——2026-08-17 的失败运行terraform apply 失败但 job 显示成功就是因为默认 shell 无 pipefailtask ... | tee返回的是 tee 的退出码。4.2 PR 对比 soak_pr.yml在 PR 上评论/soak需 write 权限即可触发 base-vs-PR 的 A/B同一套基础设施上分别运行 base 构建与 PR 构建的二进制唯一变量就是二进制结果以 sticky comment 形式回帖。对应的 postgres/orders-soak-pr.yaml 展示了 A/B 场景的写法matrix: cpu_points: [2] # 两个臂只允许在二进制上不同——runner 对 soak A/B 强制执行这一点 arms: - id: base binary: base - id: pr binary: pr该场景刻意与夜间场景命名不同CloudWatch 指标落在没有告警匹配的独立序列且 runner 跳过滚动基线比较器与 soak-index 写入——一次刻意的 A/B 不是夜间基线样本。每臂 30 分钟让整个/soak回合控制在 ~2.5 小时内同时足够让泄漏斜率与停滞从噪声中分离出来。五、从笔记本手动运行命令手册所有命令都在benchmarking/aws下通过 Taskfile.yml 暴露。注意 runner 是独立 Go module其 AWS SDK 依赖不能进入仓库根模块所以不能从仓库根go runTaskfile 用go build到临时目录再运行# 一次性每账户持久化栈看板、告警、reaper、OIDC、归档桶 license 密钥 cd benchmarking/aws task aws:persistent # 会自己构建 cleanup-lambda/bootstrap.zip # 校验场景不产生 AWS 花费 task aws:validate scenariopostgres/orders-cdc # 跑一次 bench约 25 分钟基础设施 扫描约 $2-3 aws-vault exec profile -- env REDPANDA_LICENSE_FILEPATHpath \ task aws:bench scenariopostgres/orders-cdc # 在失败/保留的运行后拆除基础设施 task aws:down scenariopostgres/orders-cdc配套任务task aws:cost-check查询 AWS Cost Explorer 中 bench 项目当日/7 天/本月花费task aws:summary重新生成 docs/benchmark-results/SUMMARY.md 中自动维护的 AWS 部分task aws:test运行本模块单元测试独立 module不归仓库根的task test管task aws:tf-clean清理terraform/下的.terraform/缓存与 lock 文件后端或 provider 配置变化导致 init 混乱时使用。六、血的教训操作纪律每一条都对应一次真实事故README 与 SOAK.md 反复强调以下规则每条背后都曾有真实 incident同时只能有一个 bench所有会话共享同一个 Terraform state 与栈runner 的 pre-flight 在存在 bench EC2 时会拒绝启动--preflightoff是带有强烈警告的覆盖开关。这跨机器生效——笔记本跑的和定时 soak 会互相冲突凭据必须比运行活得久aws-vault exec的静态凭据约 1 小时后失效曾因此毁掉两次笔记本驱动的 soak优先用工作流或使用 SSO 会话型 profile。工作流侧用role-duration-seconds: 144004 小时覆盖约 2h20m 的运行Ctrl-C 只能按一次第二、三次中断会杀掉 deferred teardown留下孤儿资源日志行不是 teardown 证明必须用 EC2/RDS 查询验证工作流自动做这件事从 git worktree 运行如果你可能在拆除前切换分支不要用普通 checkout。七、孤儿清理reaper Lambda 兜底cleanup-lambda/ 是一个独立的 Go module由持久化栈部署每 15 分钟扫描一次销毁任何Projectredpanda-connect-bench且存在超过4 小时的 EC2/RDS/S3/IAM 资源。关键设计它刻意放在会话栈之外——安全网不能和它守护的对象共享生命周期。一个合法超过 4 小时的运行需要先停掉规则再跑aws events disable-rule --name redpanda-connect-bench-orphan-cleanup # ... 跑完记得重新启用设个提醒 aws events enable-rule --name redpanda-connect-bench-orphan-cleanupreaper 的通知经由 cleanup-lambda/sweep.go 的自定义通知信封发出Chatbot 会静默丢弃纯 SNS 文本必须保留这个信封。持久化栈本身因使用独立的 Project 标签而豁免。八、目录布局速查路径角色runner/Go 编排器provision → stage → seed → sweep/soak → results → teardown核心在 main.go、matrix.go、cloudwatch.goscenarios/bench soak PR 对比场景postgres、mysql 各 3 份 YAMLseeders/cdc-rows-postgres、cdc-rows-mysql写负载生成器terraform/shared每会话的 VPC、主机、broker、结果桶terraform/stacks/每会话的 RDS Postgres / RDS MySQLterraform/modules/rds-postgres、rds-mysql、redpanda 等可复用模块terraform/persistent/只应用一次看板、告警、OIDC、reaper、归档桶、Slackcleanup-lambda/孤儿 reaper独立 Go moduleSOAK.mdsoak 操作手册runbookgrafana/soak-dashboard.json可导入的 Grafana 看板九、持久化栈看板、告警、基线比较与 Slack 通知terraform/persistent/只应用一次不属于每次运行的会话生命周期aws:down永远不会拆除它看板 告警main.tf的soak_scenarios变量与alarms.tf为每个场景生成 1 个看板 3 个告警stall / rss-slope / backlog全部汇入 SNS 主题redpanda-connect-bench-soak-alertsSlack 投递slack.tf提交了 workspace/channel ID 作为默认值Slack 是唯一由 Terraform 管理的投递通道——把 ID 置空会让 validation 失败而不是悄悄把主题变成无路由状态。普通task aws:persistent即可保持 Slack 接通三级告警通道运行中的告警是急性通道夜间工作流变红是构建之间的通道/soak评论是合并前的通道归档与滚动基线结果写入redpanda-connect-bench-soak-archive桶soak-index/目录喂给滚动基线比较器——少于 3 次运行条目时仅咨询advisory之后当吞吐 基线的 85% 或 RSS 基线的 130% 时判定 job 失败Grafanasoak-dashboard.json 是基于同一批 CloudWatch 指标的可导入看板connector/scenario 模板下拉、内嵌告警阈值、CloudWatch 告警注解导入时需要账户 605419575229 的 CloudWatch 数据源通过 contenteditable="false">【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
![DS2API引用标记替换原理：[citation:N]→Markdown链接完整算法](http://pic.xiahunao.cn/yaotu/DS2API引用标记替换原理：[citation:N]→Markdown链接完整算法)
