據Sysdig發佈的容器報告，容器以及如Kubernetes等編排工具的使用增長了５１％以上，大家開始將工作負載在集羣中進行託管並管理。鑑於集羣中短暫的狀態，對於端到端的集羣有一個十分重要的需求，即能夠詳細監控節點、容器以及pod。
IT工程師需要管理應用程序、集羣（節點和數據），並且需要減少手動配置service、目標和數據存儲的工作量，同時在應用程序每次關閉和返回時進行監控。這就需要一個無縫部署以及管理高可用監控系統（如Prometheus），其中可以與Operator一起處理抓取目標的動態配置、服務發現以及用於告警集羣中各種目標的配置規則。同時，使用Operator模式編寫代碼以減少人工干預。
本文，我們將關注Prometheus Operator是如何工作的，service monitor在Prometheus Operator中是如何發現目標和獲取指標的。
在集羣監控中Prometheus Operator所扮演的角色
-
能夠使用原生Kubernetes配置選項無縫安裝Prometheus Operator
-
能夠在Kubernetes命名空間中創建和摧毀一個Prometheus實例，某個特定的應用程序或者團隊能夠輕鬆地使用Operator
-
能夠預配置配置文件，包括Kubernetes資源的版本、持久性、保留策略和replica
- 能夠使用標籤發現目標service，並根據熟悉的Kubernetes標籤查詢自動生成監控目標配置。
例如：當pod /service銷燬並返回時，Prometheus Operator可以自動創建新的配置文件，無需人工干預。
在Operator模式下所需的組件
- Custom Resource Definition（CRD）：創建一個新的自定義資源，包括可指定的名稱和模式，無需任何編程。Kubernetes API提供和處理自定義資源的存儲。
- 自定義資源：擴展Kubernetes API或允許將自定義API引入kubernetes集羣的對象。
- 自定義控制器：以新的方式處理內置的Kubernetes對象，如Deployment、Service等，或管理自定義資源，如同管理本機Kubernetes組件
- Operator模式（適用於CRD和自定義控制器）：Operator基於Kubernetes資源和控制器增加了允許Operator執行常見應用程序任務的配置。
![實操案例：使用Prometheus Operator進行集羣監控]()
Operator的工作流程
Operator在後臺執行以下操作以管理自定義資源：
1、CRD創建：CRD定義規範和元數據，基於該規範和元數據應創建自定義資源。當創建CRD的請求時，使用Kubernetes內部模式類型（OpenAPI v3模式）驗證元數據，然後創建自定義資源定義（CRD）對象
2、自定義資源創建根據元數據和CRD規範驗證對象，並相應地創建自定義對象創建。
3、Operator（自定義控制器）開始監控event及其狀態變更，並基於CRD管理自定義資源。它可以提供event在自定義資源上執行CRUD操作，因此每當更改自定義資源的狀態時，都能被觸發相應的event。
服務發現及自動配置獲取的目標
Prometheus Operator使用Service Monitor CRD執行自動發現和自動配置獲取的目標。
ServiceMonitoring包括以下組件：
-
Service：實際上是service/deployment，它在定義的端點、端口暴露指標，並使用對應的標籤進行標識。每當service或pod發生故障時，該service以相同的標籤返回，因此使得它可被service monitor發現。
-
Service Monitor：可基於匹配的標籤發現service的自定義資源。Servicemonitor處於部署了Prometheus CRD的命名空間中，但通過使用NamespaceSelector，它依舊能夠發現部署在其他命名空間中的service。
-
Prometheus CRD：基於標籤與service monitor相匹配並且能夠生成Prometheus的配置。
- Prometheus Operator：它可調用config-reloader組件以自動更新yaml配置，其中包含抓取目標的詳細信息。
![實操案例：使用Prometheus Operator進行集羣監控]()
接下來我們來看一個簡單的使用案例，以此理解Prometheus Operator時如何監控service的。
使用案例：使用Prometheus Operator進行Gerrit服務監控
Gerrit是一個代碼review工具，主要用於DevOps CI流水線，在代碼入庫前對每個提交進行審閱。本文假設Gerrit已經在Kubernetes集羣中運行，因此不再贅述Gerrit在Kubernetes作爲服務運行的步驟。
如果你還沒有Prometheus Operator，可以使用helm chart來安裝或直接使用Rancher，在Rancher2.2及以上的版本中，Rancher會在新添加的集羣中部署一個Prometheus Operator。以下組件將會被默認下載安裝：
-
prometheus-operator
-
prometheus
-
alertmanager
-
node-exporter
-
kube-state-metrics
-
grafana
-
service monitors to scrape internal kubernetes components
kube-apiserver kube-scheduler kube-controller-manager etcd kube-dns/coredns
以下步驟將展示Prometheus Operator如何自動發現運行在Kubernetes集羣上的Gerrit服務以及如何從Gerrit中抓取指標。
使用Gerrit-Prometheus插件暴露指標
可以使用Prometheus jar插件暴露Gerrit指標，但需要提前將該插件安裝在Gerrit實例上運行。
-
Prometheus jar插件下載地址：
-
https://gerrit-ci.gerritforge.com/ ，將jar放在Gerrit插件目錄中：/var/gerrit/review_site/plugins/，並重啓gerrit服務。
-
在管理員的web界面校驗Prometheus插件：Gerrit -> Plugins -> Prometheus plugin。
-
創建一個賬號和組並給予查看指標的訪問權限
-
以管理員權限登錄到Gerrit的web界面，訪問：Projects>List>All-Projects。點擊【Access】標籤，再點擊【edit】按鈕。
-
在block global capabilities中，點擊【Add Permission】並且在下拉列表中選擇【View Metrics】。
-
在Gerrit中爲用戶生成一個token。
-
選擇我們此前創建的組“Prometheus Metrics“，點擊【Add】按鈕。
- 滑至頁面底部並點擊【Save Changes】按鈕。
![實操案例：使用Prometheus Operator進行集羣監控]()
創建secret以訪問Gerrit服務
-
在Gerrit中生成token之後，你可以使用用戶id和token來生成Base64編碼格式的用戶id和token，用於將憑證存儲在Kubernetes中。
-
使用secret的詳細信息創建一個yaml並在Kubernetes中創建secret。
kubectl apply -f gerrit-secret.yaml
![實操案例：使用Prometheus Operator進行集羣監控]()
將標籤應用到服務
使用兩個標籤標記Gerrit服務，例如：app: gerrit and release: prometheus-operator
kubectl label svc gerrit app=gerrit release=prometheus-operator
爲Gerrit創建Service Monitor
在servicemonitoring添加端點的詳細信息以發現Gerrit服務指標以及具有匹配標籤的的selector，如下所示：
帶標籤的service selector
Selector下的標籤是用於標識服務的標籤：
Selector:
matchLabels:
app: gerrit
release: prometheus-operator
ServiceMonitor selector
元數據部分下的標籤是指用於通過Prometheus CRD識別服務監視器的標籤。
Metadata:
labels:
app: gerrit
release: prometheus-operator
Namespaceselector：在Gerrit服務所運行的Kubernetes集羣中提供命名空間。Service可以在任何命名空間中運行，但service monitor只能在Prometheus Operator運行的命名空間創建，這樣Prometheus CRD就可以識別service monitor對象。
在Prometheus中匹配Service Monitor selector
使用以下命令驗證Prometheus對象中Service Monitor selector的部分：
kubectl get prometheus
Match and apply the label as given in step 4b for the Prometheus object.
serviceMonitorSelector:
matchLabels:
release: prometheus-operator
注意：如果Prometheus-operator使用helm部署，標籤release=Prometheus-operator已經應用到Prometheus對象上。我們依舊需要在service monitor中匹配這個標籤，因爲Prometheus CRD需要確定合適的service monitor。
以上servicemonitor創建步驟可以使用prometheus-operator helm自定義values.yaml來完成。
自動發現Gerrit服務
標籤更新之後，Prometheus自定義對象將會自動調用config-reloader來讀取終端並更新Prometheus配置文件。這是Prometheus Operator的一個好處，無需手動介入創建Prometheus配置文件和更新抓取的配置。
1、 打開Prometheus url：http://prometheusip:nodeport
kubectl get svc prometheus以獲取nodeport詳細信息並用節點的詳細信息來替代IP。
2、 訪問菜單：Status -> Configuration，來查看使用抓取配置自動加載的Prometheus配置。在scrape_configs部分，可以查看Gerrit service monitor的詳細信息，如下所示：
3、 訪問菜單 -> Status -> Targets or Service Discovery。如果service monitor已經成功抓取Gerrit的指標，目標應該顯示爲健康[1/1up]。
在Grafana中的Gerrit 健康指標
Gerrit暴露了各種指標，如JVM運行時間、線程內存、heap size、error等。這些都可以在Grafana儀表板中配置以監控Gerrit的性能和運行狀況（如下所示）。
Gerrit指標在scrape url下暴露：
http://gerrit-svcip:nodeport/a/plugins/metrics-reporter-prometheus/metrics
kubectl get svc prometheus-獲取service 節點端口。
將gerrit-svcip、nodeport替換爲gerrit服務的gerrit IP / nodeport的詳細信息，暴露的指標將如下所示。
指標的值可以在Prometheus -> Graph 中的表達字段進行評估，如：caches_disk_cached_git_tags
在Grafana中配置指標以監控Gerrit的健康狀況，選擇數據源爲Prometheus並在dashboard中配置widget。一些已經配置的關鍵指標有JVM_threads、Uptime、Http_Plugin errors、內存使用情況、事件等。
Prometheus Operator有助於Prometheus的無縫部署和管理、抓取目標的動態配置、服務發現、可擴展性、以及內置的SRE專業知識，這可以加速集羣監控。
開箱即用的Prometheus
2018年年末，Rancher Labs宣佈加強對Prometheus的支持，這將爲跨多個Kubernetes集羣和多個隔離租戶環境提供更高的可見性。在Rancher2.2及以上的版本中，每當添加一個新的Kubernetes集羣到Rancher中，Rancher都將在集羣中部署一個Prometheus operator，然後在集羣中創建一個Prometheus部署。此外，還支持以下兩個功能：
-
集羣範圍內的Prometheus部署將被用於存儲集羣指標（如CPU節點和內存消耗），並存儲從單個用戶部署的應用程序中收集的項目級指標。
- 項目級的Grafana與Prometheus的通信將通過安全代理完成，該代理可爲Prometheus實現多租戶。安全代理工具PromQL語句可確保僅能通過用戶項目的命名空間進行查詢。
Rancher對Prometheus的增強支持，可確保爲所有Kubernetes集羣、所有項目和所有用戶進行高效的部署和有效的監測。安全代理確保不在多租戶之間重複共享數據，並且對多租戶進行隔離。除此之外，Rancher還收集使用Prometheus處理的數據公開端點的任意自定義指標。所有指標均可用於Rancher內部的告警和決策，通過通知用戶的Slack及PagerDuty進行簡單操作，通過啓動工作負載的橫向擴展最終增加負載進行復雜操作。Rancher現在還擁有完全安全隔離和RBAC的集羣級和項目級的指標和儀表盤。