# 企業級日志解決方案設計  ## 1\. 組件說明 * filebeat：部署在每臺應用服務器、數據庫、中間件中，負責日志抓取與聚合日志 * 日志聚合：把多行日志合并成一條，例如exception的堆棧信息等 * logstash：通過各種filter結構化日志信息，并把字段transform成對應的類型 * elasticsearch：負責存儲和查詢日志信息 * kibana：通過ui展示日志信息、還能生成餅圖、柱狀圖等 ## 2\. ELK常見部署架構 ### 2.1. Logstash作為日志收集器 * 這種架構是比較原始的部署架構，在各應用服務器端分別部署一個Logstash組件，作為日志收集器，然后將Logstash收集到的數據過濾、分析、格式化處理后發送至Elasticsearch存儲，最后使用Kibana進行可視化展示，這種架構不足的是：Logstash比較耗服務器資源，所以會增加應用服務器端的負載壓力 ### 2.2. Filebeat作為日志收集器 * 該架構與第一種架構唯一不同的是：應用端日志收集器換成了Filebeat，Filebeat輕量，占用服務器資源少，所以使用Filebeat作為應用服務器端的日志收集器，一般Filebeat會配合Logstash一起使用，這種部署方式也是目前最常用的架構 ### 2.3. 引入緩存隊列的部署架構 * 該架構在第二種架構的基礎上引入了Kafka消息隊列（還可以是其他消息隊列），將Filebeat收集到的數據發送至Kafka，然后在通過Logstasth讀取Kafka中的數據，這種架構主要是解決大數據量下的日志收集方案，使用緩存隊列主要是解決數據安全與均衡Logstash與Elasticsearch負載壓力 ### 2.4. 以上三種架構的總結 * 第一種部署架構由于資源占用問題，現已很少使用，目前使用最多的是第二種部署架構，至于第三種部署架構個人覺得沒有必要引入消息隊列，除非有其他需求，因為在數據量較大的情況下，Filebeat 使用壓力敏感協議向 Logstash 或 Elasticsearch 發送數據。如果 Logstash 正在繁忙地處理數據，它會告知 Filebeat 減慢讀取速度。擁塞解決后，Filebeat 將恢復初始速度并繼續發送數據