Splunk初體驗——像Google那樣搜索你的數據

Splunk是啥？

Splunk是日誌/流式數據領域中作的最好的商業軟件實現，它的核心能力只有一個：

像Google那樣搜索企業內部全部產生的日誌

這個的威力很是大，如今的企業不缺數據，缺的是有效挖掘數據的能力。而顯然大部分企業沒有Google的能力去作搜索，因而Splunk提供這樣的能力。與之相競爭的開源實現有Logstash。

Splunk ≈ Logstash
Logstash = Redis(傳輸) + ElasticSearch(搜索) + Kibana(展示)
ElasticSearch = Lucene + Search

那麼，哪裏能夠買到呢？##

Splunk官網上有，我就不替他們作廣告了，總之，很貴，一萬美圓能買1G的流量天天。言歸正傳，我仍是分析一下這個玩意兒的一些功能特性吧。

首先，Splunk有一個很炫酷的界面

能夠看到，Splunk的主要使用方式就是那個搜索框，在裏面輸入一種叫作SPL的搜索語言，就能獲取到你想要的各類信息了。Splunk能在後臺對數據進行過濾、聚合、統計，最後獲得各類報表、圖像

SPL是一種向SQL致(chao)敬(xi)的語言，語法很是的相似，不一樣的是，SPL搜索的不是關係數據庫，而是輸入到Splunk系統中全部的日誌數據，如下是幾個具體的案例：

能夠看到，對於一行SPL搜索語句

sourcetype = syslog ERROR | top user | fields - precent

Splunk是這麼幹的，

1. 首先從硬盤上搜索字段sourcetype（來源類型）爲syslog的日誌，同時，在日誌中含有ERROR這個關鍵字的。
2. 經過管道符，把上面的搜索結果根據user字段作聚合，取出其中出現次數最多的前10個
3. 再經過管道符，去掉百分比字段，最後得出結果

最後看到，這個搜索幹了什麼事情呢？它一會兒就把日誌中出錯最多的前十個用戶給統計出來了，這樣後續程序員就能跟蹤這些錯誤爲何產生，而後着手去解決。

| where distance/time > 100

使用where，對日誌中兩個字段進行相除後比較。

來龍去脈架構圖

Splunk主要作了3件事

1. 解析原始日誌格式，分解成有意義的字段，有的 log 收集方案在第一階段就解析日誌只發送關心的字段，以節省帶寬。
2. 根據時間戳，request ID，session ID，user ID 等關聯日誌條目，以儘可能清晰當時各個子系統的狀態；
3. 根據分析的目的作過濾、聚合、統計等等，最後整一份漂亮的報表出來。

Splunk出彩的特性是……

1. WEB的UI很出色，插件式的，把這個作成了一個平臺，容許不少第三方的公司在上面發佈應用。
2. 搜索語法強大，例如查找HTTP 503錯誤近期的出現頻率，例如某一個地區用戶訪問最多的商品列表，例如頁面訪問量排名。基本上，你能想到的能夠由SQL完成的搜索，SPL都可以作出來。
3. 自動猜想一些日誌的字段，同時能夠在Web上手動調整怎麼解析源頭日誌。
4. 以上全部操做，都能由掌握SPL語言的非程序員來完成，也就是說Splunk能夠由產品經理或者運營團隊來操控。並且還能把數據可視化作出來。
5. 流式搜索，實時過濾日誌而後報警，這個對運維團隊頗有用。

以上幾點，就決定了Splunk的市場很是的大，這家公司的概念是流式數據領域的數據倉庫，2012在納斯達克上市，不過這兩年被人作空，股票大跌。由於不少雲計算廠商都能提供這種服務，例如阿里雲1MB/S都是免費的。

競品分析 —— Logstash, Kafka##

###Splunk vs Logstash###

Logstash是個開源的日誌搜索工具，也是一體化的開箱即用的產品。基本上，能實現Splunk六成的功力。Web沒有那麼強，也沒有SPL這樣簡單的語言，ElasticSearch須要經過Json來查詢，Kibana的搜索語句能力有限。目前能夠說Logstash這個項目還在成熟期。須要後續不少的工做才能作好。

###Splunk vs Kafka ###

這麼比較其實不是很公平。

Kafka只解決了日誌的統一搜集、傳輸、序列化存儲問題。Splunk作的更多些，還作了數據索引的深加工。

同時，Kafka須要在源頭使用schema來定義數據格式，嚴格，有利於後期的消費程序使用。

Splunk卻對源頭數據要求沒有那麼高，對現有系統改動小，由於是個企業軟件，須要追求兼容性。

從高可用方面來看，Splunk目前尚未一天蒐集幾個T的數據的案例，Kafka在這方面的能力絕對沒有問題。

Kafka是個比較好的車身框架，但還缺一個強大的發動機和很多內飾；Splunk是一輛功能完善的車子，就是價格很貴，並且沒有在150碼以上開過的案例。

因此，對於Kafka，可能的整體解決方案有：

Kafka + YARN + Hadoop = Samza(Linkin) 
Kafka + Strom + MySQL
Kafka + ElasticSearch + Kibana

To be continued...##

Splunk和Logstash能夠說是日誌處理領域較爲成功的商業和開源產品了

—— 可是，我認爲對於雲計算廠商來說，還有兩個產品能夠作分析，那就是2014年開始有的阿里雲的簡單日誌服務SLS，以及亞馬遜的Amazon kinesis。

欲知後事如何，且聽下回分解 ~~

主要參考文章

探索 Splunk ，搜尋處理語言 (SPL) 入門和操做手冊 —— 繁體的技術手冊，估計是Splunk找臺灣人翻譯的吧

ElasticSearch 權威指南 —— 上海的一家互聯網公司，作EverMemo和食色的那家，的某位員工翻譯的

訪談與書評：《LogStash，使日誌管理更簡單》 —— 英文原書要9刀，做者窮瘋了……仍是看看評論吧

次要參考文章

《經過 ElasticSearch 進行可伸縮搜索》

《使用logstash+elasticsearch+kibana快速搭建日誌平臺》

《LogStash日誌分析系統》

《logstash VS splunk》