## 概述 本文介紹如何利用騰訊雲容器服務 TKE 的日誌功能對日誌進行採集、儲存與查詢，分析各種功能用法與場景，給出一些最佳實踐建議。 > **注**: 本文僅適用於 TKE 叢集。 ## 如何快速上手 ? TKE 的日誌功能入口在 `叢集運維-日誌規則`，更多關於如何為 TKE 叢集啟用日誌採集與基礎用法，參考官方文件 [日誌採集](https://cloud.tencent.com/document/product/457/36771)。 ## 技術架構是怎樣的 ? TKE 叢集開啟日誌採集後，tke-log-agent 作為 DaemonSet 部署在每個節點上，負責根據採集規則採集節點上容器的日誌，然後上報到 CLS 日誌服務，由 CLS 進行統一儲存、檢索與分析:  ## 採集哪裡的日誌 ? 在 TKE 使用日誌採集時，需要在 `叢集運維-日誌規則` 裡新建日誌採集規則，首先需要確定採集的目標資料來源是什麼，下面介紹支援的 3 種類型資料來源及其各自使用場景與建議。 ### 採集標準輸出 最簡單也是最推薦的方式是將 Pod 內容器的日誌輸出到標準輸出，日誌內容就會由容器執行時 (docker, containerd) 來管理，有以下幾點好處: 1. 不需要額外掛載 volume。 2. 可以直接通過 `kubectl logs` 檢視日誌內容。 3. 業務不需要關心日誌輪轉，容器執行時會對日誌進行儲存和自動輪轉，避免因個別 Pod 日誌量大將磁碟寫滿。 4. 不需要關心日誌檔案路徑，可以使用比較統一的採集規則，用更少的採集規則數量覆蓋更多的工作負載，減少運維複雜度。 採集配置示例:  ### 採集容器內的檔案 很多時候業務通過寫日誌檔案的方式來記錄日誌，使用容器跑業務時，日誌檔案被寫到容器內: 1. 如果日誌檔案所在路徑沒有掛載 volume，日誌檔案會被寫入容器可寫層，落盤到容器資料盤裡，通常路徑是 `/var/lib/docker` (建議給此路徑掛盤，避免與系統盤混用)，容器停止後日志會被清理。 2. 如果日誌檔案所在路徑掛載了 volume，日誌檔案會落盤到對應 volume 型別的後端儲存；通常用 emptydir，容器停止後日志會被清理，執行期間日誌檔案會落盤到宿主機的 `/var/lib/kubelet` 路徑下，此路徑通常沒有單獨掛盤，也就是會使用系統盤；由於使用了日誌採集，有統一儲存的能力，不推薦再掛載其它持久化儲存來存日誌檔案(如雲硬碟CBS, 物件儲存COS, 共享儲存CFS)。 許多開源日誌採集器需要給 Pod 日誌檔案路徑掛載 volume 才能採集，使用 TKE 的日誌採集則不需要，所以如果將日誌輸出到容器內的檔案裡，不需要關心是否掛載 volume。 採集配置示例:  ### 採集宿主機上的檔案 如果業務將日誌寫入日誌檔案，但又想容器停止之後還能保留原始日誌檔案，好有個備份，避免採集異常時導致日誌完全丟失，這時可以給日誌檔案路徑掛載 hostPath，日誌檔案會落盤到宿主機指定目錄，並且容器停止後不會清理日誌檔案。 由於不會自動清理日誌檔案，有同學就可能會擔心日誌會被重複採集，比如 Pod 排程走又排程回來，日誌檔案被寫在之前相同路徑。是否會重複採集，這裡分兩種情況: 1. 檔名相同，比如固定檔案路徑 `/data/log/nginx/access.log`。此時不會重複採集，因為採集器會記住之前採集過的日誌檔案的位點，只採集增量部分。 2. 檔名不同，通常是業務用的日誌框架會按照一定時間週期自動進行日誌輪轉，一般是按天輪轉，自動為舊日誌檔案進行重新命名，加上時間戳字尾。如果採集規則裡使用了 "*" 作為萬用字元匹配日誌檔名，可能就會重複採集，因為日誌框架對日誌檔案重新命名後，採集器就會認為匹配到了新寫入的日誌檔案，就又對其進行採集一次。 所以，一般不會重複採集，如果日誌框架會對日誌進行自動輪轉，建議採集規則不要使用萬用字元 "*" 來匹配日誌檔案。 採集配置示例:  ## 日誌吐到哪裡 ? 知道了採集哪裡的資料之後，我們還需要知道採集到的日誌往哪裡存。根據前面講的技術架構可以知道，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`， 示例:  更多時間格式配置參考日誌服務官方文件 [配置時間格式](https://cloud.tencent.com/document/product/614/38614)。 需要注意的是，日誌服務時間戳暫時只支援精確到秒，也就是如果業務日誌的時間戳欄位精確到了毫秒，將無法使用自定義時間戳，只能使用預設的採集時間作為時間戳，不過時間戳精確到毫秒後續將會得到支援。 ## 如何查詢日誌 ? 日誌採集規則配好了，採集器就會自動開始採集日誌並上報到日誌服務，然後就可以在 `日誌服務-檢索分析` 中查詢日誌了，支援 Lucene 語法，但前提是需要開啟索引，有以下 3 類索引: 1. 全文索引。用於模糊搜尋，不用指定欄位。  2. 鍵值索引。索引結構化處理過的日誌內容，可以指定日誌欄位進行檢索。  3. 元欄位索引。上報日誌時額外自動附加的一些欄位，比如 pod 名稱、namespace 等，方便檢索時指定這些欄位進行檢索。  查詢示例:  ## 如何將日誌投遞到其它地方 ? 日誌服務支援將日誌投遞到 COS 物件儲存和 Ckafka (騰訊雲託管的 Kafka)，可以在日誌主題裡設定投遞:  可以用在以下場景: 1. 對日誌資料進行長期歸檔儲存。日誌集預設儲存 7 天的日誌資料，可以調整時長，但資料量越大，成本就越高，通常只保留幾天的資料，如果需要將日誌存更長時間，可以投遞到 COS 進行低成本儲存。 2. 需要對日誌進行進一步處理 (如離線計算)，可以投遞到 COS 或 Ckafka，由其它程式消費來處理。 ## 參考資料 - TKE 日誌採集用法指引: https://cloud.tencent.com/document/product/457/36771 - 日誌服務配置時間格式: https://cloud.tencent.com/document/product/614/38614 - 日誌服務投遞 COS: https://cloud.tencent.com/document/product/614/37908 - 日誌服務投遞 Ckafka: https://cloud.tencent.com/document/product/614/33342 >【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！ ![](https://img2020.cnblogs.com/other/2041406/202010/2041406-20201020095213583-1892769