人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载导读Substrate 的每个组件ateapi、ate-controller、atelet、atenet-router 以及各类 actor都会向 OpenTelemetry Collector 发送遥测数据但在 GKE 上托管 Collector 只把自身的自指标上报到 Cloud Monitoring并不会按来源拆解任何数据——你无法回答每个服务到底发了多少 spans 和 datapoints。本指南讲解仓库中benchmarking/telemetry/提供的解决方案一个名为meter的第二 Collector它以OTLP Tee的形式在数据流中旁路计数、原样转发从而在保持托管 Collector 负载真实可测的同时按service.name精确统计每个服务的遥测体积。读完本文你将掌握 meter 的安装、kind 集群差异、Prometheus 查询口径、tee 架构的三类副作用以及客户端侧丢包计数器等一整套可落地的测量流程。meter 是什么一个不改变数据流的 Teebenchmarking/telemetry/README.md开篇即定义了 meter 的定位测量 Substrate 发送多少遥测数据、以及由哪个组件发送。其动机来自 GKE 托管 Collector 的能力边界——托管 Collector 仅将自指标发送到 Cloud Monitoring对每个数据源不提供任何数据。因此benchmarking/telemetry/meter.yaml被设计为第二个 Collector它按service.name统计 spans 和 datapoints同时是一个 tee——计数后把数据继续转发给托管 Collector从而让托管 Collector 继续承受本轮运行的真实负载。这一设计的关键收益在 benchmarking/telemetry/README.md 中表述得很清楚一次运行同时得到两组测量——来自 meter 的各服务流量体积以及来自托管 Collector 的负载成本。其内部结构见 meter.yaml由四类构件组成构件配置要点receivers.otlpgRPC0.0.0.0:4317 HTTP0.0.0.0:4318processors.memory_limitercheck_interval: 1s、limit_percentage: 80、spike_limit_percentage: 15processors.deltatocumulativemax_streams: 20000connectors.count对 spans 生成substrate_spans、对 datapoints 生成substrate_datapoints均以service.name为维度default_value: unknowncountconnector 按service.name聚合的机制值得注意配置注释有说明connector 依次从数据项的 attributes、scope、resource 中读取键因此service.name会从 resource 中解析出来前面不需要任何 transform而default_value: unknown保证没有service.name的项不会从计数中静默消失。deltatocumulative处理器则解决了一个微妙问题count connector 发送 delta每个 batch 都有新的起始时间戳Prometheus exporter 会把新起始时间戳当作计数器重置不经过转换每次抓取就只显示最后一个 batch。进行一次测量GKE 场景安装 meter 并重定向控制面测量流程从两条命令开始kubectl apply -f benchmarking/telemetry/meter.yaml METERhttp://telemetry-meter.benchmarking.svc.cluster.local:4317 ./hack/install-ate.sh --deploy-ate-system --otlp-endpoint ${METER}--otlp-endpoint的作用机制在 install-ate.sh 中有完整实现它会 patchate-otel-configConfigMap 中的OTEL_EXPORTER_OTLP_ENDPOINT键然后对deployment/ate-api-server、deployment/ate-controller、deployment/atenet-router以及所有appatelet的 DaemonSet 执行rollout restart——因为 ConfigMap 的变更不会自动触发 Pod 重启必须显式滚动。该 ConfigMap 是 GKE 场景下各组件 OTLP 出口设置的唯一事实来源见 ate-otel-config.yamldata: OTEL_EXPORTER_OTLP_ENDPOINT: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4317一次 patch 即可覆盖全部控制面组件ateapi、ate-controller、atelet、atenet-router都通过envFrom读取该 ConfigMap而ate-controller还会把同样的值复制给它创建的 ateom worker Pod因此 worker 无需额外配置。actor 容器跟随 ActorTemplate 的 envactor 容器与上述组件不同Substrate 不会向 actor 容器注入任何 OTLP 配置它们只能使用 ActorTemplate 中声明的env。因此需要第二步部署 workload./benchmarking/workloads/deploy.sh --deploydeploy.sh 的resolve_otlp_endpoint函数在未显式传入--otlp-endpoint时会从ate-otel-configConfigMap 读取OTEL_EXPORTER_OTLP_ENDPOINT。由于上一步已把该 ConfigMap 指向 meteractor 会跟随控制面一起把数据发给 meter。只有当你想让 actor 与控制面走不同地址时才需要显式传--otlp-endpoint。最后务必让负载生成器留在常规 Collector 上——如果负载生成器也指向 metermeter 会把负载生成器自身的遥测错误地计作 Substrate 的遥测。kind 集群不要装 meter文档给出了一个明确的边界meter 只为 GKE 存在因为在 GKE 上托管 Collector 无法承载 connector。而 kind 集群的 Collector 是我们自己的manifests/ate-install/kind/otel-collector.yaml 中已经内置了完全相同的countconnector 与两个计数substrate_spans、substrate_datapoints还额外统计了substrate_actor_state_changes日志计数。在 meter 前再加一层只会徒增一跳量不出任何新东西。kind 上无需额外步骤——hack/install-ate.sh会随 Collector 一起安装一个 Prometheuskubectl port-forward -n otel-system svc/prometheus 9090:9090kind 与 GKE 的查询完全一致但有三处差异需要留意README 明确列出命名空间不同kind 上 Prometheus 和 Collector 位于otel-system而非benchmarking。不给--otlp-endpointkind 的ate-otel-configConfigMap 已经指向集群内 Collector见 kind/ate-otel-config.yamldeploy.sh读取该 ConfigMap 后 actor 自动跟随控制面。指标导出间隔不同kind 的 ConfigMap 把OTEL_METRIC_EXPORT_INTERVAL设为1000010 秒而非 GKE 的 60 秒该值由 kind overlay 专门设置以保证 metrics e2e 套件在有限时限内可见数据因此 kind 上查询范围[1m]已足够。另外要明确benchmarking/monitoring.yaml与 cAdvisor 是GKE 专用的。kind 只能测量流量体积——其 Collector 是单副本、无 HPA且单节点内存即整机内存成本数字不能推广到真实集群。读取数字Prometheus 查询口径benchmarking/monitoring.yaml部署了专门的 Prometheus含 cAdvisor 抓取、RBAC、Grafana 与预置面板用于抓取 meter。启动方式kubectl apply -f benchmarking/monitoring.yaml kubectl port-forward -n benchmarking svc/prometheus 9090:9090README 强调不要手动比较原始抓取值应通过 Prometheus 读取。核心查询口径如下表要查找的内容查询语句每个服务的 Spans/秒sum by (service_name) (rate(substrate_spans_total[5m]))每个服务的 Datapoints/分钟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]))计数是否丢弃了 seriessum(otelcol_deltatocumulative_datapoints{errorlimit})距离流上限有多近otelcol_deltatocumulative_streams_tracked / otelcol_deltatocumulative_streams_limit范围range选择至少取 60 秒推送间隔的三倍[5m]是默认推荐小于 3 分钟会产生噪声。GKE 上 SDK 的指标推送间隔为 60 秒newMeterProvider使用PeriodicReader见 serverboot.go。必须同时读后四行计数器一个报告零流量的服务本身不会产生任何数据——accepted必须大于 0 且refused必须为 0 才能确认数据真正到达。若二者不满足那个零说明数据从未到达而不是服务未发送。max_streams失败模式count connector 会把 resource 复制进每个计数而 serverboot 为每个进程分配独立的service.instance.id由OTEL_RESOURCE_ATTRIBUTES注入见 serverboot_test.go 的验证因此一个进程对每个计数各占一条流——流是按进程而非按服务计数的。超过max_streams后deltatocumulative会静默丢弃每条新流不打印任何日志series 从抓取中消失体积读数偏低且无任何报错。所以丢弃计数必须为 0、比值必须在整个运行窗口内低于 1。从 tee 的视角理解三类边界条件meter 的本质是 tee这个设计带来三个必须接受的副作用README 逐条给出了应对方案1. 托管 Collector 会把遥测归因给 meter。托管 Collector 以from: connection的方式应用k8sattributes每个转发过来的条目现在都来自 meter Pod。流量体积和 CPU 仍然正确但任何在托管侧按 Pod 分组的查询都会失真——应当改按 resource 中的service.name分组它经过一跳后依然正确。2. 负载形状发生改变。通常多个进程各自持有到托管 Collector 的连接引入 tee 后变成单一发送者、更大的批次。总量正确但跨副本的分布不再真实连接粘性connection stickiness的效应也随之消失。3. meter 自身可能成为瓶颈。它是单副本spec.replicas: 1。因此必须把 meter 自己的计数器加入通过标准sum(rate(otelcol_receiver_refused_spans[5m])) # 必须为 0 sum(rate(otelcol_exporter_sent_spans[5m])) # 必须大于 0 max_over_time(otelcol_exporter_queue_size[5m]) # 必须保持平稳 absent(otelcol_exporter_sent_spans) # 必须无结果 sum(otelcol_deltatocumulative_datapoints{errorlimit}) # 必须为 0 otelcol_deltatocumulative_streams_tracked / otelcol_deltatocumulative_streams_limit # 必须低于 1这里有一个重要的陷阱不要单独使用otelcol_exporter_send_failed_spans。默认的retry_on_failure.max_elapsed_time是 5 分钟exporter 会重试满该时长才会计一次失败——一个正在丢数据的 meter 在短步长内看起来完全正常。队列深度queue depth是立即变化的信号因此它才是需要盯住的指标absent()则捕获另一种情况meter 完全停止上报。如果 meter 丢数据流量体积和成本两个读数会同时错误且两种错误互相掩盖——这正是必须把上述计数器纳入通过标准的原因。内存保护与 terminal 模式meter.yaml 中的memory_limiterlimit 80% spike 15%与GOMEMLIMIT: 3000MiB协同工作Go 运行时不会读取 cgroup 限制若不设置GOMEMLIMIT堆会按节点内存来定尺寸设置后运行时会在 meter 拒绝数据之前触发 GC。其效果是达到内存上限的 meter 会拒绝数据从而显现在otelcol_receiver_refused_*中、可被通过标准捕获而不是被内核 OOM 杀掉。注意加大运行规模时要同步提高容器内存上限与GOMEMLIMIT——limiter 按百分比跟随容器上限但GOMEMLIMIT是绝对值需要手动更新。如需把 meter 变为terminal终端模式删除 meter.yaml 中traces/forward与metrics/forward两条转发 pipeline 即可。terminal meter 适用于长时间 soak把遥测挡在 Cloud Monitoring 之外但此时托管 Collector 的 resource 值是空闲 Collector 的值不得记录。托管 Collector 的成本读数由于 meter 是 tee托管 Collector 依然承受真实负载。README 给出的内存读数口径max_over_time( container_memory_working_set_bytes{namespacegke-managed-otel, container!}[5m] )必须使用 working set工作集kubectl top读取的是 metrics-server它在自己的窗口内计算平均值会隐藏短时峰值而 working set 正是OOM killer 采用的值monitoring.yaml 的 cAdvisor 抓取配置也直接采自 kubelet 端点并做了同样的取舍。将 working set 除以container_spec_memory_limit_bytes可得到限额使用比例。记录 CPU 与内存时必须同时记录副本数——托管 Collector 是 HPA 扩缩的 Deployment若不记录副本数处于最大副本数与仍有大量余量的 Collector 会呈现完全相同的表格。客户端侧丢包计数器meter 看不到的部分meter 只能反映到达的数据看不到客户端丢弃的数据。要观测客户端侧丢失需打开 SDK 的实验性可观测性开关kubectl set env -n ate-system deployment/ate-api-server OTEL_GO_X_OBSERVABILITYtrue随后直接抓取进程的:9090/metrics端点——该端点是一个Prometheus reader不经过 OTLP 路径因此在它测量的拥塞期间仍能正常工作。三个关键指标指标含义otel_sdk_span_started_total{otel_span_parent_origin,otel_span_sampling_result}采样决策根 span 与继承 span 分别统计otel_sdk_processor_span_processed_total{error_typequeue_full}客户端丢弃的 spansotel_sdk_processor_span_queue_sizevs_capacity开始丢弃前的余量没有丢包计数器时客户端的数据丢失与稳定平台毫无区别——这正是该指标存在的意义。README 特别提醒该 flag 是实验性的位于sdk/internal/x升级 SDK 后指标名可能变化每次升级后都应重新核对名称。移除 meter 恢复默认测量结束后的清理顺序与安装对称./hack/install-ate.sh --deploy-ate-system ./benchmarking/workloads/deploy.sh --deploy kubectl delete -f benchmarking/telemetry/meter.yaml两个脚本在不传--otlp-endpoint时都会回到集群默认端点控制面通过ate-otel-configConfigMap 的原始值actor 通过deploy.sh从该 ConfigMap 重新解析随后删除 meter 的 Namespace、Deployment、Service 与 ConfigMap全部封装在 meter.yaml 中。与场景阶梯Scenario Ladder配合telemetry 测量并非孤立存在它与 benchmarking/observability.md 定义的场景阶梯配套使用。该文件benchmarking/automation/tests.yaml中的observability_*测试规定了四个阶梯S0idle_floor5 分钟、无负载、S1user_sweep用户数 5→10→15--trace-probability 0.1、S2sample_rate_sweep采样率 0→0.1→1.0、S3soak12 用户10 分钟。其通过标准与 meter 的口径一致otelcol_receiver_refused_*必须为 0、客户端queue_full必须为 0、S3 中 Collector working set 与 exporter 队列的斜率须趋近于 0且必须检查阳性对照otelcol_receiver_accepted_*大于 0否则exporter 什么都没发会被误判为一次合格运行。而 docs/dev/best-practices/otel-collector.md 则解释了为什么需要按服务计量Substrate 的遥测体积有两个独立的驱动维度——指标随运行的组件数量增长与负载量无关traces 随操作速率增长因此每个服务的真实体积只能靠测量得到不能凭假设推断。meter 正是这一测量基础设施的落点。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐KTransformers 前缀缓存实战Balance Serve 下 GPU-CPU-Disk 三层 KV Cache 的启用与实现原理KTransformers 前缀缓存实战Balance Serve 下 GPU CPU Disk 三层 KV Cache 的启用与实现原理 前缀缓存Pref前端UI组件设计系统kornia.geometry.subpix 亚像素定位模块完全指南从 Soft-Argmax 到尺度空间二次插值kornia.geometry.subpix 亚像素定位模块完全指南从 Soft Argmax 到尺度空间二次插值 kornia 的 kornia.geome计算机视觉人工智能深度学习图像处理Clockwork服务器计时功能精确测量应用程序性能的完整指南Clockwork服务器计时功能精确测量应用程序性能的完整指南 Clockwork服务器计时功能 是PHP开发者必备的性能分析利器通过精确的时间测量和开发工具可观测性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Substrate 遥测计量（Telemetry Meter）：用 OTLP Tee 按服务精确测量 Spans 与 Datapoints 流量
人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载导读Substrate 的每个组件ateapi、ate-controller、atelet、atenet-router 以及各类 actor都会向 OpenTelemetry Collector 发送遥测数据但在 GKE 上托管 Collector 只把自身的自指标上报到 Cloud Monitoring并不会按来源拆解任何数据——你无法回答每个服务到底发了多少 spans 和 datapoints。本指南讲解仓库中benchmarking/telemetry/提供的解决方案一个名为meter的第二 Collector它以OTLP Tee的形式在数据流中旁路计数、原样转发从而在保持托管 Collector 负载真实可测的同时按service.name精确统计每个服务的遥测体积。读完本文你将掌握 meter 的安装、kind 集群差异、Prometheus 查询口径、tee 架构的三类副作用以及客户端侧丢包计数器等一整套可落地的测量流程。meter 是什么一个不改变数据流的 Teebenchmarking/telemetry/README.md开篇即定义了 meter 的定位测量 Substrate 发送多少遥测数据、以及由哪个组件发送。其动机来自 GKE 托管 Collector 的能力边界——托管 Collector 仅将自指标发送到 Cloud Monitoring对每个数据源不提供任何数据。因此benchmarking/telemetry/meter.yaml被设计为第二个 Collector它按service.name统计 spans 和 datapoints同时是一个 tee——计数后把数据继续转发给托管 Collector从而让托管 Collector 继续承受本轮运行的真实负载。这一设计的关键收益在 benchmarking/telemetry/README.md 中表述得很清楚一次运行同时得到两组测量——来自 meter 的各服务流量体积以及来自托管 Collector 的负载成本。其内部结构见 meter.yaml由四类构件组成构件配置要点receivers.otlpgRPC0.0.0.0:4317 HTTP0.0.0.0:4318processors.memory_limitercheck_interval: 1s、limit_percentage: 80、spike_limit_percentage: 15processors.deltatocumulativemax_streams: 20000connectors.count对 spans 生成substrate_spans、对 datapoints 生成substrate_datapoints均以service.name为维度default_value: unknowncountconnector 按service.name聚合的机制值得注意配置注释有说明connector 依次从数据项的 attributes、scope、resource 中读取键因此service.name会从 resource 中解析出来前面不需要任何 transform而default_value: unknown保证没有service.name的项不会从计数中静默消失。deltatocumulative处理器则解决了一个微妙问题count connector 发送 delta每个 batch 都有新的起始时间戳Prometheus exporter 会把新起始时间戳当作计数器重置不经过转换每次抓取就只显示最后一个 batch。进行一次测量GKE 场景安装 meter 并重定向控制面测量流程从两条命令开始kubectl apply -f benchmarking/telemetry/meter.yaml METERhttp://telemetry-meter.benchmarking.svc.cluster.local:4317 ./hack/install-ate.sh --deploy-ate-system --otlp-endpoint ${METER}--otlp-endpoint的作用机制在 install-ate.sh 中有完整实现它会 patchate-otel-configConfigMap 中的OTEL_EXPORTER_OTLP_ENDPOINT键然后对deployment/ate-api-server、deployment/ate-controller、deployment/atenet-router以及所有appatelet的 DaemonSet 执行rollout restart——因为 ConfigMap 的变更不会自动触发 Pod 重启必须显式滚动。该 ConfigMap 是 GKE 场景下各组件 OTLP 出口设置的唯一事实来源见 ate-otel-config.yamldata: OTEL_EXPORTER_OTLP_ENDPOINT: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4317一次 patch 即可覆盖全部控制面组件ateapi、ate-controller、atelet、atenet-router都通过envFrom读取该 ConfigMap而ate-controller还会把同样的值复制给它创建的 ateom worker Pod因此 worker 无需额外配置。actor 容器跟随 ActorTemplate 的 envactor 容器与上述组件不同Substrate 不会向 actor 容器注入任何 OTLP 配置它们只能使用 ActorTemplate 中声明的env。因此需要第二步部署 workload./benchmarking/workloads/deploy.sh --deploydeploy.sh 的resolve_otlp_endpoint函数在未显式传入--otlp-endpoint时会从ate-otel-configConfigMap 读取OTEL_EXPORTER_OTLP_ENDPOINT。由于上一步已把该 ConfigMap 指向 meteractor 会跟随控制面一起把数据发给 meter。只有当你想让 actor 与控制面走不同地址时才需要显式传--otlp-endpoint。最后务必让负载生成器留在常规 Collector 上——如果负载生成器也指向 metermeter 会把负载生成器自身的遥测错误地计作 Substrate 的遥测。kind 集群不要装 meter文档给出了一个明确的边界meter 只为 GKE 存在因为在 GKE 上托管 Collector 无法承载 connector。而 kind 集群的 Collector 是我们自己的manifests/ate-install/kind/otel-collector.yaml 中已经内置了完全相同的countconnector 与两个计数substrate_spans、substrate_datapoints还额外统计了substrate_actor_state_changes日志计数。在 meter 前再加一层只会徒增一跳量不出任何新东西。kind 上无需额外步骤——hack/install-ate.sh会随 Collector 一起安装一个 Prometheuskubectl port-forward -n otel-system svc/prometheus 9090:9090kind 与 GKE 的查询完全一致但有三处差异需要留意README 明确列出命名空间不同kind 上 Prometheus 和 Collector 位于otel-system而非benchmarking。不给--otlp-endpointkind 的ate-otel-configConfigMap 已经指向集群内 Collector见 kind/ate-otel-config.yamldeploy.sh读取该 ConfigMap 后 actor 自动跟随控制面。指标导出间隔不同kind 的 ConfigMap 把OTEL_METRIC_EXPORT_INTERVAL设为1000010 秒而非 GKE 的 60 秒该值由 kind overlay 专门设置以保证 metrics e2e 套件在有限时限内可见数据因此 kind 上查询范围[1m]已足够。另外要明确benchmarking/monitoring.yaml与 cAdvisor 是GKE 专用的。kind 只能测量流量体积——其 Collector 是单副本、无 HPA且单节点内存即整机内存成本数字不能推广到真实集群。读取数字Prometheus 查询口径benchmarking/monitoring.yaml部署了专门的 Prometheus含 cAdvisor 抓取、RBAC、Grafana 与预置面板用于抓取 meter。启动方式kubectl apply -f benchmarking/monitoring.yaml kubectl port-forward -n benchmarking svc/prometheus 9090:9090README 强调不要手动比较原始抓取值应通过 Prometheus 读取。核心查询口径如下表要查找的内容查询语句每个服务的 Spans/秒sum by (service_name) (rate(substrate_spans_total[5m]))每个服务的 Datapoints/分钟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]))计数是否丢弃了 seriessum(otelcol_deltatocumulative_datapoints{errorlimit})距离流上限有多近otelcol_deltatocumulative_streams_tracked / otelcol_deltatocumulative_streams_limit范围range选择至少取 60 秒推送间隔的三倍[5m]是默认推荐小于 3 分钟会产生噪声。GKE 上 SDK 的指标推送间隔为 60 秒newMeterProvider使用PeriodicReader见 serverboot.go。必须同时读后四行计数器一个报告零流量的服务本身不会产生任何数据——accepted必须大于 0 且refused必须为 0 才能确认数据真正到达。若二者不满足那个零说明数据从未到达而不是服务未发送。max_streams失败模式count connector 会把 resource 复制进每个计数而 serverboot 为每个进程分配独立的service.instance.id由OTEL_RESOURCE_ATTRIBUTES注入见 serverboot_test.go 的验证因此一个进程对每个计数各占一条流——流是按进程而非按服务计数的。超过max_streams后deltatocumulative会静默丢弃每条新流不打印任何日志series 从抓取中消失体积读数偏低且无任何报错。所以丢弃计数必须为 0、比值必须在整个运行窗口内低于 1。从 tee 的视角理解三类边界条件meter 的本质是 tee这个设计带来三个必须接受的副作用README 逐条给出了应对方案1. 托管 Collector 会把遥测归因给 meter。托管 Collector 以from: connection的方式应用k8sattributes每个转发过来的条目现在都来自 meter Pod。流量体积和 CPU 仍然正确但任何在托管侧按 Pod 分组的查询都会失真——应当改按 resource 中的service.name分组它经过一跳后依然正确。2. 负载形状发生改变。通常多个进程各自持有到托管 Collector 的连接引入 tee 后变成单一发送者、更大的批次。总量正确但跨副本的分布不再真实连接粘性connection stickiness的效应也随之消失。3. meter 自身可能成为瓶颈。它是单副本spec.replicas: 1。因此必须把 meter 自己的计数器加入通过标准sum(rate(otelcol_receiver_refused_spans[5m])) # 必须为 0 sum(rate(otelcol_exporter_sent_spans[5m])) # 必须大于 0 max_over_time(otelcol_exporter_queue_size[5m]) # 必须保持平稳 absent(otelcol_exporter_sent_spans) # 必须无结果 sum(otelcol_deltatocumulative_datapoints{errorlimit}) # 必须为 0 otelcol_deltatocumulative_streams_tracked / otelcol_deltatocumulative_streams_limit # 必须低于 1这里有一个重要的陷阱不要单独使用otelcol_exporter_send_failed_spans。默认的retry_on_failure.max_elapsed_time是 5 分钟exporter 会重试满该时长才会计一次失败——一个正在丢数据的 meter 在短步长内看起来完全正常。队列深度queue depth是立即变化的信号因此它才是需要盯住的指标absent()则捕获另一种情况meter 完全停止上报。如果 meter 丢数据流量体积和成本两个读数会同时错误且两种错误互相掩盖——这正是必须把上述计数器纳入通过标准的原因。内存保护与 terminal 模式meter.yaml 中的memory_limiterlimit 80% spike 15%与GOMEMLIMIT: 3000MiB协同工作Go 运行时不会读取 cgroup 限制若不设置GOMEMLIMIT堆会按节点内存来定尺寸设置后运行时会在 meter 拒绝数据之前触发 GC。其效果是达到内存上限的 meter 会拒绝数据从而显现在otelcol_receiver_refused_*中、可被通过标准捕获而不是被内核 OOM 杀掉。注意加大运行规模时要同步提高容器内存上限与GOMEMLIMIT——limiter 按百分比跟随容器上限但GOMEMLIMIT是绝对值需要手动更新。如需把 meter 变为terminal终端模式删除 meter.yaml 中traces/forward与metrics/forward两条转发 pipeline 即可。terminal meter 适用于长时间 soak把遥测挡在 Cloud Monitoring 之外但此时托管 Collector 的 resource 值是空闲 Collector 的值不得记录。托管 Collector 的成本读数由于 meter 是 tee托管 Collector 依然承受真实负载。README 给出的内存读数口径max_over_time( container_memory_working_set_bytes{namespacegke-managed-otel, container!}[5m] )必须使用 working set工作集kubectl top读取的是 metrics-server它在自己的窗口内计算平均值会隐藏短时峰值而 working set 正是OOM killer 采用的值monitoring.yaml 的 cAdvisor 抓取配置也直接采自 kubelet 端点并做了同样的取舍。将 working set 除以container_spec_memory_limit_bytes可得到限额使用比例。记录 CPU 与内存时必须同时记录副本数——托管 Collector 是 HPA 扩缩的 Deployment若不记录副本数处于最大副本数与仍有大量余量的 Collector 会呈现完全相同的表格。客户端侧丢包计数器meter 看不到的部分meter 只能反映到达的数据看不到客户端丢弃的数据。要观测客户端侧丢失需打开 SDK 的实验性可观测性开关kubectl set env -n ate-system deployment/ate-api-server OTEL_GO_X_OBSERVABILITYtrue随后直接抓取进程的:9090/metrics端点——该端点是一个Prometheus reader不经过 OTLP 路径因此在它测量的拥塞期间仍能正常工作。三个关键指标指标含义otel_sdk_span_started_total{otel_span_parent_origin,otel_span_sampling_result}采样决策根 span 与继承 span 分别统计otel_sdk_processor_span_processed_total{error_typequeue_full}客户端丢弃的 spansotel_sdk_processor_span_queue_sizevs_capacity开始丢弃前的余量没有丢包计数器时客户端的数据丢失与稳定平台毫无区别——这正是该指标存在的意义。README 特别提醒该 flag 是实验性的位于sdk/internal/x升级 SDK 后指标名可能变化每次升级后都应重新核对名称。移除 meter 恢复默认测量结束后的清理顺序与安装对称./hack/install-ate.sh --deploy-ate-system ./benchmarking/workloads/deploy.sh --deploy kubectl delete -f benchmarking/telemetry/meter.yaml两个脚本在不传--otlp-endpoint时都会回到集群默认端点控制面通过ate-otel-configConfigMap 的原始值actor 通过deploy.sh从该 ConfigMap 重新解析随后删除 meter 的 Namespace、Deployment、Service 与 ConfigMap全部封装在 meter.yaml 中。与场景阶梯Scenario Ladder配合telemetry 测量并非孤立存在它与 benchmarking/observability.md 定义的场景阶梯配套使用。该文件benchmarking/automation/tests.yaml中的observability_*测试规定了四个阶梯S0idle_floor5 分钟、无负载、S1user_sweep用户数 5→10→15--trace-probability 0.1、S2sample_rate_sweep采样率 0→0.1→1.0、S3soak12 用户10 分钟。其通过标准与 meter 的口径一致otelcol_receiver_refused_*必须为 0、客户端queue_full必须为 0、S3 中 Collector working set 与 exporter 队列的斜率须趋近于 0且必须检查阳性对照otelcol_receiver_accepted_*大于 0否则exporter 什么都没发会被误判为一次合格运行。而 docs/dev/best-practices/otel-collector.md 则解释了为什么需要按服务计量Substrate 的遥测体积有两个独立的驱动维度——指标随运行的组件数量增长与负载量无关traces 随操作速率增长因此每个服务的真实体积只能靠测量得到不能凭假设推断。meter 正是这一测量基础设施的落点。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐KTransformers 前缀缓存实战Balance Serve 下 GPU-CPU-Disk 三层 KV Cache 的启用与实现原理KTransformers 前缀缓存实战Balance Serve 下 GPU CPU Disk 三层 KV Cache 的启用与实现原理 前缀缓存Pref前端UI组件设计系统kornia.geometry.subpix 亚像素定位模块完全指南从 Soft-Argmax 到尺度空间二次插值kornia.geometry.subpix 亚像素定位模块完全指南从 Soft Argmax 到尺度空间二次插值 kornia 的 kornia.geome计算机视觉人工智能深度学习图像处理Clockwork服务器计时功能精确测量应用程序性能的完整指南Clockwork服务器计时功能精确测量应用程序性能的完整指南 Clockwork服务器计时功能 是PHP开发者必备的性能分析利器通过精确的时间测量和开发工具可观测性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考