本次分享是由来自阿里巴巴的高级工程师 赵汉青 带来的。主要讲述了：
- 基于ELK + Kafka 的日志分析系统
- Elasticsearch 优化经验
- Elasticsearch 运维实践
ElasticSearch介绍
分布式实时分析搜索引擎，优点包括：
- 查询近实时
- 内存消耗小，搜索速度快
- 可扩展性强
- 高可用
数据结构
- FST(Finite State Transducer)
- 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 的 timestampmetrics: 获取 logstash 的 metricscodec.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 少用通配符。
集群规划的基本问题：
- 总数据量大小：每天流入多少数据，保存多少天数据。
每日增加的数据量：每日新增的 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 采用普通机械盘。
- 单节点配置：每个节点多少索引，多少 shard ，每个 shard 大小控制在多少。
