Prometheus 之 發展史與添加監控

1、K8S監控系統的發展史

初版：Cadvisor+InfluxDB+Grafana

只能從主機維度進行採集，沒有Namespace、Pod等維度的匯聚功能

第二版：Heapster+InfluxDB+Grafana

heapster負責調用各node中的cadvisor接口，對數據進行彙總，而後導到InfluxDB ， 能夠從cluster，node，pod的各個層面提供詳細的資源使用狀況。

第三版：Metrics-Server + Prometheus

• Resource Metrics
  對應的接口是 metrics.k8s.io，主要的實現就是 metrics-server，它提供的是資源的監控，比較常見的是節點級別、pod 級別、namespace 級別、class 級別。這類的監控指標均可以經過 metrics.k8s.io 這個接口獲取到

• Custom Metrics
  對應的接口是 custom.metrics.k8s.io，主要的實現是 Prometheus， 它提供的是資源監控和自定義監控，資源監控和上面的資源監控實際上是有覆蓋關係的。

Metrics Server 與 Cadvsior 與 Cgroup 關係

Metrics Server 做爲標準的 Kubernetes API 把監控數據暴露出來的服務，好比獲取某一Pod的監控數據；不管是 heapster仍是 metric-server，都只是數據的中轉和聚合，二者都是調用的 kubelet 的 api 接口獲取的數據（prometheus-adapter也是調用kubelete api），而 kubelet 代碼中實際採集指標的是 cadvisor 模塊；cadvisor獲取指標時實際調用的是 runc/libcontainer庫，而libcontainer是對 cgroup文件 的封裝，即 cadvsior也只是個轉發者，它的數據來自於cgroup文件。
cgroup文件中的值是監控數據的最終來源，

如：mem usage的值

對於docker容器來說，來源於
/sys/fs/cgroup/memory/docker/[containerId]/memory.usage_in_bytes
對於pod來說
/sys/fs/cgroup/memory/kubepods/besteffort/pod[podId]/memory.usage_in_bytes

2、經常使用集羣監控要求

• 內部系統組件的狀態：好比 kube-apiserver、kube-scheduler、kube-controller-manager、kubedns/coredns 等組件的詳細運行狀態
• Kubernetes 節點的監控：好比節點的 cpu、load、disk、memory 等指標
• 業務容器指標的監控（容器CPU、內存、磁盤等）
• 編排級的 metrics：好比 Deployment 的狀態、資源請求、調度和 API 延遲等數據指標

3、添加監控服務的要求與格式標準

一、知足監控條件要求
不管是業務應用仍是k8s系統組件，只要提供了metrics api，而且該api返回的數據格式知足標準的Prometheus數據格式要求便可。

二、Prometheus格式標準

4、將以上coredns提供的對外監控服務添加到Prometheus監控

一、原有prometheus配置文件

二、在當前prometheus配置文件下，添加以下內容

- job_name: 'coredns'
      static_configs:
      - targets: ['10.96.0.10:9153']

三、從新應用該配置文件apply

5、查看監控狀況