劉晶晶

隨著近幾年大數(shù)據(jù)技術(shù)的興起，業(yè)內(nèi)開始把大數(shù)據(jù)技術(shù)應(yīng)用到IT運維上進行分析，進而產(chǎn)生了IT運維分析ITOA。把大數(shù)據(jù)技術(shù)應(yīng)用到IT運維上分析的目的是提高數(shù)據(jù)質(zhì)量和效率，以及可用性監(jiān)控、應(yīng)用性能監(jiān)控、故障根源分析、安全審計等方面的指標。根據(jù)權(quán)威的調(diào)查機構(gòu)Gartner預(yù)測，到2017年15%的大企業(yè)會積極使用ITOA，盡管2014年這個數(shù)字只有5%，日志易首席執(zhí)行官陳軍表示ITOA是新生事物，正在被市場逐步接受。

多源的數(shù)據(jù)支持

ITOA將大數(shù)據(jù)技術(shù)應(yīng)用在運維數(shù)據(jù)的分析上，數(shù)據(jù)的來源就非常重要。ITOA的數(shù)據(jù)來源主要分為四方面：第一是機器數(shù)據(jù)、服務(wù)器、網(wǎng)絡(luò)設(shè)備產(chǎn)生的數(shù)據(jù)，簡言之就是日志;第二是通信數(shù)據(jù)，如今網(wǎng)絡(luò)普及，后臺的設(shè)備很多都是大型的分布式系統(tǒng)，都有網(wǎng)絡(luò)的通信;第三是代碼級別進行統(tǒng)計分析，例如通過PHP、JAVA這些字節(jié)碼來插入統(tǒng)計分析的代碼，進而統(tǒng)計函數(shù)調(diào)用情況、堆站的使用情況等，從代碼級別來進行統(tǒng)計分析會呈現(xiàn)更加精細化的成果，也可稱為代理數(shù)據(jù);第四是探針數(shù)據(jù)，例如全國用戶訪問IDC的延時是多少，必須在全國布點并發(fā)起模擬用戶的請求探測，進行端到端延時方面的度量。

美國有一家運作ITOA的公司，他們做了一項用戶調(diào)查來統(tǒng)計四種數(shù)據(jù)來源使用情況，其中日志的使用比例非常高，達86%，網(wǎng)絡(luò)抓包達93%，插入代碼代理數(shù)據(jù)是47%，探針數(shù)據(jù)是72%。日志與網(wǎng)絡(luò)抓包占的比例非常高，占總體的80%-90%，這充分顯示了日志數(shù)據(jù)采用的重要性。

日志無所不在，所有服務(wù)器、網(wǎng)絡(luò)設(shè)備、應(yīng)用系統(tǒng)都會產(chǎn)生日志，不同的應(yīng)用輸出的日志完整性與可用性不同。通信數(shù)據(jù)從網(wǎng)絡(luò)流量統(tǒng)計的信息非常全面，但也有局限性，一些事件未必觸發(fā)網(wǎng)絡(luò)通信，如果沒有觸發(fā)網(wǎng)絡(luò)通信的話就不會產(chǎn)生網(wǎng)絡(luò)流量，也就沒法做出統(tǒng)計。

代理數(shù)據(jù)潛入代碼的使用比例較低，它的優(yōu)勢在于可以進行代碼級別的精細監(jiān)控，能看到代碼的執(zhí)行情況，但它也存在一定的侵入性。插入代碼，執(zhí)行時已經(jīng)改變了原來程序的執(zhí)行流程，每次執(zhí)行都會插入代碼，插入的代碼可能會帶來性能問題，降低被檢測程序的性能。另外，還有安全、穩(wěn)定性的顧慮，插入代碼有沒有把一些敏感信息竊取，插入的代碼是不是足夠穩(wěn)定，如果插入代碼崩潰則會導致被監(jiān)測程序的一系列崩潰。

探針數(shù)據(jù)是用來模擬用戶請求，完成端到端監(jiān)控，可以從手機訪問到服務(wù)器端到端的延時，但并不是真實的用戶度量，業(yè)界希望度量到用戶真正的延時情況，而不是模擬。例如像騰訊、百度類似的移動應(yīng)用廠商，已經(jīng)有數(shù)以億計的終端用戶，他們可以直接在手機應(yīng)用端做真實的用戶度量，可以看到真實用戶的訪問情況。2008年汶川地震的時候騰訊QQ客戶端實時監(jiān)測到汶川地區(qū)用戶QQ掉線，馬上知道那里發(fā)生了重大事故，做到了真實的網(wǎng)絡(luò)度量。

海量日志的“前世”與“今生”

日志，學術(shù)性的說法是時間序列機器數(shù)據(jù)，因為它是帶時間戳的機器數(shù)據(jù)，由網(wǎng)絡(luò)設(shè)備、服務(wù)器產(chǎn)生，并包含IT系統(tǒng)很多信息，其中涉及服務(wù)器、網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用軟件，甚至包括用戶、業(yè)務(wù)的信息。日志反映了事實數(shù)據(jù)，不管是數(shù)據(jù)中心還是企業(yè)發(fā)生的一切都會被記錄下來。通過統(tǒng)計分析日志，不同系統(tǒng)之間的通信也可以通過日志傳遞信息。

日志呈現(xiàn)非結(jié)構(gòu)化特征，如果要進行分析就要轉(zhuǎn)化為結(jié)構(gòu)化，一條日志包含的信息非常多，從統(tǒng)計分析的角度就會得出更多有價值的信息。日志可以用到哪些場景？首先是運維監(jiān)控，保證系統(tǒng)的可用性，如果出現(xiàn)故障，能夠及時地追溯根源并及時知道問題。

其次是應(yīng)用性能監(jiān)控，主要是得知性能的情況，例如網(wǎng)站的運轉(zhuǎn)速度，緩慢的原因等，這些均屬于應(yīng)用性能監(jiān)控。數(shù)據(jù)中心還有一條很重要的原則就是安全，要保證數(shù)據(jù)中心的安全，防止黑客的入侵。這可以用在安全審計方面，主要是安全信息事件管理、合規(guī)審計、發(fā)現(xiàn)高級持續(xù)威脅APT等。

日志如此重要，包含了那么多重要信息，以前怎么處理日志值得探討。過去中小型公司不太重視日志，大型的企業(yè)正開始重視日志。企業(yè)日志沒有集中管理，散落在各臺服務(wù)器上，出了問題就登錄到各臺服務(wù)器上用腳本命令、用VI去查看日志，其中不乏一些水平高的運維工程師用AWK寫一些腳本分析程序去分析日志，但是這樣的做法也有問題。因為登錄到各臺服務(wù)器，這些服務(wù)器都是生產(chǎn)服務(wù)器，一不小心的錯誤操作可能會導致事故。

另外有的運維工程師把日志當做垃圾，看到磁盤空間達到極限，首先做的事情就是刪除日志，刪除日志后如果發(fā)現(xiàn)有些故障需要分析又找不到日志。后來業(yè)界開始重視日志，他們用數(shù)據(jù)庫存儲日志，這也是如今一個比較普遍的做法。原則上講，數(shù)據(jù)庫是用來存結(jié)構(gòu)化數(shù)據(jù)的，日志是非結(jié)構(gòu)化的數(shù)據(jù)，數(shù)據(jù)庫有固定的Schema，為了讓表的格式最大限度的靈活化，數(shù)據(jù)庫就定義了三列，其中第一列是產(chǎn)生日志的機器IT地址，第二列是時間戳，第三列是日志本身的信息，把整個日志的文本當做一個字段放到數(shù)據(jù)庫中，并沒有針對日志中的信息進行抽取進行分析?，F(xiàn)在產(chǎn)生的日志越來越多，每臺服務(wù)器一天產(chǎn)生幾GB甚至幾十GB的數(shù)據(jù)，一個數(shù)據(jù)中心上千臺服務(wù)器一天可能產(chǎn)生幾TB的數(shù)據(jù)，數(shù)據(jù)庫沒辦法適用TB級的海量日志。

如今，Hadoop出現(xiàn)后業(yè)界開始用Hadoop處理日志。首先Hadoop是批處理的框架，不夠及時。用Hadoop處理分析都是今天看昨天的數(shù)據(jù)，或者是看幾個小時之前的，最快也只能看到幾十分鐘之前的。要想看幾秒鐘之前的，Hadoop是做不到的。Hadoop的查詢，雖然有Hef（音）這樣的東西來做查詢，但Hef的查詢也非常慢，所以Hadoop基本是用來做數(shù)據(jù)的離線挖掘，沒辦法做在線數(shù)據(jù)分析。后來又開始出現(xiàn)了Storm、Spark，但這些都是使用框架，后來出現(xiàn)NoSQL，但沒辦法全文檢索。可見在海量日志的處理方面還有很多可挖掘與突破的地方。

隨著互聯(lián)網(wǎng)的飛速發(fā)展以及Web日志數(shù)據(jù)的爆炸式增長，海量日志數(shù)據(jù)的處理越來越受到人們的關(guān)注。對這些海量日志的數(shù)據(jù)挖掘，可以從中分析用戶的行為特征，獲取用戶屬性，也可以發(fā)現(xiàn)用戶訪問網(wǎng)站頁面的模型與訪問習慣，為網(wǎng)站管理員優(yōu)化網(wǎng)站頁面設(shè)計提供有效依據(jù)，但這只是未來發(fā)展方向之一。