陳軍
日志易創始人兼ceo
擁有17年it及網際網路研發管理經驗，曾就職于cisco、google、騰訊和高德軟體，曆任進階軟體工程師、專家工程師、技術總監、技術副總裁等崗位。
負責過cisco路由器研發、google資料中心系統及搜尋系統研發、騰訊資料中心系統和叢集任務排程系統研發、高德軟體雲平台系統研發及管理，對資料中心自動化運維和監控、雲計算、搜尋、大資料和日志分析具有豐富的經驗。
他發明了4項計算機網絡及分布式系統的美國專利，擁有美國南加州大學計算機碩士學位。
演講實錄
目錄：
it 運維分析（it operation analytics）
日志的應用場景
過去及現在的做法
日志搜尋引擎
日志易産品介紹
一it 運維分析
1、it 運維分析
1.1 從 it operation management (itom) 到 it operation analytics (itoa)
it運維分析，即it operation analytics，簡稱itoa，是個新名詞。以前it運維是itom，it operation management ，it 運維管理。這兩年大資料技術開始普及，把大資料技術應用于it運維，通過資料分析提升it運維效率與水準，就是itoa。
1.2 大資料技術應用于it運維，通過資料分析提升it運維
itoa主要用于：
可用性監控
應用性能監控
故障根源分析
安全審計
1.3 gartner估計，到2017年15%的大企業會積極使用itoa；而在2014年這一數字隻有5%。
2、itoa的資料來源有以下四個方面：
1.1 機器資料（machine data）：是it系統自己産生的資料，包括用戶端、伺服器、網絡裝置、安全裝置、應用程式、傳感器産生的日志，及 snmp、wmi 等時間序列事件資料，這些資料都帶有時間戳。機器資料無所不在，反映了it系統内在的真實狀況，但不同系統産生的機器資料的品質、可用性、完整性可能差别較大。
1.2 通信資料（wire data）：是系統之間2~7層網絡通信協定的資料，可通過網絡端口鏡像流量，進行深度包檢測 dpi（deep packet inspection）、標頭取樣 netflow 等技術分析。一個10gbps端口一天産生的資料可達100tb，包含的資訊非常多，但一些性能、安全、業務分析的資料未必通過網絡傳輸，一些事件的發生也未被觸發網絡通信，進而無法獲得。
1.3 代理資料（agent data）：是在 .net、php、java 位元組碼裡插入代理程式，從位元組碼裡統計函數調用、堆棧使用等資訊，進而進行代碼級别的監控。但要求改變代碼并且會增加程式執行的開銷，降低性能，而且修改了使用者的程式也會帶來安全和可靠性的風險。
1.4 探針資料（probe data），又叫合成資料（synthetic data）：是模拟使用者請求，對系統進行檢測獲得的資料，如 icmp ping、http get等，能夠從不同地點模拟用戶端發起，進行包括網絡和伺服器的端到端全路徑檢測，及時發現問題。但這種檢測并不能發現系統為什麼性能下降或者出錯，而且這種檢測是基于取樣，并不是真實使用者度量（real user measurement）。
擁有大量用戶端的公司，如bat，會直接在用戶端度量系統性能，做real user measurement，通常不需要模拟使用者檢測。
3、itoa 四種資料來源使用占比
美國某itoa公司的使用者調研發現，使用這四種不同資料來源的比例為：machine data 86%, wire data 93%, agent data 47%, probe data 72%。這四種資料來源各有利弊，結合在一起使用，效果最好。
4、日志：時間序列機器資料
通常結合日志與網絡抓包，能夠覆寫大部分it運維分析的需求。日志因為帶有時間戳，并由機器産生，也被稱為時間序列機器資料。
它包含了it系統資訊、使用者資訊、業務資訊。
日志反映的是事實資料：linkedin（領英）是非常著名的職業社交應用，非常重視使用者資料分析，也非常重視日志。
它的一個工程師寫了篇很有名的文章：
“the log: what every software engineer should know about real-time data's unifying abstraction”, jay kreps, linkedin engineer
linkedin的使用者資料挖掘基于日志，公司内部有專門的部門處理所有的日志，各子產品的日志都被采集，傳送到這個部門。
著名的開源消息隊列軟體kafka就是linkedin開發，用來傳輸日志的。
以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
可見，日志是非結構化文本資料，如果分析，最好把它轉換為結構化資料。
上面就是抽取了各個字段，把日志結構化了，結構化之後，統計、分析就很友善了。
二日志的應用場景
1、運維監控：
包括可用性監控和應用性能監控 (apm)
2、安全審計：
包括安全資訊事件管理 (siem)、合規審計、發現進階持續威脅 (apt)
3、使用者及業務統計分析
三過去及現在的做法
1、過去
過去對日志是不夠重視的，比如：
1.1 日志沒有集中處理
運維工程師登陸每一台伺服器，使用腳本指令或程式檢視
1.2 日志被删除
磁盤滿了删日志，或者日志復原
黑客入侵後會删除日志，抹除入侵痕迹
1.3 日志隻做事後追查
沒有集中管理、實時監控、分析
1.4 使用資料庫存儲日志
後來開始集中管理日志，但使用資料庫存儲日志有什麼問題？
無法适應tb級海量日志
資料庫的schema無法适應千變萬化的日志格式
無法提供全文檢索
我見過使用資料庫存日志的，資料庫就三列：産生日志的伺服器ip、時間戳、日志原文。沒有對日志字段進行抽取。如果抽取，不同日志有不同字段，資料庫無法适應，而且，資料庫無法提供全文檢索。
2、近年
近年開始使用hadoop處理日志，但hadoop是批處理，查詢慢，不夠及時。hadoop适合做資料離線挖掘，無法做線上資料挖掘 olap (on line analytic processing)。後來又有storm、spark streaming這些流式處理架構，延時比hadoop好不少，但hadoop/storm/spark都隻是一個開發架構，不是拿來即用的産品。也有用各種nosql處理日志的，但nosql是key-value store，不支援全文檢索。
3、現在
我們需要日志實時搜尋分析引擎，它有三個特點：
快：
日志從産生到搜尋分析出結果隻有幾秒的延時
google、百度的新聞搜尋也隻能搜尋5分鐘之前的新聞
大：
每天處理 tb 級的日志量
靈活：
google for it， 可搜尋、分析任何日志，運維工程師的搜尋引擎
簡而言之，這是fast big data，除了大，還要快。
四日志搜尋引擎
1、日志管理系統的進化：
2、日志易：日志實時搜尋分析平台
1.1 可接入各種來源的資料
可接入伺服器、網絡裝置、作業系統、應用程式的日志檔案，資料庫，甚至恒生電子交易系統二進制格式的日志。
1.2 企業部署版及saas 版
saas版每天500mb日志處理免費
五日志易産品介紹
它的主要功能有：日志搜尋、告警、統計、關聯分析（關聯不同系統的日志）。使用者可以在web頁面配置解析規則，抽取任何日志的任何字段，也開放api，對接第三方系統，供客戶或第三方二次開發。
采用了高性能、可擴充分布式架構，可支援20萬eps (event per second), 每天數tb日志。
日志易還是個可程式設計的日志實時搜尋分析引擎，使用者可以在搜尋框編寫spl（search processing language，搜尋處理語言），使用各種分析指令，通過管道符把這些指令串起來，組成上百行的腳本程式，進行複雜的分析。
這就是李彥宏在雲計算剛出現的時候說的“框計算”。給大家看一個例子：某省移動公司做的業務分析↓
q & a
q1：您說的可程式設計是es的表達式？能講一下實作了那些表達式，我們能做些什麼功能？
a1：transaction (事務關聯）、eval（算術表達式）、stats（統計）、sort（排序）等等。https://www.rizhiyi.com/docs/howtouse/transaction.html 釋出了部分指令的使用指南。
q2：為什麼hadoop不行，這個産品能行，跟elk有什麼差別？
a2：hadoop實時性差。elk功能很有限，權限管理很差。日志易有非常豐富的使用者分組、日志分組、基于角色的權限管理。
q3：請問需要提前對業務日志做格式改造嗎？
a3：不需要，使用者在日志易的web管理頁配置解析規則，就可以抽取日志的字段了。
q4：不同日志的怎麼關聯起來分析嗎？
a4：不同的日志需要有共同的字段，如id，來做關聯。
q5：權限管理自己實作，用web控制，es索引控制就好了，還有其他權限？
a5：主要是哪個人能看哪條日志裡的哪個字段，而且要做到很靈活，友善管理，日志易在中國平安有上百使用者在同時使用，幾百種日志，增加一個使用者，他有什麼權限，能看哪些日志，要很友善管理。
q6：nosql + spark + kafka +flume怎麼樣？
a6：這還是批處理，而且不支援全文檢索。
q7：每天6tb的資料，需要多少個elk的節點？然後是否需要增加一些ssd來做處理？
a7：取決于伺服器的性能，近百台伺服器吧，有ssd當然更好。
q8：企業版資料采集，分享一下你們的經驗！
a8：企業版就是部署在客戶的環境，日志易隻提供工具，不碰使用者的資料。采集可以使用linux自帶的rsyslog agent，也可以使用日志易提供的agent，日志易提供的agent可以壓縮、加密，壓縮比1：15。
q9：是否友善展示一下這個系統的架構？
a9：
q10：你們對es做的改造能實作不同的業務資料按任意的字段進行關聯分析嗎？
a10：隻要不同業務的日志包含了相同的字段，就可以關聯分析。
q11：日志易跟 splunk 有什麼大的差別？
a11：最大的差別是splunk在檢索的時候抽取字段，日志易是在索引之前抽取字段。是以日志易的檢索速度比splunk快。
q12：saas版的架構能介紹下嗎？日志易是如何做到資料隔離的？
a12：saas環境下，每個租戶有自己的子域名，各租戶登陸到自己的子域名。内部有權限控制、管理。
q13：看你們的介紹有使用spark-streaming，那它在系統中是用來做什麼功能呢？
a13：抽取字段，把日志從非結構化資料轉換成結構化資料。
q14：你們和sumologic比的差別或亮點是什麼？
a14：sumologic有一些功能，如log reduce等，日志易還沒有實作，sumologic是純saas，日志易同時支援部署版和saas。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2015-12-18</b>