IT 運維分析及海量日誌搜索的實踐之路（上）

內容簡介：

IT運維分析（IT Operation Analytics, ITOA）是近年興起，其把大數據技術應用於分析IT運維產生的大量數據，數據來源主要有日誌、網絡流量、植入代碼、布點模擬監控等。過去使用數據庫處理日誌無法支持大數據量，後來出現了使用Hadoop/Storm/SparkStreaming等開發框架來處理日誌，及最新的使用實時搜索分析引擎來對日誌進行實時處理。現如今使用Hadoop/Storm/SparkStreaming等開發框架來處理日誌已經在各大公司被廣泛的運用，本次演講嘉賓將結合具體實踐爲大家帶來如何使用實時搜索分析引擎來對日誌進行實時處理。

本文爲日誌易創始人兼CEO陳軍，在2016年GOPS全球運維大會.深圳站的演講實錄，包括介紹ITOA，比較各種日誌處理技術等話題，重點講解實時日誌搜索分析引擎，比較索引階段對日誌做結構化（Schema on Write）及檢索階段對日誌做結構化（Schema on Read），在搜索框裏編寫搜索處理語言（Search Processing Language, SPL）以靈活地支持各種業務分析，及在金融的應用案例。

陳軍：

謝謝那麼多人來參加這個大會，感謝這個機會。剛纔前面有一位朋友問到日誌分析的情況，日誌易就是專門做日誌分析的，我也專門講一下日誌。實際上日誌只是一個方面，我今天要講的是一個更大的話題，《IT運維分析與海量日誌搜索》。

IT運維分析

“IT運維分析”是這兩年新提出來的概念，過去那麼多年我們一直在講的運維，實際上講的是運維管理，即ITOM。

而ITOA是這兩年隨着大數據技術的產生而產生的，它就是把大數據的技術用在IT運維產生的數據上面。

因爲IT運維本身就會產生大量的數據，用大數據的技術去處理IT運維產生的數據，來提高IT運維的效率。它的用途是在可用性監控、應用性能監控、故障根源分析、安全審計這些方面。

據Gartner估計，到2017年15%的大企業會積極使用ITOA，在2014年的時候這個數字只有5%。這個報告還是基於歐美的市場，歐美IT方面的投入更大、更加精細化，在他們那裏才做到明年有15%的大企業積極用ITOA。

很多公司還停留在ITOM（IT運維管理）的階段，ITOA是一個新的階段，要去做分析，分析之後來提升管理水平。

ITOA的四種數據來源

ITOA是把大數據的技術用在IT運維產生的數據上面，所以數據的來源就很重要，它分析些什麼數據？

1 機器數據: 其實主要就是日誌，服務器、網絡設備產生的數據；
2 通信數據: 實際上就是網絡抓包，這些流量的數據，把它抓包解包之後會產生大量的數據；
3 代理數據: 在.NET/Java這些字節碼裏面插入你的監控代碼，去統計函數調用的情況、堆棧使用的情況，在代碼這一級來進行分析，插入代碼也可以獲得一些程序執行的數據；
4 探針數據: 在全國各地布點來模擬用戶的請求，來發起ICMP的ping、HTTP GET這種請求，對系統進行檢測，看延時的情況、響應的情況。

所以，ITOA就是圍繞着這四種數據來源，使用大數據的技術來做分析。

美國一家ITOA公司做的用戶調查，這四種數據來源使用佔比，大家可以看到：日誌佔86%，流量抓包占93%，代理數據佔47%，擬檢測佔72%。這是美國一家公司做的調查，這個數據背後其實也是有理由可以解釋的。

ITOA四種數據來源的比較

1、 機器數據：

日誌無處不在，網絡、設備、服務器、應用程序都會產生日誌，比較全。但是它也有它的情況，不同的應用可能吐出來的日誌包含的信息不一樣，有的應用可能吐出更多的日誌，包含的信息比較面；有的日誌可能吐出來的日誌非常少，只有出錯的時候吐出日誌，正常情況下都不吐出日誌。所以，可能你能夠獲得的信息不夠，日誌內容的完整性和可用性不太一樣。

2、 通信數據:

這個信息也非常全面，只要有通信，你就可以抓包。它的問題是什麼呢？ 有一些事件未必觸發了網絡流量，如果沒有觸發網絡流量，你就抓不了包。另外，有些包可能是加密的，你抓了之後解不了密，不知道里面的內容，或者裏面很多應用層解析的規則你不清楚，沒有辦法解析，不知道它包含的意義。它用的都是二進制的，你這個解包，每一種應用你都需要專門自己開發解包的規則，去把它給解出來。

3、代理數據：

就是在字節碼裏嵌入你的統計分析代碼來進行監控，它是一個代碼級的監控分析，它是非常精細化的，精細到代碼這一級，哪一個指令被調用了多少次，在這一級做統計分析。但是它有它的問題，它是具有侵入性的。當你做這種分析的時候，你已經改變了這個程序，你在原有的生產線上植入了你的代碼，你植入了代碼：如果穩定性有問題，可能導致進程崩潰。還有安全的問題，你植入的代碼會不會把敏感的信息拿走？

哪怕解決了穩定性和安全性的問題，植入的代碼每一次又會被執行，可能也會造成性能的影響。這就有點像量子力學的“測不準”原理，你觀測這個量子的時候，你的觀測行爲就改變了它，你觀測得到的東西實際上不是最真實的，並不是它原來執行的情況。

4、探針數據:

模擬用戶請求，現在市面上也有一些產品。他們在全國可能有幾百個節點，它布節點，不斷地對你的後臺服務器發起請求，來監測全國各地的用戶訪問你的服務的情況，包括網絡的延時。它是一種模擬監控，而且是端到端的監控，好處是可以模擬從客戶端一直到服務器請求到響應等來回的種類的延時。

但是它就不是真實的用戶度量，現在講監控監測都講真實的用戶度量。對於服務商來講，他關心的是真實的用戶感受到的延時，而不是一個模擬的請求。當然，模擬的請求發現慢了，可能是網絡出問題了，立即要採取行動。

• 一些小的應用，因爲他們沒有辦法在全國布點，日活量不夠，那可能會用這種方式。
• 像大的應用，不管是微信，淘寶，這種每天的活躍用戶都是過億的，全國到縣區這一級都有大量的用戶。

其實他們是不太需要用這種探針數據去模擬用戶請求的，他們直接統計真實的用戶請求就知道網絡狀況，而且他們要做這個事情可以直接來做，不需要用第三方的應用。我記得08年汶川地震的時候，騰訊QQ的後臺馬上就看到汶川地區的QQ用戶下線了。所以，這種大的應用直接就可以知道網絡的狀況。可以看到，這四種數據來源中，具有侵入性的是代理數據，日誌和網絡流量都是旁路的，網絡也是通過鏡像流量旁路來抓包的。

日誌數據、通信數據、探針數據這三類對應用本身是沒有產生直接影響的，但是代理數據是會對應用直接產生影響。所以，這也說明了爲什麼代理數據的使用百分比是比較低的，而日誌和網絡抓包是非常高的，也就是了這個理。

日誌：時間序列機器數據

首先，它是從服務器、網絡設備和應用軟件這些機器上產生的，甚至現在智能設備越來越多了，傳感器等這些都會產生日誌。它還有一個很特別的地方是時間序列，爲什麼叫時間序列？日誌一個很重要的東西是帶時間戳，基本上我們很少見到沒帶時間戳的日誌。我們是一個第三方的獨立廠商，是賣工具給各種類型用戶的，所以各種各樣很奇葩的問題都會遇到，比如說：

• 有的客戶日誌真的沒有帶時間戳的，帶多個時間戳的也有,一條日誌裏帶了好多時間戳。
• 還有時間戳的格式有近百種，標準的時間戳日誌是放在比較靠前的，有的是時間戳放在靠後，都有，它的位置也不固定。

日誌包含的信息：

• 日誌包含了IT的系統信息，比如：服務器的信息，網絡設備的信息，操作系統的信息，應用軟件的信息；
• 日誌也包括用戶的信息，用戶的行爲信息；
• 也可能包括業務的信息。

所以，日誌反映了IT系統的事實數據。LinkIn這家公司是硅谷很有名的做職業社交的公司，它在大數據方面是走得比較前的。他們的工程師寫了一篇文章叫《深度解析LinkIn大數據平臺》，有中譯本，在CSDN上，大家可以搜索一下。非常長，十幾頁，它的中文翻譯跟原來的英文名稱是不太一樣的，你看中文的名稱好象跟日誌沒啥關係。但是你要看它原文的名稱，意思是“每一個軟件工程師需要知道的實時數據的統一的抽象”。

日誌是一個什麼東西？

是每一個軟件工程師必須知道的實時的、數據的一種統一的一種抽象，LinkIn是把日誌做到極致了，LinkIn裏面很多不同業務系統之間的對接都通過日誌。Kafka現在是用得最廣泛的消息系統。Kafka這個消息系統是在LinkIn十多年前發明的，十多年前上線，就是用來處理日誌、傳輸日誌的，把日誌在不同的系統之間流轉。所以，有興趣的同學可以看一下這個文章。

越來越多的公司也意識到日誌需要統一來管。我之前工作過不同的公司，公司一大了之後，內部有好多部門，不同的業務，每一個業務部門統計分析自己的業務數據，然後報給老闆。這些報上來的數據可能都互相打架，這邊講得非常好，那邊看出來好象不太那麼好，各個部門有自己的動機和利益，統計出來的東西不完全客觀。所以，有的公司老闆就意識到這個問題了。

日誌集中管理，不同業務部門的日誌全部交給一個部門來負責，他們會成立大數據部來統一處理日誌，把不同業務系統的日誌對照着來看，就會更加協調，更加統一，數據更加對得上號。這個大數據部門就像×××這樣的角色，各省說它的GDP是多少，還得看它的用電量。從其他角度來看，日誌就是非常重要的角度來看業務的情況，包括日活是多少，每天新增的用戶是多少，這些全部在日誌中可以看出來。

一條Apache Access日誌

大家對Apache日誌比較熟悉，Apache日誌也是一個包含信息量非常豐富的日誌。首先，它是一個文本數據，它帶來了時間戳、主機名、產生這條日誌的IP、字段。

我們把每一個字段抽出來：

• IP地址叫Client IP;
• 時間戳叫Timestamp;
• POST，我們給它這個字段名稱叫Method;
• report叫URI;
• 這個HTTP的版本1.1，Version;
• 這個狀態碼是200;
• 21是字節;
• 從哪裏過來訪問的;
• User Agent也比較重要，客戶端那邊是什麼操作系統、什麼瀏覽器;
• 0.005是本臺服務器響應的時間;
• 0.001是後面應用服務其的響應時間。

所以，從這一條日誌中可以分析出來的東西就非常多，可以做業務分析，也可以做應用性能的監控。你的響應時間是多少就可以監控，是不是網站慢了，是不是堵了，甚至從URI這裏可以看出安全審計，你是不是被安全***了。所以，日誌包含的信息是非常豐富的。

日誌的應用場景

• 運維監控：可用性監控、應用性能監控
• 安全審計：安全信息事件管理、合規審計、發現高級持續威脅
• 用戶及業務統計分析

谷歌的安全做到沒有內網了，它認爲內網是不安全的，內網和外網是一樣的，內網得做很多防護。其實APT這種技術就是認爲沒有內網，內網是不安全的，所以才需要APT。如果內網是安全的，我在外面放道防火牆就足夠了，就像你家有個大鐵門，但是小偷爬牆進來，爬窗進來，甚至挖個地洞進來，甚至現在還有無人機了，從窗戶飛進來。所以，你必須得全方位地監控，全方位地監控流量和日誌，做APT最重要的就是這兩個數據來源。

現在及過去的做法

過去

1、很多小公司沒有集中管理日誌，扔在那裏，覺得日誌是個負擔，出現問題才登錄到這臺服務器，用一些腳本命令，或者寫一些簡單的腳本程序去查一下日誌，大部分公司還是停留在這樣的階段。

2、服務器的硬盤滿了，首先第一件事就是去刪掉垃圾。日誌是有時間效應的，太久之前的日誌是沒有什麼用的，特別是對運維工程師來講，關心的可能就是今天的日誌或者昨天的日誌，出現問題了從日誌裏看是什麼問題。對安全工程師來講，這個日誌需要的時間就要長了，有些******可能是幾個月、一年之前發生的，得去查。***如果***了系統，聰明一點的***第一件事可能就是刪除日誌，把自己***的痕跡抹除掉，因爲他的登錄行爲都在日誌中反映出來。

3、日誌在過去只做事後的追查，沒有實時的監控分析。出現錯誤不能預先知道，都是已經知道錯了，然後到日誌去找原因，日誌沒有作爲一種監控的手段，只是用來作爲追溯根源的手段而已。

4、一些公司開始意識到日誌的重要性了，開始把日誌管起來，但是管的方法不對，用數據庫來管日誌。

其實市面上也有一些所謂的日誌管理分析產品都是基於數據庫的，基於數據庫有什麼問題呢？
首先，這些日誌越來越多，可能海量的日誌每天上TB。

我們現在日誌易在生產線上跑，在樂視跑每天新增日誌量是20TB。

這樣一種日誌的量，你用數據庫是根本沒有辦法處理的，而且數據庫是用來處理結構化數據的，非結構化數據是沒有辦法處理的。

所以，我看過一些用數據庫處理日誌的產品，數據庫有所謂的表格式，但是這個表就三列： IP地址，產生日誌的主機名、時間戳，日誌文本信息。所以，他沒有對日誌做任何的字段抽取，又不支持全文檢索，有時候搜一條日誌得把整條日誌的信息寫全了才能搜出來，否則搜不出來所以，數據庫處理日誌是一種非常落後、過時的方法。

近年

隨着大數據技術的出現，就出現了像Hadoop這樣的框架了，大部分互聯網公司目前都是用Hadoop處理日誌的。但是Hadoop處理日誌又有什麼問題呢？Hadoop是批處理的，不夠實時。用Hadoop處理日誌通常是晚上處理當天的日誌，第二天早上十點鐘或者九點鐘上班可以看到前一天的日誌統計分析的情況，或者有時候要查一些東西也得跑個幾小時才能看到日誌的情況，而且查詢也慢。

我06年到09年在Google美國總部的時候是做網頁抓取爬蟲。當時是每天3000臺服務器的一個集羣，每天爬一百多個網站。全世界的網站都爬下來了，但是不是說全部，一部分有的更新慢，有的網站幾天才訪問一次，有的是每天要去訪問。爬這些不同的網站，出現錯誤的信息就千差萬別、千奇百怪，都得看日誌。出現了新的錯誤或者新加了一個功能的時候，原來的程序是處理不了的。當時我在Google，經常每天早上上班的第一件事是先看一下日誌:有一些錯誤信息是無法確認的，不能歸類的;不能歸類的那部分我馬上寫一個小的程序，可能也就幾十行;寫完之後去跑，跑下來可能幾十分鐘甚至一兩個小時，可能到下午才能出現結果。

所以，Hadoop的東西是給開發人員用的，不是給運維人員用的，它還得寫程序，而且它是做離線挖掘，沒有辦法做在線分析。所以，對於運維工程師來說，你要讓他用Hadoop，頂多用Hive來查一下。當然，每次運維工程師可能都得求助於開發工程師再改一下Hadoop的程序來處理。

後來，爲了解決實時性的問題，又出現了Storm、Spark這些性能更好的流式處理，但是不管是Hadoop、Storm、Spark，它都是一個開發框架，不是一個拿來就可以用的產品。另外可能又有一些工程師用NoSql，NoSql的方案也很多，但是NoSql不支持全文檢索，它不是一個搜索引擎，你只能是檢索它對應的值是什麼，並不能夠直接搜一個日誌的信息。

現在

現在我們需要一種新的技術對日誌進行實時的搜索分析，就是所謂的日誌的實時搜索分析引擎，它有什麼特點：

• 快：日誌從產生到搜索、分析出結果，只有幾秒鐘的延時，我馬上要知道信息。日誌裏出現了一個錯誤的信息，不會像Apache出來一個500的狀態碼，500意味着後臺的應用服務器出錯了，運維工程師是最擔心的，出了500的狀態碼馬上進行告警，以前可能是用腳本寫一些工具來做告警。但是你用日誌實時搜索分析馬上可以告訴你這個500出現了多少次。
• 大：每天要能夠處理DT級的日誌量。
• 靈活：它是IT工程師的搜索引擎，是所謂的Google for IT，它可以搜索分析任何的日誌、日誌裏任何的字段。
• Fast Big Data：大而快的數據，不僅僅是一個大數據，是一個事實大數據。

日誌搜索引擎

日誌管理系統的進化

最早的1.0用數據庫來做日誌，到2.0用Hadoop或者NoSql，到3.0就是實時搜索引擎，我們現在就進入到日誌3.0的階段。

日誌易亮點

• 日誌易就是一個可編程的日誌實時搜索分析平臺。

• 搜索處理語言（SPL）
  有一個搜索框，光有一個搜索框讓你搜東西太基本了，我們是運維工程師，我們具備一定的腳本編程能力，它的可編程在哪裏？日誌易可以在搜索框裏編寫腳本語言。我們實現了腳本語言的搜索處理語言，它包括管道服務。你有多個命令，用管道服務把這些命令串起來，跟你在Linux腳本里面命令行寫腳本一樣，有很多小的命令執行單元操作，再用管道服務把這些單元操作給串起來。所以，寫這種SPL的腳本就可以完成這種複雜的查詢付息。
  這樣，這個產品就變得非常靈活強大了，用戶的業務是千差萬別、千變萬化的，我們不需要把業務定製到產品裏，而是提供基礎的平臺，讓用戶直接在搜索框裏去寫腳本語言來做這種定製化，就可以適應不同的應用場景。任何的應用場景都可以在搜索框裏寫這種腳本程序，這種腳本程序可能是幾十行，甚至是上百行的腳本程序，來進行復雜的分析處理。
• 日誌易可以接入多種的數據來源:可以是日誌文件;可以是數據庫裏的;甚至我們給券商做的恆生電子交易系統，它產生的日誌是二進制格式的，我們調用了恆生電子交易系統提供的Java API來把它解碼成文本格式。
• 我們提供企業部署版，也提供SaaS版，SaaS版是每天上傳500MB的字節處理免費，歡迎大家試用，在我們的網站上有。

日誌易功能

• 搜索。
• 告警。基於搜索結果，某個字段出現了多少次，可以去告警；
• 統計。進行統計分析，可以進行事務關聯，不同系統產生的日誌可以關聯起來。
• 配置解析規則，識別任何日誌。

剛纔前面的演講，有一位同學問到日誌多種多樣，要不要對日誌歸一化、統一日誌格式？當然，如果你能夠說服開發人員去改系統去統一日誌格式是最好的，但是現實的現有的系統沒有人願意去改，就沒有辦法去統一日誌的規格。日誌易強大的地方是可以讓用戶在Web界面上配置解析規則，來抽取裏面的字段，把日誌從非結構化數據轉成結構化數據，就可以對每個字段進行統計分析，非常強大靈活。任何格式的日誌我們都可以把它從非結構化數據轉成結構化數據；

這裏講的是日誌進入日誌易系統時就抽取字段做結構化，是所謂的Schema on Write，好處是日誌在入庫前做結構化預處理，檢索速度快，不好的地方是不夠靈活，用戶可能在檢索日誌的時候，才確認需要抽取什麼字段。爲了適應這種場景，日誌易也實現了Schema on Read，支持檢索階段使用SPL的Parse命令，抽取用戶想要的字段，非常靈活。日誌易同時支持Schema on Write 及 Schema on Read，由用戶根據使用場景決定使用哪種方式，非常靈活、強大。

• 安全***自動識別的功能；
• 開放API，可以讓用戶在上面做二次開發，對接第三方系統；
• 高性能、可擴展分佈式系統。現在在樂視那裏跑到每天20TB，每秒鐘峯值達到100萬條的處理量。

因內容文字限定，本文未完結，剩餘內容請看本賬號文章《日誌易：IT運維分析及海量日誌搜索的實踐之路（下）》

日誌易提供部署版產品，SaaS版產品在騰訊雲的體驗入口：點我

日誌易簡介：

日誌易專注日誌分析領域，產品做得像Google搜索引擎一樣強大、靈活、易用。目前，日誌易產品已成功應用於金融、能源、運營商及互聯網等諸多行業，其中金融客戶包括中國銀行、新疆農信、鵬華基金及第三方支付公司等；能源行業客戶已囊括國家電網、南方電網、中石油、中石化等國內知名企業；移動、電信等國內主流運營商以及小米、樂視、網宿科技等諸多明星互聯網企業均已牽手日誌易——目前日誌易大客戶已達百餘家。

日誌易對運維日誌及業務日誌進行實時採集、搜索、分析及可視化等，用於運維監控、安全審計、業務數據分析，最終發掘出數據價值。