【分享】让prometheus支持PUSH模式，可以使用remote write协议推送数据

2021-10-21补充：
我通过修改源码来让prometheus支持remote-write，纯属多此一举：
--enable-feature=remote-write-receiver这个命令行参数可以开启remote-write能力，不过写入路径是：/api/v1/write
不过，我仍然保留了原来的代码，并兼容了 /api/v1/receive 这个路径。

之前测试了thanos reveiver的remote write能力，后续又希望thanos reveiver具备更多能力。
既然如此，何不在prometheus的基础上改出支持remote write能力呢？
经过一天，已经成功，请看：https://github.com/ahfuzhang/prometheus-2.29.1

测试

• 测试环境为：
  • CPU: Intel(R) Xeon(R) Platinum 8361HC CPU @ 2.60GHz, 1核
  • 32GB内存
  • K8S容器环境
• 在单核跑满的情况下，观测一秒钟可以处理多少个data point
• 测试中发现，单核极限性能在：2763196/min, 46053/s
• 平均性能为：33450/s
• 接口主要延迟在 0-10ms之间
  • 次要延迟在 50-100ms之间

TSDB数据

• 配置:
  • storage.tsdb.min-block-duration=10m
  • storage.tsdb.max-block-duration=10m
  • storage.tsdb.retention.time=30m
• data point总数：85506661
• 内存：20.333GB
• time series总数：3222668
• 现象：
  • prometheus并未严格按照10分钟来产生TSDB
  • 当产生新的TSDB后，time series/ head chunks有一定下降，但是不多；内存也有一定下降，大约200MB左右
  • 切换TSDB时，CPU消耗过多，导致remote write处理能力下降48.9%
  • 内存占用与time series的数量正相关，data point的数量影响不大

总结：

• prometheus支持推模式，起码在部署中多了一个选择
• 如果单纯看data point的处理能力，thanos reveiver要比prometheus好一些
• 内存占用上，prometheus和thanos receiver查不太多（可能底层都是同样的TSDB组件导致）