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

[[265226]]

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

1.使用托管日志記錄解決方案，還是自建基礎架構

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

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

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

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

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

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

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

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

由于日志勢必會接觸到敏感數(shù)據(jù)，因此我們的日志安全策略應當包含檢查諸如：客戶端的個人數(shù)據(jù)、以及API內部訪問密鑰等敏感數(shù)據(jù)源的環(huán)節(jié)。同時，在將日志傳送給任何第三方之前，我們應確保敏感數(shù)據(jù)被匿名化(或稱脫敏)或加密。為了將日志數(shù)據(jù)安全地傳輸?shù)饺罩竟芾矸掌魃希覀兺枰诳蛻舳撕头掌鞫酥g啟用、并設置TLS或HTTPS等端點加密的方式。

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

4.日志存儲

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

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

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

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

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

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

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

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

使用結構化的日志格式

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

使得日志級別可配置

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

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

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

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

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

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

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

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

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

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

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

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

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

8.獲取有關任何事件類型的實時反饋

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

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

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

總結

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

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

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