阿里雲容器Kubernetes監控(七) - Prometheus監控方案部署

摘要： 前言 Prometheus是一款面向雲原生應用程式的開源監控工具，作為第一個從CNCF畢業的監控工具而言，開發者對於Prometheus寄予了巨大的希望。在Kubernetes社群中，很多人認為Prometheus是容器場景中監控的第一方案，成為容器監控標準的制定者。在本文中，我們...

前言

Prometheus方案的解析

在解析Prometheus容器監控方案之前，我們先要確定在Kubernetes中需要監控的物件包含什麼？對於一個監控系統而言，常見的監控維度包括：資源監控和應用監控。資源監控是指節點、應用的資源使用情況，在容器場景中就延伸為節點的資源利用率、叢集的資源利用率、Pod的資源利用率等。應用監控指的是應用內部指標的監控，例如我們會將應用線上人數進行實時統計，並通過埠進行暴露來實現應用業務級別的監控與告警。那麼在Kubernetes中，監控物件會細化為哪些實體呢？

1. 系統元件
   kubernetes叢集中內建的元件，包括apiserver、controller-manager、etcd等等。
2. 靜態資源實體
   主要指節點的資源狀態、核心事件等等
3. 動態資源實體
   主要指Kubernetes中抽象工作負載的實體，例如Deployment、DaemonSet、Pod等等。
4. 自定義應用
   主要指需要應用內部需要定製化的監控資料以及監控指標。

對於靜態資源實體和系統元件而言，大家可能非常好理解，他們的監控方式也比較簡單，只需要在配置檔案中指明即可。那麼如何處理動態的資源實體監控呢？對於這種需要動態感知監控端點的場景，prometheus提出了自己的解決方案 - prometheus operator。prometheus operator是 CoreOS 開源的一套用於管理在 Kubernetes 叢集上的 Prometheus 控制器，它是為了簡化在 Kubernetes 上部署、管理和執行 Prometheus 和 Alertmanager 叢集。

簡單的講，prometheus operator的作用通過CRD的方式將需要動態監聽的實體進行定義，並通過監聽apiserver中實體的變化，實現prometheus中動態更新配置與報警規則。用更通俗的話講就是，通過prometheus operator的方案，可以讓prometheus的監控物件變成自動生成的，開發者無需額外配置監控任務，即可實現動態實體的監控。

prometheus監控方案的主體是prometheus operator，為了滿足Kubernetes中的監控場景，Prometheus方案在prometheus之上作了很多的擴充套件，主要包含如下元件：

• prometheus-server：資料儲存以及監控資料聚合
• prometheus-config-reloader：動態更新prometheus配置
• rules-configmap-reloader：動態更新prometheus報警配置
• alert manager：報警元件
• node-exporter：節點資源資訊採集元件
• kube-state-metrics：動態發現endpoint，三方監控的核心元件
• prometheus-operator：prometheus配置的operator
• grafana：資料展現

部署Prometheus監控方案

1. 在叢集的master節點執行程式碼下載

git clone https://github.com/AliyunContainerService/prometheus-operator

和社群的prometheus-operator相比，阿里雲的版本做了少許的定製，並會定期同步最新版本。

2. 部署Prometheus監控方案

cd contrib/kube-prometheus
kubectl apply -f manifests

3. 檢視部署結果

預設情況下由於安全的原因，Prometheus、AlertManager與Grafana都沒有開放公網訪問，開發者可以通過本地的Proxy方式檢視。具體方式如下：首先在容器服務控制檯下載kubeconf到本地。

訪問prometheus可以在本地執行如下命令

kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

此時訪問本地的 localhost:9090 ，即可使用prometheus。

選擇Status下的Target檢視所有采集任務，如果所有的狀態都是up，表明採集任務都已經執行。

4. 檢視資料聚合與展現

訪問grafana可以在本地執行如下命令，預設的使用者名稱密碼為admin/admin，訪問本地的 localhost:3000 ，登陸並選擇相應的dashboard，即可檢視相應的聚合內容。

kubectl --namespace monitoring port-forward svc/grafana 3000

5. 檢視告警規則與告警壓制

在Prometheus的Alerts類目中可以檢視當前的報警規則，紅色的規則表示正在觸發報警，綠色的規則表示狀態正常，預設prometheus operator會自動建立一批報警規則。

如果需要設定報警壓制，需要訪問Alter Manager，可以在本地執行如下命令，訪問本地的 localhost:9093

kubectl --namespace monitoring port-forward svc/alertmanager-main 9093

點選 Silence 可以設定報警壓制的內容。

定製Prometheus監控方案

看到這裡很多開發者會提出一個疑問，這麼多內容是否可以進行定製？答案是肯定的，標準的Prometheus是通過配置檔案來實現，傳統中對於容器中的配置檔案變化處理是非常麻煩的，因為配置的變化需要重啟應用甚至容器，而且還需要提前將檔案拷貝到主機上。我們先拋開Prometheus這件事情，先想想Kubernetes中是怎麼解決的，在Kubernetes中所有的實體操作都可以通過Yaml變更來進行實現。那麼Prometheus的配置是否可以通過類似的方式下發呢？

答案是肯定的，這就是Prometheus operator做的事情，他將操作Promtheus的一些動作變得更有kubernetes的味道。

我們回到最開始部署的命令：

kubectl apply -f manifests

manifests是本次部署的所有內容檔案，當我們深入到目錄中的具體檔案時，就會發現一些熟悉的內容。例如 prometheus-rules.yaml 這個檔案，內容如下：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
prometheus: k8s
role: alert-rules
name: prometheus-k8s-rules
namespace: monitoring
spec:
groups:
- name: k8s.rules
rules:
- expr: |
sum(rate(container_cpu_usage_seconds_total{job="kubelet", image!="", container_name!=""}[5m])) by (namespace)
record: namespace:container_cpu_usage_seconds_total:sum_rate

此處有一個特殊的抽象叫 PrometheusRule ，這就是 prometheus-operator 定義的的CRD，在rules欄位中是定義的具體的報警規則與方式。因此，如果要修改prometheus中的報警規則，只需要修改這個yaml，並重新apply即可。

Prometheus不是“銀彈”

Prometheus的方案相比社群中Heapster(Metrics Server)的方案而言更加強大。但是也並非沒有缺點，常常被開發者詬病的缺點主要有如下幾個。

• 效能差
  首先對於Prometheus而言，是一個拉取模式的採集系統，而拉取式的系統通常會有一個通病，就是資料提供方的資料量級問題。推送資料的時候，我們可以根據資料的量級分批，分次進行推送。而拉取通常是全量資料的同步。此外相比傳統的監控系統的資料儲存Prometheus自身的儲存資料格式效能還是很低下的。這會導致在叢集量級比較大的情況下，Prometheus的CPU、記憶體、磁碟、網路都存在較高的利用率。Prometheus本身是單點的架構，雖然社群中已經有叢集的模式，但是依然不夠成熟，使用Promehteus的開發者要做好熱備多活的思想準備，使用資源冗餘的方式來保證系統穩定。
• 元件過多
  剛才我們已經看到一個標準的Prometheus方案會涉及的元件部分，這些元件大部分都是不可缺少的，這也會導致部署這個方案後，需要額外維護很多監控相關的元件，維護的成本較高。
• 學習成本高
  Kubernetes的風格固然能夠成為一種標準表達和執行的正規化，但是對於監控而言，後續有些過於激進，本身Prometheus的學習成本已經較高，加入CRD的方式，會使學習的成本變得更高。
• 擴充套件性差
  表面上看Prometheus定義了CRD可以進行擴充套件，但是從Prometheus本身而言，缺乏外掛的機制進行擴充套件，從程式碼外直接擴充套件則會增加整體架構的複雜，相比zabbix、grafana或者heapster等等監控相關工具的擴充套件方式，Prometheus還有很長的路要走。
• 監控指標不準確
  這個問題是從Prometheus監控制定開始就存在的問題，由於kubelet的資料指標不是實時的，而Prometheus的資料採集會丟失時間戳，這會導致非常異常的利用率曲線。具體的描述，可以參考如下兩個PR ofollow,noindex">2059 與 2028

最後

雖然Prometheus有很多的缺點，但是他依然是Kubernetes社群中監控領域的重要一環，開發者可以根據自己的需求來選擇合適的方案。對於大部分的開發者而言，內建的 Heapter（Metrics Server) 與雲監控整合的方案已經可以解決80%的基礎問題了，未嘗不是一個便捷的選擇。Prometheus的未來依然是光明的，阿里雲也會和社群一起，推進Prometheus的演進，提供更好的Prometheus監控方案。