課時 12：可觀測性-監控與日志（莫源）

本文主要分為四個部分：

1. 在 K8s 中監控和日志的背景資訊；
2. 在 K8s 中監控方案的演進，以及常見的監控方案的提供；
3. 日志采集的一些細節以及常見的日志的開源系統；
4. 課程總結，介紹一下阿裡雲容器服務上面監控和日志的最佳實踐。

背景

監控和日志是大型分布式系統的重要基礎設施，監控可以幫助開發者檢視系統的運作狀态，而日志可以協助問題的排查和診斷。

在 Kubernetes 中，監控和日志屬于生态的一部分，它并不是核心元件，是以大部分的能力依賴上層的雲廠商的适配。Kubernetes 定義了介入的接口标準和規範，任何符合接口标準的元件都可以快速內建。

監控

監控類型

先看一下監控，從監控類型上劃分，在 K8s 中可以分成四個不同的類型：

• 資源監控

比較常見的像 CPU、記憶體、網絡這種資源類的一個名額，通常這些名額會以數值、百分比的機關進行統計，是最常見的一個監控方式。這種監控方式在正常的監控裡面，類似項目 zabbix telegraph，這些系統都是可以做到的。

• 性能監控

性能監控指的就是 APM 監控，也就是說常見的一些應用性能類的監控名額的檢查。通常是通過一些 Hook 的機制在虛拟機層、位元組碼執行層通過隐式調用，或者是在應用層顯示注入，擷取更深層次的一個監控名額，一般是用來應用的調優和診斷的。比較常見的類似像 jvm 或者 php 的 Zend Engine，通過一些常見的 Hook 機制，拿到類似像 jvm 裡面的 GC 的次數，各種記憶體代的一個分布以及網絡連接配接數的一些名額，通過這種方式來進行應用的性能診斷和調優。

• 安全監控

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

• 事件監控

事件監控是 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，它就可以自動地來配置采集任務來進行資料采集，是非常友善的。

在報警上面，Prometheus 提供了一個外置元件叫 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。

日志

日志的場景

接下來給大家來介紹一下在 K8s 裡面日志的一個部分。首先我們來看一下日志的場景，日志在 K8s 裡面主要分為四個大的場景：

主機核心的日志

• 第一個是主機核心的日志，主機核心日志可以協助開發者進行一些常見的問題與診斷，比如說網棧的異常，類似像我們的 iptables mark，它可以看到有 controller table 這樣的一些 message；
• 第二個是驅動異常，比較常見的是一些網絡方案裡面有的時候可能會出現驅動異常，或者說是類似 GPU 的一些場景，驅動異常可能是比較常見的一些錯誤；
• 第三個就是檔案系統異常，在早期 docker 還不是很成熟的場景之下，overlayfs 或者是 AUFS，實際上是會經常出現問題的。在這些出現問題後，開發者是沒有太好的辦法來去進行監控和診斷的。這一部分，其實是可以主機核心日志裡面來檢視到一些異常；
• 再往下是影響節點的一些異常，比如說核心裡面的一些 kernel panic，或者是一些 OOM，這些也會在主機日志裡面有相應的一些反映。

Runtime 的日志

第二個是 runtime 的日志，比較常見的是 Docker 的一些日志，我們可以通過 docker 的日志來排查類似像删除一些 Pod Hang 這一系列的問題。

核心元件的日志

第三個是核心元件的日志，在 K8s 裡面核心元件包含了類似像一些外置的中間件，類似像 etcd，或者像一些内置的元件，類似像 API server、kube-scheduler、controller-manger、kubelet 等等這一系列的元件。而這些元件的日志可以幫我們來看到整個 K8s 叢集裡面管控面的一個資源的使用量，然後以及目前運作的一個狀态是否有一些異常。

還有的就是類似像一些核心的中間件，如 Ingress 這種網絡中間件，它可以幫我們來看到整個的一個接入層的一個流量，通過 Ingress 的日志，可以做到一個很好的接入層的一個應用分析。

部署應用的日志

最後是部署應用的日志，可以通過應用的日志來檢視業務層的一個狀态。比如說可以看業務層有沒有 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 做展現。這個其實是社群裡目前比較推薦的一個做法。

總結

最後給大家做一下今天課程的總結，以及給大家介紹一下在阿裡雲上面監控和日志的最佳實踐。在課程開始的時候，給大家介紹了監控和日志并不屬于 K8s 裡面的核心元件，而大部分是定義了一個标準的一個接口方式，然後通過上層的這個雲廠商進行各自的一個适配。

阿裡雲容器服務監控體系

監控體系元件介紹

首先，我先給大家來介紹一下在阿裡雲容器服務裡面的監控體系，這張圖實際上是監控的一個大圖。

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

sls

第一個是 SLS，就是日志服務，那剛才我們已經提到了在 K8s 裡面日志分為很多種不同的采集，比如說有核心元件的日志、接入層的日志、還有應用的日志等等。在阿裡雲容器服務裡面，可以通過 API server 采集到審計的日志，然後可以通過類似像 service mesh 或者 ingress controller 采集到接入層的日志，然後以及相應的應用層采集到應用的日志。

有了這條資料鍊路之後，其實還不夠。因為資料鍊路隻是幫我們做到了一個資料的離線，我們還需要做上層的資料的展現和分析。比如說像審計，可以通過審計日志來看到今天有多少操作、有多少變更、有沒有攻擊、系統有沒有異常。這些都可以通過審計的 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 的一個采集方案；
• 最後向大家介紹了一下阿裡雲日志和監控的一個最佳實踐。