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





8 月 27 日晚上八點，七牛雲高級解決方案架構師程雪松在 IT 大咖說進行了題爲《挖掘傳統行業日誌大數據的無限價值》的直播，對傳統行業運維常見困境和統一日誌管理的必要性進行了深刻解析，並經過 Pandora 的一些真實用戶案例和你們詳細闡述瞭如何挖掘傳統行業日誌大數據的無限價值。



本文是對直播內容的整理，共分爲上下兩篇，上篇主要介紹傳統行業運維常見困境和統一日誌管理的必要性，以及日誌分析幾個典型場景。




什麼是運維




首先咱們談一談什麼是運維。





不少人對運維有本身的理解，他們認爲運維是一件特別簡單的事情。當咱們企業購買了一些信息化的產品，硬件、軟件等，咱們須要有一個團隊讓它正常的運轉。可是在運轉的過程中，不可避免的會出現各類問題，這就須要有一個專門的團隊來作保障。若是你只是把運維簡單的理解爲一個平臺，我以爲這種認識可能比較膚淺。到底什麼是運維呢？網上有不少理解 ，關於運維工做的劃分，包括網站的運維、系統的運維、網絡的運維、數據庫的運維、IT 的運維，運維開發、運維安全。從這些分工來看，運維實際上是一個複雜、系統的一個工程。


 

運維的價值



 
· 運維要知道準確的系統瓶頸點，進而知道系統準確的容量；在系統出現瓶頸前，知道如何快速提供容量。


· 知道系統的風險點，能夠協調風險點上下相關關聯模塊，作出冗餘策略；相比集中解決單點模塊穩定性，更合理。


· 長期從事相關工做，積累較多的架構設計經驗，能夠指導新架構設計和審覈。


· 從公司不一樣業務角度看，運維能夠從中抽象相同的模塊，進行統一管理，去造成企業內部的能力平臺、基礎設施平臺，包括咱們能夠共用的一些微服務，那麼造成這樣有效的平臺和自動化的管理方法。



現有運維的廣泛現狀以及運維人員的挑戰



從運維的價值來看，咱們瞭解到運維是一個複雜、系統的工程。對運維工程師來講，平常須要處理很是多的工做，如何幫助運維工程師作好平常的運維工做，相當重要。可是如今運維工程師在平常運維裏遇到不少問題，最主要的緣由是如今的 IT 環境愈來愈複雜。由於信息化建設不是一蹴而就的，公司會在不一樣的階段建設不一樣的業務系統、不一樣的應用支撐、採購不一樣的硬件設備。可是因爲採購週期的互相遞進、堆疊，其實會形成內部有衆多不一樣型號的網絡設備、海量不一樣型號的服務器、各類各樣的虛擬化方案、不一樣的操做系統、多樣化的應用軟件和數據庫。


其實如今不少數據庫是由應用軟件的開發商來決定的，有些開發商更熟悉 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 數據實時滾動的場景。這也是不少用戶在對數據分析的過程中會遇到的一個痛點。若是有一個產品可以去解決用戶的這些痛點，下降平臺的使用負擔，這可以大大下降你們平常運維的壓力，提高整個工做效率。



牛人說
「牛人說」專欄致力於技術人思想的發現，其中包括技術實踐、技術乾貨、技術看法、成長心得，還有一切值得被發現的內容。咱們但願集合最優秀的技術人，挖掘獨到、犀利、具備時代感的聲音。