prometheus的協助方案thanos

prometheus作為一站式監控方式（程式包含抓取，儲存，sql查詢等等功能）被大家廣泛接受，如果作為一個短期或者一段時期的監控，他的功能非常齊全，在小規模的採集中，完全不需要依賴其他元件就可以達到監控的目的，這裡說的是監控的目的，接入grafana那個是展示的部分。但是應對大叢集，大資料量的情況，他的表現如何，需要我們帶著這個問題分析一下。

prometheus的不足

• 弱叢集化
  prometheus的方案和資料庫類似，主要是水平的切割，例如1w的叢集，10臺prometheus抓取，那麼一臺prometheus負責抓取100個程式。可能有人會提出prometheus是有聯邦模式的，叢集的部署方式如下，為了保證高可用，一個程式的資訊被兩臺或者更多的prometheus抓取，這樣即使當機了一臺，其餘兩臺可以繼續工作。這裡必須說明的是，這樣的多活其實是多次抓取，算不上一個資料的同步過程了，因為3臺prometheus抓取同一個程式3次，很可能是取到的是三個狀態，有明顯的ABA的問題，但是在監控中，這個是可以接受的，只要不是一直維護的狀態，瞬間的變化並不會帶來影響，典型的cpu飆高，1毫秒上升到90%然後下降，這個狀態，是否能捕捉到並不影響我們診斷。最後多臺prometheus相當於一個叢集，用一個只讀的prometheus去代理查詢就可以了。這個叢集的方案確實不是什麼特別好的方案。
• 資料沒有保障
  之所以說上面的方案不是一個很好的方案，是因為資料是分散在多臺prometheus的。在變動或者長期儲存的時候，他依賴了本地磁碟，這個是一個很嚴重的問題，本地磁碟並不是一個高可用的儲存方案，他的資料變的沒有保障。

thanos的功能補充

thanos的存在則補充了上面的一些問題。
thanos query 專業做查詢排程的元件，角色相當於代理只讀的prometheus。
thanos sidecar 接受query查詢的載體，他有兩個功能，一個是作為prometheus的代理，如果有查詢過來，是透過 sidecar與prometheus進行互動，而不是直接和prometheus互動，另外一個是搬運prometheus的資料到高可用的檔案系統裡。
thanos compactor 可以做壓縮和下采樣，由於prometheus自身其實是有這種功能的，這個元件就相當於是一個叢集環境下的一個專業的元件吧。
thanos store 這個元件相當重要，我們的資料儲存到一個高可用的儲存裡的時候，prometheus是無法直接讀取查詢的，這樣就必須出現一個可以讀取高可用系統檔案的角色，這就是store。query發起查詢的時候，會給store和sidecar，在查詢角度看store和sidecar都是一種可以返回結果的代理。

解決的方式

資料沒有保障的問題，就是透過sidecar把他傳送到高可用的儲存系統裡，這樣就保障了資料的可靠性。
現在再來分析這個系統，叢集化方案更完美了。prometheus主要變成了一個儲存一段時間資料的載體。
thanos store是可以根據時間做分片的，我們現在看這個系統，就是根據時間分片，現在看整個時間的跨度，變成了多個store和一個sidecar。最終組成了整個時序的資料，資料已經有了橫向和縱向的切割，水平方向分prometheus抓取，縱向分時間查詢，這樣就很好的保證了資料的量的減少，並且提高了資料查詢的並行度，例如查詢5天的資料，store可以變成1到2一個區間，3到5一個區間，查詢的時候2個store可以同時工作查詢，而且更好的利用compactor進行資料的壓縮和下采樣，讓資料點更少了。資料最終彙集到query，query會進行整理和去重。
這裡需要解釋一下為什麼要去重，prometheus的高可用主要靠的是多活，但是帶來的一個問題是他的資料會被採集多分，我們要的只是一個程式的一個時間序列而已，並不需要重複的資料，例如三個prometheus就有會出現三個類似接近的時間序列，去重主要是應對這種狀態的，還有就是store分割的有重複也會帶來重複的資料，因為store是可以做相對時間的切分的，例如最近1d的資料，最近2d的資料，這就需要一個同步資料的過程，最好的做法就是邊界都帶上，保證在查詢的時候不會因為大家的同步的程度不一樣，導致邊界的資料丟失的情況。