专栏首页大数据成神之路Elasticsearch在日志分析领域应用和运维实践

Elasticsearch在日志分析领域应用和运维实践

By 大数据技术与架构

场景描述:Elasticsearch及相关产品,介绍基于ELK + Kafka 的日志分析系统,Elasticsearch优化经验,阿里云 Elasticsearch服务以及Elasticsearch 运维实践。

关键词:ELK 运维 优化

本次分享是由来自阿里巴巴的高级工程师赵汉青带来的。主要讲述了:

  • 基于ELK + Kafka 的日志分析系统
  • Elasticsearch 优化经验
  • Elasticsearch 运维实践

ElasticSearch介绍

分布式实时分析搜索引擎,优点包括:

  • 查询近实时
  • 内存消耗小,搜索速度快
  • 可扩展性强
  • 高可用

数据结构

  • FST(Finite State Transducer)

这种数据结构适用于文本查询。通过对词典中单词前缀和后缀的重复利用,压缩存储空间,压缩比率一般在 3~20 倍之间。O( len ( str )) 的查询时间复杂度。范围搜索,前缀搜索比传统的 hashmap 有明显优势。

  • BDK Tree

适用于数值型,地理信息( geo )等多维度数据类型。当K=1, 二叉搜索树,查询复杂度 log(N)

K=2, 确定切分维度,切分点选这个维度的中间点

扩展性

通过索引分片机制,实现集群的横向扩展

高可用

通过shard冗余备份,跨可用区部署,数据快照 (snapshot) 。应对集群节点故障,数据损坏。

ElasticSearch全家桶

Kibana : 数据可视化,与 elasticsearch 交互。Elasticsearch: 存储,索引,搜索。Logstash: 数据收集,过滤,转换。Beats: 比 logstash 更轻巧 , 更多样化 : Filebeat, Metricbeat, Packetbeat, Winlogbeat …

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

Logstash优点

提供了大量的用于数据过滤,转换的插件 drop: 丢掉不需要的数据 grok : 正则匹配抓取数据 date : 从数据中解析date属性,用作 Elasticsearch document 的 timestamp metrics: 获取 logstash 的 metrics codec.multiline :多行数据合成一条记录 fingerprint : 防止插入重复的数据

Logstash 缺点:收集 log 效率低,耗资源。Filebeat: 弥补的缺点,但自身插件较少。

使用Kafka进行日志传输

Kafka 有数据缓存能力。Kafka 数据可重复消费。Kafka 本身高可用,防止数据丢失。Kafka 的 throughput 更好。Kafka 使用广泛。

实践经验:不同的 service ,创建不同的 topic 。根据 service 的日志量,设定 topic partition 个数。按照 kafka partition 的个数和消费该 topic 的 logstash 的个数,配置 consumer_threads。尽量明确 logstash 和对应消费的 topic ( s) ,配置消费的 topic 少用通配符。

集群规划的基本问题:

1. 总数据量大小:每天流入多少数据,保存多少天数据。

每日增加的数据量:每日新增的 log 量 * 备份个数 。

如果 enable 了 _ all 字段,则在上面的基础上再翻一倍。比如每天新增 1T 的 log ,每个 shard 有 1 个备份, enable_all ,则 Elasticsearch 集群的实际数据增加量约等于 4T 。

如果每天需要存 4T 数据,假如保存 30 天的数据,需要的最低存储是 120T ,一般还会加 20% 的 buffer 。

至少 需要准备 144T 的存储空间。根据日志场景的特点,可做 hot-node, warm - node 划分。

hot-node 通常用 SSD 磁盘, warm-node 采用普通机械盘。

2. 单节点配置:每个节点多少索引,多少 shard ,每个 shard 大小控制在多少。

根据总数据量和单节点配置,得出集群总体规模。

单节点,根据经验通常 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 节点发来的请求(比如 cluster health heartbeat), master 节点会因为等待该节点的响应而被 block ,导致别的节点认为 master 节点丢失,从而触发一系列非常反应,比如重选master 。

若无法及时响应 logstash 请求, logstash connect elasticsearch 便会出现 timeout , logstash 会认得这个 Elasticsearch 为 dead ,同时不再消费 kafka 。Kafka 发现在同一个 consumer group 里面某个 consumer 消失了,便会触发整个 consumer group 做 rebalance ,从而影响别的 logstash 的消费,影响整个集群的吞吐量。

典型 羊群效应 ,需要消除头羊带 来的影响。可通过 elasticsearch API: GET/_cat/thread_pool / bulk?v&h =name , host,active,queue,rejected,completed 定位哪个节点比较忙:queue 比较大, rejected 不断增加。然后通过 GET /_cat/shards 找到该 node 上活跃的 shard 。最后再通过 POST /_cluster/reroute API 把 shard 移到 load 比较低的 node 上,缓解该 node 的压力。

ElasticSearch集群运维实践

我们主要关注:

  • 集群健康状态 2 . 集群索引和搜索性能
  • 节点 cpu , memory, disk 使用情况

集群green ,正常。

集群yellow,主要是有 replica shard 未分配。

集群 red ,是因为有 primary shard 未分配。

主要原因:集群 node disk 使用率超过 watermark ( 默认 85% )。可通过 api GET/_cat/ allocation 查看 node 的磁盘使用率。可通过 api GET/_cluster/ settings 查看 cluster.routing.allocation.enable 是否被禁止。可通过 api GET /_cluster/allocation/explain? pretty 查看 shard 未分配到 node 的具体原因。

监控工具推荐使用:cerebro( https://github.com/lmenezes/cerebro )

ElasticSearch优化经验

索引优化

  • 提前创建索引
  • 避免索引稀疏,index 中 document 结构最好保持一致,如果 document 结构不一致,建议分 index ,用一个有少量 shard 的 index 存放 field 格式不同的 document 。3 . 在加载大量数据时可设置 refresh_interval =-1 , index.number_of_replicas =0 ,索引完成后再设回 来。4 . load 和 IO 压力不大的情况,用 bulk 比单条的 PUT/DELETE 操作索引效率更高 。5 . 调整 index buffer( indices.memory.index_buffer_size ) 。
  • 不需要 score 的 field ,禁用 norms;不需要 sort 或 aggregate 的 field ,禁用 doc_value 。

查询优化

  • 使用 routing 提升某一维度数据的查询速度。
  • 避免返回太大量的搜索结果集,用 limit 限制。
  • 如果 heap 压力不大,可适当增加 node query cache( indices.queries.cache.size ) 。
  • 增加 shard 备份可提高查询并发能力,但要注意 node 上的 shard 总量。
  • 定期合并 segment 。

阿里云ElasticSearch服务

阿里云提供的ElasticSearch服务包含了监控、报警、日志可视化、一键扩容等特点

本文分享自微信公众号 - 大数据技术与架构(import_bigdata),作者:赵汉青

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 斗转星移 | 三万字总结Kafka各个版本差异

    Kafka 2.0.0引入了线程协议的变化。通过遵循下面建议的滚动升级计划,您可以保证在升级期间不会出现停机。但是,请在升级之前查看2.0.0中的重大更改。

    王知无
  • Kafka工作流程及文件存储机制

    Kafka中消息是以topic进行分类的,生产者生产消息,消费者消费消息,都是面向topic的。

    王知无
  • Elasticsearch索引和检索优化与压测监控总结

    先来看看es的整体架构图,上面有多个重要模块,今天主要写在lucene上面的index模块与search模块的优化经历,力求简要写出改变了configurati...

    王知无
  • Elasticsearch在日志分析领域应用和运维实践

    场景描述:Elasticsearch及相关产品,介绍基于ELK + Kafka 的日志分析系统,Elasticsearch优化经验,阿里云 Elasticsea...

    暴走大数据
  • 浅析Java中的Lock和AbstractQueuedSynchronizer 1.Lock接口2.队列同步器3.自定义同步组件4.同步器队列的实现

    在之前的文章中我也曾经介绍过Lock,像ReentrantLock(可重入锁)和ReentrantReadWriteLock(可重入读写锁),这些所我们在说的时...

    MindMrWang
  • mqtt推送介绍

    方案1、使用GCM服务(Google Cloud Messaging) 简介:Google推出的云消息服务,即第二代的C2DM。 优点:Google提供的服务、...

    xiangzhihong
  • C++之内联函数与constexpr

    inline 函数 规模小,流程直接且频繁调用 cout<<shortString(s1,s2)<<endl; = cout<<(s1.size()<s2.si...

    互联网金融打杂
  • 译文 | 数据驱动下的送餐服务!

    本文由CDA数据分析研究院翻译,译者:王晨光,转载必须获得本站、原作者、译者的同意,拒绝任何不表明译者及来源的转载! Conrad Chu不是餐馆老板、杂货店主...

    CDA数据分析师
  • Arm中国金勇斌:15年之后的场景是什么样子?

    前不久举行的“2018硬科技行业领袖峰会暨镁客网年会”上,Arm中国副总裁金勇斌带来了主题为《Open Platforms for AIoT Ecosystem...

    镁客网
  • 手机删除的短信怎么找回?你想不到的方法

      手机删除的短信怎么找回?前段时间在等几个很重要的面试短信,后来想把里面的一些垃圾短信删除掉,后来不知道怎么了把几个面试的短信一起给删除掉了,然后就一直想找方...

    科技第六人

扫码关注云+社区

领取腾讯云代金券