项目背景：
项目上有一个agent，负责归集局域网中各类exporter的数据，再统一被prometheus拉取。
统一归集后，简化了局域网的暴露面，但同时暴露了一个问题：prometheus单次拉取数据量过大。每次拉取的数据量都在100M左右，占用了宝贵的带宽资源。
思路：
通过cpu资源置换带宽资源。在发送http包数据前，利用agent所在机器的cpu，对发送数据进行压缩。到达prometheus后，再利用prometheus所在机器的cpu进行解压。这样，带宽资源得到了明显的释放。
试验数据比对与整理：
1.通过直接curl agent，知道指标量大小为138M
2.观测prometheus拉agent的用时，大概为30秒
3..通过对prometheus的指标监控，得到prometheus的网络流入量为325K/s。
4.计算得出：prometheus30秒内流入量为325k/s*30s=9.75M流量。（忽略机器的其他数据流入量。如果考虑其他数据流入量，其真实压缩率会更高）
通过以上步骤得到giz压缩比：138M/9.75M=14.14倍
（prometheus pull exporter的时候，header会设置为：Accept-Encoding: gzip, deflate）
数据从agent到prometheus wal的完整链路：
agent-->http/https(gzip)-->prometheus解码-->prometheus wal压缩
138M 9.75M 138M 小于9.75M（prometheus自身拥有更高的压缩率）
gzip协议说明：
1.gzip的压缩率是可以设置等级的，但并不是等级越高，压缩效果就越好。如果不是有苛刻要求，用默认等级即可；
2.gzip的压缩效果，也和文本内容相关。如果文本中相似内容越多，压缩率会越高。
