需求原因：
平常在維護系統時，突然遇到狀況，需要一台一台登進去看log ，只能靠經驗逐漸縮小範圍來debug , 有時log 量太多，且分散在許多檔案，無法明確看出哪個時間點出問題．我們需要一個集中管理 log 的地方，也幫助往 devops 的趨勢發展，因為如果看log 更方便，RD 和QA會更願意勤勞追蹤問題, 系統運作也可以更透明化．
Graylog 是open source的 log 集中管理平台, 用來搜集,壓縮, index, 和分析來自很多device 的 log 資料；Graylog不會像 Splunk 需要依據使用量付費用買licence，安裝也算方便，很符合我們的需求．
安裝參考：
http://www.itzgeek.com/how-tos/linux/centos-how-tos/how-to-install-graylog2-on-centos-7-rhel-7.html#axzz3hLHT1k83
架構：
input 包含幾種格式，比較特別的是GELF，它是 graylog 自己的 log 格式．Log 資料進來後，開始做一些即時的比對分類（根據我們設定的 rule ），然後送到 Elasticsearch 儲存．
MongoDB 是用來儲存除了 log data 以外的 metadata, 例如：stream rules ．可以想成 web的資料庫. 不會有太大的負擔，graylog 未來也有計畫導入資料庫抽象層，到時就可以使用其他 databases (例如 mysql)去儲存.
與另一套開源的開源工具ELK (Elasticsearch, Logstash, Kibana)做比較：
Logstash 是用來搜集 log 資料，直接送到 Elasticsearch 時 , 需要自己指定 index，還要寫冗長的 filters 去設定時間區間；Graylog 則是會先進行 log 的前處理(壓縮分類等)，還有依照時間順序送到 Elasticsearch 保存．
Kibana 提供 web 介面去呈現 Elasticsearch 裡面的 log 資料. 但它不能再 output 到其他 backend 做分析，也沒有客製化 alert 的功能；這些功能 graylog 都能做到．
實際測試：
我用一些方式對graylog server 進行壓力測試，主要是想看它可以承受一秒鐘多少 log 量，上表中 msgs/sec , process buffer, output buffer, Utilization 的數據都是由 graylog web interface 得到的，%CPU 的數據則是在 linux 下 top 指令獲得．目前實測結果，在還未調整任何參數的狀況下，大概能及時處理每秒 12000 左右的 log 而不會 queue 住．
有一次壓測真的把server 打掛了，主因是連續一小時左右，用每秒3萬多log 轟炸它，後來 JVM 的 Memory/Heap usage 那個長條圖縮不回去，就撐不住了．如果真的用量這麼大而且會持續很久，可以考慮調 processor 的數量或往官方建議的HA 架構設計．
參考資料：
1. 官方網站 https://www.graylog.org/
2. 安裝參考(CentOS) http://www.itzgeek.com/how-tos/linux/centos-how-tos/how-to-install-graylog2-on-centos-7-rhel-7.html#axzz3hLHT1k83
