经常有人在问应该需要哪种架构？要不要使用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等）

以上简单谈了以下两种常见架构，它的使用场景、各层的功能、以及与之相关的一些工具，接下来我会以我们目前使用的架构了逐一讲解。