（上）挖掘傳統(tǒng)行業(yè)日志大數(shù)據(jù)的無限價值

?
?

8 月 27 日晚上八點，七牛云高級解決方案架構(gòu)師程雪松在 IT 大咖說進行了題為《挖掘傳統(tǒng)行業(yè)日志大數(shù)據(jù)的無限價值》的直播，對傳統(tǒng)行業(yè)運維常見困境和統(tǒng)一日志管理的必要性進行了深入解析，并通過 Pandora 的一些真實用戶案例和大家詳細闡述了如何挖掘傳統(tǒng)行業(yè)日志大數(shù)據(jù)的無限價值。
?

本文是對直播內(nèi)容的整理，共分為上下兩篇，上篇主要介紹傳統(tǒng)行業(yè)運維常見困境和統(tǒng)一日志管理的必要性，以及日志分析幾個典型場景。

?

什么是運維

?

首先我們談一談什么是運維。??
?
?
?
很多人對運維有自己的理解，他們認為運維是一件特別簡單的事情。當我們企業(yè)購買了一些信息化的產(chǎn)品，硬件、軟件等，我們需要有一個團隊讓它正常的運轉(zhuǎn)。但是在運轉(zhuǎn)的過程當中，不可避免的會出現(xiàn)各種問題，這就需要有一個專門的團隊來做保障。如果你只是把運維簡單的理解為一個平臺，我覺得這種認識可能比較膚淺。到底什么是運維呢？網(wǎng)上有很多理解 ，關(guān)于運維工作的劃分，包括網(wǎng)站的運維、系統(tǒng)的運維、網(wǎng)絡(luò)的運維、數(shù)據(jù)庫的運維、IT 的運維，運維開發(fā)、運維安全。從這些分工來看，運維其實是一個復(fù)雜、系統(tǒng)的一個工程。
?
?

運維的價值

?
?
·?運維要知道準確的系統(tǒng)瓶頸點，進而知道系統(tǒng)準確的容量；在系統(tǒng)出現(xiàn)瓶頸前，知道如何快速提供容量。
?
·?知道系統(tǒng)的風(fēng)險點，可以協(xié)調(diào)風(fēng)險點上下相關(guān)關(guān)聯(lián)模塊，做出冗余策略；相比集中解決單點模塊穩(wěn)定性，更合理。
?
·?長期從事相關(guān)工作，積累較多的架構(gòu)設(shè)計經(jīng)驗，可以指導(dǎo)新架構(gòu)設(shè)計和審核。
?
·?從公司不同業(yè)務(wù)角度看，運維可以從中抽象相同的模塊，進行統(tǒng)一管理，去形成企業(yè)內(nèi)部的能力平臺、基礎(chǔ)設(shè)施平臺，包括我們可以共用的一些微服務(wù)，那么形成這樣有效的平臺和自動化的管理方法。
?

現(xiàn)有運維的普遍現(xiàn)狀以及運維人員的挑戰(zhàn)

?
從運維的價值來看，我們了解到運維是一個復(fù)雜、系統(tǒng)的工程。對運維工程師來說，日常需要處理非常多的工作，如何幫助運維工程師做好日常的運維工作，至關(guān)重要。但是現(xiàn)在運維工程師在日常運維里遇到很多問題，最主要的原因是現(xiàn)在的 IT 環(huán)境越來越復(fù)雜。因為信息化建設(shè)不是一蹴而就的，公司會在不同的階段建設(shè)不同的業(yè)務(wù)系統(tǒng)、不同的應(yīng)用支撐、采購不同的硬件設(shè)備。但是由于采購周期的互相遞進、堆疊，其實會造成內(nèi)部有眾多不同型號的網(wǎng)絡(luò)設(shè)備、海量不同型號的服務(wù)器、各種各樣的虛擬化方案、不同的操作系統(tǒng)、多樣化的應(yīng)用軟件和數(shù)據(jù)庫。
?
其實現(xiàn)在很多數(shù)據(jù)庫是由應(yīng)用軟件的開發(fā)商來決定的，有些開發(fā)商更熟悉 MySQL，他可能用 MySQL 作為應(yīng)用支撐的數(shù)據(jù)庫，有一些開發(fā)商原來一直都在用 Oracle，他可能就會用 Oracle 來做應(yīng)用支撐。各種不同的業(yè)務(wù)軟件、不同的業(yè)務(wù)系統(tǒng)都會有不同的業(yè)務(wù)架構(gòu)和底層的不同平臺，每個平臺又會帶來不同的監(jiān)控系統(tǒng)、自己內(nèi)部相關(guān)的一些工具，這會導(dǎo)致一個企業(yè)整體的 IT 部門環(huán)境變得很復(fù)雜，從而帶來很多問題： ?
?
·?監(jiān)控軟件紛繁復(fù)雜眾多監(jiān)控軟件，無法統(tǒng)一管理；??
?
·?監(jiān)控告警雜亂無章監(jiān)控方式存在各種不足，在問題發(fā)生時無法及時感知；
?
·?排錯時間長系統(tǒng)復(fù)雜，排查問題流程漫長，在發(fā)生問題后無法快速準確的定位問題原因；
?
·?全局性弱無法對全局情況有一個全面的掌控，從而無法有效預(yù)測問題的發(fā)生；
?
·?安全挑戰(zhàn)大無法高效發(fā)現(xiàn)安全性問題，比如×××侵入和違規(guī)操作；
?
·?管理員管理難度大面對眾多異構(gòu)的監(jiān)控軟件，管理員需要承擔(dān)極大的心智負擔(dān)；
?

通過日志進行運維管理

?
現(xiàn)在大量的運維團隊都是通過日志來進行運維管理。原因是什么呢？
?
日志系統(tǒng)將我們系統(tǒng)運行的每一個狀況信息都使用文字或者日志的方式記錄下來。這些信息我們可以理解為設(shè)備或是普通人在虛擬世界的行為的記錄和投影。這些信息有助我們觀察系統(tǒng)運行過程中的正常狀態(tài)和系統(tǒng)運行錯誤時快速定位錯誤位置的途徑等。
?
日志的類型很多，主要包括系統(tǒng)日志、應(yīng)用程序日志和安全日志還包括很多數(shù)據(jù)庫的日志，等等。每條日志都記載著時間戳、相關(guān)設(shè)備名稱、使用者及操作行為等相關(guān)的描述，系統(tǒng)運維和開發(fā)人員可以通過日志了解服務(wù)器軟硬件信息、檢查配置過程中的錯誤及錯誤發(fā)生的原因。經(jīng)常分析日志可以了解服務(wù)器的負荷，性能安全性，及時分析相關(guān)問題、追查錯誤根源糾正錯誤。
?
下面我們舉了幾個相關(guān)的例子，大家在日常工作中也會遇到一些這樣的監(jiān)控或是安全的日志。
?
?
?
日常對日志的分析主要是應(yīng)對以下幾個場景：
?
?

機房集中化監(jiān)控

?

第一個是機房集中化監(jiān)控，特別是現(xiàn)在很多機房的建設(shè)都會存在大量的不同品牌的服務(wù)器、網(wǎng)絡(luò)設(shè)備，特別是大型的企業(yè)，他們往往不愿采購單一品牌的服務(wù)器，為了避免出現(xiàn)一些廠商依賴的風(fēng)險，所以會出現(xiàn)機房里存在不同品牌甚至異構(gòu)的一些設(shè)備，運維人員需要對機房有一個管控平臺。將交換機、服務(wù)器等相關(guān)的一些硬件設(shè)備，包括你可能涉及到的一些軟件上的日志，以及保安系統(tǒng)的日志、業(yè)務(wù)的日志、用戶訪問行為的日志等等。將這些日志統(tǒng)一的收集整理起來，形成一個機房的日常的運行狀態(tài)的一個監(jiān)控。
?
上圖的示例圖是我們在一個案例里面給客戶做的展示大屏，他可以反映整個機房的運行狀況，運維人員能夠很直觀的通過大屏知道機房整體的日常運行狀態(tài)。下面是我們設(shè)計的架構(gòu)圖，我們通過交換機、服務(wù)器上采集到相關(guān)的硬件、軟件的一些監(jiān)控指標，然后讀取到我們的日志管理系統(tǒng)里，對日志進行統(tǒng)一的存儲、分析、監(jiān)控、告警，最終形成這樣一個大屏的展示。這個是現(xiàn)在很多運維同學(xué)在日志使用中最經(jīng)典的場景。
?
?

應(yīng)用質(zhì)量管理

?
?
?
??
第二個是應(yīng)用質(zhì)量管理，也就是 APM。因為所有的業(yè)務(wù)系統(tǒng)在運行過程當中也會產(chǎn)生一些業(yè)務(wù)系統(tǒng)的日志，我們通過采集業(yè)務(wù)系統(tǒng)日志，能夠快速的去分析整個應(yīng)用針對最終用戶的服務(wù)質(zhì)量是怎么樣的。
?
比如說企業(yè)有一個 OA 系統(tǒng)，大家平時去 OA 系統(tǒng)查詢企業(yè)的組織架構(gòu)人員、日常的一些電子流的流轉(zhuǎn)，包括一些業(yè)務(wù)申請審批，都會產(chǎn)生大量的日志。我們?nèi)シ治鲞@些日志可以看到服務(wù)平均的響應(yīng)時長是多少，或者大家平均多久會去使用這個平臺一次，我們就能夠全面的對這個應(yīng)用質(zhì)量進行管理和追蹤。一旦我們發(fā)現(xiàn)大家都在吐槽我的 OA 打開的很慢，我的整個數(shù)據(jù)查詢反饋結(jié)果很慢。到底問題是什么？我們通過應(yīng)用質(zhì)量管理的模塊去查詢到對應(yīng)的故障點然后對這個應(yīng)用質(zhì)量進行優(yōu)化，為最終的用戶去提供更優(yōu)質(zhì)的體驗。不僅在互聯(lián)網(wǎng)企業(yè)會用到應(yīng)用質(zhì)量管理，我們在日常的很多傳統(tǒng)企業(yè)也會有這樣一個需求。
???
?

統(tǒng)一日志管理平臺

?
?
?
?
第三個叫做統(tǒng)一日志管理平臺，這個其實是把場景 1 和場景 2 做了一個更深層次的延伸。大家最開始可能只是針對機房設(shè)備做一個監(jiān)控，后來希望能夠針對更上層的業(yè)務(wù)系統(tǒng)、應(yīng)用系統(tǒng)進行監(jiān)控。那現(xiàn)在我們希望能夠把企業(yè)里面只要能產(chǎn)生日志地方的日志都收集起來。包括開發(fā)團隊在開發(fā)過程中產(chǎn)生的日志，包括業(yè)務(wù)運行過程中產(chǎn)生的日志，包括機房運維的日志，等等。把這些日志統(tǒng)一的收集在一起，形成統(tǒng)一的日志倉庫，這跟我們傳統(tǒng)理解的數(shù)據(jù)倉庫類似。
?
數(shù)據(jù)倉庫是把所有的業(yè)務(wù)數(shù)據(jù)、結(jié)構(gòu)化的數(shù)據(jù)存在一起，來做后續(xù)的數(shù)據(jù)分析。統(tǒng)一的日志管理平臺是把所有企業(yè)產(chǎn)生的日志收集在一起，然后你來做實時或離線的數(shù)據(jù)分析，然后把分析出來的結(jié)果通過接口輸出的方式或是通過消息隊列的方式去支撐具體的業(yè)務(wù)應(yīng)用。相關(guān)人員可以對這些日志進行檢索與分析，從而更快的定位問題，并且持續(xù)挖掘數(shù)據(jù)價值?，F(xiàn)在很多企業(yè)在逐步發(fā)展，不僅建設(shè)企業(yè)內(nèi)部統(tǒng)一的數(shù)據(jù)管理平臺，也在建設(shè)內(nèi)部統(tǒng)一的日志管理平臺。
?
?

物聯(lián)網(wǎng)數(shù)據(jù)分析和監(jiān)控

?
?
?
?
第四個結(jié)合了現(xiàn)在國家在大力推動的工業(yè) 4.0 或是中國制造 2025，其實是希望能夠以物聯(lián)網(wǎng)的手段更好的支撐制造業(yè)的發(fā)展?，F(xiàn)在很多制造業(yè)企業(yè)會在自己的生產(chǎn)線上去增設(shè)很多物聯(lián)網(wǎng)的探頭或是傳感器，收集整個生產(chǎn)線在運轉(zhuǎn)過程中產(chǎn)生的各種收據(jù)。比如說車間的溫度、濕度，包括機器的轉(zhuǎn)速、壓力、流量等等。然后把這些數(shù)據(jù)以數(shù)據(jù)流的方式采集回我的數(shù)據(jù)平臺，實時的對數(shù)據(jù)進行匯聚和分析，例如進行數(shù)據(jù)的上卷統(tǒng)計或者實時數(shù)據(jù)的監(jiān)控，一旦出現(xiàn)溫濕度的異常，轉(zhuǎn)速的異常，壓力的異常，流量的異常，系統(tǒng)需要及時報警，車間管理人員能夠及時解決出現(xiàn)的問題。
?
除此之外，也需要及時的監(jiān)控一段時間內(nèi)我的整個生產(chǎn)線上生產(chǎn)的運行情況，甚至和我的品控、質(zhì)量管理等等結(jié)合在一起，能夠去找出生產(chǎn)線上的溫濕度指標和實際的生產(chǎn)質(zhì)量之間的一些因果關(guān)系。這是很多企業(yè)現(xiàn)在在做的物聯(lián)網(wǎng)方面的一些嘗試。這四個我認為是現(xiàn)在傳統(tǒng)行業(yè)、新興行業(yè)遇到的一些日志運維方面的場景和問題。
?

統(tǒng)一日志管理的必要性

?
所以我們很明顯感覺到統(tǒng)一日志管理對于傳統(tǒng)行業(yè)來講是一個非常重要的事情，不僅能夠解決傳統(tǒng)行業(yè)運維上面的問題，甚至能夠去提升一些企業(yè)業(yè)務(wù)層面的能力，包括能夠支撐未來很多業(yè)務(wù)方面的決策和發(fā)展。過去，日志被分散的儲存在各臺服務(wù)器上，沒有集中管理，難以做關(guān)聯(lián)分析，甚至被刪除。
?
舉個簡單的例子，傳統(tǒng)的防火墻 IPS 等等很多安全數(shù)據(jù)都存在各自的日志系統(tǒng)里，現(xiàn)在去做安全日志關(guān)聯(lián)分析的企業(yè)還很少，像這樣的數(shù)據(jù)很多時候是被大大的浪費掉了。如果你管理數(shù)十上百臺服務(wù)器，你還在使用依次登錄每臺機器的傳統(tǒng)方法查閱日志。這樣感覺很繁瑣和效率低下。當務(wù)之急我們需要使用集中化的日志管理，將所有服務(wù)器上的日志收集匯總。在大數(shù)據(jù)時代，日志數(shù)量巨大，種類多樣化，企業(yè)數(shù)據(jù)就如同一座亟待開發(fā)的金礦，但是隨著日志的統(tǒng)一集中，日志的統(tǒng)計和檢索的難度也會加大，傳統(tǒng)上一般我們使用 grep、awk 和wc 等 Linux 命令來實現(xiàn)日志的檢索和統(tǒng)計，但是對于要求更高的查詢、排序和統(tǒng)計等要求和龐大的機器數(shù)量依然使用這樣的方法難免有點力不從心。
?

日志管理的技術(shù)選擇

?
針對日志管理，現(xiàn)在有非常多的技術(shù)選擇，最傳統(tǒng)簡單的就是使用 grep/sed/awk 等腳本工具，無需額外工具支持，而且很多運維工程師都有獨立寫腳本的能力，但效率低下，容易出錯。后來也可以把數(shù)據(jù)采集到 MySQL 里，進行統(tǒng)一數(shù)據(jù)匯聚和一些簡單的計算，雖然使用方便，但是由于 MySQL 本身性能問題，對于數(shù)據(jù)量的支撐不會很大，所以能力有限。有些企業(yè)會采用 NoSQL 數(shù)據(jù)庫來支持大數(shù)據(jù)量的存儲，但它不支持交叉查詢與全文檢索，去查具體的某一條日志信息的時候，使用負擔(dān)就會變得很大。
?
后來出現(xiàn)了很多大數(shù)據(jù)方面的技術(shù)，比如說 Hadoop/Spark/Storm，他們都能很方便的以離線的方式、實時的方式、或者數(shù)據(jù)流的方式把數(shù)據(jù)采集進來，但是使用比較繁雜，對于我們的運維團隊、IT 部門來說要求會比較高，而且不支持全文檢索。所以現(xiàn)在使用 Hadoop/Spark 來做日志管理的公司也不多。現(xiàn)在絕大多數(shù)做日志管理的都會使用 ELK，你可以很方便的在網(wǎng)上下載安裝來使用，但是 ELK 產(chǎn)品化及體驗層面優(yōu)化做得遠遠不足，在一些小批量的數(shù)據(jù)想試用功能的時候，是沒有問題的。但如果想把整個機房或是整個企業(yè)所有的日志采用 ELK 來做一個統(tǒng)一日志倉庫或者企業(yè)日志中心的話，他的穩(wěn)定性和易用性都會受到很大挑戰(zhàn)。特別是如果你的數(shù)據(jù)量達到百TB 級數(shù)據(jù)的時候，使用 ELK 就會遇到很多的問題。
?

日志管理系統(tǒng)建設(shè)關(guān)注要點

?
那么我們到底如何去選擇日志管理系統(tǒng)來支撐我們內(nèi)部的運維或者支撐我們?nèi)罩痉治瞿?？我認為可能需要通過八個角度去思考日志管理平臺建設(shè)的要點，也就是說數(shù)據(jù)的采集、清洗、存儲、搜索、監(jiān)控告警、分析、報表、開放這八個環(huán)節(jié)。
??
?
?
?

數(shù)據(jù)采集

?
?
數(shù)據(jù)采集看起來是一個很簡單的概念。但是細分下來，還可以再分為四個功能點：數(shù)據(jù)的收集、解析、轉(zhuǎn)換、發(fā)送。
?
?
?
數(shù)據(jù)采集需要日志管理平臺支持各種各樣的數(shù)據(jù)源，這是作為一個優(yōu)秀的數(shù)據(jù)采集平臺必須具備的功能。包括關(guān)系型數(shù)據(jù)庫比如說 MySQL、Oracle，甚至可能像 SQL server 等。以及非關(guān)系型數(shù)據(jù)庫、消息隊列、 ES 這樣的搜索平臺，還包括 Hadoop 的服務(wù)，將這些數(shù)據(jù)源的數(shù)據(jù)準確無誤的采集進來是一個數(shù)據(jù)管理平臺在數(shù)據(jù)采集這塊必須支持的功能。另外最好還有針對硬件指標的采集，比如說服務(wù)器的 CPU, 服務(wù)器的內(nèi)存使用率，存儲的使用率，還包括網(wǎng)絡(luò)設(shè)備的網(wǎng)絡(luò)流量。這些指標可能不會以日志的形式呈現(xiàn)出來，但是你需要有一個相關(guān)的采集工具，能夠部署在服務(wù)器上，或是部署在網(wǎng)絡(luò)設(shè)備上去采集這些底層硬件的監(jiān)控指標。這也是數(shù)據(jù)采集平臺在采集這塊功能需要去體現(xiàn)的一些能力。
?
很多的日志其實都是以文本的形式來做數(shù)據(jù)記錄的，如果想做深層次的日志分析、統(tǒng)計、計算的時候，就需要對日志的內(nèi)容進行提取和切片。例如說安全設(shè)備的一條日志需要拆分成具體的時間、日志來源設(shè)備、安全事件名，具體描述等若干個字段。日志管理平臺需要考慮的第一個功能就是支持非常豐富的預(yù)定義的解析規(guī)則，不管以什么日志格式進來，都可以很方便的把這些數(shù)據(jù)解析成相關(guān)的字段。
?
第二個針對個性化的日志格式，能夠支持自定義日志解析規(guī)則，原因是日志一定是每一個應(yīng)用開發(fā)商在做系統(tǒng)開發(fā)的過程當中自己定義的，包含日志相關(guān)的格式、內(nèi)容、規(guī)則。所以這個就會造成百花齊放，各個公司日志都不一樣的情況發(fā)生。那么不同系統(tǒng)的不同日志我們都只用同一套的解析規(guī)則去解析的話，一定會出現(xiàn)水土不服的情況。所以如果用戶能夠非常方便的自定義的對這些日志的解析規(guī)則，比如說關(guān)于一條樣本的日志，能夠以劃詞的方式把切分成若干個字段，系統(tǒng)自動生成相關(guān)的解析的規(guī)則，這樣的話對運維日常的使用來說，就會非常方便易用。
?
收集、解析之后還有數(shù)據(jù)轉(zhuǎn)換，為什么還會有轉(zhuǎn)換的工作呢？是因為針對日志中的某些字段，我們希望它的可讀性更好一些。比如內(nèi)網(wǎng)的某個用戶訪問了某一個業(yè)務(wù)系統(tǒng)，日志系統(tǒng)一定會記錄訪問的源 IP 地址，但是當我后續(xù)想要對這條日志進行分析的時候，我其實并不關(guān)心這個 IP 地址是多少，我關(guān)心的其實是這個 IP 地址對應(yīng)的賬號或者是具體的哪個人，所以我們這個時候就需要一個轉(zhuǎn)換的過程，把 IP 地址轉(zhuǎn)換為對應(yīng)的實體。而通過這樣一些轉(zhuǎn)換規(guī)則運維人員可以對于后續(xù)數(shù)據(jù)的分析和對數(shù)據(jù)的統(tǒng)計做到更精準，而且使用過程更易用。
?
所以說收集、解析、轉(zhuǎn)化都是一個非常重要的工作，這些環(huán)節(jié)缺一不可。最后處理完的數(shù)據(jù)，我們需要發(fā)送到一個存儲里面去進行持久化的存儲或者進行后續(xù)的分析。那么收集、解析、轉(zhuǎn)化、發(fā)送就是數(shù)據(jù)采集這個功能點里面細分的四個小的需要思考的方面。
?
?

數(shù)據(jù)處理

?
?
?
?
數(shù)據(jù)采集完成之后，可能還需要對數(shù)據(jù)進行一些深層次加工處理。對于一些簡單的數(shù)據(jù)可以不處理直接拿來做分析或是搜索。那針對一些復(fù)雜的業(yè)務(wù)場景，例如有大量的數(shù)據(jù)采集進來后，需要每五分鐘或是每十分鐘去對數(shù)據(jù)進行一個簡單的計算統(tǒng)計，或者針對一些實時性要求比較高的業(yè)務(wù)應(yīng)用，需要數(shù)據(jù)實時的采集進來之后，跟已有的業(yè)務(wù)模型或安全模型進行匹配，去實現(xiàn)業(yè)務(wù)服務(wù)或者安全態(tài)勢監(jiān)控，在這些場景下，單純通過數(shù)據(jù)采集平臺是無法滿足需求的。這時候需要的是一個強大的數(shù)據(jù)處理的平臺，最好可能是類似于 Hadoop、Spark 這樣的大數(shù)據(jù)計算引擎，能夠針對不同種類的數(shù)據(jù)源進行實時的或者離線的計算，并且支持任務(wù)的定時執(zhí)行、循環(huán)執(zhí)行等周期性調(diào)度，最終能夠把計算分析的結(jié)果，導(dǎo)出到對象存儲、日志分析，或者導(dǎo)出到業(yè)務(wù)數(shù)據(jù)庫去直接支撐后續(xù)的實際生產(chǎn)業(yè)務(wù)。
?
?

數(shù)據(jù)分析

?
?
數(shù)據(jù)采集處理過后就可以進入數(shù)據(jù)分析的階段，在這個環(huán)節(jié)里面，我們需要對收集到的日志進行全方位的快速分析并對結(jié)果進行展示，那么首先需要對日志進行統(tǒng)一存儲，這個存儲至少需要支持 TB 級，甚至 PB 級的數(shù)據(jù)量，并且能夠支持對這些數(shù)據(jù)進行快速搜索，形成相關(guān)的圖表以及支撐相關(guān)的監(jiān)控、告警或者分析預(yù)測，日志管理平臺同時也需要提供相關(guān)的 API 接口，能夠去對接第三方的監(jiān)控平臺、監(jiān)控工具或者直接去支撐類似精準營銷，用戶畫像這樣的業(yè)務(wù)系統(tǒng)，以上都是數(shù)據(jù)分析在這個過程中需要支撐的功能。我日常跟很多用戶在溝通的過程當中，我也會發(fā)現(xiàn)他們或多或少都會遇到一些日志分析業(yè)務(wù)的痛點，我總結(jié)了四點如下：?
?
?
?
?
自動字段分析
在日志采集階段已經(jīng)完成了日志解析，把一條標準的文本型日志解析成了若干個字段，那么能不能對這些字段做一些自動的統(tǒng)計和分析，運維人員不需要自己再去通過寫腳本的方式，編輯任務(wù)的方式去做數(shù)據(jù)的計算。比如說系統(tǒng)能夠自動的告訴你網(wǎng)絡(luò)中平均流量是多少，你的流量的峰值和最低值是多少，如果有一些錯誤的日志，我們統(tǒng)計出來，你的 TOP10 的錯誤是哪些錯誤，他來自于哪一個用戶或是哪一臺設(shè)備，針對這樣的一些字段分析能大大的降低用戶在使用這個平臺過程當中去做的一些計算或是任務(wù)配置方面的一些工作或難度。
?
?
聯(lián)合搜索
顧名思義就是通過一個條件去同時搜索多個日志倉庫，這個場景就比如說防火墻、IPS、殺毒軟件、訪問日志可能是存在不同地方，統(tǒng)一采集到日志管理平臺上以后一般也是放在不同的日志倉庫中，當有一個安全事件發(fā)生的時候，安全事件會包含來自哪個 IP 地址的×××，或是來自哪個用戶名的×××，那我需要通過這個 IP 地址或是用戶名能夠檢索到所有安全設(shè)備的日志，然后把相關(guān)內(nèi)容統(tǒng)一的展現(xiàn)出來，那么這個時候就有一個聯(lián)合搜索的場景。這個時候需要有這樣一個功能，能夠搜索所有能看到的在這個日志倉庫里的內(nèi)容。
?
?
劃詞分析
大家在日常使用日志分析功能的時候，并不是所有任務(wù)都是固化的，有時候需要根據(jù)業(yè)務(wù)要求靈活變動。比如今天我需要分析一個設(shè)備或是某一個用戶的日常訪問行為，那我會搜索這個用戶的用戶名，日志管理平臺會把符合條件對應(yīng)的所有內(nèi)容列出來。但當你仔細去看時，搜索出來的內(nèi)容會非常多，可能是成百甚至上千條相關(guān)的日志，若是傳感器類的日志可能會更多。僅僅通過一個搜索條件，往往無法滿足你對于日志分析的需求的。這個時候，你可以選擇在搜索框里增加一個 and 搜索條件去對日志進行更深層次的結(jié)果的篩選。
?
但能不能有一種更簡單的方式？例如既然已經(jīng)找出了跟這個用戶名相關(guān)的所有日志，那么是不是能夠搜索結(jié)果中的某條日志里再劃一段詞出來，自動的填充到我的搜索框里面，去對數(shù)據(jù)的搜索結(jié)果進行二次過濾，或者我可以在搜索結(jié)果里面排除掉劃出來的這些詞所對應(yīng)的日志內(nèi)容，如果這個功能可以實現(xiàn)的話是可以大大提高平臺的易用性，去解決日常很多令人崩潰的事情。這是劃詞分析的一個痛點。
?
?
實時搜索
系統(tǒng)中產(chǎn)生的所有日志都會以數(shù)據(jù)流的方式不停的采集到日志平臺上，對日志進行搜索的時候希望新進來的日志也能實時的展現(xiàn)出來。這樣當我去對一個業(yè)務(wù)進行變更，或?qū)收线M行恢復(fù)的時候，我能看到最新進來的日志情況，可以很方便地看到業(yè)務(wù)是否恢復(fù)正常。這有點像我們?nèi)粘Ｊ褂玫?tail -f 數(shù)據(jù)實時滾動的場景。這也是很多用戶在對數(shù)據(jù)分析的過程當中會遇到的一個痛點。如果有一個產(chǎn)品能夠去解決用戶的這些痛點，降低平臺的使用負擔(dān)，這能夠大大降低大家日常運維的壓力，提升整個工作效率。
?
?
牛人說
?
「牛人說」專欄致力于技術(shù)人思想的發(fā)現(xiàn)，其中包括技術(shù)實踐、技術(shù)干貨、技術(shù)見解、成長心得，還有一切值得被發(fā)現(xiàn)的內(nèi)容。我們希望集合最優(yōu)秀的技術(shù)人，挖掘獨到、犀利、具有時代感的聲音。
?