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

[[265226]]

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

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

首先，除了和本地部署的系統(tǒng)一樣，日志記錄需要能夠反映出應(yīng)用程序的運行狀態(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)、以及其他工具。它們在架構(gòu)上可以處理大規(guī)模的數(shù)據(jù)分析，并能夠?qū)崟r地顯示處理的結(jié)果。它們不但能夠協(xié)助用戶對數(shù)據(jù)進行復(fù)雜性的搜索與查詢，還能夠支持基于API的開放性集成、以及與其他工具相集成。當(dāng)然，盡管這些工具在業(yè)界十分常用，但是要成功地將它們集成到一起，以滿足您的管控目的，則著實需要花費一些功夫。

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

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

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

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

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

3.配套實施日志安全和保留策略

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

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

4.日志存儲

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

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

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

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

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

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

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

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

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

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

使得日志級別可配置

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)然，業(yè)界也有另一種觀點認(rèn)為：日志記錄是DevOps和CI/CD的催化劑。總的說來，為了在開發(fā)管道的每一個步驟上都實現(xiàn)自動化，您需要可視化問題出現(xiàn)的位置，以及它們的主要原因，例如：錯誤代碼、問題依賴性關(guān)系、資源不足、或者是其他方面。問題的原因可能不勝枚舉，但是日志記錄絕對能夠為您提供查找和修復(fù)問題的參考維度。

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

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

9.使用日志記錄來識別自動化的契機和趨勢

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

總結(jié)

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

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

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