优化遥测数据传输

数据面（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 上，请相应地调整步骤。

1. 记录 CPU 使用率（在上传过程中持续监控）：

   docker stats ${gateway-container-name}

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

   docker exec -it ${gateway-container-name} /bin/sh
   
   curl "http://127.0.0.1:9091/apisix/prometheus/metrics" | wc -c

3. 使用 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 容量和带宽需求来选择合适的压缩级别。