（上）挖掘傳統行業日誌大資料的無限價值

8 月 27 日晚上八點，七牛雲高階解決方案架構師程雪松在 IT 大咖說進行了題為《挖掘傳統行業日誌大資料的無限價值》的直播，對傳統行業運維常見困境和統一日誌管理的必要性進行了深入解析，並通過 Pandora 的一些真實使用者案例和大家詳細闡述瞭如何挖掘傳統行業日誌大資料的無限價值。
本文是對直播內容的整理，共分為上下兩篇，上篇主要介紹傳統行業運維常見困境和統一日誌管理的必要性，以及日誌分析幾個典型場景。
什麼是運維
首先我們談一談什麼是運維。

很多人對運維有自己的理解，他們認為運維是一件特別簡單的事情。當我們企業購買了一些資訊化的產品，硬體、軟體等，我們需要有一個團隊讓它正常的運轉。但是在運轉的過程當中，不可避免的會出現各種問題，這就需要有一個專門的團隊來做保障。如果你只是把運維簡單的理解為一個平臺，我覺得這種認識可能比較膚淺。到底什麼是運維呢？網上有很多理解 ，關於運維工作的劃分，包括網站的運維、系統的運維、網路的運維、資料庫的運維、IT 的運維，運維開發、運維安全。從這些分工來看，運維其實是一個複雜、系統的一個工程。
運維的價值
· 運維要知道準確的系統瓶頸點，進而知道系統準確的容量；在系統出現瓶頸前，知道如何快速提供容量。
· 知道系統的風險點，可以協調風險點上下相關關聯模組，做出冗餘策略；相比集中解決單點模組穩定性，更合理。
· 長期從事相關工作，積累較多的架構設計經驗，可以指導新架構設計和稽核。
· 從公司不同業務角度看，運維可以從中抽象相同的模組，進行統一管理，去形成企業內部的能力平臺、基礎設施平臺，包括我們可以共用的一些微服務，那麼形成這樣有效的平臺和自動化的管理方法。
現有運維的普遍現狀以及運維人員的挑戰
從運維的價值來看，我們瞭解到運維是一個複雜、系統的工程。對運維工程師來說，日常需要處理非常多的工作，如何幫助運維工程師做好日常的運維工作，至關重要。但是現在運維工程師在日常運維裡遇到很多問題，最主要的原因是現在的 IT 環境越來越複雜。因為資訊化建設不是一蹴而就的，公司會在不同的階段建設不同的業務系統、不同的應用支撐、採購不同的硬體裝置。但是由於採購週期的互相遞進、堆疊，其實會造成內部有眾多不同型號的網路裝置、海量不同型號的伺服器、各種各樣的虛擬化方案、不同的作業系統、多樣化的應用軟體和資料庫。
其實現在很多資料庫是由應用軟體的開發商來決定的，有些開發商更熟悉 SQL/">MySQL，他可能用 MySQL 作為應用支撐的資料庫，有一些開發商原來一直都在用 Oracle，他可能就會用 Oracle 來做應用支撐。各種不同的業務軟體、不同的業務系統都會有不同的業務架構和底層的不同平臺，每個平臺又會帶來不同的監控系統、自己內部相關的一些工具，這會導致一個企業整體的 IT 部門環境變得很複雜，從而帶來很多問題：
· 監控軟體紛繁複雜眾多監控軟體，無法統一管理；
· 監控告警雜亂無章監控方式存在各種不足，在問題發生時無法及時感知；
· 排錯時間長系統複雜，排查問題流程漫長，在發生問題後無法快速準確的定位問題原因；
· 全域性性弱無法對全域性情況有一個全面的掌控，從而無法有效預測問題的發生；
· 安全挑戰大無法高效發現安全性問題，比如黑客侵入和違規操作；
· 管理員管理難度大面對眾多異構的監控軟體，管理員需要承擔極大的心智負擔；
通過日誌進行運維管理
現在大量的運維團隊都是通過日誌來進行運維管理。原因是什麼呢？
日誌系統將我們系統執行的每一個狀況資訊都使用文字或者日誌的方式記錄下來。這些資訊我們可以理解為裝置或是普通人在虛擬世界的行為的記錄和投影。這些資訊有助我們觀察系統執行過程中的正常狀態和系統執行錯誤時快速定位錯誤位置的途徑等。
日誌的型別很多，主要包括系統日誌、應用程式日誌和安全日誌還包括很多資料庫的日誌，等等。每條日誌都記載著時間戳、相關裝置名稱、使用者及操作行為等相關的描述，系統運維和開發人員可以通過日誌瞭解伺服器軟硬體資訊、檢查配置過程中的錯誤及錯誤發生的原因。經常分析日誌可以瞭解伺服器的負荷，效能安全性，及時分析相關問題、追查錯誤根源糾正錯誤。
下面我們舉了幾個相關的例子，大家在日常工作中也會遇到一些這樣的監控或是安全的日誌。

日常對日誌的分析主要是應對以下幾個場景：
機房集中化監控
第一個是機房集中化監控，特別是現在很多機房的建設都會存在大量的不同品牌的伺服器、網路裝置，特別是大型的企業，他們往往不願採購單一品牌的伺服器，為了避免出現一些廠商依賴的風險，所以會出現機房裡存在不同品牌甚至異構的一些裝置，運維人員需要對機房有一個管控平臺。將交換機、伺服器等相關的一些硬體裝置，包括你可能涉及到的一些軟體上的日誌，以及保安系統的日誌、業務的日誌、使用者訪問行為的日誌等等。將這些日誌統一的收集整理起來，形成一個機房的日常的執行狀態的一個監控。
上圖的示例圖是我們在一個案例裡面給客戶做的展示大屏，他可以反映整個機房的執行狀況，運維人員能夠很直觀的通過大屏知道機房整體的日常執行狀態。下面是我們設計的架構圖，我們通過交換機、伺服器上採集到相關的硬體、軟體的一些監控指標，然後讀取到我們的日誌管理系統裡，對日誌進行統一的儲存、分析、監控、告警，最終形成這樣一個大屏的展示。這個是現在很多運維同學在日誌使用中最經典的場景。
應用質量管理
 第二個是應用質量管理，也就是 APM。因為所有的業務系統在執行過程當中也會產生一些業務系統的日誌，我們通過採集業務系統日誌，能夠快速的去分析整個應用針對終端使用者的服務質量是怎麼樣的。
比如說企業有一個 OA 系統，大家平時去 OA 系統查詢企業的組織架構人員、日常的一些電子流的流轉，包括一些業務申請審批，都會產生大量的日誌。我們去分析這些日誌可以看到服務平均的響應時長是多少，或者大家平均多久會去使用這個平臺一次，我們就能夠全面的對這個應用質量進行管理和追蹤。一旦我們發現大家都在吐槽我的 OA 開啟的很慢，我的整個資料查詢反饋結果很慢。到底問題是什麼？我們通過應用質量管理的模組去查詢到對應的故障點然後對這個應用質量進行優化，為最終的使用者去提供更優質的體驗。不僅在網際網路企業會用到應用質量管理，我們在日常的很多傳統企業也會有這樣一個需求。
統一日誌管理平臺

第三個叫做統一日誌管理平臺，這個其實是把場景 1 和場景 2 做了一個更深層次的延伸。大家最開始可能只是針對機房裝置做一個監控，後來希望能夠針對更上層的業務系統、應用系統進行監控。那現在我們希望能夠把企業裡面只要能產生日誌地方的日誌都收集起來。包括開發團隊在開發過程中產生的日誌，包括業務執行過程中產生的日誌，包括機房運維的日誌，等等。把這些日誌統一的收集在一起，形成統一的日誌倉庫，這跟我們傳統理解的資料倉庫類似。
資料倉庫是把所有的業務資料、結構化的資料存在一起，來做後續的資料分析。統一的日誌管理平臺是把所有企業產生的日誌收集在一起，然後你來做實時或離線的資料分析，然後把分析出來的結果通過介面輸出的方式或是通過訊息佇列的方式去支撐具體的業務應用。相關人員可以對這些日誌進行檢索與分析，從而更快的定位問題，並且持續挖掘資料價值。現在很多企業在逐步發展，不僅建設企業內部統一的資料管理平臺，也在建設內部統一的日誌管理平臺。
物聯網資料分析和監控

第四個結合了現在國家在大力推動的工業 4.0 或是中國製造 2025，其實是希望能夠以物聯網的手段更好的支撐製造業的發展。現在很多製造業企業會在自己的生產線上去增設很多物聯網的探頭或是感測器，收集整個生產線在運轉過程中產生的各種收據。比如說車間的溫度、溼度，包括機器的轉速、壓力、流量等等。然後把這些資料以資料流的方式採集回我的資料平臺，實時的對資料進行匯聚和分析，例如進行資料的上卷統計或者實時資料的監控，一旦出現溫溼度的異常，轉速的異常，壓力的異常，流量的異常，系統需要及時報警，車間管理人員能夠及時解決出現的問題。
除此之外，也需要及時的監控一段時間內我的整個生產線上生產的執行情況，甚至和我的品控、質量管理等等結合在一起，能夠去找出生產線上的溫溼度指標和實際的生產質量之間的一些因果關係。這是很多企業現在在做的物聯網方面的一些嘗試。這四個我認為是現在傳統行業、新興行業遇到的一些日誌運維方面的場景和問題。
統一日誌管理的必要性
所以我們很明顯感覺到統一日誌管理對於傳統行業來講是一個非常重要的事情，不僅能夠解決傳統行業運維上面的問題，甚至能夠去提升一些企業業務層面的能力，包括能夠支撐未來很多業務方面的決策和發展。過去，日誌被分散的儲存在各臺伺服器上，沒有集中管理，難以做關聯分析，甚至被刪除。
舉個簡單的例子，傳統的防火牆 IPS 等等很多安全資料都存在各自的日誌系統裡，現在去做安全日誌關聯分析的企業還很少，像這樣的資料很多時候是被大大的浪費掉了。如果你管理數十上百臺伺服器，你還在使用依次登入每臺機器的傳統方法查閱日誌。這樣感覺很繁瑣和效率低下。當務之急我們需要使用集中化的日誌管理，將所有伺服器上的日誌收集彙總。在大資料時代，日誌數量巨大，種類多樣化，企業資料就如同一座亟待開發的金礦，但是隨著日誌的統一集中，日誌的統計和檢索的難度也會加大，傳統上一般我們使用 grep、awk 和wc 等 Linux 命令來實現日誌的檢索和統計，但是對於要求更高的查詢、排序和統計等要求和龐大的機器數量依然使用這樣的方法難免有點力不從心。
日誌管理的技術選擇
針對日誌管理，現在有非常多的技術選擇，最傳統簡單的就是使用 grep/sed/awk 等指令碼工具，無需額外工具支援，而且很多運維工程師都有獨立寫指令碼的能力，但效率低下，容易出錯。後來也可以把資料採集到 MySQL 裡，進行統一資料匯聚和一些簡單的計算，雖然使用方便，但是由於 MySQL 本身效能問題，對於資料量的支撐不會很大，所以能力有限。有些企業會採用 NoSQL 資料庫來支援大資料量的儲存，但它不支援交叉查詢與全文檢索，去查具體的某一條日誌資訊的時候，使用負擔就會變得很大。
後來出現了很多大資料方面的技術，比如說 Hadoop/Spark/Storm，他們都能很方便的以離線的方式、實時的方式、或者資料流的方式把資料採集進來，但是使用比較繁雜，對於我們的運維團隊、IT 部門來說要求會比較高，而且不支援全文檢索。所以現在使用 Hadoop/Spark 來做日誌管理的公司也不多。現在絕大多數做日誌管理的都會使用 ELK，你可以很方便的在網上下載安裝來使用，但是 ELK 產品化及體驗層面優化做得遠遠不足，在一些小批量的資料想試用功能的時候，是沒有問題的。但如果想把整個機房或是整個企業所有的日誌採用 ELK 來做一個統一日誌倉庫或者企業日誌中心的話，他的穩定性和易用性都會受到很大挑戰。特別是如果你的資料量達到百TB 級資料的時候，使用 ELK 就會遇到很多的問題。
日誌管理系統建設關注要點
那麼我們到底如何去選擇日誌管理系統來支撐我們內部的運維或者支撐我們日誌分析呢？我認為可能需要通過八個角度去思考日誌管理平臺建設的要點，也就是說資料的採集、清洗、儲存、搜尋、監控告警、分析、報表、開放這八個環節。 
資料採集
資料採集看起來是一個很簡單的概念。但是細分下來，還可以再分為四個功能點：資料的收集、解析、轉換、傳送。

資料採集需要日誌管理平臺支援各種各樣的資料來源，這是作為一個優秀的資料採集平臺必須具備的功能。包括關係型資料庫比如說 MySQL、Oracle，甚至可能像 SQL server 等。以及非關係型資料庫、訊息佇列、 ES 這樣的搜尋平臺，還包括 Hadoop 的服務，將這些資料來源的資料準確無誤的採集進來是一個數據管理平臺在資料採集這塊必須支援的功能。另外最好還有針對硬體指標的採集，比如說伺服器的 CPU, 伺服器的記憶體使用率，儲存的使用率，還包括網路裝置的網路流量。這些指標可能不會以日誌的形式呈現出來，但是你需要有一個相關的採集工具，能夠部署在伺服器上，或是部署在網路裝置上去採集這些底層硬體的監控指標。這也是資料採集平臺在採集這塊功能需要去體現的一些能力。
很多的日誌其實都是以文字的形式來做資料記錄的，如果想做深層次的日誌分析、統計、計算的時候，就需要對日誌的內容進行提取和切片。例如說安全裝置的一條日誌需要拆分成具體的時間、日誌來源裝置、安全事件名，具體描述等若干個欄位。日誌管理平臺需要考慮的第一個功能就是支援非常豐富的預定義的解析規則，不管以什麼日誌格式進來，都可以很方便的把這些資料解析成相關的欄位。
第二個針對個性化的日誌格式，能夠支援自定義日誌解析規則，原因是日誌一定是每一個應用開發商在做系統開發的過程當中自己定義的，包含日誌相關的格式、內容、規則。所以這個就會造成百花齊放，各個公司日誌都不一樣的情況發生。那麼不同系統的不同日誌我們都只用同一套的解析規則去解析的話，一定會出現水土不服的情況。所以如果使用者能夠非常方便的自定義的對這些日誌的解析規則，比如說關於一條樣本的日誌，能夠以劃詞的方式把切分成若干個欄位，系統自動生成相關的解析的規則，這樣的話對運維日常的使用來說，就會非常方便易用。
收集、解析之後還有資料轉換，為什麼還會有轉換的工作呢？是因為針對日誌中的某些欄位，我們希望它的可讀性更好一些。比如內網的某個使用者訪問了某一個業務系統，日誌系統一定會記錄訪問的源 IP 地址，但是當我後續想要對這條日誌進行分析的時候，我其實並不關心這個 IP 地址是多少，我關心的其實是這個 IP 地址對應的賬號或者是具體的哪個人，所以我們這個時候就需要一個轉換的過程，把 IP 地址轉換為對應的實體。而通過這樣一些轉換規則運維人員可以對於後續資料的分析和對資料的統計做到更精準，而且使用過程更易用。
所以說收集、解析、轉化都是一個非常重要的工作，這些環節缺一不可。最後處理完的資料，我們需要傳送到一個儲存裡面去進行持久化的儲存或者進行後續的分析。那麼收集、解析、轉化、傳送就是資料採集這個功能點裡面細分的四個小的需要思考的方面。
資料處理

資料採集完成之後，可能還需要對資料進行一些深層次加工處理。對於一些簡單的資料可以不處理直接拿來做分析或是搜尋。那針對一些複雜的業務場景，例如有大量的資料採集進來後，需要每五分鐘或是每十分鐘去對資料進行一個簡單的計算統計，或者針對一些實時性要求比較高的業務應用，需要資料實時的採集進來之後，跟已有的業務模型或安全模型進行匹配，去實現業務服務或者安全態勢監控，在這些場景下，單純通過資料採集平臺是無法滿足需求的。這時候需要的是一個強大的資料處理的平臺，最好可能是類似於 Hadoop、Spark 這樣的大資料計算引擎，能夠針對不同種類的資料來源進行實時的或者離線的計算，並且支援任務的定時執行、迴圈執行等週期性排程，最終能夠把計算分析的結果，匯出到物件儲存、日誌分析，或者匯出到業務資料庫去直接支撐後續的實際生產業務。
資料分析
資料採集處理過後就可以進入資料分析的階段，在這個環節裡面，我們需要對收集到的日誌進行全方位的快速分析並對結果進行展示，那麼首先需要對日誌進行統一儲存，這個儲存至少需要支援 TB 級，甚至 PB 級的資料量，並且能夠支援對這些資料進行快速搜尋，形成相關的圖表以及支撐相關的監控、告警或者分析預測，日誌管理平臺同時也需要提供相關的 API 介面，能夠去對接第三方的監控平臺、監控工具或者直接去支撐類似精準營銷，使用者畫像這樣的業務系統，以上都是資料分析在這個過程中需要支撐的功能。我日常跟很多使用者在溝通的過程當中，我也會發現他們或多或少都會遇到一些日誌分析業務的痛點，我總結了四點如下：

自動欄位分析在日誌採集階段已經完成了日誌解析，把一條標準的文字型日誌解析成了若干個欄位，那麼能不能對這些欄位做一些自動的統計和分析，運維人員不需要自己再去通過寫指令碼的方式，編輯任務的方式去做資料的計算。比如說系統能夠自動的告訴你網路中平均流量是多少，你的流量的峰值和最低值是多少，如果有一些錯誤的日誌，我們統計出來，你的 TOP10 的錯誤是哪些錯誤，他來自於哪一個使用者或是哪一臺裝置，針對這樣的一些欄位分析能大大的降低使用者在使用這個平臺過程當中去做的一些計算或是任務配置方面的一些工作或難度。
聯合搜尋顧名思義就是通過一個條件去同時搜尋多個日誌倉庫，這個場景就比如說防火牆、IPS、防毒軟體、訪問日誌可能是存在不同地方，統一採集到日誌管理平臺上以後一般也是放在不同的日誌倉庫中，當有一個安全事件發生的時候，安全事件會包含來自哪個 IP 地址的攻擊，或是來自哪個使用者名稱的攻擊，那我需要通過這個 IP 地址或是使用者名稱能夠檢索到所有安全裝置的日誌，然後把相關內容統一的展現出來，那麼這個時候就有一個聯合搜尋的場景。這個時候需要有這樣一個功能，能夠搜尋所有能看到的在這個日誌倉庫裡的內容。
劃詞分析大家在日常使用日誌分析功能的時候，並不是所有任務都是固化的，有時候需要根據業務要求靈活變動。比如今天我需要分析一個裝置或是某一個使用者的日常訪問行為，那我會搜尋這個使用者的使用者名稱，日誌管理平臺會把符合條件對應的所有內容列出來。但當你仔細去看時，搜尋出來的內容會非常多，可能是成百甚至上千條相關的日誌，若是感測器類的日誌可能會更多。僅僅通過一個搜尋條件，往往無法滿足你對於日誌分析的需求的。這個時候，你可以選擇在搜尋框裡增加一個 and 搜尋條件去對日誌進行更深層次的結果的篩選。
但能不能有一種更簡單的方式？例如既然已經找出了跟這個使用者名稱相關的所有日誌，那麼是不是能夠搜尋結果中的某條日誌裡再劃一段詞出來，自動的填充到我的搜尋框裡面，去對資料的搜尋結果進行二次過濾，或者我可以在搜尋結果裡面排除掉劃出來的這些詞所對應的日誌內容，如果這個功能可以實現的話是可以大大提高平臺的易用性，去解決日常很多令人崩潰的事情。這是劃詞分析的一個痛點。
實時搜尋系統中產生的所有日誌都會以資料流的方式不停的採集到日誌平臺上，對日誌進行搜尋的時候希望新進來的日誌也能實時的展現出來。這樣當我去對一個業務進行變更，或對故障進行恢復的時候，我能看到最新進來的日誌情況，可以很方便地看到業務是否恢復正常。這有點像我們日常使用的 tail -f 資料實時滾動的場景。這也是很多使用者在對資料分析的過程當中會遇到的一個痛點。如果有一個產品能夠去解決使用者的這些痛點，降低平臺的使用負擔，這能夠大大降低大家日常運維的壓力，提升整個工作效率。
 牛人說
「牛人說」專欄致力於技術人思想的發現，其中包括技術實踐、技術乾貨、技術見解、成長心得，還有一切值得被發現的內容。我們希望集合最優秀的技術人，挖掘獨到、犀利、具有時代感的聲音。
 點選「閱讀原文」 瞭解更多七牛雲智慧日誌管理平臺