日誌易：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搜尋引擎一樣強大、靈活、易用。目前，日誌易產品已成功應用於金融、能源、運營商及網際網路等諸多行業，其中金融客戶包括中國銀行、新疆農信、鵬華基金及第三方支付公司等；能源行業客戶已囊括國家電網、南方電網、中石油、中石化等國內知名企業；移動、電信等國內主流運營商以及小米、樂視、網宿科技等諸多明星網際網路企業均已牽手日誌易——目前日誌易大客戶已達百餘家。

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