ELK实战一:架构的选择

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

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

文章目录
  1. 1. 一、数据量小,且数据可靠性要求不强(允许ELK故障时丢失数据)的公司
  2. 2. 二、数据量大,且数据不允许丢失,实时、稳定性要求高的公司
,