長期以來公司蒐集 Log 的方式都是使用 ELK 來達成 Log 的收集和分析，最近開始評估商業版本的 Splunk 作為比較，這篇純粹
資料收集方式
- Elasticsearch / Splunk 都有自己的 Forwarder agent，Splunk 針對比較舊的 OS 系統(像是 CentOS 5) 必須要找原廠要舊版 (官網並不會保存所有版本的 Forwarder agent)
- 承1. 兩者都有支援相同的 Input Protocol，所以也能共用 Forwarder，像是拿 Logstash / Filebeat 來取代之類的。
ETL (資料正規化) 執行差異
Elasticsearch 的 ETL 通常是在 Logstash 進行 ETL (通常是用 filter 先切好再 Output elasticsearch)
Splunk 的 ETL 是先 Log 收到 Splunk 後再做 ETL
《ETL 差異比較》
- Elasticsearch 先做 ETL 缺點是當 data filed 要改變時，所有資料都必須 rebuild 重新推進 Elasticsearch，所以資料的備份需要保留 raw data。
- Splunk 後做 ETL 優點是儲存在 Splunk 的資料就是 raw data，隨時可以重做 ETL，這塊設計非常彈性。
raw data 資料儲存空間
- Elasticsearch 是以 ETL 後的資料大小為主。
- Splunk 儲存後還會再進行壓縮，號稱可以減少 30% 左右的資料大小。
Log 收集後的應用
- Elasticsearch 大多利用 Kibana 畫圖，或是直接打 API 撈出來客製化，但商業應用要手刻的部份會比較多。
- Splunk 提供各種商業應用的 Plugin (當然有些要錢)，像是 ML … 。
費用比較
- Elasticsearch 除了 X-Pack 功能以外都是 Open Source，採用 Apache 2.0 License。
- Splunk 是以資料量計費，by GB / Month
ELK vs. Splunk 總評
兩者的比較 Splunk 除了價格以外都算是「大勝」，尤其 Splunk 的強項在於收集 Data 後的應用 Plugin 很齊全，幾乎可以讓你用很簡單的方式實現商業應用，對於財力龐大的金融業、電訊業是很常用的解決方案。
值得一提的是 Splunk ETL 的設計真的不錯，Elasticsearch 遇到 filed data 變更的時候 rebuild data 真的很煩，如果 Elasticsearch 要與 Splunk 抗衡，ETL 的方法應該調整一下。
最後，如果資料量很大，有一點預算，但又無法花大錢買 Splunk 的話，也許可以考慮以 Elasticsearch 為 Log Provider，再由 Splunk 將 Elasticsearch 整理好的 Data 進行後續商業應用。
