IT運維分析與海量日志搜索需要注意什么(1)
2016-02-20 19:34:15 來源: 陳軍 互聯(lián)網(wǎng)運維雜談 評論:0 點擊:
日志易創(chuàng)始人兼CEO陳軍老師12月16日在【DBA+社群】中間件用戶組進(jìn)行了一次主題為“IT運維分析與海量日志搜索 ”的線上分享。
目錄:
◆IT 運維分析(IT Operation Analytics)
◆日志的應(yīng)用場景
◆過去及現(xiàn)在的做法
◆日志搜索引擎
◆日志易產(chǎn)品介紹
一、IT 運維分析
1、IT 運維分析
1.1 從 IT Operation Management (ITOM) 到 IT Operation Analytics (ITOA)
IT運維分析,即IT Operation Analytics,簡稱ITOA,是個新名詞。以前IT運維是ITOM,IT Operation Management ,IT 運維管理。這兩年大數(shù)據(jù)技術(shù)開始普及,把大數(shù)據(jù)技術(shù)應(yīng)用于IT運維,通過數(shù)據(jù)分析提升IT運維效率與水平,就是ITOA。
1.2 大數(shù)據(jù)技術(shù)應(yīng)用于IT運維,通過數(shù)據(jù)分析提升IT運維
ITOA主要用于:
◆可用性監(jiān)控
◆應(yīng)用性能監(jiān)控
◆故障根源分析
◆安全審計
1.3 Gartner估計,到2017年15%的大企業(yè)會積極使用ITOA;而在2014年這一數(shù)字只有5%。
2、ITOA的數(shù)據(jù)來源有以下四個方面:
1.1 機(jī)器數(shù)據(jù)(Machine Data):是IT系統(tǒng)自己產(chǎn)生的數(shù)據(jù),包括客戶端、服務(wù)器、網(wǎng)絡(luò)設(shè)備、安全設(shè)備、應(yīng)用程序、傳感器產(chǎn)生的日志,及 SNMP、WMI 等時間序列事件數(shù)據(jù),這些數(shù)據(jù)都帶有時間戳。機(jī)器數(shù)據(jù)無所不在,反映了IT系統(tǒng)內(nèi)在的真實狀況,但不同系統(tǒng)產(chǎn)生的機(jī)器數(shù)據(jù)的質(zhì)量、可用性、完整性可能差別較大。
1.2 通信數(shù)據(jù)(Wire Data):是系統(tǒng)之間2~7層網(wǎng)絡(luò)通信協(xié)議的數(shù)據(jù),可通過網(wǎng)絡(luò)端口鏡像流量,進(jìn)行深度包檢測 DPI(Deep Packet Inspection)、包頭取樣 Netflow 等技術(shù)分析。一個10Gbps端口一天產(chǎn)生的數(shù)據(jù)可達(dá)100TB,包含的信息非常多,但一些性能、安全、業(yè)務(wù)分析的數(shù)據(jù)未必通過網(wǎng)絡(luò)傳輸,一些事件的發(fā)生也未被觸發(fā)網(wǎng)絡(luò)通信,從而無法獲得。
1.3 代理數(shù)據(jù)(Agent Data):是在 .NET、PHP、Java 字節(jié)碼里插入代理程序,從字節(jié)碼里統(tǒng)計函數(shù)調(diào)用、堆棧使用等信息,從而進(jìn)行代碼級別的監(jiān)控。但要求改變代碼并且會增加程序執(zhí)行的開銷,降低性能,而且修改了用戶的程序也會帶來安全和可靠性的風(fēng)險。
1.4 探針數(shù)據(jù)(Probe Data),又叫合成數(shù)據(jù)(Synthetic Data):是模擬用戶請求,對系統(tǒng)進(jìn)行檢測獲得的數(shù)據(jù),如 ICMP ping、HTTP GET等,能夠從不同地點模擬客戶端發(fā)起,進(jìn)行包括網(wǎng)絡(luò)和服務(wù)器的端到端全路徑檢測,及時發(fā)現(xiàn)問題。但這種檢測并不能發(fā)現(xiàn)系統(tǒng)為什么性能下降或者出錯,而且這種檢測是基于取樣,并不是真實用戶度量(Real User Measurement)。
擁有大量客戶端的公司,如BAT,會直接在客戶端度量系統(tǒng)性能,做Real User Measurement,通常不需要模擬用戶檢測。
3、ITOA 四種數(shù)據(jù)來源使用占比
美國某ITOA公司的用戶調(diào)研發(fā)現(xiàn),使用這四種不同數(shù)據(jù)來源的比例為:Machine Data 86%, Wire Data 93%, Agent Data 47%, Probe Data 72%。這四種數(shù)據(jù)來源各有利弊,結(jié)合在一起使用,效果最好。
4、日志:時間序列機(jī)器數(shù)據(jù)
通常結(jié)合日志與網(wǎng)絡(luò)抓包,能夠覆蓋大部分IT運維分析的需求。日志因為帶有時間戳,并由機(jī)器產(chǎn)生,也被稱為時間序列機(jī)器數(shù)據(jù)。
它包含了IT系統(tǒng)信息、用戶信息、業(yè)務(wù)信息。
日志反映的是事實數(shù)據(jù):LinkedIn(領(lǐng)英)是非常著名的職業(yè)社交應(yīng)用,非常重視用戶數(shù)據(jù)分析,也非常重視日志。
它的一個工程師寫了篇很有名的文章:
◆“The Log: What every software engineer should know about real-time data's unifying abstraction”, Jay Kreps, LinkedIn engineer
附:中文翻譯:深度解析LinkedIn大數(shù)據(jù)平臺
LinkedIn的用戶數(shù)據(jù)挖掘基于日志,公司內(nèi)部有專門的部門處理所有的日志,各模塊的日志都被采集,傳送到這個部門。
著名的開源消息隊列軟件Kafka就是LinkedIn開發(fā),用來傳輸日志的。
以Apache日志為例,包含了非常豐富的信息:
- 180.150.189.243 - - [15/Apr/2015:00:27:19 +0800] “POST /report HTTP/1.1” 200 21 “https://rizhiyi.com/search/” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0” “10.10.33.174” 0.005 0.001
里面包含的字段:
- Client IP: 180.150.189.243
- Timestamp: 15/Apr/2015:00:27:19 +0800
- Method: POST
- URI: /report
- Version: HTTP/1.1
- Status: 200
- Bytes: 21
- Referrer: https://rizhiyi.com/search/
- User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
- X-Forward: 10.10.33.174
- Request_time: 0.005
- Upstream_request_time:0.001
可見,日志是非結(jié)構(gòu)化文本數(shù)據(jù),如果分析,最好把它轉(zhuǎn)換為結(jié)構(gòu)化數(shù)據(jù)。
上面就是抽取了各個字段,把日志結(jié)構(gòu)化了,結(jié)構(gòu)化之后,統(tǒng)計、分析就很方便了。
二、日志的應(yīng)用場景
1、運維監(jiān)控
包括可用性監(jiān)控和應(yīng)用性能監(jiān)控 (APM)。
2、安全審計
包括安全信息事件管理 (SIEM)、合規(guī)審計、發(fā)現(xiàn)高級持續(xù)威脅 (APT)。
3、用戶及業(yè)務(wù)統(tǒng)計分析
三、過去及現(xiàn)在的做法
1、過去
過去對日志是不夠重視的,比如:
1.1 日志沒有集中處理
◆運維工程師登陸每一臺服務(wù)器,使用腳本命令或程序查看。
1.2 日志被刪除
◆磁盤滿了刪日志,或者日志回滾。
◆黑客入侵后會刪除日志,抹除入侵痕跡。
1.3 日志只做事后追查
◆沒有集中管理、實時監(jiān)控、分析。
1.4 使用數(shù)據(jù)庫存儲日志
后來開始集中管理日志,但使用數(shù)據(jù)庫存儲日志有什么問題?
◆無法適應(yīng)TB級海量日志
◆數(shù)據(jù)庫的schema無法適應(yīng)千變?nèi)f化的日志格式
◆無法提供全文檢索
我見過使用數(shù)據(jù)庫存日志的,數(shù)據(jù)庫就三列:產(chǎn)生日志的服務(wù)器IP、時間戳、日志原文。沒有對日志字段進(jìn)行抽取。如果抽取,不同日志有不同字段,數(shù)據(jù)庫無法適應(yīng),而且,數(shù)據(jù)庫無法提供全文檢索。
2、近年
近年,開始使用Hadoop處理日志,但Hadoop是批處理,查詢慢,不夠及時。Hadoop適合做數(shù)據(jù)離線挖掘,無法做在線數(shù)據(jù)挖掘 OLAP (On Line Analytic Processing)。后來又有Storm、Spark Streaming這些流式處理架構(gòu),延時比Hadoop好不少,但Hadoop/Storm/Spark都只是一個開發(fā)框架,不是拿來即用的產(chǎn)品。也有用各種NoSQL處理日志的,但NoSQL是key-value store,不支持全文檢索。
3、現(xiàn)在
我們需要日志實時搜索分析引擎,它有三個特點:
◆快:
日志從產(chǎn)生到搜索分析出結(jié)果只有幾秒的延時。
Google、百度的新聞搜索也只能搜索5分鐘之前的新聞。
◆大:
每天處理 TB 級的日志量。
◆靈活:
Google for IT, 可搜索、分析任何日志,運維工程師的搜索引擎。
簡而言之,這是Fast Big Data,除了大,還要快。
四、日志搜索引擎
1、日志管理系統(tǒng)的進(jìn)化:

2、日志易:日志實時搜索分析平臺
1.1 可接入各種來源的數(shù)據(jù)
◆可接入服務(wù)器、網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用程序的日志文件,數(shù)據(jù)庫,甚至恒生電子交易系統(tǒng)二進(jìn)制格式的日志。
1.2 企業(yè)部署版及SaaS 版
SaaS版每天500MB日志處理免費,https://www.rizhiyi.com/register/。
五、日志易產(chǎn)品介紹
它的主要功能有:日志搜索、告警、統(tǒng)計、關(guān)聯(lián)分析(關(guān)聯(lián)不同系統(tǒng)的日志)。用戶可以在Web頁面配置解析規(guī)則,抽取任何日志的任何字段,也開放API,對接第三方系統(tǒng),供客戶或第三方二次開發(fā)。
采用了高性能、可擴(kuò)展分布式架構(gòu),可支持20萬EPS (Event Per Second), 每天數(shù)TB日志。
日志易還是個可編程的日志實時搜索分析引擎,用戶可以在搜索框編寫SPL(Search Processing Language,搜索處理語言),使用各種分析命令,通過管道符把這些命令串起來,組成上百行的腳本程序,進(jìn)行復(fù)雜的分析。
這就是李彥宏在云計算剛出現(xiàn)的時候說的“框計算”。給大家看一個例子:某省移動公司做的業(yè)務(wù)分析。
Q & A
Q1:您說的可編程是ES的表達(dá)式?能講一下實現(xiàn)了那些表達(dá)式,我們能做些什么功能?
A1:transaction (事務(wù)關(guān)聯(lián))、eval(算術(shù)表達(dá)式)、stats(統(tǒng)計)、sort(排序)等等。https://www.rizhiyi.com/docs/howtouse/transaction.html 發(fā)布了部分命令的使用指南。
Q2:為什么hadoop不行,這個產(chǎn)品能行,跟ELK有什么區(qū)別?
A2:Hadoop實時性差。ELK功能很有限,權(quán)限管理很差。日志易有非常豐富的用戶分組、日志分組、基于角色的權(quán)限管理。
Q3:請問需要提前對業(yè)務(wù)日志做格式改造嗎?
A3:不需要,用戶在日志易的Web管理頁配置解析規(guī)則,就可以抽取日志的字段了。
Q4:不同日志的怎么關(guān)聯(lián)起來分析嗎?
A4:不同的日志需要有共同的字段,如ID,來做關(guān)聯(lián)。
Q5:權(quán)限管理自己實現(xiàn),用web控制,ES索引控制就好了,還有其他權(quán)限?
A5:主要是哪個人能看哪條日志里的哪個字段,而且要做到很靈活,方便管理,日志易在中國平安有上百用戶在同時使用,幾百種日志,增加一個用戶,他有什么權(quán)限,能看哪些日志,要很方便管理。
Q6:Nosql + spark + Kafka +flume怎么樣?
A6:這還是批處理,而且不支持全文檢索。
Q7:每天6TB的數(shù)據(jù),需要多少個elk的節(jié)點?然后是否需要增加一些ssd來做處理?
A7:取決于服務(wù)器的性能,近百臺服務(wù)器吧,有SSD當(dāng)然更好。
Q8:企業(yè)版數(shù)據(jù)采集,分享一下你們的經(jīng)驗!
A8:企業(yè)版就是部署在客戶的環(huán)境,日志易只提供工具,不碰用戶的數(shù)據(jù)。采集可以使用Linux自帶的rsyslog agent,也可以使用日志易提供的agent,日志易提供的agent可以壓縮、加密,壓縮比1:15。
Q9:是否方便展示一下這個系統(tǒng)的架構(gòu)?
A9:
Q10:你們對es做的改造能實現(xiàn)不同的業(yè)務(wù)數(shù)據(jù)按任意的字段進(jìn)行關(guān)聯(lián)分析嗎?
A10:只要不同業(yè)務(wù)的日志包含了相同的字段,就可以關(guān)聯(lián)分析。
Q11:日志易跟 Splunk 有什么大的區(qū)別?
A11:最大的區(qū)別是Splunk在檢索的時候抽取字段,日志易是在索引之前抽取字段。所以日志易的檢索速度比Splunk快。
Q12:SaaS版的架構(gòu)能介紹下嗎?日志易是如何做到數(shù)據(jù)隔離的?
A12:SaaS環(huán)境下,每個租戶有自己的子域名,各租戶登陸到自己的子域名。內(nèi)部有權(quán)限控制、管理。
Q13:看你們的介紹有使用spark-streaming,那它在系統(tǒng)中是用來做什么功能呢?
A13:抽取字段,把日志從非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)換成結(jié)構(gòu)化數(shù)據(jù)。
Q14:你們和SumoLogic比的區(qū)別或亮點是什么?
A14:SumoLogic有一些功能,如Log Reduce等,日志易還沒有實現(xiàn),SumoLogic是純SaaS,日志易同時支持部署版和SaaS。
陳軍
◆日志易創(chuàng)始人兼CEO
◆擁有17年IT及互聯(lián)網(wǎng)研發(fā)管理經(jīng)驗,曾就職于Cisco、Google、騰訊和高德軟件,歷任高級軟件工程師、專家工程師、技術(shù)總監(jiān)、技術(shù)副總裁等崗位。
◆負(fù)責(zé)過Cisco路由器研發(fā)、Google數(shù)據(jù)中心系統(tǒng)及搜索系統(tǒng)研發(fā)、騰訊數(shù)據(jù)中心系統(tǒng)和集群任務(wù)調(diào)度系統(tǒng)研發(fā)、高德軟件云平臺系統(tǒng)研發(fā)及管理,對數(shù)據(jù)中心自動化運維和監(jiān)控、云計算、搜索、大數(shù)據(jù)和日志分析具有豐富的經(jīng)驗。
◆他發(fā)明了4項計算機(jī)網(wǎng)絡(luò)及分布式系統(tǒng)的美國專利,擁有美國南加州大學(xué)計算機(jī)碩士學(xué)位。
【編輯推薦】
上一篇:優(yōu)秀的運維架構(gòu)師應(yīng)該具備哪些能力?(1)
下一篇:49款頂級開源辦公工具推薦(1)
