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

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

架構如下:

Logstash -> Elasticsearch -> Kibana

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

• 數據存儲、搜索: elasticsearch 配置默認即可滿足，至于分片復本默認都可以，視數據重要性決定是否添加復本，如果添加，最多一個復本足矣（添加復本性能下降很大，規模不大，這個問題應該不會出現）

• 數據展示: kibana 可以根據ES的數據做各種各樣的圖表來直觀展示業務實時狀況

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

架構如下:

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等）

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