由於身處的公司有 21 年的歷史，所以我每天都在和技術債搏鬥，這次的對手是分散到各地殘缺不全的 Log，每當要查記錄的時候就要東找找，西找找花了一堆時間才能拼湊出全貌 …
簡述有幾種類型的 Log：
- 系統 Log：在 Linux 內的各種 syslog、audit …。
- 應用程式 Log：Apache、Nginx、Tomcat …。
- 自定義 Log：除了原本的 Log 以外還特別寫出來利於 debug 或是分析使用的 Log。
- 網路設備 Log：VPN、Load Balance
然後因為公司是 Hybrid Cloud 的架構，所以又分為 AWS / IDC 簡直苦不堪言 … 還記得上次去 AWS reinvent 2017 看到最多的廠商就是整合 AWS Log 的 SaaS 服務，AWS 目前在這塊真的不是很友善阿，雖然有 Elasticsearch 的服務，但是既不彈性又貴！
講到 Log 服務大概就不能忘記 elastic 這家公司，說到 ELK 大家耳熟能詳阿！！就 Log 界來說 elastic 也算是王者了，但是能把整個 elastic 產品線兜的很完善也不是一件容易的事情，我記得之前某一家邀請我面試的公司有提到，他們有一個部分是在負責 ELK 分析的，elastic 玩不好很容易就變狗熊。
講到 ELK 除了 elastic 官方文件以外，我還推薦大家可以去看 logz.io 這家公司的 Blog (不是業配啦)，logz.io 是專門做 elastic 服務整合的，提供 SaaS 平台直接使用，這間也是在 AWS reinvent 2017 遇到的廠商，有許多技術文章可以參考。
進入正題 … 這篇要講的是架構大補帖，只講架構，不談細節
傳統大家都知道 ELK，ELK 就是由 Elasticsearch + Logstash + Kibana 組成而成名，不過隨著時代的變遷開始有一些架構上的改變
由於 Logstash 的 Java 效能一直被垢病，尤其是安裝在 Production 的機器還沒跑服務就被吃掉一塊資源，不是很好 … 當時 Golang 開始流行，所以 elastic 就用 Golang 重寫了 logstash-forwarder 用的還是自家開發的 lumberjack protocol，不過用了沒有很久，就出現 Filebeat 取代 logstash-forwarder
因為是用 Golang 開發的，所以安裝在 Server 上的效能大幅提昇，但是 Golang 畢竟是新語言，對於舊 OS 的支援度不好，像是 CentOS 5 就沒辦法用，然後就出現 Filebeat + Logstash 並行的架構。
中間再放一層 Logstash 的原因是 filebeat 目前還是只能拿來收 Log 比較好用，比較複雜的 index、filter pattern、output、input 還是讓 Logstash 來處理會比較好。
如果沒有技術債，你就可以盡情的拋棄 Logstash 安裝在 Production 機器的煩惱，除了 filebeat 以外還有一堆很厲害的 beat 系列工具，例如 Metricbeat 收集 system loading、Packetbeat 收集網路封包。
如果你的架構過於龐大，並且 Log 一筆都不能遺失，那麼上述兩者的架構就不符合需求了，前面有說 Logstash 的效能並沒有這麼好，當他忙起來的時候會沒辦法接收 input，雖然 filebeat 有重送的機制，但是遇到 Production 機器上剛好跑 logrotate 的話就 GG 了，還沒送到 Logstash 就被壓起來了 …
為了避免悲劇發生，就要讓 Log 不管忙不忙隨時隨地都要能被寫入廢話，可以在中介做一些手腳 … 例如 Kafka、Redis、RabbitMQ。
不管後端 Logstash 忙不忙，都先送到 Redis 就對了，等到後端 Logstash 開始有空再把 Redis 還未歸檔的資料抓出來，然後就可以針對 Redis 做監控，如果超過一定的筆數就是後端的 Logstash 處理不來啦，準備該加機器囉。
至於中介的服務要用哪一個來接，我個人比較建議用 Redis 畢竟是 in memory，所以會比較快，可以減輕前端服務的等待，愛好 kafka 或是 RabbitMQ 也行，只要用的順手就好
以上三種提供參考，後續大概會有更多關於 elastic 的文章雷可以分享。