首先，官方文檔的 FAQ 是這麼解釋爲何使用拉取（pull）而不是推送（push）模式：
- 可以在筆記本上監控開發時產生的變更
- 如果監控目標宕了可以更容易發現
- 可以通過web瀏覽器手工訪問監控目標並檢查其健康狀況
總之我們認爲拉取比推送好一點點，但是這並不一個監控系統需要考慮的重點。
下文是一篇 Prometheus 官方博客的閱讀筆記。
有些人認爲拉取模式是無法擴展的，然而這和我們的實踐經驗相反，以下進一步討論這一誤解。
Prometheus 不是 Nagios
Nagios 有擴展性不好的名聲，這部分源於在Nagios主機上要創建用於檢查的子進程，這些子進程執行隨機操作來探測節點和服務的健康狀況，這造成Nagios中心節點的壓力迅速升高。於是人們通常爲間隔幾分鐘執行一次這種檢查。
而 Prometheus 採取了完全不同的方式，它不執行檢查腳本，而僅僅通過網絡收集被控目標的時序數據。對每個被控目標，Prometheus服務器簡單地通過HTTP（高併發，使用goroutines）收取所有指標的當前狀態，沒有任何其他的運行負荷。這引出下一點
誰發起連接無關緊要
對於擴展性而言，服務器和被控端哪一端發起TCP連接無關緊要，創建連接的開銷比傳輸的指標負載要小。
推送模式可以使用UDP來避免創建連接，誠然，但是TCP/HTTP開銷與Prometheus服務器的注入數據（尤其是持久化時序數據到硬盤）的工作比起來是微不足道的。一些數據：一個單節點Prometheus服務器可以輕鬆存儲數百萬時序數據，每秒80萬樣本數據。設刮取週期爲10秒，每個被控端700個時序指標，這允許你用一臺Prometheus服務器監控超過1萬臺主機。擴展的瓶頸絕對不是拉取模式，而通常是Prometheus服務器注入數據到內存然後持久化到硬盤的速度。
而且鑑於網絡的可靠性，使用基於TCP的拉取模式使指標數據的到達非常可靠，如果由於網絡原因導致指標傳輸失敗時，監控系統也可以立刻發現。
Prometheus 不是基於事件的系統
有些監控系統是基於事件的，每一個事件（HTTP請求、異常）發生時他們立即向監控服務器報告。監控服務器可以匯聚事件爲指標或保存事件用於後續處理（ELK）。對於這種系統，拉取確實是有問題的，計量服務必須在拉取的間隔中間緩存事件，拉取的頻率也要非常高才能接近推送模式的效果。
Prometheus不是基於事件的監控系統，它僅僅關心標準化地採集給定指標的當前狀態，而不是導致這些指標的底層事件。例如，計量服務不會發送關於每個HTTP請求的消息給Prometheus服務器，而是在內存中簡單地累加這些請求。每秒可能會發生成百上千次這種累加而不會產生任何監控流量。Prometheus然後每隔15或30秒簡單地問一下這個服務實例當前狀態的累積值而已。監控結果的傳輸量很小，拉取模式也不會產生問題。
但是現在監控需要知道我的服務實例！
基於拉取模式的監控系統需要知道存在哪些服務實例和如何連接到它們。有些人擔心這會導致很大的配置量從而限制擴展性。
對於嚴格的監控系統，無論如何都無法逃避這些配置工作，推送模式會要求更多的配置，因爲服務器要知道被控端，被控端還要知道服務器。拉取模式不但需要的配置量更少，而且配置更靈活。當被控端點移動以後，不需要重新配置被控端。你也可以簡單地copy一個生產環境的監控到你的筆記本上。你還可以通過其他手段或者手工檢查被控端。
Prometheus有方便地配置界面，內置支持廣泛的雲服務廠商的服務發現機制。
監控中偶爾遭遇DDoS
無論那種模式，發送給時序數據庫的數據量超過它的處理能力就會導致它宕機。推送模式更容易導致這種情況發生，相比而言拉取模式地風險更低一些
真實世界的證明
Google就用它，你還能比Google的服務器規模大麼？
拉取模式還是存在問題的
一個突出的問題是server和被控端的網絡不可達，此時Prome也有變通的推送網關模式。這主要是TCP網絡操作的困難性導致的。