企业官网建设流程全解析

Salt nightly-stress-test 工作流参数化：branch、OpenTelemetry 指标与 master worker 线程池的 CI 调优指南

【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt

Salt（SaltStack）通过其nightly-stress-test持续集成工作流对 master 进行高压并发压测，用于在夜间自动暴露事件洪泛、高频 Highstate、大文件传输下的性能回退与资源泄漏问题。本指南围绕3006.x分支nightly-stress-test.yml工作流的一次关键增强展开：新增必填的branch输入，并引入enable_metrics（OpenTelemetry 指标开关）与worker_threads（salt-master worker 线程池大小覆盖）两个可调输入。读完本文，你将掌握该工作流的三个输入参数的含义与协作方式、如何将其 dispatch 到任意分支，以及它们与仓库内tests/monitoring压测脚本、master.conf配置项的对应关系。

一、变更概览：一次针对 CI 压测可复用性的参数化改造

关联变更（changelog/70099.added.md）的核心内容可以概括为三件事：

1. branch成为必填输入：此前nightly-stress-test.yml工作流被硬绑定到3006.x分支；改造后调用方必须显式传入branch，工作流得以针对仓库中的任意分支（master、3006.x、其他维护分支或临时特性分支）触发相同的压测流程。
2. enable_metrics输入：允许运行者在压测开始前切换 OpenTelemetry 指标采集的开关，从而决定本轮压测是否同时采集并导出 OpenTelemetry 指标数据。
3. worker_threads输入：允许运行者覆盖 salt-master 的 worker 线程池大小，在压测开始前以不同的并发规模启动 master，用于对比不同 worker 配置下的吞吐与稳定性。

这三项输入共同解决了原工作流"只能跑 3006.x、指标和并发规模不可调"的僵化问题，让同一套压测流水线可以在任意分支、任意并发档位、是否开启指标观测的组合下重复执行，为性能回归对比提供了标准化的 CI 通道。

二、为什么需要分支参数化：压测环境的现实约束

Salt 的压测并非在空跑环境进行，而是需要一套包含 master、minion、事件系统、文件服务器和 Salt API 的完整拓扑。仓库中的 tests/monitoring/ 目录正是这套压测与观测环境的工程化落地，其 README.md 描述了由 Salt Master、两个 Minion、Prometheus 与 cAdvisor 构成的 Docker Compose 环境：

docker-compose up -d docker exec -it salt-master bash salt '*' test.ping # 验证 master/minion 通道

在这种环境下，一次完整的夜间压测会同时启动多路后台压力源（见 stress_test.sh）：

• 事件洪泛器flood_events.py以 1KB 载荷持续向 master 事件总线灌入stress/test/flood事件；
• 每 10 秒一轮的state.highstate --async全量 Highstate 循环；
• Runner（manage.status）、Wheel（salt-key -L）、Local（test.ping、grains.items）混合执行循环；
• 文件服务器压力（cp.cache_file拉取重型 Jinja 模板）；
• Salt API 压力循环（stress_api.sh 以 eauth=PAM 登录后高频调用client=local与client=runner）；
• 软件安装/卸载交替循环（state.apply heavy.software_install/software_remove）。

不同 Salt 分支（如3006.x与 master 开发线）在事件处理、MWorker 调度等核心路径上存在实现差异，压测结论不能跨分支直接套用。因此branch输入的价值在于：让同一套上述压测矩阵可以在任意分支的代码上重新执行，从而在分支合并前就拿到该分支自身的性能基线，而不是依赖"其他分支测过就算数"的间接推断。

三、branch输入：把工作流从分支绑定中解放出来

按照变更描述，branch为必填（required）输入。在 GitHub Actions 的workflow_dispatch语义下，这意味着使用方在手动触发该工作流时，必须显式选择目标分支，工作流内随后基于该分支检出代码并执行压测。典型的调用形态（示意，字段含义与变更一致）：

on: workflow_dispatch: inputs: branch: description: "Branch to run the nightly stress test against" required: true enable_metrics: description: "Toggle OpenTelemetry metrics collection" type: boolean default: false worker_threads: description: "Override salt-master worker pool size" type: number default: 10

需要说明的是，当前仓库中并未包含.github/workflows/nightly-stress-test.yml的工作流源文件，本变更的记录仅存在于 changelog/70099.added.md。上述 YAML 是根据变更语义还原的输入结构，实际字段类型（boolean/number）与默认值请以目标分支中真实工作流文件为准。

四、enable_metrics：用 OpenTelemetry 观测压测全程

enable_metrics输入控制的是压测开始前是否开启OpenTelemetry 指标（metrics）采集。将其做成开关而非常驻开启，理由在于：

• 观测成本可控：指标导出与抓取本身会消耗 CPU/网络资源，在压测场景中若始终开启，会污染对 master 纯性能表现的测量；
• 按需取证：当某轮压测出现吞吐回退或资源异常时，可单独开启指标重跑一轮，获得带观测数据的对照样本；
• 与既有监控体系互补：仓库的压测环境本就配有 Prometheus + Grafana 观测链路——prometheus.yml 定义抓取配置，salt_monitoring.json 预置了 Salt Monitoring 仪表盘，fd_exporter.py 从/proc采集各守护进程的 RSS 与文件描述符指标（对应salt_master_process_rss_bytes等时序），README.md 中给出了经典的内存泄漏排查查询：

container_memory_usage_bytes{container_label_com_docker_compose_service="salt-master"} # 或更精确的 RSS 指标： container_memory_rss{container_label_com_docker_compose_service="salt-master"}

OpenTelemetry 指标则从应用内部视角补充了这一观测链路，二者结合可以覆盖"容器外部资源视角 + master 进程内部遥测视角"两个层面。

五、worker_threads：在压测前覆盖 master 线程池规模

worker_threads对应 salt-master 配置项worker_threads，它决定 master 事件循环中用于处理请求的 MWorker 线程池大小。仓库内的压测 master 配置 tests/monitoring/master.conf 就是一份参考取值：

worker_threads: 10 worker_resource_backcount: 50 ipc_write_buffer: 104857600

其中worker_resource_backcount控制 worker 的资源回退计数，ipc_write_buffer设置 IPC 写缓冲（此处显式调大到 100MB，用于应对高频事件流的写压力）。worker_threads的合理取值取决于机器核心数与压测负载类型：线程池过小会在高并发事件洪泛时形成排队瓶颈，过大则会引入线程切换开销并放大内存占用。nightly-stress-test工作流新增的worker_threads输入，正是为了在压测前用环境变量或配置注入的方式覆盖默认值，从而支持：

• 同一分支在 5 / 10 / 20 等不同线程池规模下的吞吐对比；
• 线程池规模与事件洪泛速率（见 flood_events.py 中每事件 1KB 载荷、持续无限循环的灌入方式）之间的瓶颈定位；
• 确认 IPC 写缓冲（ipc_write_buffer）在特定 worker 规模下是否出现背压或 silent drop 类问题。

六、三个输入的协作方式与推荐用法

将三个输入组合使用，可以编排出一张覆盖多维度变量的压测矩阵：

建议的观测流程：先以enable_metrics=false跑出纯净基线；若发现异常（如 Highstate 返回变慢、事件积压），再开启指标并配合 Prometheus 的container_memory_rss与 fd_exporter 的进程级时序数据定位瓶颈；最后通过调整worker_threads验证线程池规模是否为影响因素。整个过程中branch始终指向被测分支，确保结论只对被测代码成立。

七、总结

nightly-stress-test工作流的这次增强，本质上是把 Salt 既有压测方法论（stress_test.sh 中的多路并发压力源 + Prometheus/Grafana 观测）正式参数化进了 CI：branch让压测可以针对任意分支复现，enable_metrics让 OpenTelemetry 观测按需开关，worker_threads让 master 并发规模成为可控变量。对于需要在多个维护分支间维持性能基线的 Salt 维护者或大规模部署团队，这套"分支可指定、指标可开关、并发可调档"的压测矩阵值得直接借鉴——它让性能问题从"事后发现"前移到"合入前暴露"。

【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt