2.基于Kibana和ES的苏宁实时日志分析平台-彭燕卿

Size: px

Start display at page:

Download "2.基于Kibana和ES的苏宁实时日志分析平台-彭燕卿"

威崔
5 years ago
Views:

1 基于 Kibana 和 ES 的苏宁实时志分析平台苏宁云商 IT 总部技术总监 - 彭燕卿 Elastic{ON} DevChina Dec 10,

2 Agenda 集群现状志平台架构演进常优化总结运维小技巧 Kibana4 二次开发 2

3 集群现状 126 个数据节点,7 个 cluster,12c/128g/2t SATA 16C/128G/3T SSD 12C/128G/16T 接苏宁近 2000 个系统的应志 web 访问缓存应防墙等志促每天新索引 25T 数据,doc 数超过 450 亿条 open 1100 索引 130T 2500 亿数据 shard 7 天存储峰值 90W/s 数据写平均每个 doc 0.6kb 3

4 整体架构实时志平台采的是 flume+kafka+elasticsearch+kibana 的部署架构与 ELK 架构有点不同, 我司使 flume 实时采集志,Kafka 作为数据通道, ES river 插件消费 Kafka 的数据, 将 Kafka 中的数据清洗过滤后,index 到 ES 集群中 Logs Flume Kafka Kafka Kafka Elasticsearch Elasticsearch Elasticsearch Kibana4 4

5 志平台架构演进 -1 配置 : 虚拟机节点 Kibana 按天生成索引 ES Cluster Master Nginx river 问题 : 部分数据节点负载非常高数据消费延时查询响应慢 QPS 低 Master flume Log source kafka river 原因 : 同一个主机上存在多个 ES 虚拟机 Node 数据节点同时承担索引和检索, 负荷重 enabled _all 按天索引体量量大集群节点少 flume 5

6 志平台架构演进 -2 Kibana Nginx ES Cluster 主要优化 : 增加 client 节点解决同一物理理机上多虚拟机 data 节点增加部分物理理机关闭 _all 字段, 小时生成索引根据日志类型划分不不同的索引 Master Master flume Log source Client Client kafka river river 运状况 : 非大促期间, 索引和检索速度基本能达到秒级大促期间, 日志量量膨胀以及访问人数过多时, 索引和检索速度任然很慢原因分析 : 单集群能力力受限不不同类型的数据混在一个大集群中, 互相影响 client 节点性能提升不不明显虚拟机和物理理机混合, 制约物理理机的能力力 flume 6

7 志平台架构演进 -3 Kibana Nginx Tribe Tribe 主要优化 : 使用 tribe 做多集群路路由根据不不同的分析类型进行行集群拆分将 data 节点全部替换成物理理机提供按照系统文件路路径等应对大促期间的日志洪峰系统进行行降级的功能统计型集群使用 SSD 运行行状况 : 流量量的剧增通过降级, 能够保证核心系统数据的实时性 ES Cluster1( 统计型 ) Master ES Cluster2( 检索型 ) Master 存在的问题 : 随着业务量量的快速增长, 简单的按照分析类型进行行集群拆分已不不能满足要求, 并且增加机器器资源容量量并不不是线性增加用户希望保留留 7 天以前以及大促期间数据, 集群容量量以及性能也存在严重问题 river river Offline Cluster Master Log source flume Kafka hadoop Kafka 7 flume River

8 志平台架构演进 - 现状主要优化 : Tribe Kibana Nginx Tribe 在 3 的基础上同时支持按照业务划分以及数据类型划分集群接入流程自动化使用不不同的硬件配置划分 Hot/Cold 节点, 业务低峰时将历史数据迁移到 Cold 节点针对 Exception 等重点关注且长期保留留分析业务 Cluster1 Hot Cold Type Cluster1 Hot Cold 业务 Cluster N 的数据单独存储多 kafka Exception Log Cluster Master 问题 : 跨多索引进行行统计分析性能差以及对集群压力力任然很大 River Master Kafka1 river Master Kafka2 river Type Cluster N Offline Cluster Master 不不同业务 Log 不不同类型 Log hadoop Kafka 8 flume flume River

9 常优化总结 - 硬件优先独立物理理机对于实时性要求非常高的需求, 优先 SSD 适当调整 OS 的 max_file_descriptors, 解决 Too many open files 异常单服务器器运行行多个 node 时, 调整 max user processes, 否则容易易 native thread OOM. 关闭 swap 交换或锁内存 ulimit -l unlimited/bootstrap.mlockall: true 9

10 常优化总结 -ES 根据数据量合理的规划索引 pattern 和 shard 数 disabled _all 节省存储空间提升索引速度不需要分词的字段设成 not_analyzed 对于不要求 100% 可的内部系统, 可不设置副本, 提升 index 速度和减少存储 10

11 常优化总结 -ES 设置合理的 refresh 时间 index.refresh_interval: 300S 设置合理的 flush 间隔 index.translog.flush_threshold_size: 4g index.translog.flush_threshold_ops: 合理配置 throttling indices.store.throttle.max_bytes_per_sec: 200mb 适当调整 bulk 队列 11 threadpool.bulk.queue_size: 1000

12 常优化总结 -ES 有时可能因为 gc 时间过长, 导致该数据节点被主节点踢出集群的情况, 导致集群出现不健康的状态, 为了解决这样的问题, 我们适当的调整 ping 参数 (master) discovery.zen.fd.ping_timeout: 40s discovery.zen.fd.ping_interval: 5s discovery.zen.fd.ping_retries: 5 调整数据节点的 JVM 新代数据节点 young gc 频繁, 适当调转新代 (-Xmn3g), 降低 young gc 的频率在进检索和聚合操作时,ES 会读取反向索引, 并进反向解析, 然后进排序, 将结果保存在内存中这个处理会消耗很多 Heap, 有必要进限制, 不然会很容易出现 OOM Disabled analyzed field fielddata 限制 Field 的 Heap Size 的使 12 indices.fielddata.cache.size: 40% indices.breaker.fielddata.limit: 50%

13 ES 运维技巧增加节点调整 shard 数 index.routing.allocation.total_shards_per_node: 2 index 在每个 node 的 shard 数据 ( 如果后期需要移除节点, 保证每个 node 有可分配的 shard) 移除节点移除 node 前可以先 exclude 要移除的 node cluster:cluster.routing.allocation.exclude._name : node1 index:index.routing.allocation.exclude._name: node1 index.routing.allocation.require.node_type: hot 以上参数可根据 _ip _host 等来进配置 13 以上参数可实现 hot-cold cold 数据的动迁移

ES 运维技巧 - 具监控插件满天飞, 各有千秋 Head Kopf bigdesk elasticsearch-sql(nlpchina) 定时关闭和删除 index: curator 基于 python 脚本实现采集 ES 集群指标数据, 并使 kibana 展志平台监控 ES 志, 重点对以下关键词进监控告警

14 ES 运维技巧 - 具监控插件满天飞, 各有千秋 Head Kopf bigdesk elasticsearch-sql(nlpchina) 定时关闭和删除 index: curator 基于 python 脚本实现采集 ES 集群指标数据, 并使 kibana 展志平台监控 ES 志, 重点对以下关键词进监控告警 OutOfMemoryError removed AND cluster.service node 退出 cluster unable to create new native thread master_left master 退出 cluster Slow log 监控, 重量级 query 可能把整个集群拖慢, 对 slow log 重点监控分析 ( 待实现 ) 14

15 15 Kibana 二次开发 - 从汉化开始

16 Kibana 次开发 - 权限 nodejs 实现 cas 单点登录授权数据权限不同业务可查询的数据范围禁通过 kibana 访问 _plugin _shutdown 等户关联仪表盘检索统计分析 16

17 Kibana 二次开发 -discover 可查询更更多 Discover 可以前后查询更多数据, 解决查询 discover:samplesize 数限制外数据查看的问题 17

18 Kibana 二次开发 - 数据上下文查询可查看检索结果的上下关联志, 对于分析问题便很多时间 long+ 号对志排序选取上下关联字段, 能保证志顺序, 最好是 number 类型或 Date 类型, 否则排序会很慢 18

19 Kibana 二次开发 - 禁用 check es version Kibana 每次打开都会请求 _node, 获取各 node 信息,check es version 当使用 tribe 做多集群架构的情况下, 如果 tribe 下某个集群出现不不可用,_node 得不不到响应, 会影响整个 kibana 不不可用可去掉 check es version 解决因部分集群影响整个 kibana 不不可用问题 19

20 Kibana 二次开发 -dashboard 管理员可分享 dashboard 模板给普通户使 dashboard 可选择系统查看数据 20

21 Kibana 二次开发 -other indexpattern 映射为中禁分词字段的统计分析 ( 误操作容易导致长 GC 甚 OOM, 亲经历 ), 如果 template 中指定 fileddata 为 disabled, 进统计分析或排序会报异常根据不同的数据类型默认展不同的默认 field 修改默认排序字段, 根据定义 seqnum 排序 visualize 持模板共享 Discover 左侧 field 快速计数展更多解决 dashboard 长时间 refresh page crash 问题 21

22 NEXT 升级 ES5 多数据中服务化 22

23 Thanks! Questions? 23

第 06 期李祥池 : 基于 ELK 和 Spark Streaming 的日志分析系统设计与实现 1 日志 1.1 日志定义 IT 1.2 日志处理方案演进 v1.0 v2.0 Hadoop Storm Spark Hadoop/Storm/Spark v3.0 TB Splunk ELK SI

第 06 期李祥池 : 基于 ELK 和 Spark Streaming 的日志分析系统设计与实现 1 日志 1.1 日志定义 IT 1.2 日志处理方案演进 v1.0 v2.0 Hadoop Storm Spark Hadoop/Storm/Spark v3.0 TB Splunk ELK SI 电子科学技术第 02 卷第 06 期 2015 年 11 月 Electronic Science & Technology Vol.02 No.06 Nov.2015 年基于 ELK 和 Spark Streaming 的日志分析系统设计与实现李祥池 ( 杭州华三通信技术有限公司北京研究所, 北京,100085) 摘要 : 在大数据时代对数据平台各组件的运行状态实时监控与运行分析具有重要意义