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組件導致）