介紹
在考慮如何將度量採集到監視系統中時，有兩種不同的思想流派：要麼客戶端（被監控物件）將度量推送（通常通過
udp）
到系統中，要麼伺服器（監控系統）將它們拉取（通常通過
）到系統中。在某些地方說
「基於推送或拉取的系統
」以使文章簡潔時，我可能不會提到這一點。
push
方法用於
等系統，而
pull
方法用於
prometheus
等監視系統。
哪乙個更好？就像生活中的一切一樣，沒有明確的答案，雙方都有很強的理由支援他們。我將嘗試了解它們。
爭論
支援拉：更容易控制資料的真實性和數量
當提取資料時，由於伺服器本身是發起連線的伺服器，因此我們可以確定資料的真實性。我認為這使資料路徑更加清晰，因為當今大多數使用者的公共
ip位址後面都有路由器，因此我們很容易會誤解資料是否真正來自。
讓我嘗試澄清這一點。對於基於
tcp拉式的系統，需要直接訪問度量，即，度量資料可用的埠始終在偵聽，而在基於推的系統中，使用臨時連線，這些連線會消失並很快出現。
而且，由於預先知道從中收集度量資料的確切目標，因此可以更輕鬆地計畫基於拉式系統的容量。另一方面，在基於推送的系統上，任何型別的系統都可以推送到度量標準收集伺服器。可以通過使用伺服器白名單來解決此問題，從該伺服器接受資料，但大多數基於推送的系統均不支援。另外，我們正在考慮兩個不同模型的特徵，而不是它們的實現。
支援推送：更容易實現對不同攝入點的複製
由於所有操作都是由客戶端本身啟動的，因此將相同的流量複製到不同的伺服器變得更加容易。您只需要將其傳輸到多個目標
ip位址即可。
基於推送的最流行的監視系統之一
它的組成部分之一
-carbon-
具有複製因子，中繼方法等內容，這使得開始進行此類操作變得容易。這樣做比站起來另乙個例項（例如
prometheus
）要容易得多。
另外，請考慮所有接收器將獲得相同的準確資料這一事實。如果您要啟動兩個不同的
prometheus
例項（使用
方法），則它們很可能將沒有相同的確切資料。
首先，時間戳會有所不同。對於
graphite
，時間戳必須在資料內部編碼（在
prometheus
中是可選的）。此外，時間序列的值很可能會有所不同，因為由於在開始刮刮時增加了抖動，因此刮刮的大部分時間不會同時發生。
支援拉動：更容易加密流量
將tls
終止反向**置於提供度量標準的普通
伺服器之前非常容易，如果它是面向公眾的系統或來自私有
ca的證書，我們甚至可以使用
letsencrypt
之類的方法自動獲取證書內部網上的每個人都信任。像
caddy
這樣的軟體使它變得盡可能容易。
是的，也可以使用客戶端
tls，但是它容易出錯，並且給**庫增加了很多混亂。你會喜歡什麼：
大多數人會選擇第乙個選項。為什麼在客戶端軟體上執行此加密是乙個壞主意的原因，與通常在客戶端
tls上執行錯誤的原因相同。例如，您可以檢視
本文的原因。此外，
本答案由
多項式＃2：
主要原因是
95％的網際網路使用者不知道客戶端證書是什麼，更不用說如何使用它了。有些使用者勉強可以使用使用者名稱和密碼，而大多數使用者仍然不用擔心雙重身份驗證。將客戶端證書安裝在單獨的裝置（台式電腦，膝上型電腦，平板電腦，智慧型手機等）上以對單個服務進行身份驗證也很麻煩。
我認為程式設計師或多或少都適用於同樣的故事。而且，我們也希望將這種加密複雜性從客戶端**移到單獨的伺服器中。這僅對於基於拉的模型是可行的。
支援推送：易於建模壽命短的批處理作業
在push
方法中，客戶端本身將度量標準推送到伺服器。另一方面，在拉方法中，伺服器會定期探測客戶端並收集其指標。在普羅公尺修斯，這稱為刮擦期。這會帶來（痛苦的）結果
-如果客戶端的生存期不超過該時間段，則指標將丟失。此圖說明了迴圈的工作方式，例如： 在
push
方法中，我們對此沒有問題，因為只要批處理作業完成，我們就可以傳送指標。當然，普羅公尺修斯試**決這個問題。我們擁有所謂的
pushgateway。
本質上，它是度量標準的接收者，該度量標準會定期被
prometheus
中的prometheus aka graphite
刮取。它的工作方式也與
石墨出口商相同。
但是，它們有自己的問題。例如，如果推送閘道器出現故障，指標可能會消失。否則，如果客戶端更新它們的速度比
prometheus
抓取它們的速度足夠快，則度量值可能會丟失。
推方法和
graphite
（擴充套件）不會遇到此問題。
支援拉取：更輕鬆地按需檢索資料（和除錯）
在tcp
）之上具有
pull
方法意味著很容易按需檢索資料並除錯問題。特別是，如果度量資料像
prometheus
所使用的格式一樣易於閱讀且易於理解。
這使您有機會輕鬆地區分客戶端和伺服器端的錯誤。在
push
方法中，我們的雙手會被綁在背後，因為如果我們沒有收到任何指標，則意味著兩件事之一： 使用
）方法，我們只需通過
web瀏覽器轉到可以找到指標資料的
ip位址和埠，就可以輕鬆地在這兩者之間進行檢查。
如果我們要重置
tcp連線，則意味著網路正常，但是客戶端出了點問題。如果我們什麼都沒得到回應，那意味著網路出了點問題。當然，這取決於客戶端在關閉埠時傳送回
tcp_rst
，但這就是大多數計算機的行為。
有利於推動：可能會更有表現
推方法通常使用
udp，而拉方法則基於
tcp（
）。這意味著我們有可能更有效地推動指標而不是拉動指標。這是由於以下事實：管理
udp連線的開銷更少。例如，不需要檢查您傳送給對等方的訊息是否已實際收到並且以正確的順序接收。
但是，隨著對
tcp的支援已經滲透到許多商用網絡卡中，並且使用硬體加速的作業系統無處不在，例如，開銷可能不像
90年代那樣大。
結論
這兩種模型都各有利弊。但是，基於拉的模型似乎可以勝出，因為它提供了更高的可靠性（尤其是在談論非常大規模的部署時），並且它僅需要很少的解決方法即可滿足所有可能的度量收集需求案件。 諸如
prometheus
之類的系統成為
borgmon
監視系統的後代非常流行的原因可能並非沒有原因。而且，眾所周知，
borgmon
被用來監視
稱為borg
的工作排程系統，後來成為大家都知道並喜歡的系統
kubernetes。
監控資料的採集
監控資料有多種形式 有些系統會持續地輸出資料，而其他系統只會在發生罕見事件時生成資料。有些資料能夠直接定位問題，有些資料能幫助調查問題。更寬泛的說，擁有監控資料是觀察系統工作狀況的必要條件。無論採集什麼形式的監控資料，核心要點都是一樣的 採集資料的開銷很小，但是如果在需要的時候沒有資料，代價可就大了...
直播Android推流外部資料採集
有些研發能力比較強的客戶，會有自定義影象處理的需求 比如自定義影象濾鏡 同時又希望復用rtmp sdk的整體流程，如果是這樣，您可以按照如下攻略進行定製。custommode txliveconstants.custom mode audio preprocess 可以和video preproce...
監控軟體 資料採集方式
目前流行的監控資料採集方式通常有兩種 主動方式和被動方式。主動方式主要通過監控終端 伺服器直接訪問被監控物件的方式獲取監控資訊。此方式由於需要跨越防火牆，對技術的要求比較高，實現起來比較複雜，特別是當監控終端安裝了不同的防火牆軟體時，實現起來極其困難。並且由於監控伺服器需要對多台監控終端進行監控，當...