![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/59ffe27f4c614fb989f5afd49ac77f32.png)

作者 | 悟鵬、沉醉
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/5ezU9Z6f1-Q8YyRU7O5ZXA)

《Kubernetes 穩定性保障手冊》系列文章：

- [Kubernetes 穩定性保障手冊 -- 極簡版](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247501775&idx=1&sn=8b3b27934e7bced10b2a7f81483e3256&chksm=fae6cc00cd9145168b57c579ed488a7f92b67f86daf039de6b9518995d9e1ad27df2a382290e&scene=21#wechat_redirect)

- Kubernetes 穩定性保障手冊 -- 日誌專題（本文）

不論對於軟體的使用者還是開發者，日誌都是很重要的資訊源。日誌可以用來表徵軟體的執行狀態，在軟體執行不符合預期時提供豐富的資訊，也可以用在開發階段除錯軟體，方便定位問題。

軟體的生命週期涉及到 **開發** 和 **執行** 兩個階段，日誌的生成是在軟體的開發階段，日誌的使用集中在軟體的執行階段。
在開發階段規範化日誌，有助於執行階段透過標準化方法分析日誌、配置日誌監控和告警。
在執行階段透過標準化方法使用日誌，有助於低成本把握程式的執行態行為，及時感知異常，促進開發階段的迭代效率。

在軟體的生命週期中，執行階段時長佔比會遠大於開發階段，即對日誌的使用時長會遠大於開發階段寫日誌邏輯的時長。在開發階段應用良好的日誌規範，會對軟體生命週期的正常執行和快速迭代帶來很大幫助：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/b2ea82724a8447b386854c680c2b9a09.png)

## 複雜度分析

程式中的元素可以抽象為兩部分：自身邏輯，依賴。兩類元素之間的互動為：自身邏輯閉環，自身邏輯與依賴互動。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/149749745bca4ebf8dd962a16c9386d8.png)

從長期角度來看，互動環節出問題的機率會比自身邏輯出問題的機率高，因此要重點關注互動環節的日誌邏輯。

同時，對日誌的管理需要意識到 _誰會使用這些日誌，_通常有 4 類角色：

- 使用者
- 維護者
- 安全人員
- 審計人員

使用者從黑盒角度使用軟體，透過日誌瞭解軟體當前的執行狀態，關注重點是軟體正常的狀態。

維護者從白盒角度使用軟體，開發角色透過日誌除錯軟體，SRE 角色透過日誌及時感知軟體的異常狀態，並透過日誌上下文分析異常原因。

安全人員透過分析日誌，瞭解惡意登入、異常刪除等風險。

審計人員透過審計日誌、應用日誌，確認業務、架構的合規性。

根據上述不同的使用場景，我們可以梳理出幾類日誌類別，進一步增強開發和執行階段對日誌的理解：

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/fb6dca3ee6b6445bb49671a04662f9d3.jpg)

## 開發階段

### 最佳實踐

理解了日誌使用者關注的重點後，開發階段寫日誌時，推薦使用如下最佳實踐：

- 使用 structured logs
   - 不使用 format strings
- 使用 info 和 error 表徵日誌級別
   - info 又可細化為多個級別，0~10，資訊的重要性依次降低 (也可以參考[《Kubernetes: sig-instrumentation/logging.md》](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
      - 0：使用者想要看到的資訊
      - 1：維護者關注的白盒行為資訊
      - 10： 維護者除錯用的資訊
- 使用具有過濾器能力的 log lib，透過 logger 自動過濾敏感資訊
   - 參見 [《KEP: Kubernetes system components logs sanitization》](https://github.com/kubernetes/enhancements/blob/master/keps/sig-security/1753-logs-sanitization/README.md)
- 日誌透過 stdout/stderr 輸出，關閉不必要的文字日誌
   - 避免額外的磁碟佔用、IO 消耗、日誌清理任務的維護等

對於 golang，可以考慮使用 [klog](https://github.com/kubernetes/klog) 作為 logger 實現。

### FAQ

#### 為什麼使用 structured logs？

structured logs 是一種結構化的日誌格式，結構如下，其中 msg 表徵通用的事件，多對的 k=v 用來具化事件：

> msg k=v k=v ... k=v

示例：

> "Pod status updated" pod="kube-system/kubedns" status="ready"

對於開發階段，structured logs 透過固化的結構和欄位語義，協助開發者思考程式邏輯狀態，有助於進一步控制程式複雜度和理解程式邏輯。

對於執行階段，structured logs 中的 k 天然具備索引的屬性，便於進行查詢和分析。也可以考慮將 msg 規範化，增加 **事件** 語義，透過限制 msg 語義來增強 msg 的作用。

#### 為什麼不使用 debug/warning/critical/fatal？

透過減少日誌型別，降低使用和維護負擔。

debug 可以融入到 info 級別。

warning/critical 對於使用者和維護者都是模糊的詞，對於要採取的行動通常不具備指導意義。warning/critical 和 error 類似，表徵程式執行過程中出現了預期外的現象，此時程式要麼自動處理，要麼交由外部人工介入判斷。若由程式自動處理，那麼使用者和維護者感知到這類現象即可，info 可以滿足。若需要交由外部人工介入，那麼 error 就可以滿足。對於問題的嚴重性，可放在執行階段，透過異常具體的資訊來表徵，如 ServiceUnavailable、Unauthorized 等。

fatal 是將 error 和 panic 兩類邏輯封裝了起來，在開發過程中可能會帶來執行邏輯上的不清晰，如決定是否 panic 的邏輯需要放在最頂層邏輯中，若在頂層邏輯之下呼叫 fatal，可能會帶來資源洩露、程式執行復雜度增加等問題。

#### 為什麼不使用 format strings？

format strings 是形如如下的結構：

> klog.V(4).Infof("Got a Retry-After %ds response for attempt %d to %v", seconds, retries, url)

這種結構將 **通用事件** 和 **具體內容** 耦合在一起，不利於開發階段降低理解程式邏輯的成本，也不便於使用階段透過標準化的方式進行查詢、分析，增加日誌的使用成本。

一種改善方式：

> klog.V(4).InfoS("got a retry-after response when requesting url", "attempt", retries, "after seconds", seconds, "url", url)

#### 為什麼要使用具有過濾器能力的 log lib？

開發過程中，可能會由於疏忽而將敏感資訊輸出到日誌中，如密碼、token 等資訊。為了避免敏感資訊洩露，需要加強 code review，同時也可以考慮在 logger 中配置過濾器，自動進行敏感資訊的過濾，參見 [《KEP: Kubernetes system components logs sanitization》](https://github.com/kubernetes/enhancements/blob/master/keps/sig-security/1753-logs-sanitization/README.md) 。

對於 golang，可以考慮使用 [klog](https://github.com/kubernetes/klog) 作為 logger 實現，並配合 [Kubernetes/component-base: sanitization](https://github.com/kubernetes/component-base/blob/master/logs/sanitization/sanitization.go) 進行使用。

## 執行階段

### 最佳實踐

執行階段是對日誌的使用，包括如下 4 個階段：

1. 採集
1. 查詢
1. 分析
1. 告警

由於日誌服務對程式的執行以及後續的運營極為重要，建議採用託管型的日誌產品來滿足執行階段對日誌的使用需求，如[阿里雲的 SLS 產品](https://www.aliyun.com/product/sls)。

若在多個 region 部署叢集，且叢集的元件相同，在使用日誌產品時，需要確保每個 region 中日誌專案名稱規則的一致性。以阿里雲 SLS 產品為例，若需要分別收集多個 region 的日誌，則 project、logstore 的名稱需要在多個 region 中保持相同的規則，目的是便於透過統一的方法對不同叢集的日誌做查詢和分析。

通常情況下，日誌產品會提供上述 4 個階段的服務，具體的使用方法可以參見對應日誌產品的文件，下述針對告警做重點分析。

#### 告警

告警要滿足如下目標：

- 覆蓋面全
- 關鍵告警及時感知

基於開發階段的日誌規範，可對 error 級別的告警做統一告警，將告警資訊統一到低優先順序的通知渠道，如表徵普通告警的釘釘群。

若要及時感知到關鍵告警，需要從如下 2 個方面入手：

- 定義「關鍵告警」特徵
- 分級告警，與相應的通知渠道結合

定義「關鍵告警」的特徵是個 **長期**、**持續完善** 的過程，有 通用關鍵告警 和 業務關鍵告警。

通用關鍵告警 與業務耦合度小，如機器級別的關鍵告警 (當機、記憶體壓力大、load 過高等)、託管服務的關鍵告警 (master 元件 panic/OOM、master 元件記憶體壓力大等)，這部分告警配置可以作為基礎服務，作為叢集1交付的一部分。

業務關鍵告警 與業務耦合度大，需要與業務長期維護，重點關注「業務互動環節」的告警。

通知渠道通常會有如下幾類：

- IM 群 (如釘釘群等)
- 簡訊
- 電話
- webhook

這些通知渠道對人觸達的及時性不同，電話觸達性最好，簡訊其次，然後是 IM 群。webhook 本質上是條通道，可以對接不同的 IM 群或簡訊、電話渠道。

推薦如下三種告警級別：

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/024fdb5b730949f282d7f3f8d37765e9.jpg)

配置告警是個長期、不斷迭代的過程，為了有助於告警有效性的迭代，配置每條告警時，可以考慮使用如下表格，規範化每條告警的配置，並深入思考告警配置的有效性：

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/f1e5599357924063a74928e539acc3ed.jpg)

### FAQ

#### 如何預先配置未模擬出的異常？

業務依賴的 OpenAPI/SDK/Lib 等通常都會有錯誤碼列表，如 [阿里雲：API 錯誤中心](https://error-center.aliyun.com/)、Lib 中的 errors 檔案等。可以基於該已知資訊，列舉依賴的 OpenAPI/SDK 中對業務有明顯負面影響的狀態碼做分級告警，如 ServiceUnavailable/Forbbiden/Unauthorized 等。

歡迎大家留言交流使用 Kubernetes 過程中的穩定性保障問題，以及對穩定性保障的期待工具或服務。大家也可透過郵箱聯絡作者，進一步深入交流：flyer.zyf@alibaba-inc.com

Kubernetes 穩定性保障手冊 -- 日誌專題

相關文章