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

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