微服務(wù)的日志與監(jiān)控：微服務(wù)日志管理將面臨的挑戰(zhàn)

日志來(lái)自正在運(yùn)行的進(jìn)程的事件流。對(duì)于傳統(tǒng)的JavaEE應(yīng)用程序而言，有許多框架和庫(kù)可用于日志記錄。Java Logging (JUL）是Java自身所提供的現(xiàn)成選項(xiàng)。除此之外，Log4j、Logback和SLF4J也是其他一些流行的日志框架。

這些框架都能很好地支持UDP及 TCP。應(yīng)用程序?qū)⑷罩緱l目發(fā)送到控制臺(tái)或文件系統(tǒng)。通常使用文件回收技術(shù)來(lái)避免日志填滿所有磁盤空間。

日志處理的最佳實(shí)踐之一是關(guān)閉生產(chǎn)中的大部分日志條目，因?yàn)榇疟PIO的成本很高。磁盤IO不但會(huì)減慢應(yīng)用程序的運(yùn)行速度，還會(huì)嚴(yán)重影響它的可伸縮性。將日志寫入磁盤也需要較高的磁盤容量。當(dāng)磁盤空間用完之后，就有可能降低應(yīng)用程序的性能。日志框架提供了在運(yùn)行時(shí)控制日志記錄的選項(xiàng)，以限制必須打印及不打印的內(nèi)容。這些框架中的大部分不僅對(duì)日志記錄控件提供了細(xì)粒度的控制，還提供了在運(yùn)行時(shí)更改這些配置的選項(xiàng)。

另外，日志可能包含重要的信息，如果分析得當(dāng)，則可能具有很高的價(jià)值。因此，限制日志條目本質(zhì)上限制了用戶理解應(yīng)用程序行為的能力。所以，日志是一把“雙刃劍”。

對(duì)于傳統(tǒng)的單個(gè)架構(gòu)而言，日志管理本身并不存在難點(diǎn)，畢竟所有的日志文件都存儲(chǔ)在應(yīng)用所部署的主機(jī)上，獲取日志文件或搜索日志內(nèi)容都比較簡(jiǎn)單。但分布式系統(tǒng)則不同，特別是微服務(wù)架構(gòu)所帶來(lái)的部署應(yīng)用方式的重大轉(zhuǎn)變，都使得微服務(wù)的日志管理面臨很多新的挑戰(zhàn)，主要有以下幾種。

日志文件分散

微服務(wù)架構(gòu)所帶來(lái)的直觀結(jié)果，就是微服務(wù)實(shí)例數(shù)量的增長(zhǎng)，伴隨而來(lái)的就是日志文件的遞增。

在微服務(wù)架構(gòu)里，每個(gè)微服務(wù)實(shí)例都是獨(dú)立部署的，日志文件分散在不同的主機(jī)里。如果還是按照傳統(tǒng)的運(yùn)維方式，登錄到應(yīng)用程序所在的主機(jī)來(lái)查看日志文件，這種方式基本上不可能在微服務(wù)架構(gòu)中使用。所以需要有一套可以管理幾種日志文件的獨(dú)立系統(tǒng)。

日志容易丟失

從傳統(tǒng)部署移到云部署時(shí)，應(yīng)用程序不再鎖定到特定的預(yù)定義機(jī)器。虛擬機(jī)和容器與應(yīng)用程序之間并沒(méi)有強(qiáng)制的關(guān)聯(lián)關(guān)系，這意味著用于部署的機(jī)器可能會(huì)隨時(shí)更改。特別是像Docker這樣的容器，通常來(lái)說(shuō)都是非常短暫的，這基本上意味著不能依賴磁盤的持久狀態(tài)。一旦容器停止并重新啟動(dòng)，寫入磁盤的日志文件將會(huì)丟失。所以不能依靠本地機(jī)器的磁盤來(lái)寫日志文件。

事務(wù)跨越了多個(gè)服務(wù)

在微服務(wù)架構(gòu)中，微服務(wù)實(shí)例將運(yùn)行在孤立的物理或虛擬機(jī)上。在這種情況下，跟蹤跨多個(gè)微服務(wù)的端到端事務(wù)幾乎是不可能的?？缍鄠€(gè)微服務(wù)的事務(wù)如圖12-1所示。

在圖12-1中，每個(gè)微服務(wù)都將日志發(fā)送到本地文件系統(tǒng)。在這種情況下，事務(wù)1先調(diào)用應(yīng)用1,然后調(diào)用應(yīng)用3。由于應(yīng)用Ⅰ和應(yīng)用3運(yùn)行在不同的物理機(jī)器上，它們都將各自的日志寫入不同的日志文件。這使得難以關(guān)聯(lián)和理解端到端的事務(wù)處理流程。另外，由于應(yīng)用Ⅰ和應(yīng)用3的兩個(gè)實(shí)例在兩臺(tái)不同的機(jī)器上運(yùn)行，因此很難實(shí)現(xiàn)服務(wù)級(jí)別的日志聚合，最終導(dǎo)致了日志文件的碎片化。

日志集中化的意義

為了解決前面提到的日志管理的挑戰(zhàn)，首先需要對(duì)傳統(tǒng)的日志解決方案進(jìn)行認(rèn)真的反思。因此需要新的日志管理解決方案，除了解決上述挑戰(zhàn)外，還需要考慮以下的功能。

• 能夠收集所有日志消息并在日志消息之上運(yùn)行分析。

• 能夠關(guān)聯(lián)和跟蹤端到端的事務(wù)。

• 能夠保存更長(zhǎng)時(shí)間的日志信息，以便進(jìn)行趨勢(shì)分析和預(yù)測(cè)。

• 能夠消除對(duì)本地磁盤系統(tǒng)的依賴。

• 能夠聚合來(lái)自多個(gè)來(lái)源的日志信息，如網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、微服務(wù)等。

解決這些問(wèn)題的方法是集中存儲(chǔ)和分析所有日志消息，而不考慮日志的來(lái)源。這種新的日志解決方案中采用的基本原則是將日志存儲(chǔ)和處理從執(zhí)行環(huán)境中分離出來(lái)。

在集中式日志解決方案中，日志消息將從執(zhí)行環(huán)境發(fā)送到中央大數(shù)據(jù)存儲(chǔ)。日志分析和處理將使用大數(shù)據(jù)解決方案進(jìn)行處理。因?yàn)橄啾扰c在微服務(wù)執(zhí)行環(huán)境中存儲(chǔ)和處理大數(shù)據(jù)而言，大數(shù)據(jù)解決方案更適合及更有效地存儲(chǔ)和處理大量的日志消息。

集中化日志管理的系統(tǒng)架構(gòu)

如圖12-2所示，集中化日志管理系統(tǒng)解決方案中包含了許多組件。

這些組件如下。

• 日志流:這些是來(lái)自源系統(tǒng)的日志消息流。源系統(tǒng)可以是微服務(wù)，也可以是其他應(yīng)用程序甚至網(wǎng)絡(luò)設(shè)備。在典型的基于Java的系統(tǒng)中，這相當(dāng)于對(duì)Log4j日志消息進(jìn)行流式傳輸。

• 日志托運(yùn):這些組件負(fù)責(zé)收集來(lái)自不同來(lái)源或端點(diǎn)的日志消息。然后，日志托運(yùn)組件將這些消息發(fā)送到另一個(gè)端點(diǎn)，如寫入數(shù)據(jù)庫(kù)、推送到儀表板，或者將其發(fā)送到流處理端點(diǎn)以供進(jìn)一步實(shí)時(shí)處理。

• 日志存儲(chǔ):這是所有日志消息將被存儲(chǔ)在能夠用于實(shí)時(shí)分析的地方。通常情況下，日志存儲(chǔ)將是能夠處理大量數(shù)據(jù)的NoSQL數(shù)據(jù)庫(kù)，如HDFS等。

• 日志流處理器:這個(gè)組件能夠分析實(shí)時(shí)日志事件，以便快速做出決策。流處理器采取如儀表板發(fā)送信息、發(fā)送警報(bào)等操作。在具備自愈能力系統(tǒng)的情況下，流處理器甚至可以采取行動(dòng)來(lái)糾正這些問(wèn)題。

• 日志儀表板:該儀表板用于顯示日志分析結(jié)果窗口。這些儀表板能夠方便運(yùn)維和管理人員直觀地查看日志分析記錄。

集中化日志管理的意義

集中化日志管理的好處是不僅沒(méi)有本地IO或阻塞磁盤寫人,也沒(méi)有使用本地機(jī)器的磁盤空間。

這種架構(gòu)與用于大數(shù)據(jù)處理的Lambda架構(gòu)基本相似。

同時(shí)，每條日志信息都包含了上下文及相關(guān)ID。上下文通常會(huì)有時(shí)間戳、IP地址、用戶信息、日志類型等。關(guān)聯(lián)ID將用于建立服務(wù)調(diào)用之間的鏈接，以便可以跟蹤跨微服務(wù)的調(diào)用。

本篇文章內(nèi)容給大家講解的是微服務(wù)的日志與監(jiān)控：微服務(wù)日志管理將面臨的挑戰(zhàn)

1. 下篇文章給大家講解的是常見(jiàn)日志集中化的實(shí)現(xiàn)方式和Elastic Stack 實(shí)現(xiàn)日志集中化；

2. 覺(jué)得文章不錯(cuò)的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；

3. 感謝大家的支持！