版本：3.10.x

优化遥测数据传输

数据面（DP）定期向控制面（CP）报告其运行状态和指标数据，以实现集中的监控、管理和分析。为了减少网络传输开销，DP 在报告遥测数据时默认启用 Gzip 压缩。

本指南介绍了如何配置遥测数据传输和压缩级别，以在网络带宽占用和 CPU 消耗之间实现最佳平衡。

数据从 DP 到 CP 的传输

DP 定期向 CP 发送遥测指标，包括 API 流量、请求延迟、状态码、带宽和连接数等关键性能指标（KPI）。这些指标遵循 Prometheus 格式并为监控和告警奠定了基础。

自定义数据传输配置

默认情况下，DP 每 15 秒向 CP 报告一次遥测数据。你可以在网关的配置文件中自定义此频率及相关设置。

以下配置列出了所有遥测相关的选项及其默认值：

conf/config.yaml
api7ee:
  telemetry:
    # -- 是否启用向控制面报告遥测数据
    enable: true

    # -- 向控制面发送遥测数据的时间间隔（秒）
    interval: 15

    # -- 发送到控制面的指标数据的最大大小（字节，默认 32MB），超出的部分将被截断
    max_metrics_size: 33554432

    # -- 压缩前的最大批处理大小（字节，默认 4MB）
    metrics_batch_size: 4194304

    # -- gzip 压缩级别。-1 表示使用库的默认值（通常是 6），范围是 0-9；1 速度最快，9 压缩率最高
    compression_level: -1

了解 Gzip 压缩级别

为了减少网络传输的开销，DP 默认在报告遥测数据时启用 Gzip 压缩。可配置的压缩级别允许用户在 CPU 消耗与网络带宽之间进行权衡。

默认情况下，Gzip 压缩级别设置为 -1。你可以通过网关配置文件中的 api7ee.telemetry.compression_level 参数来自定义压缩级别。

级别	描述	特征
-1	使用 zlib 库默认设置	通常为级别 6
0	不压缩	仅打包数据；没有 CPU 消耗，数据体积最大。
1	最快压缩	CPU 消耗最低，压缩率最低。
6	平衡压缩	在 CPU 消耗与压缩率之间实现最佳平衡。
9	最高压缩	压缩率最高，CPU 消耗最高。

禁用数据传输

要禁用遥测数据传输，可在配置文件中将 api7ee.telemetry.enable 参数设置为 false。请注意，禁用遥测将带来以下影响：

影响类别	详情
丧失可观测性	控制面将不再接收来自数据面的性能指标。监控仪表板和告警系统将会失效。
影响运维决策	运维团队将丢失评估服务健康、进行容量规划以及故障排查的关键数据来源。
合规风险	某些行业对系统监控和审计的合规要求可能将无法得到满足。

注意

除非有特殊需求（如调试场景或处于完全隔离的环境中），否则强烈建议不要禁用此功能。

压缩性能测试

本节提供了完整的测试流程，以在实际环境中验证不同压缩级别对数据大小和 CPU 性能的影响。

前提条件

在开始测试之前，请确保你的环境设置正确并满足以下要求。

准备 API7 企业版

确保：

一个 API7 企业版部署，包含一个 CP 和至少一个 DP（网关）。
DP 能够正常向 CP 报告数据。
具有修改 DP 配置文件和重启容器的权限。
能够访问 DP 的日志和监控指标。

准备流量生成工具

为了生成实际的指标数据，需要向 DP 发送一定数量的请求流量。以下脚本可以用来创建大量的路由，随后向 DP 发送请求以生成充足的指标数据。

下面的示例脚本会创建 60 个服务，每个服务包含 60 个路由，共计 3600 个路由。

create-routes.sh
#!/usr/bin/env bash
set -e

############################
# 1. 测前准备
############################

# 替换为你自己的 Admin API 地址和访问 Token
ADMIN_API="http://127.0.0.1:7080"
ADMIN_KEY="$API7_EE_TOKEN"

############################
# 2. 创建 60 个服务，每个包含 60 个路由
############################

echo "==> Creating 60 services, each with 60 routes..."

for i in $(seq 1 60); do
  SERVICE_ID="demo-echo-service-${i}"
  SERVICE_PREFIX="/service-${i}"

  echo ""
  echo "==> Creating service ${i}/60: ${SERVICE_ID} (prefix: ${SERVICE_PREFIX})"

  curl -s -X PUT "${ADMIN_API}/apisix/admin/services/${SERVICE_ID}?gateway_group_id=default" \
    -H "X-API-KEY: ${ADMIN_KEY}" \
    -H "Content-Type: application/json" \
    -d "{
      \"id\": \"${SERVICE_ID}\",
      \"name\": \"${SERVICE_ID}\",
      \"desc\": \"service ${i} with 60 echo routes (prefix: ${SERVICE_PREFIX})\",
      \"upstream\": {
        \"type\": \"roundrobin\",
        \"nodes\": []
      }
    }" | jq .

  echo "   Creating 60 routes for service ${i}..."

  for j in $(seq 1 60); do
    ROUTE_ID="echo-route-service-${i}-${j}"
    URI="${SERVICE_PREFIX}/${j}/get"

    curl -s -X PUT "${ADMIN_API}/apisix/admin/routes/${ROUTE_ID}?gateway_group_id=default" \
      -H "X-API-KEY: ${ADMIN_KEY}" \
      -H "Content-Type: application/json" \
      -d "{
        \"name\": \"${ROUTE_ID}\",
        \"service_id\": \"${SERVICE_ID}\",
        \"methods\": [\"GET\"],
        \"paths\": [\"${URI}\"],
        \"plugins\": {
          \"echo\": {
            \"before_body\": \"hello from service ${i}, route ${j}\",
            \"headers\": {
              \"X-Service-Index\": \"${i}\",
              \"X-Route-Index\": \"${j}\"
            }
          }
        }
      }" > /dev/null

    echo "   ✓ Created route ${URI}"
  done
done

############################
# 3. 完成提示
############################

echo ""
echo "✅ Done!"
echo "Created 60 services, each with 60 routes (3600 routes total)"
echo ""
echo "Test examples:"
echo "  curl http://<gateway-host>:9080/service-1/1/get"
echo "  curl http://<gateway-host>:9080/service-2/15/get"
echo "  curl http://<gateway-host>:9080/service-10/30/get"

运行压缩测试

在本次测试中，你将修改压缩级别并生成流量，以测量其对性能的影响。

修改压缩级别

在 DP 的配置文件中调整 compression_level，以使用不同的压缩级别：

config.yaml
api7ee:
  telemetry:
    compression_level: 1  # 示例：测试级别 1, 6, 和 9

重启 DP 容器（如果使用 Docker）或升级网关的 Release（如果使用 Kubernetes）以应用配置更改。随后，生成测试流量并观察其对 CPU 使用率和数据大小的影响。

生成测试流量

向 DP 发起足够多的请求，以生成有意义的指标数据：

generate-traffic.sh
#!/usr/bin/env bash
set -e

############################
# 1. 配置
############################

# 替换为你自己的网关监听地址
DP_HOST="http://127.0.0.1:9080"
SERVICE_COUNT=60
ROUTES_PER_SERVICE=60
TOTAL=$((SERVICE_COUNT * ROUTES_PER_SERVICE))

############################
# 2. 测试路由
############################

echo "==> Testing ${TOTAL} echo routes (${SERVICE_COUNT} services × ${ROUTES_PER_SERVICE} routes each)..."

ROUTE_NUM=0
for i in $(seq 1 ${SERVICE_COUNT}); do
  echo ""
  echo "==> Testing service ${i}/${SERVICE_COUNT} (prefix: /service-${i}/)..."

  for j in $(seq 1 ${ROUTES_PER_SERVICE}); do
    ROUTE_NUM=$((ROUTE_NUM + 1))
    URL="${DP_HOST}/service-${i}/${j}/get"

    echo -n "[${ROUTE_NUM}/${TOTAL}] GET ${URL} ... "

    RESPONSE=$(curl -s -o /tmp/echo_test_service${i}_route${j}.out -w "%{http_code}" "${URL}")
  done
done

echo ""
echo "✅ All routes are accessible!"

收集测试数据

对于每一个压缩级别，请收集以下数据：

CPU 使用率： 在流量压力测试期间持续监控。
压缩后的数据大小： 使用 tcpdump 捕获从 DP 到 CP 的网络流量，以分析压缩后的数据大小。

以下步骤假设网关在 Docker 中运行。如果你的网关部署在 Kubernetes 上，请相应地调整步骤。

记录 CPU 使用率（在上传过程中持续监控）：
```
docker stats ${gateway-container-name}
```

从 DP 容器获取原始数据大小：

docker exec -it ${gateway-container-name} /bin/sh

curl "http://127.0.0.1:9091/apisix/prometheus/metrics" | wc -c

使用 tcpdump 捕获从 DP 到 CP 的网络流量，以分析压缩后的数据大小：
```
sudo tcpdump -i any -w /tmp/dp_to_cp_level_X.pcap host ${cp-address} and port ${cp-port}
```
信息
DP 和 CP 使用 mTLS 进行通信，这可能会影响抓包分析的结果。

审查测试结果

不同压缩级别的测试结果示例如下表所示：

测量项	级别 1	级别 6	级别 9
原始指标数据大小 (MB)	7.71	6.60	6.45
压缩后数据大小 (MB)	0.22	0.16	0.12
压缩比（节省空间比例 %）	97.10%	97.54%	97.98%
DP CPU 使用率	17.39%	21.57%	29.61%

测试结果展示了不同 Gzip 压缩级别带来的权衡。随着压缩级别从 1 提高到 9，压缩后的数据大小减小，压缩比提高，从而降低了网络带宽的占用。

但是，较高的压缩级别也会增加 DP 上的 CPU 使用率。级别 6 提供了较好的平衡点，在不过度消耗 CPU 的同时能提供很强的压缩能力。级别 9 虽然能达到最大的压缩效果，但代价是 CPU 消耗显著增加。请根据你所在环境的 CPU 容量和带宽需求来选择合适的压缩级别。

数据从 DP 到 CP 的传输​

自定义数据传输配置​

了解 Gzip 压缩级别​

禁用数据传输​

压缩性能测试​

前提条件​

准备 API7 企业版​

准备流量生成工具​

运行压缩测试​

修改压缩级别​

生成测试流量​

收集测试数据​

审查测试结果​