ARMS 切换到按量计费后，少部分用户反馈数据上报量偏大。也有用户尝试自行调整应用配置，但效果并不明显。本文将由浅入深，带你快速定位“数据量大”的主要来源，并给出一套更高效、可落地的降量方法。
一、先定位：到底是谁在“吃”掉用量？
在 ARMS 控制台的概览页进入用量统计，可以快速查看当前账号在不同 region 的数据上报情况。
对于数据上报量较高的 region，点击该行右侧的查看详情，即可看到该 region 内各应用的上报分布。如下图所示，每一行会分别展示某个应用的指标、调用链以及持续剖析数据写入量。到这里，你基本就能锁定“主要元凶”，接下来就是针对性降量。
二、降低指标数据上报量：先找最大头，再逐个处理
ARMS 在某个 region 的指标数据会落在 SLS 的 MetricStore 中。我们可以通过查询语句，快速判断某个应用上报的指标里，究竟哪一类指标占比最高，从而“先砍大头”。
2.1 找到对应的 MetricStore
进入 SLS 控制台，选择对应 region，并搜索包含 xtrace 关键字的 project，如下图所示：
进入该 project 后，点击左侧 metricstore，重点关注以下三个 metricstore：
- metricstore-apm-metrics：存储探针上报的系统指标、Runtime 指标以及预聚合后的 RED 指标
- metricstore-apm-metrics-detail：存储探针原始上报的 RED 数据
- metricstore-apm-metrics-custom：存储探针上报的自定义指标，比如通过 OpenTelemetry SDK 自定义上报的指标
当指标上报量偏高时，通常会体现在以上三个 metricstore 的写入量明显增大。
2.2 用查询语句找出“最费量”的指标类型
进入单个 metricstore，点击自定义查询：
在自定义分析页面，使用下述语句即可统计右上角时间范围内，指定应用不同指标类型的上报量。
需要注意：${metricstoreName} 和 ${serviceName} 需要替换为当前查询的 metricstore 名称，以及数据上报量较高的应用名称。
(*)| SELECT round(sum(length(**name**) + length(**labels**) + 16), 3) as num, **name** as name from "${metricstoreName}.prom" where **name** != '' and element_at(**labels**, 'service') = '${serviceName}' group by name order by num desc
结果如下图所示，会展示不同类型指标的数据量占比：
2.3 常见“大户”与对应处理建议
常见的高上报量指标类型通常包括以下几类：
- arms_thread_pool 开头指标上报量高：一般意味着业务中线程池实例很多。ARMS 线程池监控会采集所有线程池实例指标，详情见 ARMS 线程池监控功能介绍。此时可以在应用配置页面关闭池化监控功能，或过滤部分不关注的线程池实例，详情参见线程池监控配置
- arms_grouped_thread 开头指标上报量高：一般是应用线程数较多。ARMS 会采集 JVM 线程耗时与状态分布，并按线程名聚类统计，详情参见 ARMS 线程分析功能介绍。此时只能通过关闭线程池监控来整体关闭线程分析能力，详情参见线程分析配置
- **arms_callTyperequests∗∗开头指标上报量高：通常是某类插件采集过多。这里的‘callTyperequests∗∗开头指标上报量高：通常是某类插件采集过多。这里的‘callType` 代表协议类型，如 http、redis、grpc 等。可按实际场景选择两种治理方式：
三、降低调用链数据上报量：先校准采样，再排查“外部采样决策”
ARMS 在某个 region 的调用链数据会存储在 SLS 的 Logstore 中。调用链写入量偏高时，最常见的优化手段是调整采样率，并确认采样是否真的生效。
3.1 采样率调整的关键前提：只在“入口”生效
调用链数据上报过多时，通常可以先尝试调整采样率。但需要特别注意：在 ARMS 当前采样策略下，采样率仅对调用入口有效。
例如：应用 A 调用应用 B。若 A 的采样率为 100%，那么 B 无论设置多少采样率都不会生效，最终会以 A 的采样决策为准。做治理时更推荐：修改完采样率后批量复制到所有应用，减少寻找入口应用的成本。
3.2 如何验证采样率是否生效？
调整后可按如下方式校验：
在应用的提供服务页，找一个调用量较大的接口，观察右上角时间范围内的总调用量。例如下图中 /api/ruler/v1/alerts 最近 30 分钟调用量为 123 万次，然后点击右侧调用链进入该接口的 trace 数据：
接着观察该接口的 span 数，对比 span 数与调用次数的比例，是否与采样率大致一致：
如果不一致，通常落在两类原因里：
3.3 只比采样率略高：多半是“非头采样”在补采
如果相比采样率只是小幅上涨，一般考虑 ARMS 的一些非头采样策略导致，常见三种：
- 小流量采样：可以在过滤条件中新增
- 错/异常采样：可通过 attributes.sample.reason=s9 或 attributes.sample.reason=s11 查找。目前对这类 span 没有控制手段，建议从业务侧优化，减少接口报错和异常抛出。
- 慢采样：可通过 attributes.sample.reason=s10 查找。如果过多，可在接口调用配置中调大慢调用阈值降低。
3.4 远高于采样率：入口可能“继承了外部的采样决策”
如果 span 数与采样率差距很大，通常是外部系统调用入口应用时携带了 trace 上下文，入口应用会遵从外部的采样决策，从而导致本地采样率不生效。常见场景如下：
- 接入 ARMS RUM 监控：需要在 RUM 中调整采样率，参见 调整 RUM 采样率
- 开启了 MSE 网关链路追踪：可在 MSE 网关配置页调整采样率，参见 调整 MSE 网关采样率
- K8S Ingress Controller 开启了链路追踪：场景较多，建议查阅对应项目文档。下面以 Nginx Ingress Controller + OpenTelemetry 为例：通过 ConfigMap 决定是否开启以及采样率，如下为 10% 采样率配置
- 无法确认外部 trace 上下文来源：可以随机点开一些调用链，查看 LocalRootSpan 的 trace.protocol.type 这个 attributes（如下图）。随后可在 trace 上下文传播协议配置中 配置强制使用另外一个协议，从而忽略外部携带的 trace 上下文，这里建议使用 W3C 协议
四、降低持续剖析数据上报量：三种最直接的手段
如果持续剖析数据上报量比较大，当前有下述三个优化方案：
- 在持续剖析设置页面调整部分功能开关。当前建议的持续剖析功能使用优先级是：代码热点 > CPU 热点 > 内存热点，可按优先级选择性开启部分功能
- 当一个应用存在多个实例时，可以选择性开启部分节点，而不是所有节点全部开启
- 调高 CPU 热点和代码热点的采样频率，或调高内存热点的采样阈值。需要注意：阈值调高可以显著降低该类数据的上报量，但同时也会导致持续剖析数据精度大幅下降。