带你领略基于ELK+Kafka的日志分析系统和Elasticsearch运维实践-阿里云开发者社区

开发者社区> 微服务> 正文

带你领略基于ELK+Kafka的日志分析系统和Elasticsearch运维实践

简介: 阿里巴巴高级工程师赵汉青主要从五个方面对Elasticsearch在日志分析场景的应用与运维实践的问题进行详细讲解,分别对Elasticsearch及相关产品介绍、基于ELK+Kafka的日志分析系统、Elasticsearch运维实践、Elasticsearch优化经验以及阿里云Elasticsearch服务几个方面进行了详细的介绍。

阿里巴巴高级工程师赵汉青主要从五个方面对Elasticsearch在日志分析场景的应用与运维实践的问题进行详细讲解,分别对Elasticsearch及相关产品介绍、基于ELK+Kafka的日志分析系统、Elasticsearch运维实践、Elasticsearch优化经验以及阿里云Elasticsearch服务几个方面进行了详细的介绍。
数十款阿里云产品限时折扣中,赶快点击这里,领券开始云上实践吧!
更多Elasticsearch相关信息请点击
直播视频回顾
PPT下载请点击
以下是精彩视频内容整理:

Elasticsearch及相关产品介绍

Elasticsearch是当下非常热门的分布式实时分析搜索引擎,其主要有查询近实时、内存消耗小搜索速度快、可扩展性强以及高可用等特点。Elasticsearch适用于存储文本数据,存储文本数据结构是用到了FST,主要是对词典中单词前缀和后缀的重复利用并压缩存储空间,压缩比率一般在3-20倍之间。查询复杂度一般是O(len(str)),并且范围搜索与前缀搜索比传统的hashmap有明显优势。

1

对于数值型结构采用BKDTree(Block k-d tree)的存储结构,对于数值型数据来说,K=1时为二叉搜索树,查询复杂度是log(N),若K=2,则确定切分维度,切分点选这个维度中间的点。

2

对于Elasticsearch可扩展性主要是通过索引分片机制来实现的,index即为索引,每个index下面又分为n个shard,真正的数据以doc的形式存储在每个shard中。Elasticsearch的高可用主要是通过shard冗余备份、跨可用区域部署以及数据快照等方式来实现的,并能够应对集群节点故障和数据损坏。
除对于Elasticsearch以外还有一些非常优秀的产品,例如Kibana,其注重的是数据可视化以及与Elasticsearch的交互。Logstash偏向与数据收集、过滤和转换。Beats是一系列比Logstash更灵巧的工具,例如Filebeat、Metricbeat、Packetbeat、Winlogbeat等。

基于ELK+Kafka的日志分析系统

3

产线日志通过kafka传到ELK集群中,在产线数据收集时推荐使用filebeat与logstash。在ELK集群中主要有三种node,第一个是data node,其下面部署了logstash与Elasticsearch,起作用是消费kafka中的认知数据,将其存储到Elasticsearch设计中。Web node部署了kibana和Elasticsearch,主要是通过kibana访问Elasticsearch的数据,master node主要是安装了Elasticsearch,一般需要奇数个master node。

Logstash的优点

主要的特点是提供了大量的用于数据过滤、转换的插件,比较常用的有以下几种:

  • drop:其作用是丢掉不需要的数据。
  • grok:其作用是正规匹配抓取数据中想要的数据串。
  • date:其作用是从数据中解析date属性,用作Elasticsearch document的timestamp。
  • metrics:其作用是获取logstash的metrics。
  • codec.multiline:其作用是使多行数据合成一条记录。
  • fingerprint:可以防止插入重复的数据。
  • Logstash缺点:收集log效率低,并且耗资源。
  • Filebeat:弥补了Logstash缺点,但自身插件较少,所以一般情况下将Logstash与filebeat结合使用。

为何使用Kafka进行日志传输?

使用Kafka进行日志传输的原因在于其有数据缓存的能力,并且它的数据可重复消费,Kafka本身具有高可用性,能够很好的防止数据丢失,它的throughput相对来说比较好并且使用广泛。实践经验表明,在产线上收集数据时不同的service尽量创建不同的topic,然后根据service的日志量设定topic partition的个数,按照Kafka partition的个数和消费该topic的logstash的个数配置consumer_threads,尽量明确logstash和对应消费的topic,进而配置消费的topic少用通配符。
进行集群规划时需要考虑一些问题,例如总数据量的大小,每天流入多少数据量,保存多少天数据;以及单节点的配置,每个节点多少个索引和shard,每个shard大小控制在多少等问题,根据总数据量和单节点配置,得出集群总体规模。

问题分析1

每日增加的数据量等同于每日新增的log量*备份个数,如果enable了_all字段,则在上面的基础上再翻一倍。这样一来若每天新增1T的log,每个shard有一个备份,再开一个enable_all的话,则Elasticsearch的集群的实际数据增加量与等于4T。如果每天需要存4T数据,假如数据保存30天,则需要的最低存储是120T,并且一般还会加20%的buffer,那么也就需要准备144T的存储空间。根据日志场景的特点可做hot-node与warm-node的划分,hot-node通常采用SSD磁盘来增加查询效率,而warm-node则采用普通机械磁盘来降低集成成本。

问题分析2

单节点上根据经验CPU与Memory的配比通常是1:4,Memory与Disk的配比是1:24,Elasticsearch heap的xmx设置通常不大于32g,Memory与shard的配比通常在1:20到1:25之间,并且每个shard的大小建议不要超过50g,这样集群才能保证健康的运行。

案例分析

产线上出现服务failover时,backup集群日志量会忽然增大,Kafka里的数据量也会突然增多,单位时间内logstash消费Kafka注入Elasticsearch的数据量也会增大。如果某些正在插入数据的primary shard集中在一个node上,该node会因为需要索引的数据量过大,同时响应多个logstash bulk请求等因素,导致该node的Elasticsearch服务过于繁忙。
若无法响应master节点发来的请求,master节点会因为等待该节点的响应而被block,导致其他节点认为master节点丢失,从而触发一系列非常反应,比如重选master。
若无法及时响应logstash的请求,logstash connect elasticsearch便会出现timeout,logstash会将这个Elasticsearch认成dead,同时不再消费Kafka。Kafka发现在同一个consumer group里面某个consumer消失了,便会触发整个consumer group做rebalance,从而影响别的logstash的消费,进而影响到整个集群的吞吐量。

典型羊群效应

要消除头羊带来的影响,可通过Elasticsearch API定位比较忙的节点,根据queue的大小以及rejected请求的不断增加的个数来判断哪个node是比较忙的,然后通过GET/_cat/shard找到该node上活跃的shard,最后再通过POST/_cluster/reroute API把shard移到load比较低的node上,缓解该node的压力。

Elasticsearch运维实践

运维Elasticsearch集群主要关注一下几个方面:

  1. 集群健康状态。
  2. 集群索引和搜索性能。
  3. 节点CPU、memory以及disk的使用情况。
    集群健康状态分为三种,集群green代表健康,集群yellow主要是有replica shard未分配,但不影响集群正常使用,集群red主要是因为有primary shard未分配,会影响集群正常使用。主要原因是集群node disk使用率超过默认值85%,这样一来新的shard就无法分配。这种情况可以通过以下方式查看:
  • 通过api GET/_cat/allocation查看node的磁盘使用率。
  • 通过api GET/_cluster/settings查看
    cluster.routing.allocation.enable是否被禁止。
  • 通过api GET/¬_cluster/allocation/explain?pretty查看shard未分配到node的具体原因。

Elasticsearch优化经验

对于索引优化可以提前创建索引,避免索引稀疏,index中的document结构最好保持一致,如果document结构不一致,建议分index,用一个少量shard的index存放field格式不同的document。在加载大量数据使refresh_interval=-1,index.number_of_replicas=0,索引完成后再设回来。Laod和IO压力不大的情况下,用bulk比单条的PUT/DELETE操作索引效率更高。调整index buffer的大小,若不需要field的打分,则可以禁用norms;同样的若不需要sort或aggregate的field,则可以把doc_value属性禁用。
对于查询优化可以使用routing提升一维度数的查询速度;通过limit限制,避免返回太大量的搜索结果集;如果heap压力不大,可适当增加node query cache;增加shard备份可提高查询并发能力,但要注意node上的shard总量;最后是定期合并segment。

阿里云Elasticsearch服务

x-pack

4

Security提供了Elasticsearch数据的访问的权限管理,可以为不同的人创建不同的账号,对不同的账号赋予不同的权限,这样可以保证不同的团队在同一个ELK系统下数据访问的安全性。

阿里云Elasticsearch性能

5

Elasticsearch选用5.5.3的版本,每个测试集群有三个节点,分别对2核4G、4核16G和16核64G进行了测试,磁盘选用1T的SSD云盘。压测工具是是由阿里云提供的esrally和rest api,esrally官方数据geonames为3.3GB,单doc为311B,模拟某业务日志数据80GB,单doc为1432B。阿里云自身也提供过了云监控服务、报警服务、Elasticsearch日志的可视化以及节点扩容。

大家如果有任何需求与咨询可以点击链接提交:
https://market.tianchi.aliyun.com/outsource/offer/publish.htm?type=PROJECT

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
微服务
使用钉钉扫一扫加入圈子
+ 订阅

构建可靠、高效、易扩展的技术基石

其他文章