?

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 數據實時滾動的場景。這也是很多用戶在對數據分析的過程當中會遇到的一個痛點。如果有一個產品能夠去解決用戶的這些痛點，降低平臺的使用負擔，這能夠大大降低大家日常運維的壓力，提升整個工作效率。
?

牛人說
?
「牛人說」專欄致力于技術人思想的發現，其中包括技術實踐、技術干貨、技術見解、成長心得，還有一切值得被發現的內容。我們希望集合最優秀的技術人，挖掘獨到、犀利、具有時代感的聲音。
?

轉載于:https://blog.51cto.com/7741292/2166407

總結

以上是生活随笔為你收集整理的（上）挖掘传统行业日志大数据的无限价值的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。