ELK Tips 主要介绍一些 ELK 使用过程中的小技巧，内容主要来源为 Elastic 中文社区。

一、Logstash

1、Logstash 性能调优主要参数

• pipeline.workers：设置启动多少个线程执行 fliter 和 output；当 input 的内容出现堆积而 CPU 使用率还比较充足时，可以考虑增加该参数的大小；
  
• pipeline.batch.size：设置单个工作线程在执行过滤器和输出之前收集的最大事件数，较大的批量大小通常更高效，但会增加内存开销。输出插件会将每个批处理作为一个输出单元。；例如，ES 输出会为收到的每个批次发出批量请求；调整 pipeline.batch.size 可调整发送到 ES 的批量请求（Bulk）的大小；
  
• pipeline.batch.delay：设置 Logstash 管道的延迟时间， 管道批处理延迟是 Logstash 在当前管道工作线程中接收事件后等待新消息的最长时间（以毫秒为单位）；简单来说，当 pipeline.batch.size 不满足时，会等待 pipeline.batch.delay 设置的时间，超时后便开始执行 filter 和 output 操作。
  
  

  2、使用 Ruby Filter 根据现有字段计算一个新字段
  

  <br /> filter {<br /> ruby {<br /> code => "event.set('kpi', ((event.get('a') + event.get('b'))/(event.get('c')+event.get('d'))).round(2))"<br /> }<br /> }<br />
  
  

  3、logstash filter 如何判断字段是够为空或者 null
  

  <br /> if ![updateTime]<br />
  
  

  4、Date Filter 设置多种日期格式
  

  <br /> date {<br /> match => ["logtime", "yyyy-MM-dd HH:mm:ss.SSS","yyyy-MM-dd HH:mm:ss,SSS"]<br /> target => "logtime_utc"<br /> }<br />
  
  

  二、Elasticsearch
  

  1、高效翻页 Search After
  

  通常情况下我们会使用 from 和 size 的方式实现查询结果的翻页，但是当达到深度分页时，成本变得过高（堆内存占用和时间耗费与 from+size 的大小成正比），因此 ES 设置了限制（index.max_result_window），默认值为 10000，防止用户进行过于深入的翻页。
  
  推荐使用 Scroll api 进行高效深度滚动，但滚动上下文代价很高，因此不要将 Scroll 用于实时用户请求。search_after 参数通过提供实时游标来解决深度滚动的问题，其主要思路是使用上一页的结果来帮助检索下一页。
  
  <br /> GET twitter/_search<br /> {<br /> "size": 10,<br /> "query": {<br /> "match" : {<br /> "title" : "elasticsearch"<br /> }<br /> },<br /> "search_after": [1463538857, "654323"],<br /> "sort": [<br /> {"date": "asc"},<br /> {"tie_breaker_id": "asc"}<br /> ]<br /> }<br />
  
  

  2、ES 文档相似度 BM25 参数设置
  

  ES2.X 默认是以 TF/IDF 算法计算文档相似度，从 ES5.X 开始，BM25 作为默认的相似度计算算法。
  <br /> PUT /index<br /> {<br /> "settings" : {<br /> "index" : {<br /> "similarity" : {<br /> "my_similarity" : {<br /> "type" : "DFR",<br /> "basic_model" : "g",<br /> "after_effect" : "l",<br /> "normalization" : "h2",<br /> "normalization.h2.c" : "3.0"<br /> }<br /> }<br /> }<br /> }<br /> }<br /> <br /> PUT /index/_mapping/_doc<br /> {<br /> "properties" : {<br /> "title" : { "type" : "text", "similarity" : "my_similarity" }<br /> }<br /> }<br />
  
  

  3、ES2.X 得分计算
  

  得分计算脚本：
  <br /> double tf = Math.sqrt(doc.freq); <br /> double idf = Math.log((field.docCount+1.0)/(term.docFreq+1.0)) + 1.0; <br /> double norm = 1/Math.sqrt(doc.length); <br /> return query.boost * tf * idf * norm;<br />
  
  

• 忽略词频统计及词频位置：将字段的 index_options 设置为 docs;
  
• 忽略字段长度：设置字段的 "norms": { "enabled": false }；
  
  

  4、CircuitBreakingException: [parent] Data too large
  

  报错信息：
  <br /> [WARN ][r.suppressed ] path: /, params: {}<br /> org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<http_request>] would be [1454565650/1.3gb], which is larger than the limit of [1454427340/1.3gb], usages [request=0/0b, fielddata=568/568b, in_flight_requests=0/0b, accounting=1454565082/1.3gb]<br />
  jvm 堆内存不够当前查询加载数据所以会报 data too large, 请求被熔断，indices.breaker.request.limit默认为 jvm heap 的 60%，因此可以通过调整 ES 的 Heap Size 来解决该问题。
  
  

  5、ES 免费的自动化运维工具推荐
  

• Ansible: https://github.com/elastic/ansible-elasticsearch
  
• Puppet: https://github.com/elastic/puppet-elasticsearch
  
• Cookbook: https://github.com/elastic/cookbook-elasticsearch
  
• Curator：https://www.elastic.co/guide/e ... .html
  
  

  6、elasticsearch-hanlp 分词插件包
  

  核心功能：
  

• 内置多种分词模式，适合不同场景；
  
• 内置词典，无需额外配置即可使用；
  
• 支持外置词典，用户可自定义分词算法，基于词典或是模型；
  
• 支持分词器级别的自定义词典，便于用于多租户场景；
  
• 支持远程词典热更新（待开发）；
  
• 拼音过滤器、繁简体过滤器（待开发）；
  
• 基于词语或单字的 ngram 切分分词（待开发）。
  
  https://github.com/AnyListen/e ... hanlp
  
  

  7、节点重启时延迟索引分片重分配
  

  当某个节点短时间离开集群时，一般是不会影响整体系统运行的，可以通过下面的请求延迟索引分片的再分配。
  <br /> PUT _all/_settings<br /> {<br /> "settings": {<br /> "index.unassigned.node_left.delayed_timeout": "5m"<br /> }<br /> }<br />
  
  

  8、ES 数据修改后，查询还是未修改前的数据
  

  默认是 1 秒可见，如果你的需求一定要写完就可见，那在写的时候增加 refresh 参数，强制刷新即可，但强烈建议不这么干，因为这样会把整个集群拖垮。
  
  

  9、Terms Query 从另一个索引获取 terms
  

  当 Terms Query 需要指定很多 terms 的时候，如果手动设置还是相当麻烦的，可以通过 terms-lookup 的方式从另外一个索引加载需要匹配的 terms。
  <br /> PUT /users/_doc/2<br /> {<br /> "followers" : ["1", "3"]<br /> }<br /> <br /> PUT /tweets/_doc/1<br /> {<br /> "user" : "1"<br /> }<br /> <br /> GET /tweets/_search<br /> {<br /> "query" : {<br /> "terms" : {<br /> "user" : {<br /> "index" : "users",<br /> "type" : "_doc",<br /> "id" : "2",<br /> "path" : "followers"<br /> }<br /> }<br /> }<br /> }<br /> <br /> -----------等效下面的语句--------------<br /> <br /> PUT /users/_doc/2<br /> {<br /> "followers" : [<br /> {<br /> "id" : "1"<br /> },<br /> {<br /> "id" : "2"<br /> }<br /> ]<br /> }<br />
  
  

  10、ES 备份路径设置
  

  报错信息：
  <br /> doesn't match any of the locations specified by path.repo because this setting is empty<br />
  结局方案，修改 ES 的配置文件：
  ```
  

  在 elasticsearch.yml 中添加下面配置来设置备份仓库路径
  

  path.repo: ["/home/test/backup/zty_logstash"]
  ```
  
  

  11、Query cache 和 Filter cache 的区别
  

  Filter cache 被重命名为 Node Query Cache，也就是说 Query cache 等同于 Filter cache；Query Cache 采用了 LRU 的缓存方式（当缓存满的时候，淘汰旧的不用的缓存数据），Query Cache 只缓存被用于 filter 上下文的内容。
  
  

  12、Shard 大小需要考虑的因素有哪些？
  

  Lucene 底层没有这个大小的限制，20-40GB 的这个区间范围本身就比较大，经验值有时候就是拍脑袋，不一定都好使。
  

• Elasticsearch 对数据的隔离和迁移是以分片为单位进行的，分片太大，会加大迁移成本；
  
• 一个分片就是一个 Lucene 的库，一个 Lucene 目录里面包含很多 Segment，每个 Segment 有文档数的上限，Segment 内部的文档 ID 目前使用的是 Java 的整型，也就是 2 的 31 次方，所以能够表示的总的文档数为 Integer.MAX_VALUE - 128 = 2^31 - 128 = 2147483647 - 1 = 2,147,483,519，也就是21.4亿条；
  
• 同样，如果你不 force merge 成一个 Segment，单个 shard 的文档数能超过这个数；
  
• 单个 Lucene 越大，索引会越大，查询的操作成本自然要越高，IO 压力越大，自然会影响查询体验；
  
• 具体一个分片多少数据合适，还是需要结合实际的业务数据和实际的查询来进行测试以进行评估。
  
  

  13、ES 索引更新时通过 mapping 限制指定字段更新
  

  Elasticsearch 默认是 Dynamic Mapping，新字段会自动猜测数据类型，并自动 merge 到之前的 Mapping，你可以在 Mapping 里面可以配置字段是否支持动态加入，设置参数dynamic即可：true，默认，表示支持动态加入新字段；false，表示忽略该字段的后续索引等操作，但是索引还是成功的；strict支持不支持未知字段，直接抛错。
  
  

  14、ES 数据快照到 HDFS
  

  ES 做快照和使用 ES-Hadoop 导数据是完全的两种不同的方式，使用 ES-Hadoopp 后期导入的成本可能也不小。
  

• 如果要恢复快，当然是做快照和还原的方式最快，速度完全取决于网络和磁盘的速度；
  
• 如果为了节省磁盘，快照的时候，可以选 6.5 最新支持的 source_only 模式，导出的快照要小很多，不过恢复的时候要进行重建，速度慢。
  
  

  15、segment.memory 简介
  

  segment 的大小，和 indexing buffer 有关，有三种方式会生成 segment：
  

• 一种是 indexing buffer 写满了会生成 segment 文件，默认是堆内存的10%，是节点共享的；
  
• 一种是 index buffer 有文档，但是还没满，但是 refresh 时间到了，这个时候就会把 buffer 里面的生成 segment 文件；
  
• 还有最后一种就是 es 自动的会将小的 segment 文件定期合并产生新的 segment 文件。
  
  
  

  三、社区文章精选
  

• [2018 年 Elastic Advent Calendar 分享活动](https://elasticsearch.cn/article/6149)
  
• [使用 ES-Hadoop 将 Spark Streaming 流数据写入 ES](https://elasticsearch.cn/article/6318)
  
• [Elastic Stack 6.5 最新功能](https://elasticsearch.cn/article/6209)
  
• [让Elasticsearch飞起来!——性能优化实践干货](https://mp.weixin.qq.com/s/GQfEMb2jMvm9PEANkLl3Tg)
  
  ---
  Any Code，Code Any！
  
  扫码关注『AnyCode』，编程路上，一起前行。