從零開始入門 K8s | 可觀測性：監控與日誌

做者 | 莫源  阿里巴巴技術專家

1、背景

監控和日誌是大型分佈式系統的重要基礎設施，監控能夠幫助開發者查看系統的運行狀態，而日誌能夠協助問題的排查和診斷。

在 Kubernetes 中，監控和日誌屬於生態的一部分，它並非核心組件，所以大部分的能力依賴上層的雲廠商的適配。Kubernetes 定義了介入的接口標準和規範，任何符合接口標準的組件均可以快速集成。

2、監控

監控類型

先看一下監控，從監控類型上劃分，在 K8s 中能夠分紅四個不一樣的類型：

1.資源監控

比較常見的像 CPU、內存、網絡這種資源類的一個指標，一般這些指標會以數值、百分比的單位進行統計，是最多見的一個監控方式。這種監控方式在常規的監控裏面，相似項目 zabbix telegraph，這些系統都是能夠作到的。

2.性能監控

性能監控指的就是 APM 監控，也就是說常見的一些應用性能類的監控指標的檢查。一般是經過一些 Hook 的機制在虛擬機層、字節碼執行層經過隱式調用，或者是在應用層顯示注入，獲取更深層次的一個監控指標，通常是用來應用的調優和診斷的。比較常見的相似像 jvm 或者 php 的 Zend Engine，經過一些常見的 Hook 機制，拿到相似像 jvm 裏面的 GC 的次數，各類內存代的一個分佈以及網絡鏈接數的一些指標，經過這種方式來進行應用的性能診斷和調優。

3.安全監控

安全監控主要是對安全進行的一系列的監控策略，相似像越權管理、安全漏洞掃描等等。

4.事件監控

事件監控是 K8s 中比較另類的一種監控方式。以前的文章爲你們介紹了在 K8s 中的一個設計理念，就是基於狀態機的一個狀態轉換。從正常的狀態轉換成另外一個正常的狀態的時候，會發生一個 normal 的事件，而從一個正常狀態轉換成一個異常狀態的時候，會發生一個 warning 的事件。一般狀況下，warning 的事件是咱們比較關心的，而事件監控就是能夠把 normal 的事件或者是 warning 事件離線到一個數據中心，而後經過數據中心的分析以及報警，把相應的一些異常經過像釘釘或者是短信、郵件的方式進行暴露，彌補常規監控的一些缺陷和弊端。

Kubernetes 的監控演進

在早期，也就是 1.10 之前的 K8s 版本。你們都會使用相似像 Heapster 這樣的組件來去進行監控的採集，Heapster 的設計原理其實也比較簡單。

首先，咱們在每個 Kubernetes 上面有一個包裹好的 cadvisor，這個 cadvisor 是負責數據採集的組件。當 cadvisor 把數據採集完成，Kubernetes 會把 cadvisor 採集到的數據進行包裹，暴露成相應的 API。在早期的時候，其實是有三種不一樣的 API：

• 第一種是 summary 接口；
• 第二種是 kubelet 接口；
• 第三種是 Prometheus 接口。

這三種接口，其實對應的數據源都是 cadvisor，只是數據格式有所不一樣。而在 Heapster 裏面，其實支持了 summary 接口和 kubelet 兩種數據採集接口，Heapster 會按期去每個節點拉取數據，在本身的內存裏面進行聚合，而後再暴露相應的 service，供上層的消費者進行使用。在 K8s 中比較常見的消費者，相似像 dashboard，或者是 HPA-Controller，它經過調用 service 獲取相應的監控數據，來實現相應的彈性伸縮，以及監控數據的一個展現。

這個是之前的一個數據消費鏈路，這條消費鏈路看上去很清晰，也沒有太多的一個問題，那爲何 Kubernetes 會將 Heapster 放棄掉而轉換到 metrics-service 呢？其實這個主要的一個動力來源是因爲 Heapster 在作監控數據接口的標準化。爲何要作監控數據接口標準化呢？

• 第一點在於客戶的需求是變幻無窮的，好比說今天用 Heapster 進行了基礎數據的一個資源採集，那明天的時候，我想在應用裏面暴露在線人數的一個數據接口，放到本身的接口系統裏進行數據的一個展示，以及相似像 HPA 的一個數據消費。那這個場景在 Heapster 下能不能作呢？答案是不能夠的，因此這就是 Heapster 自身擴展性的弊端；

 

• 第二點是 Heapster 裏面爲了保證數據的離線能力，提供了不少的 sink，而這個 sink 包含了相似像 influxdb、sls、釘釘等等一系列 sink。這個 sink 主要作的是把數據採集下來，而且把這個數據離線走，而後不少客戶會用 influxdb 作這個數據離線，在 influxdb 上去接入相似像 grafana 監控數據的一個可視化的軟件，來實踐監控數據的可視化。

可是後來社區發現，這些 sink 不少時候都是沒有人來維護的。這也致使整個 Heapster 的項目有不少的 bug，這個 bug 一直存留在社區裏面，是沒有人修復的，這個也是會給社區的項目的活躍度包括項目的穩定性帶來了不少的挑戰。

基於這兩點緣由，K8s 把 Heapster 進行了 break 掉，而後作了一個精簡版的監控採集組件，叫作 metrics-server。

上圖是 Heapster 內部的一個架構。你們能夠發現它分爲幾個部分，第一個部分是 core 部分，而後上層是有一個經過標準的 http 或者 https 暴露的這個 API。而後中間是 source 的部分，source 部分至關因而採集數據暴露的不一樣的接口，而後 processor 的部分是進行數據轉換以及數據聚合的部分。最後是 sink 部分，sink 部分是負責數據離線的，這個是早期的 Heapster 的一個應用的架構。那到後期的時候呢，K8s 作了這個監控接口的一個標準化，逐漸就把 Heapster 進行了裁剪，轉化成了 metrics-server。

目前 0.3.1 版本的 metrics-server 大體的一個結構就變成了上圖這樣，是很是簡單的：有一個 core 層、中間的 source 層，以及簡單的 API 層，額外增長了 API Registration 這層。這層的做用就是它能夠把相應的數據接口註冊到 K8s 的 API server 之上，之後客戶再也不須要經過這個 API 層去訪問 metrics-server，而是能夠經過這個 API 註冊層，經過 API server 訪問 API 註冊層，再到 metrics-server。這樣的話，真正的數據消費方可能感知到的並非一個 metrics-server，而是說感知到的是實現了這樣一個 API 的具體的實現，而這個實現是 metrics-server。這個就是 metrics-server 改動最大的一個地方。

Kubernetes 的監控接口標準

在 K8s 裏面針對於監控，有三種不一樣的接口標準。它將監控的數據消費能力進行了標準化和解耦，實現了一個與社區的融合，社區裏面主要分爲三類。

第一類 Resource Metrice

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

第二類 Custom Metrics

對應的 API 是 custom.metrics.k8s.io，主要的實現是 Prometheus。它提供的是資源監控和自定義監控，資源監控和上面的資源監控實際上是有覆蓋關係的，而這個自定義監控指的是：好比應用上面想暴露一個相似像在線人數，或者說調用後面的這個數據庫的 MySQL 的慢查詢。這些其實都是能夠在應用層作本身的定義的，而後並經過標準的 Prometheus 的 client，暴露出相應的 metrics，而後再被 Prometheus 進行採集。

而這類的接口一旦採集上來也是能夠經過相似像 custom.metrics.k8s.io 這樣一個接口的標準來進行數據消費的，也就是說如今若是以這種方式接入的 Prometheus，那你就能夠經過 custom.metrics.k8s.io 這個接口來進行 HPA，進行數據消費。

第三類 External Metrics

External Metrics 實際上是比較特殊的一類，由於咱們知道 K8s 如今已經成爲了雲原生接口的一個實現標準。不少時候在雲上打交道的是雲服務，好比說在一個應用裏面用到了前面的是消息隊列，後面的是 RBS 數據庫。那有時在進行數據消費的時候，同時須要去消費一些雲產品的監控指標，相似像消息隊列中消息的數目，或者是接入層 SLB 的 connection 數目，SLB 上層的 200 個請求數目等等，這些監控指標。

那怎麼去消費呢？也是在 K8s 裏面實現了一個標準，就是 external.metrics.k8s.io。主要的實現廠商就是各個雲廠商的 provider，經過這個 provider 能夠經過雲資源的監控指標。在阿里雲上面也實現了阿里巴巴 cloud metrics adapter 用來提供這個標準的 external.metrics.k8s.io 的一個實現。

Promethues - 開源社區的監控「標準」

接下來咱們來看一個比較常見的開源社區裏面的監控方案，就是 Prometheus。Prometheus 爲何說是開源社區的監控標準呢？

• 一是由於首先 Prometheus 是 CNCF 雲原生社區的一個畢業項目。而後第二個是如今有愈來愈多的開源項目都以 Prometheus 做爲監控標準，相似說咱們比較常見的 Spark、Tensorflow、Flink 這些項目，其實它都有標準的 Prometheus 的採集接口。

 

• 第二個是對於相似像比較常見的一些數據庫、中間件這類的項目，它都有相應的 Prometheus 採集客戶端。相似像 ETCD、zookeeper、MySQL 或者說 PostgreSQL，這些其實都有相應的這個 Prometheus 的接口，若是沒有的，社區裏面也會有相應的 exporter 進行接口的一個實現。

那咱們先來看一下 Prometheus 整個的大體一個結構。

上圖是 Prometheus 採集的數據鏈路，它主要能夠分爲三種不一樣的數據採集鏈路。

• 第一種，是這個 push 的方式，就是經過 pushgateway 進行數據採集，而後數據線到 pushgateway，而後 Prometheus 再經過 pull 的方式去 pushgateway 去拉數據。這種採集方式主要應對的場景就是你的這個任務多是比較短暫的，好比說咱們知道 Prometheus，最多見的採集方式是拉模式，那帶來一個問題就是，一旦你的數據聲明週期短於數據的採集週期，好比我採集週期是 30s，而我這個任務可能運行 15s 就完了。這種場景之下，可能會形成有些數據漏採。對於這種場景最簡單的一個作法就是先經過 pushgateway，先把你的 metrics push下來，而後再經過 pull 的方式從 pushgateway 去拉數據，經過這種方式能夠作到，短期的不丟做業任務。

 

• 第二種是標準的 pull 模式，它是直接經過拉模式去對應的數據的任務上面去拉取數據。

 

• 第三種是 Prometheus on Prometheus，就是能夠經過另外一個 Prometheus 來去同步數據到這個 Prometheus。

這是三種 Prometheus 中的採集方式。那從數據源上面，除了標準的靜態配置，Prometheus 也支持 service discovery。也就是說能夠經過一些服務發現的機制，動態地去發現一些採集對象。在 K8s 裏面比較常見的是能夠有 Kubernetes 的這種動態發現機制，只須要配置一些 annotation，它就能夠自動地來配置採集任務來進行數據採集，是很是方便的。

etheus 提供了一個外置組件叫 Alentmanager，它能夠將相應的報警信息經過郵件或者短信的方式進行數據的一個告警。在數據消費上面，能夠經過上層的 API clients，能夠經過 web UI，能夠經過 Grafana 進行數據的展示和數據的消費。

總結起來 Prometheus 有以下五個特色：

• 第一個特色就是簡介強大的接入標準，開發者只須要實現 Prometheus Client 這樣一個接口標準，就能夠直接實現數據的一個採集；
• 第二種就是多種的數據採集、離線的方式。能夠經過 push 的方式、 pull 的方式、Prometheus on Prometheus的方式來進行數據的採集和離線；
• 第三種就是和 K8s 的兼容；
• 第四種就是豐富的插件機制與生態；
• 第五個是 Prometheus Operator 的一個助力，Prometheus Operator 多是目前咱們見到的全部 Operator 裏面作的最複雜的，可是它裏面也是把 Prometheus 這種動態能力作到淋漓盡致的一個 Operator，若是在 K8s 裏面使用 Prometheus，比較推薦你們使用 Prometheus Operator 的方式來去進行部署和運維。

kube-eventer - Kubernetes 事件離線工具

最後，咱們給你們介紹一個 K8s 中的事件離線工具叫作 kube-eventer。kube-eventer 是阿里雲容器服務開源出的一個組件，它能夠將 K8s 裏面，相似像 pod eventer、node eventer、核心組件的 eventer、crd 的 eventer 等等一系列的 eventer，經過 API sever 的這個 watch 機制離線到相似像 SLS、Dingtalk、kafka、InfluxDB，而後經過這種離線的機制進行一個時間的審計、監控和告警，咱們如今已經把這個項目開源到 GitHub 上了，你們有興趣的話能夠來看一下這個項目。

那上面這張圖其實就是 Dingtalk 的一個報警圖。能夠看見裏面有一個 warning 的事件，這個事件是在 kube-system namespace 之下，具體的這個 pod，大體的一個緣由是這個 pod 重啓失敗了，而後大體 reason 就是 backoff，而後具體發生事件是什麼時間。能夠經過這個信息來作到一個 Checkups。

3、日誌

日誌的場景

接下來給你們來介紹一下在 K8s 裏面日誌的一個部分。首先咱們來看一下日誌的場景，日誌在 K8s 裏面主要分爲四個大的場景：

1. 主機內核的日誌

• 第一個是主機內核的日誌，主機內核日誌能夠協助開發者進行一些常見的問題與診斷，好比說網棧的異常，相似像咱們的 iptables mark，它能夠看到有 controller table 這樣的一些 message；

 

• 第二個是驅動異常，比較常見的是一些網絡方案裏面有的時候可能會出現驅動異常，或者說是相似 GPU 的一些場景，驅動異常多是比較常見的一些錯誤；

 

• 第三個就是文件系統異常，在早期 docker 還不是很成熟的場景之下，overlayfs 或者是 AUFS，其實是會常常出現問題的。在這些出現問題後，開發者是沒有太好的辦法來去進行監控和診斷的。這一部分，實際上是能夠主機內核日誌裏面來查看到一些異常；

 

• 再往下是影響節點的一些異常，好比說內核裏面的一些 kernel panic，或者是一些 OOM，這些也會在主機日誌裏面有相應的一些反映。

 

2. Runtime 的日誌

第二個是 runtime 的日誌，比較常見的是 Docker 的一些日誌，咱們能夠經過 docker 的日誌來排查相似像刪除一些 Pod Hang 這一系列的問題。

3. 核心組件的日誌

第三個是核心組件的日誌，在 K8s 裏面核心組件包含了相似像一些外置的中間件，相似像 etcd，或者像一些內置的組件，相似像 API server、kube-scheduler、controller-manger、kubelet 等等這一系列的組件。而這些組件的日誌能夠幫咱們來看到整個 K8s 集羣裏面管控面的一個資源的使用量，而後以及目前運行的一個狀態是否有一些異常。

還有的就是相似像一些核心的中間件，如 Ingress 這種網絡中間件，它能夠幫咱們來看到整個的一個接入層的一個流量，經過 Ingress 的日誌，能夠作到一個很好的接入層的一個應用分析。

4. 部署應用的日誌

最後是部署應用的日誌，能夠經過應用的日誌來查看業務層的一個狀態。好比說能夠看業務層有沒有 500 的請求？有沒有一些 panic？有沒有一些異常的錯誤的訪問？那這些其實均可以經過應用日誌來進行查看的。

日誌的採集

首先咱們來看一下日誌採集，從採集位置是哪一個劃分，須要支持以下三種：

• 首先是宿主機文件，這種場景比較常見的是說個人這個容器裏面，經過相似像 volume，把日誌文件寫到了宿主機之上。經過宿主機的日誌輪轉的策略進行日誌的輪轉，而後再經過個人宿主機上的這個 agent 進行採集；

• 第二種是容器內有日誌文件，那這種常見方式怎麼處理呢，比較常見的一個方式是說我經過一個 Sidecar 的 streaming 的 container，轉寫到 stdout，經過 stdout 寫到相應的 log-file，而後再經過本地的一個日誌輪轉，而後以及外部的一個 agent 採集；

 

• 第三種咱們直接寫到 stdout，這種比較常見的一個策略，第一種就是直接我拿這個 agent 去採集到遠端，第二種我直接經過相似像一些 sls 的標準 API 採集到遠端。

那社區裏面其實比較推薦的是使用 Fluentd 的一個採集方案，Fluentd 是在每個節點上面都會起相應的 agent，而後這個 agent 會把數據聚集到一個 Fluentd 的一個 server，這個 server 裏面能夠將數據離線到相應的相似像 elasticsearch，而後再經過 kibana 作展示；或者是離線到 influxdb，而後經過 Grafana 作展示。這個實際上是社區裏目前比較推薦的一個作法。

4、總結

最後給你們作一下今天課程的總結，以及給你們介紹一下在阿里雲上面監控和日誌的最佳實踐。在課程開始的時候，給你們介紹了監控和日誌並不屬於 K8s 裏面的核心組件，而大部分是定義了一個標準的一個接口方式，而後經過上層的這個雲廠商進行各自的一個適配。

阿里雲容器服務監控體系

監控體系組件介紹

首先，我先給你們來介紹一下在阿里雲容器服務裏面的監控體系，這張圖其實是監控的一個大圖。

右側的四個產品是和監控日誌相關比較緊密的四個產品：

sls

第一個是 SLS，就是日誌服務，那剛纔咱們已經提到了在 K8s 裏面日誌分爲不少種不一樣的採集，好比說有核心組件的日誌、接入層的日誌、還有應用的日誌等等。在阿里雲容器服務裏面，能夠經過 API server 採集到審計的日誌，而後能夠經過相似像 service mesh 或者 ingress controller 採集到接入層的日誌，而後以及相應的應用層採集到應用的日誌。

有了這條數據鏈路以後，其實還不夠。由於數據鏈路只是幫咱們作到了一個數據的離線，咱們還須要作上層的數據的展示和分析。好比說像審計，能夠經過審計日誌來看到今天有多少操做、有多少變動、有沒有attack、系統有沒有異常。這些均可以經過審計的 Dashboard 來查看。

ARMS

第二個就是應用的一個性能監控。性能監控上面，能夠經過這個 ARMS 這樣的產品來去進行查看。ARMS 目前支持的 JAVA、PHP 兩種語言，能夠經過 ARMS 來作應用的一個性能診斷和問題的一個調優。

AHAS

第三個是比較特殊的叫 AHAS。AHAS 是一個架構感知的監控，咱們知道在 K8s 裏面，不少時候都是經過一些微服的架構進行部署的。微服帶來的問題就是組件會變的很是多，組件的副本處也會變的不少。這會帶來一個在拓撲管理上面的一個複雜性。

若是咱們想要看一個應用在 K8s 中流量的一個走向，或者是針對流量異常的一個排查，其實沒有一個很好的可視化是很複雜的。AHAS 的一個做用就是經過網絡棧的一個監控，能夠繪製出整個 K8s 中應用的一個拓撲關係，而後以及相應的資源監控和網絡的帶寬監控、流量的監控，以及異常事件的一個診斷。任何若是有架構拓撲感知的一個層面，來實現另外一種的監控解決方案。

Cloud Monitor

最後是 Cloud Monitor，也就是基礎的雲監控。它能夠採集標準的 Resource Metrics Monitoring，來進行監控數據的一個展示，能夠實現 node、pod 等等監控指標的一個展示和告警。

阿里雲加強的功能

這一部分是阿里雲在開源上作的加強。首先是 metrics-server，文章開始提到了 metrics-server 作了不少的一個精簡。可是從客戶的角度來說，這個精簡其實是把一些功能作了一個裁剪，這將會帶來不少不便。好比說有不少客戶但願將監控數據離線到相似像 SLS 或者是 influxdb，這種能力實際上用社區的版本是沒有辦法繼續來作的，這個地方阿里雲繼續保留了常見的維護率比較高的 sink，這是第一個加強。

而後是第二個加強，由於在 K8s 裏面整合的一個生態的發展並非以一樣的節奏進行演進的。好比說 Dashboard 的發佈，並非和 K8s 的大版本進行匹配的。好比 K8s 發了 1.12，Dashboard 並不會也發 1.12 的版本，而是說它會根據本身的節奏來去發佈，這樣會形成一個結果就是說之前依賴於 Heapster 的不少的組件在升級到 metrics-server 以後就直接 break 掉，阿里雲在 metrics-server 上面作了完整的 Heapster 兼容，也就是說從目前 K8s 1.7 版本一直到 K8s 1.14 版本，均可以使用阿里雲的 metrics-server，來作到完整的監控組件的消費的一個兼容。

還有就是 eventer 和 npd，上面提到了 kube-eventer 這個組件。而後在 npd 上面，咱們也作了不少額外的加強，相似像增長了不少監控和檢測項，相似像 kernel Hang、npd 的一個檢測、出入網的監控、snat 的一個檢測。而後還有相似像 fd 的 check，這些其實都是在 npd 裏面的一些監控項，阿里雲作了不少的加強。而後開發者能夠直接部署 npd 的一個 check，就能夠實現節點診斷的一個告警，而後並經過 eventer 離線上的 kafka 或者是 Dingtalk。

再往上是 Prometheus 生態，Prometheus 生態裏面，在存儲層可讓開發者對接，阿里雲的 HiTSDB 以及 InfluxDB，而後在採集層提供了優化的 node-exporter，以及一些場景化監控的 exporter，相似像 Spark、TensorFlow、Argo 這類場景化的 exporter。還有就是針對於 GPU，阿里雲作了不少額外的加強，相似於像支持 GPU 的單卡監控以及 GPU share 的監控，而後在 Prometheus 上面，咱們連同 ARMS 團隊推出了託管版的 Prometheus，開發者可使用開箱即用的 helm chats，不須要部署 Prometheus server，就能夠直接體驗到 Prometheus 的一個監控採集能力。

阿里雲容器服務日誌體系

在日誌上面，阿里雲作了哪些加強呢？首先是採集方式上，作到了完整的一個兼容。能夠採集 pod log 日誌、核心組件日誌、docker engine 日誌、kernel 日誌，以及相似像一些中間件的日誌，都收集到 SLS。收集到 SLS 以後，咱們能夠經過數據離線到 OSS，離線到 Max Compute，作一個數據的離線和歸檔，以及離線預算。

而後還有是對於一些數據的實時消費，咱們能夠到 Opensearch、能夠到 E-Map、能夠到 Flink，來作到一個日誌的搜索和上層的一個消費。在日誌展示上面，咱們能夠既對接開源的 Grafana，也能夠對接相似像 DataV，去作數據展現，實現一個完整的數據鏈路的採集和消費。

本文總結

• 首先主要爲你們介紹了監控，其中包括：四種容器場景下的常見的監控方式；Kubernetes 的監控演進和接口標準；兩種經常使用的來源的監控方案；
• 在日誌上咱們主要介紹了四種不一樣的場景，介紹了 Fluentd 的一個採集方案；
• 最後向你們介紹了一下阿里雲日誌和監控的一個最佳實踐。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」