日誌採集最佳實踐

概述

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

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

如何快速上手 ?

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

技術架構是怎樣的 ?

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， 示例:

更多時間格式配置參考日誌服務官方文檔 配置時間格式。

須要注意的是，日誌服務時間戳暫時只支持精確到秒，也就是若是業務日誌的時間戳字段精確到了毫秒，將沒法使用自定義時間戳，只能使用默認的採集時間做爲時間戳，不過期間戳精確到毫秒後續將會獲得支持。

如何查詢日誌 ?

日誌採集規則配好了，採集器就會自動開始採集日誌並上報到日誌服務，而後就能夠在 日誌服務-檢索分析 中查詢日誌了，支持 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