ELK實戰一:架構的選擇

常常有人在問應該須要哪一種架構？要不要使用redis、kafka？它們是怎麼的結構去工做的？ELK分別起到了什麼做用？接下來根據個人使用經驗談一下目前最多見的兩種架構，基本知足於90%以的場景，若有錯誤之處，還望請指正！

1、數據量小，且數據可靠性要求不強（容許ELK故障時丟失數據）的公司

架構以下:

Logstash -> Elasticsearch -> Kibana

• 收集客戶端: rsyslog/heka/flume/logstash/fluent都行，在這個階段，客戶端收集性能不須要過多的考慮，* 均可以知足，看本身的喜愛，值得說的是這樣的架構規模因數據量不大，客戶端此時能夠作解析、過濾日誌處理後再入到elasticsearch，前提是必定要保證客戶端不能影響到生產環境的業務穩定性。不保證收集客戶端的可靠性，可經過 supervisor/monit等工具作守護，添加監控

• 數據存儲、搜索: elasticsearch 配置默認便可知足，至於分片複本默認均可以，視數據重要性決定是否添加複本，若是添加，最多一個複本足矣（添加複本性能降低很大，規模不大，這個問題應該不會出現）

• 數據展現: kibana 能夠根據ES的數據作各類各樣的圖表來直觀展現業務實時情況

2、數據量大，且數據不容許丟失，實時、穩定性要求高的公司

架構以下:

Logstash -> Kafka -> Logstash -> Elasticsearch -> Kibana

• 收集客戶端: 選型上，在上面基礎之上同上，在這裏就不能像小規模時的在客戶端作大量的數據處理了，儘可能收集最原始數據給kafka或redis，因數據量達到必定程度，客戶端因數據處理策略會體現出壓力過大，從而會影響到生產環境業務
  的穩定性

• 隊列: 可選擇redis/kafka這類的隊列工具，優選kafka，因它的分佈式、高可用性、大吞吐的特性，它保證了在高併發下即便ES集羣故障,在故障恢復後數據仍可追加;從數據客戶端收集的原始日誌寫入到kafka，可供各類應用消費

• 數據處理: 可選用logstash/hangout/rsyslog等，優選hangout，性能較logstash好，功能是仿照logstash作的，大部分需求可知足，在這層作數據的解析、過濾等，好比geoip、useragent、json格式化、字段切割/拼接等，按天索引寫入elasticsearch（索引建議提早一天以上創建，減小整點自動創建時的高負載），使用curator作定時關閉、刪除N天前的索引，若有多索引查詢，還可使用此工具作alias來方便多索引聯合查詢。

• 數據存儲、搜索: elasticsearch集羣，考慮多分片一複本最佳，根據數據大小與搜索頻度來調整分片數量，創建索引命名規範，相同類型數據統一創建即mapping模板，添加如bigdesk\marvel\head\kopf這樣的監控工具來長期分析性能並調優

• 數據展現: kibana 根據ES數據作圖表，使用elasticdump工具定時備份.kibana索引數據（.kibana是kibana的默認索引名稱，裏面包含了全部kibana中的配置，如圖表、搜索、設置、index pattern等）

以上簡單談了如下兩種常見架構，它的使用場景、各層的功能、以及與之相關的一些工具，接下來我會以咱們目前使用的架構了逐一講解。