【51CTO.com快譯】有過云端運(yùn)營經(jīng)驗(yàn)的讀者想必都知道：云原生應(yīng)用具有分布與動(dòng)態(tài)的特性，而所有此類應(yīng)用通常都會(huì)用到容器和無服務(wù)器函數(shù)等臨時(shí)技術(shù)(ephemeral technologies)，來予以部署。而在管理這些云原生應(yīng)用的時(shí)候，能夠在任何給定的時(shí)間內(nèi)，提供端到端的可視性顯得尤為重要。

[[265226]]

與此同時(shí)，由于云原生系統(tǒng)具有海量的數(shù)據(jù)流和抽象的復(fù)雜性，因此我們必須建立強(qiáng)大的監(jiān)控和日志記錄，以管控各種不可預(yù)知的中斷或宕機(jī)。本文將和您討論在記錄和監(jiān)控云原生應(yīng)用時(shí)，各種值得借鑒和遵循的優(yōu)秀實(shí)踐與標(biāo)準(zhǔn)。

1.使用托管日志記錄解決方案，還是自建基礎(chǔ)架構(gòu)

首先，除了和本地部署的系統(tǒng)一樣，日志記錄需要能夠反映出應(yīng)用程序的運(yùn)行狀態(tài)之外，在云原生應(yīng)用中，日志記錄解決方案還應(yīng)該遵循高可用性、分布式處理、以及智能故障轉(zhuǎn)移等原則。而這恰恰就是現(xiàn)代云原生應(yīng)用與傳統(tǒng)整體式應(yīng)用的區(qū)別所在。

能夠?qū)崿F(xiàn)此類目的的常見工具包括：Elasticsearch、Fluentd、Kibana(三者常被共稱為EFK Stack)、以及其他工具。它們?cè)诩軜?gòu)上可以處理大規(guī)模的數(shù)據(jù)分析，并能夠?qū)崟r(shí)地顯示處理的結(jié)果。它們不但能夠協(xié)助用戶對(duì)數(shù)據(jù)進(jìn)行復(fù)雜性的搜索與查詢，還能夠支持基于API的開放性集成、以及與其他工具相集成。當(dāng)然，盡管這些工具在業(yè)界十分常用，但是要成功地將它們集成到一起，以滿足您的管控目的，則著實(shí)需要花費(fèi)一些功夫。

與上述自行構(gòu)建系統(tǒng)的方式相比，使用那些由供應(yīng)商構(gòu)建、并能夠靈活擴(kuò)展的托管型日志記錄解決方案，則更為方便且實(shí)用。常見的有：Elastic Stack(請(qǐng)參見)。使用此類現(xiàn)成的集成方案，您只需要將云端的應(yīng)用數(shù)據(jù)源和目標(biāo)相連接，便可輕松地獲取與分析各種應(yīng)用日志。因此，您還可以將寶貴的時(shí)間分配到監(jiān)控和記錄其他重點(diǎn)應(yīng)用之上，而不必花精力去研究如何自行構(gòu)建日志記錄的基礎(chǔ)架構(gòu)。

2.知曉哪些內(nèi)容該監(jiān)控、哪些不必記錄

眾所周知，我們監(jiān)控的數(shù)據(jù)記錄越多，我們就越難找到真正重要的數(shù)據(jù)。與此同時(shí)，更多的日志管理任務(wù)，也意味著更加復(fù)雜的日志存儲(chǔ)與管理過程。

因此，我們需要認(rèn)真考慮那些必須記錄的內(nèi)容。例如，在任何類型的生產(chǎn)環(huán)境中，那些具有合規(guī)性、和滿足審計(jì)目的、以及至關(guān)重要的數(shù)據(jù)理應(yīng)得到完整的記錄。另外，對(duì)于那些能夠幫助您解決性能和用戶體驗(yàn)方面的問題、以及與安全事件相關(guān)的數(shù)據(jù)也需要被持續(xù)監(jiān)控與記錄。

那么，哪些數(shù)據(jù)類別不需要被記錄呢?例如：來自測(cè)試環(huán)境的數(shù)據(jù)，由于它們不是軟件交付管道(delivery pipeline)的重要組成部分，而且出于合規(guī)性或安全方面的考慮，我們對(duì)于此類數(shù)據(jù)不予記錄。另外，如果用戶啟用了“禁止跟蹤(do-not-track)”的設(shè)置，那么我們就不應(yīng)記錄與該用戶關(guān)聯(lián)的所有數(shù)據(jù)。同理，在確定自己的日志記錄和存儲(chǔ)過程已滿足了該數(shù)據(jù)的安全要求之前，我們也要避免記錄某些具有高敏感性的數(shù)據(jù)(如，信用卡號(hào)等)。

3.配套實(shí)施日志安全和保留策略

由于日志勢(shì)必會(huì)接觸到敏感數(shù)據(jù)，因此我們的日志安全策略應(yīng)當(dāng)包含檢查諸如：客戶端的個(gè)人數(shù)據(jù)、以及API內(nèi)部訪問密鑰等敏感數(shù)據(jù)源的環(huán)節(jié)。同時(shí)，在將日志傳送給任何第三方之前，我們應(yīng)確保敏感數(shù)據(jù)被匿名化(或稱脫敏)或加密。為了將日志數(shù)據(jù)安全地傳輸?shù)饺罩竟芾矸?wù)器上，我們往往需要在客戶端和服務(wù)器端之間啟用、并設(shè)置TLS或HTTPS等端點(diǎn)加密的方式。

同時(shí)，不同來源的日志可能需要被分配不同的保留時(shí)間策略。例如：某些應(yīng)用可能僅與幾天之內(nèi)的故障排除相關(guān);而那些與安全相關(guān)的事務(wù)日志、或業(yè)務(wù)事務(wù)日志，則需要有更長的保留期限。因此，我們的留存策略應(yīng)該對(duì)于日志源是靈活、且細(xì)粒度的。

4.日志存儲(chǔ)

我們?cè)谝?guī)劃日志存儲(chǔ)的容量時(shí)，應(yīng)充分考慮到高負(fù)載時(shí)的峰值流量。在系統(tǒng)平穩(wěn)運(yùn)行時(shí)，應(yīng)用每天所產(chǎn)生的數(shù)據(jù)量幾乎是不變的，而且主要取決于系統(tǒng)的利用率、以及服務(wù)每天的事務(wù)量。而系統(tǒng)在出現(xiàn)嚴(yán)重錯(cuò)誤的情況下，我們通常會(huì)發(fā)現(xiàn)日志卷的猛增。

因此，如果日志存儲(chǔ)達(dá)到分配空間的限制，而您又沒有設(shè)置過“滑動(dòng)窗體”策略的話，那么就可能無法再繼續(xù)存入那些對(duì)于修復(fù)系統(tǒng)錯(cuò)誤來說至關(guān)重要的日志。此處的滑動(dòng)窗體是指：日志存儲(chǔ)循環(huán)地在緩沖區(qū)上進(jìn)行工作，以實(shí)現(xiàn)在應(yīng)用數(shù)據(jù)達(dá)到存儲(chǔ)空間的限制之前，自動(dòng)將最早的數(shù)據(jù)刪除掉，以保持日志的存入。

如果有人問：“什么是比系統(tǒng)宕機(jī)時(shí)間更糟糕的事情?”那么我的回答是：“缺乏相應(yīng)的故障排除信息，以至于反過來延長了宕機(jī)時(shí)間。”可見，我們?cè)谠O(shè)計(jì)日志存儲(chǔ)時(shí)，要保持它的可擴(kuò)展性和可靠性。

另外，日志存儲(chǔ)應(yīng)該配備有單獨(dú)的安全策略，我們將各種日志實(shí)時(shí)地、集中性地傳送到某臺(tái)中央存儲(chǔ)庫上，如果不法分子有可能訪問您的基礎(chǔ)架構(gòu)的話，則可以考慮將日志發(fā)送到異地(例如，使用專門提供日志服務(wù)的SaaS)，以避免證據(jù)被篡改。

5.查看并持續(xù)維護(hù)您的日志

缺少對(duì)于日志數(shù)據(jù)的維護(hù)，可能會(huì)導(dǎo)致排障時(shí)間的延長、敏感數(shù)據(jù)的暴露、以及日志存儲(chǔ)成本的走高。我們需要定期查看應(yīng)用日志的輸出，通過審查服務(wù)的可用性、可操作性、以及安全性等方面的內(nèi)容，以及時(shí)按需調(diào)整系統(tǒng)。

創(chuàng)建有意義的日志信息

如果日志中只包含了局部且“神秘”的錯(cuò)誤代碼與信息，那么運(yùn)營部門是需要花時(shí)間進(jìn)行解讀的。只有那些易讀且實(shí)用的日志消息，才是快速進(jìn)行排障的關(guān)鍵。因此，各類開發(fā)人員應(yīng)當(dāng)盡可能地通過提供有意義的日志信息，來節(jié)省診斷的寶貴時(shí)間。

使用結(jié)構(gòu)化的日志格式

結(jié)構(gòu)化的日志格式(例如：JSON或key/value格式)可以包含諸如：時(shí)間戳、嚴(yán)重性、進(jìn)程ID、事務(wù)ID等與消息相關(guān)的數(shù)據(jù)字段。如果您尚未對(duì)所有應(yīng)用采取統(tǒng)一的日志格式，那么請(qǐng)盡快規(guī)范化和標(biāo)準(zhǔn)化日志的產(chǎn)生，以便系統(tǒng)能夠以結(jié)構(gòu)化的方式，高效地進(jìn)行日志的合并、解析與存儲(chǔ)。

使得日志級(jí)別可配置

在現(xiàn)實(shí)系統(tǒng)中，我們時(shí)常會(huì)發(fā)現(xiàn)某些應(yīng)用的日志過于冗長，而某些應(yīng)用日志卻沒能涵括足夠的服務(wù)信息。因此，我們需要通過可調(diào)整的日志級(jí)別(log levels)，來配置各種日志的詳略程度。另外，我們?cè)谌罩緦忛喌倪^程中，也要注意通過以脫敏和加密的方式，在詳細(xì)程度與不公開個(gè)人隱私數(shù)據(jù)、以及保護(hù)安全信息之間的建立平衡。

持續(xù)檢查審計(jì)日志

安全問題的迅速解決，依賴于我們持續(xù)對(duì)于審計(jì)日志的檢查。我們可以通過配置諸如auditd或OSSEC代理之類的安全工具，以實(shí)時(shí)日志分析的方式，生成各種指向潛在安全問題的警報(bào)日志。通過一些既定的警報(bào)日志級(jí)別，運(yùn)營人員能夠快速地獲悉任何可疑的活動(dòng)。您可以通過鏈接：https://sematext.com/blog/auditd-logs-auditbeat-elasticsearch-logsene/，來進(jìn)一步了解auditd的使用，以及各種補(bǔ)充性的框架。

使用如下日志審閱檢查表:

1. 該日志消息對(duì)用戶是否有意義?
2. 該日志消息是否包含有利于排障的上下文?
3. 該日志消息是否已被結(jié)構(gòu)化，且包括：

• 時(shí)間戳
• 嚴(yán)重性/日志級(jí)別
• 消息主體
• 其他排障信息的特征字段

1. 是否需要第三方日志解析與結(jié)構(gòu)化服務(wù)(配置日志代理)?
2. 日志級(jí)別是否可配置?
3. 該日志消息是否包含了個(gè)人數(shù)據(jù)或與安全相關(guān)的數(shù)據(jù)?
4. 是否具備檢查審計(jì)日志和調(diào)整警報(bào)日志的規(guī)則?
5. 是否已對(duì)警報(bào)日志進(jìn)行了設(shè)置?

6.不要孤立地進(jìn)行日志分析，請(qǐng)將所有數(shù)據(jù)源關(guān)聯(lián)起來

日志記錄應(yīng)該被納入到您的整體監(jiān)控策略之中。也就是說，要想實(shí)現(xiàn)真正有效的監(jiān)控，您需要使用其他類型的監(jiān)控方法(如，基于事件、警報(bào)和跟蹤的監(jiān)控類型)，來作為日志記錄的補(bǔ)充，以便隨時(shí)掌握系統(tǒng)中某個(gè)事情的“全貌”。雖然日志數(shù)據(jù)能夠針對(duì)某個(gè)問題的局部，提供非常詳盡信息，但是它卻往往無法以相互關(guān)聯(lián)的方式，給您提供全局維度的狀態(tài)信息。我們需要通過各種聚合級(jí)別的指標(biāo)和事件，來有效地從問題的開端“順藤摸瓜”地查找問題。

可見，我們不應(yīng)該孤立地查看日志，而需要綜合使用諸如：APM、網(wǎng)絡(luò)監(jiān)控、以及基礎(chǔ)架構(gòu)監(jiān)控等其他類型的監(jiān)控工具，來補(bǔ)足日志的“短板”。通過靈活地將各類工具集成到一個(gè)窗體視圖之上，我們能夠一站式地輕松獲取所有監(jiān)控信息，甚至能得到一些趨勢(shì)圖表。

7.將查看日志記錄作為GitOps的催化劑

隨著持續(xù)集成越來越多地在CI/CD管道起點(diǎn)被觸發(fā)，GitOps需要在不降低產(chǎn)品質(zhì)量和安全認(rèn)證質(zhì)量的情況下，實(shí)現(xiàn)軟件交付的自動(dòng)化、并達(dá)到迭代速度。對(duì)于忙碌的DevOps團(tuán)隊(duì)而言，他們很容易將日志記錄視為其自動(dòng)化管道、以及頻繁發(fā)布的一種工具，而欣然接受之。

當(dāng)然，業(yè)界也有另一種觀點(diǎn)認(rèn)為：日志記錄是DevOps和CI/CD的催化劑?？偟恼f來，為了在開發(fā)管道的每一個(gè)步驟上都實(shí)現(xiàn)自動(dòng)化，您需要可視化問題出現(xiàn)的位置，以及它們的主要原因，例如：錯(cuò)誤代碼、問題依賴性關(guān)系、資源不足、或者是其他方面。問題的原因可能不勝枚舉，但是日志記錄絕對(duì)能夠?yàn)槟峁┎檎液托迯?fù)問題的參考維度。

8.獲取有關(guān)任何事件類型的實(shí)時(shí)反饋

自動(dòng)化測(cè)試、以及headless測(cè)試等新的方法，使得開發(fā)人員能夠在研發(fā)環(huán)境中，對(duì)于每一行代碼的更改，都能夠在提交之時(shí)，甚至是提交之前就能夠獲取實(shí)時(shí)的效果反饋。因此，隨著測(cè)試的左移(shifts left)，以及對(duì)于管道起點(diǎn)的日益重視，日志記錄對(duì)于獲得可視性，以及GitOps的啟動(dòng)都是至關(guān)重要的?？梢哉f，如果沒有適當(dāng)?shù)臏y(cè)試和日志記錄，您的版本發(fā)布與部署可能會(huì)完全失控。

9.使用日志記錄來識(shí)別自動(dòng)化的契機(jī)和趨勢(shì)

同時(shí)，日志記錄除了有助于我們?cè)诠艿乐斜M早地發(fā)現(xiàn)問題，進(jìn)而為自己的團(tuán)隊(duì)節(jié)省寶貴的時(shí)間與精力之外，它還可以幫助我們找到自動(dòng)化的契機(jī)。您可以通過設(shè)置自定義的警報(bào)，以便在發(fā)生故障時(shí)被觸發(fā)，并且可以預(yù)先設(shè)定好針對(duì)警報(bào)的各種自動(dòng)化操作。無論是通過Slack的自定義腳本，還是Jenkins的自動(dòng)化插件，您都可以使用不同的日志，在GitOps的流程中驅(qū)動(dòng)自動(dòng)化。

總結(jié)

總之，日志記錄是構(gòu)建和管理云原生應(yīng)用的重要組成部分。成功的日志記錄，不但能夠反映應(yīng)用程序的狀態(tài)，而且能夠與之共同擴(kuò)展和迭代。同時(shí)，我們不應(yīng)孤立地分析日志，而應(yīng)當(dāng)學(xué)會(huì)與其他云原生應(yīng)用類型的監(jiān)控解決方案相集成，共同實(shí)現(xiàn)監(jiān)控與度量。另外，日志記錄還能夠通過驅(qū)動(dòng)GitOps的自動(dòng)化，以實(shí)現(xiàn)事件類型的實(shí)時(shí)反饋。

原文標(biāo)題：Best Practices for Efficient Log Management and Monitoring，作者：Twain Taylor & Stefan Thies

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】