thanos元件：
通用api:store api提供服務給查詢介面，通過grpc查詢prometheus的remote-read介面，rule的storeapi，store gateway的storeapi。
一、thanos query：
1、封裝prometheus query api，支援promql
2、暴露query服務，實現store api，可查詢來自四類endpoint的資料：
包括：rule節點record資料，sidecar節點prometheus原生資料，store gateway**的object storage資料，receiver收集到的資料。
3、無狀態，可水平擴充套件（高可用）
二、thanos sidecar
1、prometheus sidecar，實現store api，提供grpc給query元件進行指標查詢；
2、使用時與prometheus放在乙個pod裡，共享生命週期；
3、prometheus每兩個小時把資料存到硬碟一次，此時sidecar shipper同時把資料上傳到物件儲存；
4、此方案，如果prometheus節點down，會丟失最近兩個小時的資料；
三、thanos receiver
1、在prometheus remote-write基礎上實現；
2、prometheus服務會把資料實時寫到receiver；
3、receiver可分布式部署，實現一致性hash，（疑問：多個prometheus同時pull資料並上傳到receiver，配置了external_labels，receiver是否能夠實現一致性hash進行去重；）
4、此方案，乙個prometheus down掉以後，仍然保證資料完整，目前thanos還沒有推出比較穩定的版本。
5、receiver也會把資料寫入object storage。（疑問：什麼時候，什麼頻率）
6、遠端寫的同時，prometheus本地磁碟依然會寫入資料。
四、thanos store gateway
1、query查詢object storage資料的唯一入口；
2、實現query api；
3、快取物件儲存索引，優化查詢。
五、compactor
1、單例
2、object storage資料壓縮
3、object storage資料降取樣，個人理解就是把資料重新整理，生成取樣間隔更長的資料block，並上傳至物件儲存，可優化查詢。
4、官方推薦100g磁碟空間用作臨時資料處理空間
5、上傳deletion-mark.json來標記刪除物件儲存裡的block，三個重要引數–retention.resolution-raw，–retention.resolution-5m，–retention.resolution-1h
六、thanos rule
1、類似於prometheus的rule，可根據配置檔案提前生成使用者配置的metric，已經對altermanagement發去告警資訊；
2、rule聚合生成的資料也會上傳至object storage；
3、rule的資料來源是通過thanos query至prometheus查詢到的，可見於thanos query互相查詢。
thanos高可用多prometheus是如何部署的?
1、prometheus多副本。
個人理解：多副本可以達到高可用，也可以多副本採集不同分割槽的資料，可以減少儲存。
thanos本身高可用是如何部署的?
1、thanos query水平擴充套件，thanos receiver分布式部署，一致性hash，thanos gateway可以水平擴充套件
指標是水平分片還是主備冗餘還是多副本同時提供服務?
1、sidecar：指標會冗餘儲存，查詢的時候去重
2、receiver一致性hash，去重（有疑問，由於標籤不同，應該不會去重）
3、多副本同時提供服務
物件儲存如何部署? minio是什麼？
1、minio是物件儲存，相容aws s3模式
可以儲存多久的歷史資料?
1、理論上無上限
可以快速查詢多久的歷史資料?
1、採用降取樣，可以保證查詢效能。
熱資料儲存在**？儲存多久？開銷如何？
1、prometheus儲存兩個小時的資料在記憶體裡；
2、prometheus根據配置儲存資料在本地磁碟，receiver 接收資料在本地磁碟並定時上傳資料到物件儲存
thanos架構和原生prometheus架構共存，通過配置檔案切換
1、query語法相同，可通過配置檔案切換
故障/高可用測試(節點故障, 部分服務故障)
查詢效能測試(響應時間，當前資料和歷史資料)
寫入效能測試(高併發下寫延遲)
穩定性測試(連續執行一段時間)
prometheus:
1、四種資料型別，counter、gauge、histogram、summary，對於client無差別，因為prometheus server暫時未啟用資料型別；
2、exporter負責收集endpoint資料，例如：node_exporter，負責收集k8s集群node資料，專案採用daemonset資源型別，保證每個node只有乙個exporter副本；
3、exporter收集資料，server進行retrieval，整理成metric形式。可以對原生metric進行封裝生成自定義metric，至於metric是exporter生成還是server生成，不太清楚；
4、prometheus單節點執行，單副本，如果多副本，每個server會同時執行；
5、server具有自動的服務發現，個人理解，如果node上有兩個exporter，都會被發現並收集。
6、prometheus server資料儲存在pod本地儲存下，不做掛載持久化處理，會導致資料丟失。
thanos:
資料來源節點：prometheus sidecar prometheus rule node
metric data bachup:
頂級目錄：ulid，可按照字典順序檢索，編碼建立時間
chunk: metric name對齊
index：標籤查詢、所在chunk位置
meta.json: 統計範圍、時間範圍、壓縮級別
store: 索引快取，同步物件儲存塊，減少物件儲存訪問
query layer: store node、 sidecar、 rule查詢
compactor: 僅指向物件儲存，資料壓縮，降取樣，應用保留策略
擴充套件： 1、壓縮器
2、store gateway 時間分片 --min-time --max-time
compactor: 降取樣：生成額外的block，以便於統計更廣範圍的歷史資料
thanos query: promql發起，通過storeapi支撐，所以配置檔案需要制定store api的位址（grpc）
查詢目標可包括： prometheus sidecar，object storage（store gateway），rule裡面的資料，receiver裡面的資料
不同租戶可以使用不同prometheus例項
dedup：不是group by，類似於刪除label，應replica=a和replica=b被認為是一類資料
partial response: 某個store api錯誤不影響整體查詢，增加warnings欄位
sidecar: prometheus每兩小時儲存資料到tsdb時，sidecar shipper把資料寫入物件儲存
高可用： 1、業務拆分，多個sidecar對應多個bucket，多個store gateway**查詢
2、時間分片：多個store gateway分別查詢不同時間段的資料。
sidecar與receiver對比：sidecar利用remote read api，依賴於底層prometheus，如果prometheus掛了，丟失兩小時的資料，receiver利用remote write api，資料實時同步
使用thanos管理Prometheus持久化資料
關於thanos的介紹可以參考這篇官方部落格的翻譯文件，本文不作部署操作介紹。下圖是thanos的官方架構圖，主要有5個元件 通常thanos管理多集群時，除sidecar元件需要在每個集群內部署，其餘元件僅部署乙份，用於處理多個集群的資料。需要注意的是，thanos的storeapi採用的是grp...
thanos配置promethes高可用
prometheus官方的高可用有幾種方案 ha 即兩套prometheus採集完全一樣的資料，外邊掛負載均衡 ha 遠端儲存 除了基礎的多副本prometheus，還通過remote write寫入到遠端儲存，解決儲存持久化問題 聯邦集群 即federation，按照功能進行分割槽，不同的shar...
虛擬機器使用docker搭建Prometheus
docker pull prom node exporter docker pull prom prometheus docker pull grafana grafana docker run d p 9100 9100 v proc host proc ro v sys host sys ro ...