Agent Substrate 遥测容量测试一篇讲清OTel Collector 压力评估完整方法【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrateAgent Substrate 是一个安全优先的智能体执行运行时agent substrate专为高密度沙箱场景设计。围绕它的遥测容量测试telemetry capacity testing体系可以一次性回答两个关键问题系统到底发出多少遥测以及这些遥测给 OTel Collector 带来多大压力。本文带你完整看懂它的场景阶梯、流量计量器Telemetry Meter和压力评估的判定标准——无需自己拼凑压测工具仓库里的 benchmarking/ 目录已经准备好了全套方案。 一、遥测容量测试为什么重要在大规模 Agent 系统中OTel Collector 是所有遥测traces / metrics / logs的汇聚点。它一旦被压垮会出现两类静默的数据丢失Collector 侧丢弃队列写满、内存超限数据直接被拒客户端侧丢弃SDK 本地队列溢出queue_full数据根本没发出去。更隐蔽的是客户端丢弃看起来和遥测量平稳一模一样。Agent Substrate 的遥测容量测试体系就是为了让这类问题无处遁形它把加载压测 → 计量遥测 → 判定容量沉淀为一条可复现的流水线覆盖从空闲基线到长时间浸泡soak的完整场景。 核心理念容量结论不靠猜测靠测量。每个版本的仪表都会变化仓库因此只保留方法、不固化结果数字见 benchmarking/observability.md 开头的说明。 二、测试体系全景三层工具链整个体系由三层组成各司其职层次职责关键位置️ 负载生成Locust 编排 Go 负载器 boomer / 消耗型负载 gluttonbenchmarking/locust/、internal/benchmarking/boomer/、internal/benchmarking/glutton/ 遥测计量Telemetry Meter旁路流量表按服务计数benchmarking/telemetry/meter.yaml 结果读取Prometheus 抓取 现成 PromQL 查询表benchmarking/monitoring.yaml配套的容量模型与部署选型指南体积模型、Deployment vs DaemonSet 决策单独成文docs/dev/best-practices/otel-collector.md。 三、四步场景阶梯S0–S3 一次跑完整个扫描场景阶梯scenario ladder定义在 benchmarking/automation/tests.yaml 中四个以observability_开头的测试构成完整的容量扫描编号测试时长做什么S0observability_s0_idle_floor5 分钟无负载测空闲控制面的遥测地板S1observability_s1_user_sweep每步 3 分钟并发用户 5 → 10 → 15 递增采样率 0.1S2observability_s2_sample_rate_sweep每步 3 分钟10 用户不变采样率 0 → 0.1 → 1.0S3observability_s3_soak10 分钟12 用户S1 峰值的 80%长时间浸泡三条值得新手记住的设计细节每一步不少于 3 分钟。指标推送间隔是 60 秒短于 3 分钟的步骤凑不满 3 个数据点无法区分趋势和噪声S1 的上限是 15 用户而非更多。因为压测池是 10 个 worker再往上测到的是调度器排队时间不是遥测本身。想更高就同步调大workerCount负载来自 boomerGo 工作器而非 Python。Python 与 gRPC 在高并发下会互相拖累让压测器自己的延迟混进测量结果。阶梯的爬楼行为由 benchmarking/locust/shapes/ladder_shape.py 驱动一次运行完成整个扫描只需部署一次、采集一份基线。 四、Telemetry Meter给遥测装上一台流量计托管 Collector 只上报自己的自指标看不出每个服务各发了多少数据。Agent Substrate 的解法是一个旁路 Collector——Meter配置见 benchmarking/telemetry/meter.yamlkubectl apply -f benchmarking/telemetry/meter.yaml METERhttp://telemetry-meter.benchmarking.svc.cluster.local:4317 ./hack/install-ate.sh --deploy-ate-system --otlp-endpoint ${METER}Meter 是一个tee分支器先按service.name计数 spans 和数据点再把数据原样转发给托管 Collector。一次运行因此同时得到两份测量——各服务的遥测量来自 Meter和这份负载的成本来自托管 Collector。读数通过 Prometheus 完成配置benchmarking/monitoring.yaml常用查询想知道什么查询各服务 spans/秒sum by (service_name) (rate(substrate_spans_total[5m]))各服务数据点/分钟60 * sum by (service_name) (rate(substrate_datapoints_total[5m]))数据是否到达sum(rate(otelcol_receiver_accepted_spans[5m]))Collector 是否拒收sum(rate(otelcol_receiver_refused_spans[5m]))⚠️三个使用 Meter 的隐藏陷阱详见 benchmarking/telemetry/README.md转发后数据会被归属到 Meter 本身按 pod 分组会失真——要按 resource 里的service.name分组tee 后只剩一个大批发送方连接粘性的负载分布效应会消失Meter 自己是单副本它也可能先成为瓶颈。所以要把refused、queue_size等指标也加进判定标准。此外Meter 只能看到到达的数据。要看客户端是否本地丢弃需打开 SDK 的可观测开关如OTEL_GO_X_OBSERVABILITYtrue再读otel_sdk_processor_span_processed_total{error_typequeue_full}这类计数器。 本地 kind 集群则不需要Meter自带的 Collectormanifests/ate-install/kind/otel-collector.yaml内置了同样的计数连接器install-ate-kind.sh还会顺手装好 Prometheus。✅ 五、压力评估的 6 个判定标准跑完一轮怎么判断Collector 扛住了benchmarking/observability.md 给出了明确的通过标准#指标标准含义1otelcol_receiver_refused_*必须为 0Collector 未拒收数据2otelcol_exporter_enqueue_failed_*必须为 0下游导出队列未写满3客户端queue_full必须为 0数据不在源头丢失4Collector 副本数低于maxReplicas弹性扩容未被打满5S3 中 working set 与otelcol_exporter_queue_size的斜率趋近于 0浸泡期内无持续增长6otelcol_receiver_accepted_*阳性对照必须大于 0确认数据真的在流动两条容易被忽略的读数技巧内存要看 working set不要用kubectl top——后者是窗口平均值会掩盖短促峰值⚖️deltatocumulative超限是无声故障超过max_streams后新流被直接丢弃、连日志都不打。要全程盯住otelcol_deltatocumulative_datapoints{errorlimit}为 0、且streams_tracked / streams_limit低于 1。第 6 条阳性对照最关键一个什么都不发的导出器和一个完美运行的导出器在纯负向指标上长得一模一样。⚖️ 六、遥测量体积模型两条独立的轴容量评估不能只盯压测数字。docs/dev/best-practices/otel-collector.md 给出了 Substrate 遥测量的体积模型——两个驱动因素沿不同轴增长Metrics 随运行中的组件数增长与业务负载量关系不大datapoints/min ≈ nodes×atelet ateapi副本×ateapi router副本×router worker_pods×ateom 已插桩 actors×actorTraces 随操作速率增长spans/sec ≈ (生命周期操作/秒 请求/秒) × P(root被采样) × 每操作span数采样默认值采用ParentBasedateapi、atelet、ateom-*为 0.1atenet-router与 Envoy 为 0.01见 internal/serverboot/serverboot.go 的初始化逻辑。由此得出两条实操规则组件多的集群瓶颈在 metrics负载重的集群瓶颈在 traces——取两者中更大的那个来定容Collector 吃紧时优先降低 trace 采样率而不是加机器。️ 七、部署选型Deployment 还是 DaemonSet这是新手最容易问错的问题吞吐量到多少该换成 DaemonSet 官方答案很干脆吞吐量是错的坐标轴。真正的限制变量是集群里的 pod 数量——因为它决定了k8sattributes缓存的大小部署模式每实例缓存集群变大时DeploymentO(全集群 pod 数)无上限增长HPA 无法化解DaemonSet 节点作用域过滤O(本节点 pod 数)有界因为节点 pod 数天然有限正确的决策顺序是是否需要 trace 完整性处理尾采样要求一条 trace 的所有 span 落在同一实例DaemonSet 会破坏这一点——这一条常常直接定胜负数集群 pod 数测量每个副本内存随 pod 数的增长曲线找到自己的拐点最后才看节点内的遥测集中度。⚠️ 特别提醒DaemonSet 方案必须配合node_from_env_var作用域过滤官方 DaemonSet 清单里已内置否则每个节点都会缓存全集群元数据反而更差。 八、快速上手本地 kind 一键测量没有 GKE 也没关系kind 集群就是现成的遥测量测量环境hack/create-kind-cluster.sh hack/install-ate-kind.sh --deploy-ate-system # 自动装好 Collector Prometheus kubectl port-forward -n otel-system svc/prometheus 9090:9090然后打开 Prometheus用上面四、遥测计量里的查询表读数即可。kind 的差异只有两点命名空间是otel-system而非benchmarking、指标推送间隔是 10 秒查询窗口用[1m]就够。 注意kind 单节点、单副本、无 HPA只能测量测不出成本——内存和副本数结论不能外推到真实集群成本类评估要放到 GKE 上跑 Meter。 九、延伸阅读与文件清单docs/observability.md — Actor 可观测性模型跨 suspend/resume 的日志、指标与追踪docs/dev/best-practices/otel-collector.md — Collector 部署最佳实践GKE 托管 / DaemonSet / kind 三种拓扑benchmarking/observability.md — 场景阶梯与判定标准本文第三、五节出处benchmarking/telemetry/README.md — Meter 安装、读数与陷阱清单benchmarking/automation/tests.yaml — 全部基准测试含 S0–S3的自动化定义benchmarking/locust/ 与 internal/benchmarking/glutton/ — 负载生成器与可配置资源消耗负载一句话总结Agent Substrate 的遥测容量测试 场景阶梯造压 Meter 计量 六条判定标准 两条轴的体积模型。把这套方法搬到自己的集群Collector 的容量问题就从玄学变成了读数。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考