Google Managed Prometheus (GMP)
『千呼萬喚始出來，猶抱琵琶半遮面』，白居易的琵琶行，應該是對GMP一個蠻好的描述。
Google引領Kubernetes生態系已經不是新聞了，但在GCP的兩年，一直沒有使用CNCF裏最多人使用的監控技術：Prometheus，這一點一直很困擾我。我自己的解讀是因為Cloud上很久以前已經採用了StackDriver的監控機制，同時也有非常多不屬於容器的服務(e.g. BigQuery, CloudSQL等），如同Cloudwatch之於AWS，Google Cloud的整體監控就是StackDriver (a.k.a Monarch)，並提供類似PromQL的MQL語法，雖然可用，但仍覺得有些美中不足的地方。
在2022年初，千呼萬喚下終於開始有Managed Prometheus的服務出現了，身為CNCF粉絲，一定要來嚐新一下，有趣的是第一版為了因應不同使用習慣，還支援兩種模式。底下來跟大家說明一下技術架構，也順便以我的觀點跟捧油們分享什麼時候該用Cloud Monitoring，什麼時候該用GMP～
GMP架構說明
Google後台有一個很威的星球級別(全球性分散式）的內存時間序列資料庫，稱為Monarch。目前所有Google相關服務的資料收集後台，都是接入到Monarch裏。Prometheus不也是個時間序列資料庫(Time Series DB)嗎？是的，也因此在GMP的管理(Managed)模式底下，實際上Prometheus儲存的功能，就會轉移到Monarch，這個是GMP兩種模式都支援的後台，最大的價值：一個無限大的Time Series Database 取代目前大家使用的Prometheus與存儲空間。底下跟大家聊聊前面說到的兩種GMP子架構：Managed Collection Mode & Self-Deployed Collection Mode。
Managed Collection模式
- Enable Managed Collection in GKE
為了相容於前端Prometheus的資料注入方式，Managed模式提供一個Prometheus-Based Collector，這個Collector的設計，簡化了防火牆的需求，讓地端或是在Private VPC裡的叢集也不需要開啟外對內的防火牆，僅需要開放對Cloud Monitoring API的443 Port即可。Collector啟動可由以下指令開啟：
# 現有Cluster 可通過更新
gcloud beta container clusters update CLUSTER_NAME --enable-managed-prometheus --zone ZONE# 新Cluster
gcloud beta container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus
- Create PodMonitoring CRD
這個Collector的資訊採集模式，是依據PodMonitoring這個CRD所指定的matchLabels + endpoints，對服務Pod進行資料採集，並將採集的結果，通過Cloud Monitoring API轉發到Monarch裏，以下示範一個標準App Deployment與對應PodMonitoring的範例。
- [Optional] Replace GKE Infra Monitoring with Managed Prometheus
GKE內建了使用Cloud Monitoring收集Node, Pod, 僅需指定對的參數就可以自動開啟，這些參數也支援以PromQL方式查詢。但若希望連收集部分，都要使用PodMonitoring機制，我們也可以部署Node Exporter + Kube-State-Metrics等服務與對應的ClusterPodMonitoring/ PodMonitoring，詳細Yaml連結請見： [Node Exporter] & [Kube-State-Metrics].
- Deploy FrontEnd to Simulate Prometheus DB (for Grafana)
至於整合的部分，GMP還很貼心的提供一個相容於現有Prometheus Query API的Frontend 服務（下圖橘色部分），這個服務需要額外部署在叢集內，可作為Grafana Prometheus DataSource的來源，通過Grafana (UI)或是直接以PromQL查詢使用。
底下的範例是Frontend YAML，其中 query.project-id 這個args 主要指定所需要監控的專案（可指定一般服務專案，或是Scope Project)，GCP支援Scope Project的概念，意即設定一個監控專案，底下可包含其他專案的監控數據，提供一個Single-Pane of Glass的跨專案監控。query.credentials-file是service key file 必須具備對應Scope專案的roles/monitoring.viewer權限。
- Multi-tenancy Monitoring with GCP Scoped Project:
若要設定多租戶的監控環境，可以通過多個Scope專案的設定達成，下方是個三租戶的架構圖，詳細設定可見本連結：包含
- App-Team 1: 監控Project 1 & 2,
- App-Team 2: 監控Project 3 & 4,
- SRE Team: 監控Project 1 to 5
- 展示：底下展示一個Grafana加入Managed Frontend，並使用標準的Grafana Dashboard ID，快速添加不同的Dashboard的完整展示～
- Why Changed?
很多人會問說，除了Prometheus的開源性，有其他的誘因讓我們由Cloud Monitoring換到GMP嗎？事實上是有的，主要在於價格[Pricing]～
下表提供了一個有趣的比較，第一Row是Cloud Monitoring, 第二Row是GMP, 除了前面的150MiB, Cloud Monitoring的免費區間外，其餘只要每個Sample超過10bytes, GMP應該都會便宜得多。
舉個範例，假設每天收集1,000個參數，每30秒一次，一天就會產生約2,880,000個Sample, 一個月約86.4M samples。每個sample 50bytes,
- Cloud Monitoring會需要4.32GB/month的量，大概0.151x4,320=653USD.
- 但換算成GMP，0.15 x 86.4=13USD~
是不是很有誘因呢?
