DevOps雲翼日誌服務實踐

10月30日，全球權威數據調研機構IDC正式發佈《IDCMarketScape: 中國DevOps雲市場2019，廠商評估》報告。京東雲憑藉豐富的場景和實踐能力，以及高質量的服務交付和平臺穩定性，取得優異的成績， 躋身「Major Players」（核心廠商）位置。
京東雲DevOps能力起源於自身的業務實踐，針對京東集團的複雜業務場景打造並經受住屢次61八、11.11電商大促的嚴峻考驗，保證了高效高質的交付和對變化的靈活應對。可以支持複雜場景的自動化運維需求、實現工具鏈產品與平臺化產品結合，幫助客戶根據不一樣的需求靈活定製方案。

前兩次的專題內容中，咱們分別與你們分享了大型企業級監控系統的設計以及監控系統的可觀測性與數據存儲。今天，咱們將經過介紹京東雲DevOps落地實踐，和你們繼續分享DevOps中另外一個重要內容：日誌查詢服務。

日誌查詢服務，是構建軟件項目的基石之一，是系統穩定運行必不可少的一部分，已然成爲DevOps中的標配選項。這裏，咱們來聊一聊京東雲翼DevOps平臺的日誌查詢服務實踐。

本着客戶爲先，全心全意爲用戶服務的原則，雲翼日誌查詢服務的發展分如下幾個階段解決用戶的日誌需求：

場景一：用戶須要查看本身的應用日誌，以此來判斷本身的應用程序當前運行是否正常，或者在遇到問題時，須要經過查看應用輸出的日誌信息來定位問題。

針對用戶的這個需求，咱們開發並提供了現場日誌查詢功能。

何爲現場日誌？就是案發現場的日誌。案發現場通常在哪裏呢？固然是用戶應用部署所在的主機了。

咱們提供現場日誌查詢的功能，用於查詢用戶主機上的應用日誌。該功能默認支持規範目錄下的日誌查詢，且支持擴展的自定義路徑。

• 規範目錄：/export/Logs/$appName/$instanceName/，在用戶主機這個目錄下的日誌文件，會自動列到頁面，用戶選擇要查詢的文件進行查詢便可。$appName 表明用戶的應用名稱；$instanceName 表明應用部署的實例名稱。
• 用戶自定義路徑舉例：/export/test.log，因爲這個路徑對咱們系統來說是「不規範」的，用戶若是須要查這個日誌信息，就須要本身手動輸入該日誌路徑，而後再執行查詢操做。

現場日誌查詢文件選擇示例圖

如何實現現場日誌查詢功能

想一想通常咱們本身要查看主機上的日誌是怎麼作的呢？第一步每每是ssh登陸到主機，而後經過grep命令查詢指定內容。是的，咱們的現場日誌就是將這一過程進行了平臺化，用戶在現場日誌頁面上選擇要查詢的日誌文件，輸入要查詢的關鍵字，點查詢按鈕便可。出於安全性考慮，ssh認證咱們採用密鑰認證而非密碼認證。固然了，既然經過ssh鏈接，那就要求用戶主機必須開放22端口。

現場日誌經過ssh查詢遇到的問題

好比有的用戶的主機是在VPC裏的，ssh直接訪問不到，怎麼辦呢？想一想辦法這個問題是能夠解決的，那就是配置代理，這樣就致使漸漸地要維護一堆的代理配置。

改進措施

隨着雲翼內部新的控制系統zero的出現（zero是一套控制系統，經過給用戶主機上的zero-agent下發任務實現對用戶主機的一些操做），現場日誌查詢有了新的實現方式，能夠經過調用控制系統API，用控制系統下發任務的方式來實現日誌查詢，這樣採用http的鏈接方式替代以前的ssh，再也不依賴密鑰，也再也不須要再維護一堆的ssh代理配置了。嗯，感受一下清爽了好多。

新的困境

改變實現方式後，發現一個新的問題，就是用戶單條日誌太大的狀況下，查詢數據量若是超過zero-agent一次傳輸數據量的限制會致使查詢失敗，這裏就須要作個權衡了，要麼用戶調整日誌長度，要麼減少一頁的數據展現條數，再要麼能夠考慮換一種查詢方式，好比用下面將要介紹的歷史日誌查詢，固然了，這只是權宜之計，歷史日誌功能並非爲了解決這個問題才產生的。

---

場景二：用戶的應用部署在多臺機器上，用戶須要對多臺機器上的日誌進行集中檢索，且作日誌檢索時不但願消耗本身機器上的資源（好比帶寬、內存、CPU）。

爲此，雲翼的歷史日誌查詢功能應運而生。咱們指望歷史日誌支持最近7天的日誌檢索。

既然要集中檢索，那咱們首先須要及時把日誌數據採集走，進行集中存儲。這裏須要用戶作一個日誌訂閱的操做，其實就是告訴日誌服務要採集哪一個應用下的哪一個日誌文件的數據。

日誌數據流向圖：

上圖反映了用戶訂閱後，用戶日誌數據的流向狀況。能夠看到數據存儲涉及兩種介質，一種是kafka，一種是ES，數據先緩存到kafka，最終流向ES。ElasticSearch簡稱ES，是一個開源的分佈式搜索引擎，咱們的歷史日誌查詢功能正是藉助於ES強大的搜索能力實現的。

下面依次介紹一下上圖中的log-agent、fwd和indexer模塊。

• log-agent，是雲翼的日誌採集客戶端，部署在用戶的應用主機上。它能夠動態發現用戶的訂閱信息，實時採集日誌數據並將數據上報給fwd模塊。log-agent內部封裝了rsyslog，經過控制rsyslog的配置以及程序的啓停來實現對用戶日誌的採集。rsyslog是linux上一款比較成熟的系統日誌採集工具，咱們拿來採集應用級別的日誌，固然也是能夠的。
• fwd，這個模塊負責接收log-agent上報的數據，並轉發至kafka。它的價值在於解耦了log-agent和kafka，避免了成千上萬的主機和kafka直連；當kafka有變更的時候，咱們只給有限的幾臺fwd作修改和升級便可，不須要對全部的log-agent作統一的升級了。
• indexer，該模塊能夠被看做一個數據搬運工，負責把日誌數據從kafka搬到ES。indexer的本質是rsyslog，它的輸入是kafka，輸出是ES。是否是發現rsyslog很強大？這個模塊雖然簡單，但很重要。曾經一度使人特別頭疼的是它常常罷工，要麼吃內存，要麼假死不幹活。它不幹活，ES就得眼巴巴等數據而不得，ES沒數據，歷史日誌就查不出內容，這個問題簡直太嚴重了。通過反覆排查分析，最終發現是因爲action隊列裏的消息出隊太慢致使的，在對rsyslog的隊列配置反覆作了幾回調整後，這傢伙終於肯乖乖幹活了，好開心。有時候並非現成的工具很差用，而是咱們不會用。

ES索引介紹

ES存儲離不開索引，最初咱們的索引是按照天的粒度來建立的，一天一個索引，例如：index-log-2019-10-21。可是隨着日誌量的增長，按天索引，每次查詢時，搜索範圍太大，會致使一次查詢特別慢，用戶體驗很是很差。爲了提高查詢效率，後來就把索引改爲了小時粒度，例如：index-log-2019-10-21-13。

索引時間如何肯定

看完ES索引介紹，有人可能會有疑惑，既然是按時間索引，這個時間具體是怎麼取的呢？從用戶的日誌消息中解析的嗎？不是的。用戶的日誌，時間格式各不相同，從用戶日誌中解析時間顯然是不現實的。

難道是按照當前的搬運時間來肯定索引？這樣的話，在數據處理不及時，kafka消息有積壓的狀況下，用戶日誌中的時間和索引的時間就極可能不一致了呀，好比15點的數據，可能會放到16點的索引中，這樣在搜索15點的數據的時候是搜不到指望的數據的。

這裏要說明一下，咱們log-agent採集的每條數據，除了日誌內容外，都會帶有一些元信息，好比部門名稱、應用名、日誌文件路徑，time時間戳等，這裏的時間戳記錄的是日誌採集時的時間，因爲是實時採集，這個時間和用戶應用日誌中的時間能夠看做是幾乎相等的。在索引數據前，先解析出time時間戳，經過這個時間戳來肯定具體的索引。這樣即便在kafka消息有積壓的狀況下，也能保證日誌數據能夠正確存放到指望的索引中。

歷史日誌查詢示例圖

歷史日誌面臨的問題

隨着日誌量的增多，有一個比較尷尬的問題，就是ES存儲資源會出現不足的狀況。這是一個須要咱們和用戶一塊兒努力來解決的問題。

---

場景三：有的用戶以爲本身應用的日誌比較重要，但願可以長久保留，好比三個月、半年……當忽然須要某天的數據了，能夠經過日誌服務將數據文件下載下來進行查看。

針對這個用戶需求，咱們的作法是將用戶的日誌按照日期進行存儲，而後在前端頁面提供日誌下載功能，供用戶根據須要進行查詢和下載指定日期的的日誌文件。這裏咱們抽象出的功能叫日誌下載。

日誌下載功能的實現思路

日誌下載的前提和核心是將零散的日誌信息合併到文件進行長久存儲。

以前咱們將採集到的數據存放到了kafka，數據源有了，接下來就是把數據拉下來進行合併存儲的問題了。對，期初咱們選擇的存儲介質是HDFS（ES是檢索利器，且存儲成本過高，用作長久存儲顯然是不現實的）。

爲此，咱們寫了一個Spark job的程序，起了一個consumerGroup從kafka消費數據，因爲對實時性要求不高，咱們用Spark Streaming的方式，每隔兩分鐘，進行一次數據拉取，而後進行離線計算。因爲一條消息的元數據中包含採集時間戳和日誌路徑，咱們很容易肯定一條日誌該追加到哪一個HDFS文件中。最終經過httpfs從hdfs下載日誌文件。

用HDFS做爲存儲，隨着日誌量的增長，資源不足的問題便呈現出來了。最終，咱們把存儲目標鎖定到了京東雲的對象存儲OSS。固然了，初期的將數據計算後存儲到HDFS的工做仍是頗有用的，接下來的工做就是把HDFS上的文件下載導入到OSS，而後生成OSS下載連接提供給用戶就行了。這樣HDFS至關於中轉的做用，文件不須要保留過久，只要肯定數據已經轉存到OSS，HDFS上的文件就能夠刪除了，這樣大大緩解了HDFS的存儲壓力。

日誌轉存（HDFS->OSS）遇到的問題及解決辦法

在作日誌轉存至OSS的時候，咱們遇到一個問題，好比用戶的日誌文件比較大，用戶可能在本身的主機上作了日誌切割，可是因爲咱們把數據採集後，變成了kafka中一條條的日誌消息，咱們至關於再把這一條條的日誌消息從新合併到一個HDFS文件中。把一天的日誌合到一個文件進行存儲，有的應用日誌打印比較頻繁的話，最終合成的這個文件就會比較大，有的甚至超過了100G，這樣無論是從HDFS進行下載和仍是壓縮上傳至OSS操做都會比較耗時，並且磁盤空間佔用也比較多。對於用戶來講，下載一個大文件進行處理也會是一件比較頭疼的事情。

爲了解決這個問題，咱們調整了spark job處理邏輯，實現了HDFS文件切割，確保單個HDFS文件大小不超過1G。這樣一個大文件就被拆分紅了多個小文件。對多個小文件進行併發轉存，這樣總體效率就大大提高了。壓縮後的文件，通常不超過300MB，這樣用戶下載也會快不少。

日誌下載功能示例圖

OSS作持久化存儲後，有一個缺點，就是因爲須要轉存，沒法實時下載當天的日誌，不過這並非一個特別急迫的問題，由於當天的日誌徹底能夠經過前面介紹的現場日誌查詢或歷史日誌查詢功能來進行檢索查看。

---

場景四：特定存儲需求 - 用戶說，個人日誌數據不想交給你作集中存儲，我想本身保存，而後用來作分析，你幫我收集到指定地方就行了。

這確實是比較典型的用戶需求，爲了知足用戶的這個需求，咱們開發了自定義日誌目的地的功能。

自定義日誌目的地，顧名思義，就是讓用戶本身來指定將日誌存放到哪裏，而後用戶在作訂閱操做的時候，指定這個目的地名稱便可。

目前支持的日誌目的地有兩種類型：fwd和kafka。

• fwd類型，要求提供目的地服務的域名和端口號，且目的地服務支持RELP協議，RELP是一種比TCP更可靠的傳輸協議。
• kafka類型，須要指定kafka的broker和topic。

從使用狀況來看，目前kafka類型的日誌目的地佔絕大多數。

---

至此，雲翼日誌服務的幾個主要功能就介紹完了。從整個過程看，日誌服務是鏈接運維和開發之間很好的橋樑，日誌中幾乎包含了運維和開發所關心的一切，也完整呈現出了應用程序在線上真實的運行狀況。雲翼的現場日誌查詢、歷史日誌查詢、日誌下載、自定義日誌目的地這四個功能互相補充，能夠知足用戶在不一樣場景下的使用訴求。

目前京東雲監控提供免費服務，點擊【閱讀】，瞭解更多關於京東雲監控的內容。

歡迎點擊「京東雲」瞭解更多精彩內容