Elastic 中国开发者大会 2016

苏宁云商IT总部技术总监彭燕卿——基于Kibana和ES的苏宁实时日志分析平台

实时分析日志是程序员定位问题非常重要的环节,从最原始的SSH到主机tail grep日志文件到现在的ELK全套解决方案,从安全性及效率上都是质的提升。 目前苏宁在ELK的基础上搭建云迹实时日志分析产品,提供应用、web、防火墙、中间件等日志的实时检索、统计分析、告警。为苏宁1000+系统提供日志的实时检索分析服务。 在本演讲中,将和大家分享这套系统从无到有的一些技术架构演变,ES使用过程中遇到的坑及调优,Kibana二次开发等。

1. 基于Kibana和ES的苏宁实时⽇志分析平台 苏宁云商IT总部技术总监-彭燕卿 2016.11.21 Elastic{ON} DevChina – Dec 10, 2016 1
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亿数据、 20000 shard、 7天存储 • 峰值90W/s数据写⼊ • 平均每个doc 0.6kb 3
4. 整体架构 • 实时⽇志平台采⽤的是flume+Kafka+Elasticsearch+Kibana的部署架构。 • 与ELK架构有点不同,我司使⽤flume实时采集⽇志,Kafka作为数据通道, ES river插件消费Kafka⾥⾯的数据,将Kafka中的数据清洗过滤后,index到 ES集群中。 Flume Logs Kafka Kafka Kafka Elasticsearch Elasticsearch Elasticsearch Kibana4 4
5. ⽇志平台架构演进-① ES Cluster Master Kibana Nginx Data Data Master Data Data river river flume Log source flume 5 kafka 配置: • 虚拟机节点 • 按天⽣生成索引 问题: • 部分数据节点负载⾮非常⾼高 • 数据消费延时 • 查询响应慢 • QPS低 原因: • 同⼀一个主机上存在多个ES 虚拟机Node • 数据节点同时承担索引和检索,负荷重 • enabled _all • 按天索引体量量⼤大 • 集群节点少
6. ⽇志平台架构演进-② Kibana ES Cluster Master Nginx Client Data Master Client Data river river flume Log source flume 6 kafka 主要优化: • 增加client节点 • 解决同⼀一物理理机上多虚拟机data节点 • 增加部分物理理机 • 关闭_all字段, • ⼩小时⽣生成索引 • 根据⽇日志类型划分不不同的索引 运⾏状况: • ⾮非⼤大促期间,索引和检索速度基本能达到秒级 • ⼤大促期间,⽇日志量量膨胀以及访问⼈人数过多时,索引 和检索速度任然很慢 原因分析: • 单集群能⼒力力受限 • 不不同类型的数据混在⼀一个⼤大集群中,互相影响。 • client 节点性能提升不不明显 • 虚拟机和物理理机混合,制约物理理机的能⼒力力
7. ⽇志平台架构演进-③ Kibana Nginx Tribe Tribe ES Cluster1(统计型) Data Master ES Cluster2(检索型) Master Data river river flume Log source flume 7 Kafka hadoop 主要优化: • 使⽤用tribe做多集群路路由 • 根据不不同的分析类型进⾏行行集群拆分 • 将data节点全部替换成物理理机 • 提供按照系统、⽂文件路路径等应对⼤大促期间的⽇日志洪峰系统 进⾏行行降级的功能 • 统计型集群使⽤用SSD 运⾏行行状况: • 流量量的剧增通过降级,能够保证核⼼心系统数据的实时性 存在的问题: • 随着业务量量的快速增⻓长,简单的按照分析类型进⾏行行集群拆分 已不不能满⾜足要求,并且增加机器器资源容量量并不不是线性增加。 • ⽤用户希望保留留7天以前以及⼤大促期间数据,集群容量量以及性 能也存在严重问题 Offline Cluster Kafka Master Data River
8. ⽇志平台架构演进-现状 Kibana Nginx Tribe Tribe 业务 Cluster1 Hot Data Data Master Cold Data Data river Kafka1 Type Cluster1 Hot Data Data Cold Data Data Master river Kafka2 业务 Cluster N Type Cluster N 主要优化: • 在③的基础上同时⽀支持按照业务划分以及数 据类型划分集群 • 接⼊入流程⾃自动化 • 使⽤用不不同的硬件配置划分Hot/Cold节点,业务 低峰时将历史数据迁移到Cold节点 • 针对Exception等重点关注且⻓长期保留留分析 • 的数据单独存储。 多kafka 问题: • 跨多索引进⾏行行统计 Exception Log Cluster 分析性能差以及对 Master 集群压⼒力力任然很⼤大 Data River Offline Cluster Master 不不同业务Log flume 8 不不同类型Log flume hadoop Kafka Data 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: 50000 • 合理配置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 Data的Heap Size的使⽤ indices.fielddata.cache.size: 40% 12 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等来进⾏配置 以上参数可实现hot-cold cold数据的⾃动迁移 13
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. Kibana⼆二次开发-从汉化开始 15
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