基于ELK的大数据平台实践分享.docx

基于ELK的大数据平台实践分享.docx

《基于ELK的大数据平台实践分享.docx》由会员分享，可在线阅读，更多相关《基于ELK的大数据平台实践分享.docx（11页珍藏版）》请在冰豆网上搜索。

基于ELK的大数据平台实践分享

基于ELK的大数据平台实践分享

在2018年ElasticMeetup南京交流会中，来自云利来科技的涂海波为现场的听众带来了题为《南京云利来基于ELK的大数据平台》的精彩分享。

在本次分享中，他首先进行了公司简介，然后介绍了数据分类，包括数据采集及数据类型等；然后重点阐述了运维之路，最后进行了告警分析。

直播视频请点击

PPT下载请点击

以下内容根据现场分享整理而成。

南京云利来有限公司主要专注于以下三个方面：

实时网络使用分析，具备世界领先20Gbps分析能力；为数据中心搭建大数据分析平台，数据中心主要是给运维团队、安全团队和开发团队做跨部门协作；提供智能运维、网络安全和预警分析能力。

产品主要应用的行业包括电商、政府、证券等。

数据分类

数据采集

数据采集主要分为网络类和日志类。

网络类主要为旁路部署，用小盒子部署在机房内不同的点，包括出口入口。

日志类主要包括Nagios（filebeat）和Zabbix（mysqlexporter）。

数据类型

上图为主要数据类型，网络协议里也有数据库，是一些协议解析，还有一些交易的解析。

可以从网络层面和日志层面分开来比对。

数据量

每天数据量至少2TB，记录数22亿，不含副本；高峰数据量每秒6万条记录；单个索引最快处理12万条记录每秒。

使用场景

主要有三个使用场景：

查询聚合；大屏分析，预测告警；网络指标，业务指标安全指标。

网络业务安全是基于一些不同的团队，定制个性化的指标，进行一些对比分析。

运维之路

集群演变

在使用ELK的整个过程中，我们使用过Vmware、Docker，跟美国的第三方公司的一些合作。

我们自己用的最多的是单节点单实例和单节点双实例。

基本是用于功能测试小公司一些测试部署。

冷热分离

我们做的冷热分离，开始采用的是flashcache模式，每台物理机上面都配备了一个SSD的小盘，主要是为了抵消传统的机械式硬盘寻到的一个LPS。

LPS比较慢，延迟比较高，所以分布式集群每一块都配备一个小盘。

在这种模式下，磁盘IO连续小块读，负载高，IOwait高，分析发现存在抖动。

采用单机双实例冷热分离模式，充分利用1.6TB的SSD，只保存每天的热数据，隔夜迁移到HDDRaid0。

升级的主要目的有两个：

内存隔离，当天和历史JAVA对象分离在不同的JVM里；IO隔离，当天和历史数据的磁盘IO分离在不同的磁盘上。

上图为运维前后对比效果图。

左边是运维之前，右边是运维之后。

升级后，有效减少了cpuwait和磁盘读，降低了系统负载，有效提升了查询和写入性能。

上图为在单个索引上做的测试。

之前做了许多积压，可以发现索引的速度是上升的。

单个索引最高速度从之前的60000条每秒提升到120000条记录每秒，平均10万条每秒。

聚合查询性能提升1倍。

重要选型

重要选型首先从cpu介绍，我们推荐使用XeonE5-2600V4系列。

官方测试显示，它比V3系列提升JAVA性能60％，我们进行了一些设置，包括指令预取，cacheline预取，NumaSet。

结合双路cpu，它的内存和节点有一个就近读取的原则。

我们根据单个机器的实例进行cpu的绑定。

设置以后可以提高cpu的命中率，减少内存的切换。

在内存方面，每台物理机配备的是128TB，SSD是1.6TB，HDD是40TB～48TB。

具有大内存的特点，我们还进行了Cache加速，写负载高的时候上SSD，定期做Trim优化，利用SSD,SAS和SATA盘分级存储。

OSfilesystem用的最多的是xfs。

针对HDD、SSD4k对齐优化，确保每个分区的startAddress能被8整除，解决跨扇区访问，减少读写次数和延迟。

Shard和Replica个数是基于测试的经验，可以作为参考，还基于负载、性能等。

节点数设置为1.5。

Shardsize控制在30GB以内，Sharddocs控制在5百万记录以内，Replica至少为1。

可靠性

由上图可以看到每个角色都有A、B、C三个点，然后做了冷热分离，Client多个点做了负载均衡。

性能分析

·高负载

高负载主要采用IO负载型，主要关注Sar，Vmstat，IOstat，Dstat和Systemtap，Perf。

·线程池

线程池这里主要关注Index，Query，Merge，Bulk，包括Thread，QueueSize和Active，Queue。

·内存占用

内存占用主要看各个节点的内存占用大小，Fielddata设置为10％，也有的设置为1％，大部分场景都是精确查询。

·查询

用慢查询作为告警，然后进行请求、响应、延时、峰值统计。

随着资源使用率的提升，我们会发现在80%的点位，延时会特别大，于是会有多个监工。

单个监工是没问题的，但是多个监工可能是有问题的。

Queryprofile用来定位各个阶段的时间。

Cachefilling用来观看命中率如何,可以做一些cache的设置。

然后会进行日志埋点采集，queryreplay，做一些测试。

·集群健康

集群健康这里主要是对以下几项进行指标监控。

_cluster/health：

active,reallocating,initializing,unassigned；Pingtimeout；Shardallocation,recoverlatency。

·GC效率

GC效率主要关注以下几点：

GC时长占比，GC回收量占比；内存增长速率，内存回收速率；各代回收耗时，频率；Dumpprofile；Jstack，Jmap，Jstat。

存储规划

上图为基于不同业务做的存储规划。

性能提升

·合理设计

首先我们会考虑每个域的意义，没有意义的域是不允许插进来的。

然后要考虑需要存储搜索还是聚合，思考每一个域的价值所在。

它是字符串型的还是数值型的？

然后我们会对模板进行动态的设置。

当字符串过长的时候，我们是否要做一个截取？

是否要做一个Hash？

·批处理

适当调大处理时间，Translog适当把频率降低。

上图做了一个按需隔离，分表分级分组。

·规划计算

提前聚合后插入；因为空间不够，所以超过生命周期后只保留基线，然后做压缩，做合并；随后可以做Pipeline拆分。

集群监控

监控这里用了一些工具。

Netdata用来做一些系统资源的升级，_catapi是官方自带的，Cerebro是用的比较多的一个插件，Prometheus可以开箱即用。

告警分析

用Sql语法做一些包装、抽象，告警模型基于从工作日开始的迭代、同比环比、平均值及标准差，基线学习。

我们发现问题，解决问题，需要不停的去思考。

不断迭代，严苛细节，最终性能是否满足?

是否可接受?

这些都是需要思考的问题。

本文作者：

云迹九州

原文链接

更多技术干货敬请关注云栖社区知乎机构号：

阿里云云栖社区-知乎

本文为云栖社区原创内容，未经允许不得转载。

-全文完-