騰訊雲容器服務日誌採集最佳實踐

騰訊雲原生發表於2020-10-20

概述

本文介紹如何利用騰訊雲容器服務 TKE 的日誌功能對日誌進行採集、儲存與查詢，分析各種功能用法與場景，給出一些最佳實踐建議。

注: 本文僅適用於 TKE 叢集。

如何快速上手 ?

TKE 的日誌功能入口在 叢集運維-日誌規則，更多關於如何為 TKE 叢集啟用日誌採集與基礎用法，參考官方文件日誌採集。

技術架構是怎樣的 ?

TKE 叢集開啟日誌採集後，tke-log-agent 作為 DaemonSet 部署在每個節點上，負責根據採集規則採集節點上容器的日誌，然後上報到 CLS 日誌服務，由 CLS 進行統一儲存、檢索與分析:

採集哪裡的日誌 ?

在 TKE 使用日誌採集時，需要在 叢集運維-日誌規則 裡新建日誌採集規則，首先需要確定採集的目標資料來源是什麼，下面介紹支援的 3 種型別資料來源及其各自使用場景與建議。

採集標準輸出

最簡單也是最推薦的方式是將 Pod 內容器的日誌輸出到標準輸出，日誌內容就會由容器執行時 (docker, containerd) 來管理，有以下幾點好處:

不需要額外掛載 volume。
可以直接通過 kubectl logs 檢視日誌內容。
業務不需要關心日誌輪轉，容器執行時會對日誌進行儲存和自動輪轉，避免因個別 Pod 日誌量大將磁碟寫滿。
不需要關心日誌檔案路徑，可以使用比較統一的採集規則，用更少的採集規則數量覆蓋更多的工作負載，減少運維複雜度。

採集配置示例:

採集容器內的檔案

很多時候業務通過寫日誌檔案的方式來記錄日誌，使用容器跑業務時，日誌檔案被寫到容器內:

如果日誌檔案所在路徑沒有掛載 volume，日誌檔案會被寫入容器可寫層，落盤到容器資料盤裡，通常路徑是 /var/lib/docker (建議給此路徑掛盤，避免與系統盤混用)，容器停止後日志會被清理。
如果日誌檔案所在路徑掛載了 volume，日誌檔案會落盤到對應 volume 型別的後端儲存；通常用 emptydir，容器停止後日志會被清理，執行期間日誌檔案會落盤到宿主機的 /var/lib/kubelet 路徑下，此路徑通常沒有單獨掛盤，也就是會使用系統盤；由於使用了日誌採集，有統一儲存的能力，不推薦再掛載其它持久化儲存來存日誌檔案(如雲硬碟CBS, 物件儲存COS, 共享儲存CFS)。

許多開源日誌採集器需要給 Pod 日誌檔案路徑掛載 volume 才能採集，使用 TKE 的日誌採集則不需要，所以如果將日誌輸出到容器內的檔案裡，不需要關心是否掛載 volume。

採集配置示例:

採集宿主機上的檔案

如果業務將日誌寫入日誌檔案，但又想容器停止之後還能保留原始日誌檔案，好有個備份，避免採集異常時導致日誌完全丟失，這時可以給日誌檔案路徑掛載 hostPath，日誌檔案會落盤到宿主機指定目錄，並且容器停止後不會清理日誌檔案。

由於不會自動清理日誌檔案，有同學就可能會擔心日誌會被重複採集，比如 Pod 排程走又排程回來，日誌檔案被寫在之前相同路徑。是否會重複採集，這裡分兩種情況:

檔名相同，比如固定檔案路徑 /data/log/nginx/access.log。此時不會重複採集，因為採集器會記住之前採集過的日誌檔案的位點，只採集增量部分。
檔名不同，通常是業務用的日誌框架會按照一定時間週期自動進行日誌輪轉，一般是按天輪轉，自動為舊日誌檔案進行重新命名，加上時間戳字尾。如果採集規則裡使用了 "*" 作為萬用字元匹配日誌檔名，可能就會重複採集，因為日誌框架對日誌檔案重新命名後，採集器就會認為匹配到了新寫入的日誌檔案，就又對其進行採集一次。

所以，一般不會重複採集，如果日誌框架會對日誌進行自動輪轉，建議採集規則不要使用萬用字元 "*" 來匹配日誌檔案。

採集配置示例:

日誌吐到哪裡 ?

知道了採集哪裡的資料之後，我們還需要知道採集到的日誌往哪裡存。根據前面講的技術架構可以知道，TKE 日誌採集與雲上的 CLS 日誌服務整合，日誌資料也將統一上報到日誌服務。日誌服務通過日誌集和日誌主題來對日誌進行管理，日誌集是 CLS 的專案管理單元，可以包含多個日誌主題；一般將同一個業務的日誌放在一個同一日誌集，同一業務中的同一類的應用或服務使用相同日誌主題，在 TKE 中，日誌採集規則與日誌主題是一一對應的；TKE 建立日誌採集規則時選擇消費端，就需要指定日誌集與日誌主題，日誌集通常提前建立好，日誌主題通常選擇自動建立:

建立好後可以根據情況對自動建立的日誌主題進行重新命名，方便後續檢索時找到日誌所在的日誌主題:

如何配置日誌格式解析 ?

有了日誌的原始資料，我們還需要告訴日誌服務如何去解析日誌，以方便後續對其進行檢索。在建立日誌採集規則時，需要配置日誌的解析格式，下面針對各項配置給出分析與建議。

使用哪種抓取模式 ?

首先，我們需要確定日誌的抓取模式，支援 5 種：單行文字、JSON、分隔符、多行文字和完全正則。

推薦使用 JSON，因為 JSON 格式本身就將日誌給結構化了，日誌服務可以提取 JSON 的 key 作為欄位名，value 作為對應的欄位值，不再需要根據業務日誌輸出格式配置複雜的匹配規則，日誌示例:

{"remote_ip":"10.135.46.111","time_local":"22/Jan/2019:19:19:34 +0800","body_sent":23,"responsetime":0.232,"upstreamtime":"0.232","upstreamhost":"unix:/tmp/php-cgi.sock","http_host":"127.0.0.1","method":"POST","url":"/event/dispatch","request":"POST /event/dispatch HTTP/1.1","xff":"-","referer":"http://127.0.0.1/my/course/4","agent":"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0","response_code":"200"}

使用 JSON 抓取模式的前提是業務的日誌本身是以 JSON 格式輸出的，如果不是 JSON 格式，但切換到使用 JSON 格式輸出成本不大，就建議進行切換，如果實在不好切換，再考慮其它抓取模式。

如果日誌內容是以固定格式輸出的單行文字，考慮使用 "分隔符" 或 "完全正則" 抓取模式。"分隔符" 適用簡單格式，日誌中每個欄位值都以固定的字串分隔開，比如用 ":::" 隔開，某一條日誌內容是:

10.20.20.10 ::: [Tue Jan 22 14:49:45 CST 2019 +0800] ::: GET /online/sample HTTP/1.1 ::: 127.0.0.1 ::: 200 ::: 647 ::: 35 ::: http://127.0.0.1/

可以配置 ":::" 自定義分隔符，並且為每個欄位按順序配置欄位名，示例:

"完全正則" 適用複雜格式，使用正規表示式來匹配日誌的格式。如日誌內容為:

10.135.46.111 - - [22/Jan/2019:19:19:30 +0800] "GET /my/course/1 HTTP/1.1" 127.0.0.1 200 782 9703 "http://127.0.0.1/course/explore?filter%5Btype%5D=all&filter%5Bprice%5D=all&filter%5BcurrentLevelId%5D=all&orderBy=studentNum" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0"  0.354 0.354

正規表示式就可以設定為:

(\S+)[^\[]+(\[[^:]+:\d+:\d+:\d+\s\S+)\s"(\w+)\s(\S+)\s([^"]+)"\s(\S+)\s(\d+)\s(\d+)\s(\d+)\s"([^"]+)"\s"([^"]+)"\s+(\S+)\s(\S+).*

日誌服務會使用 () 捕獲組來區分每個欄位，我們還需要為每個欄位設定欄位名，配置示例:

如果日誌沒有固定的輸出格式，則考慮使用 "單行文字" 或 "多行文字" 的抓取模式。使用這兩種模式，不會對日誌內容本身進行結構化處理，不會提取日誌欄位，每條日誌的時間戳也固定由日誌採集的時間決定，檢索的時候也只能進行簡單的模糊查詢。這兩種模式的區別在於日誌內容是單行還是多行，如果是單行最簡單，不需要設定任何匹配條件，每行都是一條單獨的日誌；如果是多行則需要設定首行正規表示式，也就是匹配每條日誌第一行的正則，當某行日誌匹配上預先設定的首行正規表示式，就認為是一條日誌的開頭，而下一個行首出現作為該條日誌的結束識別符號。假如多行日誌內容是:

10.20.20.10 - - [Tue Jan 22 14:24:03 CST 2019 +0800] GET /online/sample HTTP/1.1 127.0.0.1 200 628 35 http://127.0.0.1/group/1 
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0 0.310 0.310

那麼首行正規表示式就可以設定為: \d+\.\d+\.\d+\.\d+\s-\s.*

如何過濾掉不需要的內容 ?

有些不重要或不關心的日誌可以選擇將其過濾掉，降低成本。

如果使用 "JSON"、"分隔符" 或 "完全正則" 的抓取模式，日誌內容會進行結構化處理，可以通過指定欄位來對要保留的日誌進行正則匹配:

對於 "單行文字" 和 "多行文字" 抓取模式，由於日誌內容沒有進行結構化處理，無法指定欄位來過濾，通常直接使用正則來對要保留的完整日誌內容進行模糊匹配:

需要注意的是，匹配內容一定記住是用正則而不是完整匹配，比如想只保留 a.test.com 域名的日誌，匹配的表示式應該寫 a\.test\.com 而不是 a.test.com。

日誌時間戳如何自定義 ?

每條日誌都需要有個時間戳，這個時間戳主要用於檢索，在檢索的時候可以選擇時間範圍。預設情況下，日誌的時間戳由採集的時間決定，也可以進行自定義，選擇某個欄位作為時間戳，這樣在某些情況下可能更精確些，比如在建立採集規則之前，服務已經執行了一段時間，如果不設定自定義時間格式，採集時會將之前的舊日誌的時間戳設定為當前的時間，導致時間不準確。

如何進行自定義呢？由於 "單行文字" 和 "多行文字" 抓取模式不會對日誌內容進行結構化處理，也就沒有欄位可以指定為時間戳，無法自定義時間格式解析。其它的抓取模式都可以支援，具體做法時關閉 "使用採集時間"，然後選取要作為時間戳的欄位名稱，並配置時間格式。

假如使用日誌的 time 欄位作為時間戳，其中一條日誌 time 的值為 2020-09-22 18:18:18，時間格式就可以設定為 %Y-%m-%d %H:%M:%S，示例: