本文根據〖2016 全球運維大會?深圳站〗現場演講嘉賓分享內容整理而成。

講師簡介：陳軍

17年IT及互聯網研發管理經驗，曾就職于Cisco、Google、騰訊和高德軟件，歷任高級軟件工程師、專家工程師、技術總監、技術副總裁等崗位。他發明了四項計算機網絡和分布式系統的美國專利，擁有美國加州大學計算機碩士學位。

導言

陳軍：謝謝那么多人來參加這個大會，感謝這個機會。剛才前面有一位朋友問到日志分析的情況，日志易就是專門做日志分析的，我也專門講一下日志。

實際上日志只是一個方面，我今天要講的是一個更大的話題，《IT運維分析與海量日志搜索》。

IT運維分析

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

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

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

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

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

ITOA的四種數據來源

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

機器數據: 其實主要就是日志，服務器、網絡設備產生的數據；

通信數據: 實際上就是網絡抓包，這些流量的數據，把它抓包解包之后會產生大量的數據；

代理數據: 在.NET/Java這些字節碼里面插入你的監控代碼，去統計函數調用的情況、堆棧使用的情況，在代碼這一級來進行分析，插入代碼也可以獲得一些程序執行的數據；

探針數據: 在全國各地布點來模擬用戶的請求，來發起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界面上配置解析規則，來抽取里面的字段，把日志從非結構化數據轉成結構化數據，就可以對每個字段進行統計分析，非常強大靈活。

任何格式的日志我們都可以把它從非結構化數據轉成結構化數據；

安全攻擊自動識別的功能；

開放API，可以讓用戶在上面做二次開發，對接第三方系統；

高性能、可擴展分布式系統。現在在樂視那里跑到每天20TB，每秒鐘峰值達到100萬條的處理量。

案例

案例一：某大型綜合金融機構

這是一個大型的綜合金融機構，總部就在深圳，也是中國最大的。

他們之前需要逐臺去登錄服務器：

沒有辦法集中查看日志;

沒有辦法對海量日志進行挖掘和用戶行為分析;

而且沒有辦法做多維度的查詢，比如時間段、關鍵詞、字段值;

而且沒有辦法進行日志的業務邏輯分析和告警。

在之后：

建起日志云，在內部建立了一個私有云來處理日志，已經接入了一百多個應用，每天新增的日志量是8TB。

做了這個之后的好處是省去了登錄服務器的操作，就能夠快速地查看，降低登錄服務器的人為誤操作的概率。

對金融系統來說，這些生產線上的服務器是非常關鍵的。

如果每個運維工程師都登錄到生產線上的服務器去查看日志，一不小心，一個誤操作，可能就影響了生產線上的應用，就導致一次事故。

上了日志易之后，就禁止運維工程師登錄服務器去看日志，所有看日志就在它內部的日志易云上來看，解決了需要日志統一管理的痛點。

而且可以進行多維度的查詢，提高定位異常原因的效率，可以對日志數據進行數據挖掘、用戶行為分析，可以對系統的健康指數每天出報表。

現在很多用戶用日志易主要的一個功能是每天出報表給老板看，因為之前是用Hadoop，Hadoop是第二天出昨天的報表，用了日志易之后是當天6點鐘的時候就可以出報表，讓老板下班前看到當天的情況。

而且可以是事先告警，只要一出錯，就馬上告警，而不是事后去追查這個問題。

案例二：中移動某省分公司

用來分析營業廳業務辦理的Web的日志，這里就用了SPL搜索處理語言，營業廳里面一筆交易是經過多個子系統的，每一個子系統都會產生日志。

用了之后，就把一筆交易的每一筆子系統產生的日志給串起來，串起來之后還原成一筆交易，分析一筆交易的延時情況、響應情況。

這就是在搜索框里寫的，這還是比較短的，它搜索的字段就是“json.url”，通過管道符把前面搜索的結果傳給后面的事務命令。

因為不同子系統的日志都傳給命令了，這個命令執行的操作是找ID，因為每一筆操作都是有一個獨立ID的，根據這個ID把這一筆交易在不同子系統上產生的日志都串起來。

串起來之后排一個順序，是以查詢作為起點，傳入參數，事務命令的參數有stamp，還有ends，一筆事務是從查詢開始的，以提交作為結束。

但是如果一直不提交也會超時，超時間的時間是30分鐘，如果30分鐘都不提交，就認為這筆事務就夠了，就超時了，這樣就不會無限地等下去。通過這樣一個事務的命令，把這個交易給串起來。

這就是串起來之后的結果，這是我們的界面，這就是在搜索框里剛才寫的搜索處理語言的程序，出來的結果就把這些交易全都串起來，一筆繳費業務，營業員所有操作都一目了然。

它還得監控這些營業員，看這些營業員各自的效率怎么樣。

每個步驟所需要執行的時間都排好，包括網絡處理時間、服務器處理時間，都排好序。

這就是我們在中國移動山東省分公司做的一個案例。

案例三：國家電網

主要用在安全信息事件管理，因為終端信息安全是日志的調查、分析、取證，它要到各省分公升去做審計，快速排查日志里的問題。

合作客戶

Q&A

Q：我有幾點疑問，第一，站在運維的角度，日志管理只是運維中的一部分，在我看來，它的價值是可以集中管理，可以集中查看。另外，把我平常查看日志里面，我要搜keywords，根據我的經驗去發現問題，最重要的是業務要產生價值。

那么，從這一點來看，假如說擁有日志易，肯定要通過API對接，把我的經驗放在這個平臺上，形成規則，這樣的一個思路。日志易API是不是開放的？

陳軍：非常好的問題，日志易對標的是美國的一家公司叫做Splunk，那家公司做了十幾年，那家公司上面有五百多個應用，已經做成了平臺，比如Cisco的日志是一個應用，某個防火墻的日志又是一個應用，它的上面好多應用。

回答你剛才問的這個問題，日志易也開放了這種API，把運維工程師的經驗積累下來，它可以基于API來開展一些應用。

另外，你的一些經驗，可能是通過SPL，寫了就可以保存下來，共享給其他同事，他們就直接點擊保存搜索，就來運行你之前寫的SPL這個腳本處理語言，來分析出同樣的結果，來做同樣的分析。

Q：第二個問題，剛才舉到樂視的例子，一百萬條數據，這一百萬條數據是產生數據完之后，多長時間我就可以索引到它？

陳軍：只有大概幾秒到十幾秒。

Q：無論是在線版本還是離線版本都可以，是吧？

陳軍：都可以。

Q：你好，我是華為公有云運維的，我們接觸到兩種類型：一種是Splunk，它號稱自己是沒有schema，它是后分析；還有一種是ELK，ELK是事先分析schema。事先分析可能統計比較快。不知道日志易是哪種流派？

陳軍：非常好的問題，這是設計上就需要考慮的問題，其實也是我們反復想的一個問題。

兩個流派，一種叫Schema on Read:

一種叫Schema on Write，在寫的時候就要有schema，Splunk 這種叫做Schema on Read，在讀的時候、查詢的時候才會產生schema，才會做結構化，這樣的好處是非常靈活。

日志進來之前你不知道該抽取什么字段，你不知道它的schema就把它做全文索引存下來了，然后檢索分析的時候再去抽取字段，做schema，靈活。

靈活，任何東西都有代價，代價是檢索非常慢，一次檢索可能是幾十秒鐘，甚至幾十分鐘都有，因為你在檢索的時候才去做這個schema。

另外一種ELK，叫做Schema on Write，你寫的時候就先把schema給抽出來，再做索引，就不夠靈活。可能檢索的時候發現原來抽的字段是不對的，得把這個日志重新搞一遍，很麻煩。

但是它的好處是檢索非常快，幾秒鐘就檢索出來了，分析出來了。

日志易目前是Schema on Read，但是我們也在開發Schema on Write。

其實這些東西都是可配置的，系統設計的一個理念是去實現這個機制，把這個策略交給用戶，用戶自己可以選Schema on Read還是Schema on Write，我們兩種都支持它，其實兩種都有它的好處，都有它的壞處，用處自己做評判，自己做選擇。

現在這個東西比較新，還得不斷培育教育這個市場，他們用得還沒有上升到那么高級的水平，大部分Schema on Write是可以接受的。

但是也有一部分已經反映不夠靈活，這種少量比較高級的用戶用到比較高階的階段了，Schema on Read的要求了。

Q：樂視的20TB，每天是多少主機?

陳軍：幾十臺可以處理這樣的數據量，產生就非常多了，我們有Agent，集中管理幾千個Agent，這個Agent可以對日志進行限流、壓縮、加密、脫敏等等。

Q：在Java里面有一個Eclipse報錯，這個不是看一條一條的，是上下多少行，這種您是怎么處理的？

陳軍：這個很簡單，我們配解析規則，而且這些解析規則是內置的，都不用用戶去配的。

這個Eclipse非常多行，但是它都有特征，有空了多少格、有縮進，都有規則，根據規則把多行日志歸成一條日志，它雖然是多，但是它是一條日志。