Kubernetes中的日志詳細(xì)介紹

Kubernetes 中日志重要性

發(fā)展壯大離不開廣大客戶長(zhǎng)期以來的信賴與支持,我們將始終秉承“誠(chéng)信為本、服務(wù)至上”的服務(wù)理念,堅(jiān)持“二合一”的優(yōu)良服務(wù)模式,真誠(chéng)服務(wù)每家企業(yè),認(rèn)真做好每個(gè)細(xì)節(jié),不斷完善自我,成就企業(yè),實(shí)現(xiàn)共贏。行業(yè)涉及成都地磅秤等,在網(wǎng)站建設(shè)、全網(wǎng)整合營(yíng)銷推廣、WAP手機(jī)網(wǎng)站、VI設(shè)計(jì)、軟件開發(fā)等項(xiàng)目上具有豐富的設(shè)計(jì)經(jīng)驗(yàn)。

通常日志最基礎(chǔ)的作用是記錄程序的運(yùn)行軌跡,在此之上會(huì)衍生出非常多的功能,例如線上監(jiān)控、告警、運(yùn)營(yíng)分析、安全分析等等(詳情可以參見第一篇文章《6 個(gè) K8s 日志系統(tǒng)建設(shè)中的典型問題,你遇到過幾個(gè)?》,這些功能反過來也對(duì)日志具備一定的要求,我們需要盡可能的將日志規(guī)范化,以減少收集、解析、分析的代價(jià)。

在 Kubernetes 中,環(huán)境的動(dòng)態(tài)性很強(qiáng),日志基本上都是易失的,因此需要實(shí)時(shí)將日志采集到中心的存儲(chǔ)中,為了配合日志采集,對(duì)于日志的輸出、采集會(huì)有更多的要求。

下述我們列舉了 Kubernetes 中,日志輸出的常見注意事項(xiàng)(其中標(biāo)記 (*)的是 Kubernetes 中特有的項(xiàng)目):

  1. 如何選擇日志等級(jí)
  2. 日志內(nèi)容規(guī)范
  3. 合理控制日志輸出量
  4. 選擇多種日志輸出目標(biāo)
  5. 控制日志性能消耗
  6. 如何選擇日志庫(kù)
  7. 日志形態(tài)選擇(*)
  8. 日志是否落盤以及落盤介質(zhì)(*)
  9. 如何保證日志存儲(chǔ)周期(*)

如何選擇日志等級(jí)

日志等級(jí)是用來區(qū)分日志對(duì)應(yīng)事件嚴(yán)重程度的說明,這是所有日志中必須具備的一個(gè)選項(xiàng)。通常日志會(huì)分為 6 個(gè)不同的等級(jí):

  • FATAL(致命):用來輸出非常嚴(yán)重或預(yù)期中不會(huì)發(fā)生的錯(cuò)誤,遇到此種錯(cuò)誤應(yīng)當(dāng)立即報(bào)警并人工介入處理;
  • ERROR (錯(cuò)誤):非預(yù)期中的錯(cuò)誤,此種錯(cuò)誤可能導(dǎo)致部分系統(tǒng)異常但不會(huì)影響核心業(yè)務(wù)和系統(tǒng)正常運(yùn)行;
  • WARN(警告):潛在的危險(xiǎn)或值得關(guān)注的信息(比較核心的路徑);
  • INFO(信息):應(yīng)用執(zhí)行過程中的詳細(xì)信息,一般通過該信息可以看到每個(gè)請(qǐng)求的主要執(zhí)行過程;
  • DEBUG(調(diào)試):用于線下調(diào)試的日志信息,用于分析應(yīng)用執(zhí)行邏輯,線上應(yīng)用切勿開啟;
  • TRACE(跟蹤):輸出最細(xì)致的運(yùn)行軌跡,可能包含涉及的數(shù)據(jù)內(nèi)容。

作為程序員,一定要合理設(shè)置日志等級(jí),個(gè)人在開發(fā)過程中總結(jié)了以下幾點(diǎn)經(jīng)驗(yàn):

  1. FATAL 類型日志一定是非常嚴(yán)重的錯(cuò)誤、需要人工處理的場(chǎng)景打印的;
  2. ERROR 和 WARNING 的區(qū)別很多程序員難以選擇,可以從告警角度考慮:ERROR 為一般需要告警,WARNING 為不需要;
  3. 日志等級(jí)一方面是為了能夠表示日志的嚴(yán)重程度,另一方面也是為了控制應(yīng)用程序的日志輸出量,通常線上只能打開 INFO 或 WARN 的日志;
  4. DEBUG 日志可以多打,方便分析問題;
  5. 所有用戶請(qǐng)求日志,必須記錄;
  6. 對(duì)于不確定的外部系統(tǒng)調(diào)用,日志需盡可能覆蓋周全;
  7. 程序中的日志庫(kù)需要具備運(yùn)行期間變更日志等級(jí)的能力,方便在遇到問題需要分析時(shí)臨時(shí)更改日志等級(jí);
  8. 通常在新功能上線,涉及的日志可適當(dāng)提升一個(gè)等級(jí),方便實(shí)時(shí)觀察和監(jiān)控,待穩(wěn)定后再調(diào)整到正常(記得加上注釋,方便改回來)。

日志內(nèi)容規(guī)范

通常在沒有約束的情況下,程序員的發(fā)揮天馬行空,各種日志內(nèi)容都會(huì)出現(xiàn),這些只有開發(fā)自己才能看懂的日志很難進(jìn)行分析和告警。因此我們需要一個(gè)日志頂向下的規(guī)范來約束項(xiàng)目中的開發(fā)人員,讓所有的日志看起來是一個(gè)人打印的而且是易于分析的。

日志的字段

日志中通常必備的字段有:Time、Level、Location。對(duì)于特定模塊/流程/業(yè)務(wù),還需要有一些 Common 的字段,例如:

  1. 如果使用 Trace 系統(tǒng),可以把 TraceID 附加到日志中;
  2. 固定的流程需要附加對(duì)應(yīng)的字段,例如訂單的生命周期中,一定要有訂單號(hào)、用戶 ID 等信息,這些信息可以通過 Context 附加到對(duì)應(yīng)流程的日志實(shí)例上;
  3. HTTP 請(qǐng)求需要記錄:URL、Method、Status、Latency、Inflow、OutFlow、ClientIP、UserAgent 等,詳情可以參考 Nginx日志格式;
  4. 如果多個(gè)模塊的日志都打印到同一個(gè)流/文件中,必須有字段標(biāo)識(shí)模塊名。

日志的字段規(guī)約最好由運(yùn)維平臺(tái)/中間件平臺(tái)自頂向下推動(dòng),約束每個(gè)模塊/流程的程序員按照規(guī)定打印日志。

日志表現(xiàn)形式

通常我們建議使用 KeyValue 對(duì)形式的日志格式,比如我們阿里的飛天日志庫(kù)采用的就是這種形式:

[2019-12-30 21:45:30.611992]    [WARNING]       [958] [block_writer.cpp:671]  path:pangu://localcluster/index/3/prom/7/1577711464522767696_0_1577711517     min_time:1577712000000000       max_time:1577715600000000       normal_count:27595      config:prom     start_line:57315569     end_line:57343195       latency(ms):42  type:AddBlock

KeyValue 對(duì)的日志可以完全自解析且易于理解,同時(shí)便于日志采集時(shí)自動(dòng)解析。

另外推薦的是 JSON 日志格式,支持以 JSON 格式輸出的日志庫(kù)很多,而且大部分的日志采集 Agent 都支持 JSON 格式的日志收集。

{"addr":"tcp://0.0.0.0:10010","caller":"main.go:98","err":"listen tcp: address tcp://0.0.0.0:10010: too many colons in address","level":"error","msg":"Failed to listen","ts":"2019-03-08T10:02:47.469421Z"}

注意:絕大部分場(chǎng)景不建議使用非可讀的日志格式(例如 ProtoBuf、Binlog 等)。

單條日志換行問題

非必要情況下,盡量不要一條日志輸出成多行,這種對(duì)于采集、解析和索引的代價(jià)都比較高。

合理控制日志輸出量

日志的輸出量直接影響到磁盤使用以及對(duì)于應(yīng)用的性能消耗,日志太多不利于查看、采集、分析;日志太少不利于監(jiān)控,同時(shí)在出現(xiàn)問題的時(shí)候沒辦法調(diào)查。

一般線上應(yīng)用需合理控制日志的數(shù)據(jù)量:

  1. 服務(wù)入口的請(qǐng)求和響應(yīng)日志沒有特殊原因都要輸出并采集,采集的字段可以根據(jù)需求調(diào)整;
  2. 錯(cuò)誤日志一般都要打印,如果太多,可以使用采樣方式打??;
  3. 減少無(wú)效日志輸出,尤其是循環(huán)中打印日志的情況需盡量減少;
  4. 請(qǐng)求型的日志(比如 Ingress、Nginx 訪問日志)一般不超過 5MB/s(500 字節(jié)每條,不超過 1W/s),應(yīng)用程序日志不超過 200KB/s(2KB 每條,不超過 100 條/s)。

選擇多種日志輸出目標(biāo)

建議一個(gè)應(yīng)用不同類型的日志輸出到不同的目標(biāo)(文件),這樣便于分類采集、查看和監(jiān)控。例如:

  1. 訪問日志單獨(dú)放到一個(gè)文件,如果域名不多,可以按照一個(gè)域名一個(gè)文件的形式;
  2. 錯(cuò)誤類的日志單獨(dú)放一個(gè)文件,單獨(dú)配置監(jiān)控告警;
  3. 調(diào)用外部系統(tǒng)的日志單獨(dú)放一個(gè)文件,便于后續(xù)對(duì)賬、審計(jì);
  4. 中間件通常都由統(tǒng)一的平臺(tái)提供,日志一般單獨(dú)打印一個(gè)文件。

控制日志性能消耗

日志作為業(yè)務(wù)系統(tǒng)的輔助模塊,一定不能影響到業(yè)務(wù)正常的工作,因此日志模塊的性能消耗需要單獨(dú)額外注意,一般在選擇/開發(fā)日志庫(kù)時(shí),需要對(duì)日志庫(kù)進(jìn)行性能測(cè)試,確保正常情況下日志的性能消耗不超過整體 CPU 占用的 5%。

注意:一定要確保日志打印是異步的,不能阻塞業(yè)務(wù)系統(tǒng)運(yùn)行。

如何選擇日志庫(kù)

開源的日志庫(kù)非常多,基本每個(gè)語(yǔ)言都有數(shù)十種,選擇一個(gè)符合公司/業(yè)務(wù)需求的日志庫(kù)需要精挑細(xì)選,有一個(gè)簡(jiǎn)單的指導(dǎo)原則是盡可能使用比較流行的日志庫(kù)的穩(wěn)定版本,入坑的幾率要小一點(diǎn)。例如:

  1. Java 使用 Log4J、LogBack;
  2. Golang 使用 go-kit;
  3. Python 默認(rèn)集成的日志庫(kù)大部分場(chǎng)景都?jí)蛴茫ㄗh閱讀一下 CookBook;
  4. C++ 推薦使用 spdlog,高性能、跨平臺(tái)。

日志形態(tài)選擇

在虛擬機(jī)/物理機(jī)的場(chǎng)景中,絕大部分應(yīng)用都以文件的形式輸出日志(只有一些系統(tǒng)應(yīng)用輸出到 syslog/journal);而在容器場(chǎng)景中,多了一個(gè)標(biāo)準(zhǔn)輸出的方式,應(yīng)用把日志打到 stdout 或 stderr 上,日志會(huì)自動(dòng)進(jìn)入到 docker 的日志模塊,可以通過 docker logs 或 kubectl logs 直接查看。

容器的標(biāo)準(zhǔn)輸出只適應(yīng)于比較單一的應(yīng)用,例如 K8s 中的一些系統(tǒng)組件,線上的服務(wù)類應(yīng)用通常都會(huì)涉及到多個(gè)層級(jí)(中間件)、和各種服務(wù)交互,一般日志都會(huì)分為好幾類,如果全部打印到容器的標(biāo)準(zhǔn)輸出,很難區(qū)分處理。<br />同時(shí)容器標(biāo)準(zhǔn)輸出對(duì)于 DockerEngine 的性能消耗特別大,實(shí)測(cè) 10W/s 的日志量會(huì)額外占用 DockerEngine 1 個(gè)核心的 CPU(單核 100%)。

日志是否落盤以及落盤介質(zhì)

在 Kubernetes 中,還可以將日志庫(kù)直接對(duì)接日志系統(tǒng),日志打印的時(shí)候不落盤而直接傳輸?shù)饺罩鞠到y(tǒng)后端。這種使用方式免去了日志落盤、Agent 采集的過程,整體性能會(huì)高很多。

這種方式我們一般只建議日志量極大的場(chǎng)景使用,普通情況下還是直接落盤,相比直接發(fā)送到后端的方式,落盤增加了一層文件緩存,在網(wǎng)絡(luò)失敗的情況下還能緩存一定的數(shù)據(jù),在日志系統(tǒng)不可用的情況下我們的研發(fā)運(yùn)維同學(xué)可以直接查看文件的日志,提高整體的可靠性。

Kubernetes 提供了多種存儲(chǔ)方式,一般在云上,都會(huì)提供本地存儲(chǔ)、遠(yuǎn)程文件存儲(chǔ)、對(duì)象存儲(chǔ)等方式。由于日志寫入的 QPS 很高,和應(yīng)用也直接相關(guān),如果使用遠(yuǎn)程類型的存儲(chǔ),會(huì)額外多 2-3 次網(wǎng)絡(luò)通信開銷。我們一般建議使用本地存儲(chǔ)的方式,可以使用 HostVolume 或者 EmptyDir 的方式,這樣對(duì)于寫入和采集的性能影響會(huì)盡可能的小。

如何保證日志存儲(chǔ)周期

相比傳統(tǒng)虛擬機(jī)/物理機(jī)的場(chǎng)景,Kubernetes 對(duì)于節(jié)點(diǎn)、應(yīng)用層提供了強(qiáng)大的調(diào)度、容錯(cuò)、縮/擴(kuò)容能力,我們通過 Kubernetes 很容易就能讓應(yīng)用獲得高可靠運(yùn)行、極致彈性。這些優(yōu)勢(shì)帶來的一個(gè)現(xiàn)象是:節(jié)點(diǎn)動(dòng)態(tài)創(chuàng)建/刪除、容器動(dòng)態(tài)創(chuàng)建/刪除,這樣日志也會(huì)隨時(shí)銷毀,沒辦法保證日志的存儲(chǔ)周期能夠滿足 DevOps、審計(jì)等相關(guān)的需求。

在動(dòng)態(tài)的環(huán)境下實(shí)現(xiàn)日志的長(zhǎng)期存儲(chǔ)只能通過中心化的日志存儲(chǔ)來實(shí)現(xiàn),通過實(shí)時(shí)的日志采集方式,將各個(gè)節(jié)點(diǎn)、各個(gè)容器的日志在秒級(jí)內(nèi)采集到日志中心系統(tǒng)上,即使節(jié)點(diǎn)/容器掛掉也能夠通過日志還原當(dāng)時(shí)的現(xiàn)場(chǎng)。

總結(jié)

日志輸出是日志系統(tǒng)建設(shè)中非常重要的環(huán)節(jié),公司/產(chǎn)品線一定要遵循一個(gè)統(tǒng)一的日志規(guī)范,這樣才能保證后續(xù)日志采集、分析、監(jiān)控、可視化能夠順利進(jìn)行。

當(dāng)前名稱:Kubernetes中的日志詳細(xì)介紹
網(wǎng)頁(yè)路徑:http://muchs.cn/article14/iheoge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供外貿(mào)建站移動(dòng)網(wǎng)站建設(shè)、軟件開發(fā)、靜態(tài)網(wǎng)站、、用戶體驗(yàn)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

綿陽(yáng)服務(wù)器托管