ELK 使用小技巧(第 4 期)

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

1、Logstash

一、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 操做。

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

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

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

if ![updateTime]
复制代码

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

date {
  match => ["logtime", "yyyy-MM-dd HH:mm:ss.SSS","yyyy-MM-dd HH:mm:ss,SSS"]
  target => "logtime_utc"
}
复制代码

2、Elasticsearch

一、高效翻页 Search After

一般状况下咱们会使用 from 和 size 的方式实现查询结果的翻页,可是当达到深度分页时,成本变得太高(堆内存占用和时间耗费与 from+size 的大小成正比),所以 ES 设置了限制(index.max_result_window),默认值为 10000,防止用户进行过于深刻的翻页。node

推荐使用 Scroll api 进行高效深度滚动,但滚动上下文代价很高,所以不要将 Scroll 用于实时用户请求。search_after 参数经过提供实时游标来解决深度滚动的问题,其主要思路是使用上一页的结果来帮助检索下一页。git

GET twitter/_search
{
    "size": 10,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "search_after": [1463538857, "654323"],
    "sort": [
        {"date": "asc"},
        {"tie_breaker_id": "asc"}
    ]
}
复制代码

二、ES 文档类似度 BM25 参数设置

ES2.X 默认是以 TF/IDF 算法计算文档类似度,从 ES5.X 开始,BM25 做为默认的类似度计算算法。github

PUT /index
{
    "settings" : {
        "index" : {
            "similarity" : {
              "my_similarity" : {
                "type" : "DFR",
                "basic_model" : "g",
                "after_effect" : "l",
                "normalization" : "h2",
                "normalization.h2.c" : "3.0"
              }
            }
        }
    }
}

PUT /index/_mapping/_doc
{
  "properties" : {
    "title" : { "type" : "text", "similarity" : "my_similarity" }
  }
}
复制代码

三、ES2.X 得分计算

得分计算脚本:算法

double tf = Math.sqrt(doc.freq); 
double idf = Math.log((field.docCount+1.0)/(term.docFreq+1.0)) + 1.0; 
double norm = 1/Math.sqrt(doc.length); 
return query.boost * tf * idf * norm;
复制代码
  • 忽略词频统计及词频位置:将字段的 index_options 设置为 docs;
  • 忽略字段长度:设置字段的 "norms": { "enabled": false }

四、CircuitBreakingException: [parent] Data too large

报错信息:编程

[WARN ][r.suppressed             ] path: /, params: {}
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]
复制代码

jvm 堆内存不够当前查询加载数据因此会报 data too large, 请求被熔断,indices.breaker.request.limit默认为 jvm heap 的 60%,所以能够经过调整 ES 的 Heap Size 来解决该问题。api

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

六、elasticsearch-hanlp 分词插件包

核心功能:缓存

  • 内置多种分词模式,适合不一样场景;
  • 内置词典,无需额外配置便可使用;
  • 支持外置词典,用户可自定义分词算法,基于词典或是模型;
  • 支持分词器级别的自定义词典,便于用于多租户场景;
  • 支持远程词典热更新(待开发);
  • 拼音过滤器、繁简体过滤器(待开发);
  • 基于词语或单字的 ngram 切分分词(待开发)。

github.com/AnyListen/e…ruby

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

当某个节点短期离开集群时,通常是不会影响总体系统运行的,能够经过下面的请求延迟索引分片的再分配。性能优化

PUT _all/_settings
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}
复制代码

八、ES 数据修改后,查询仍是未修改前的数据

默认是 1 秒可见,若是你的需求必定要写完就可见,那在写的时候增长 refresh 参数,强制刷新便可,但强烈建议不这么干,由于这样会把整个集群拖垮。

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

当 Terms Query 须要指定不少 terms 的时候,若是手动设置仍是至关麻烦的,能够经过 terms-lookup 的方式从另一个索引加载须要匹配的 terms。

PUT /users/_doc/2
{
    "followers" : ["1", "3"]
}

PUT /tweets/_doc/1
{
    "user" : "1"
}

GET /tweets/_search
{
    "query" : {
        "terms" : {
            "user" : {
                "index" : "users",
                "type" : "_doc",
                "id" : "2",
                "path" : "followers"
            }
        }
    }
}

-----------等效下面的语句--------------

PUT /users/_doc/2
{
 "followers" : [
   {
     "id" : "1"
   },
   {
     "id" : "2"
   }
 ]
}
复制代码

十、ES 备份路径设置

报错信息:

doesn't match any of the locations specified by path.repo because this setting is empty 复制代码

结局方案,修改 ES 的配置文件:

# 在 elasticsearch.yml 中添加下面配置来设置备份仓库路径 
path.repo: ["/home/test/backup/zty_logstash"]
复制代码

十一、Query cache 和 Filter cache 的区别

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

十二、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 压力越大,天然会影响查询体验;
  • 具体一个分片多少数据合适,仍是须要结合实际的业务数据和实际的查询来进行测试以进行评估。

1三、ES 索引更新时经过 mapping 限制指定字段更新

Elasticsearch 默认是 Dynamic Mapping,新字段会自动猜想数据类型,并自动 merge 到以前的 Mapping,你能够在 Mapping 里面能够配置字段是否支持动态加入,设置参数dynamic便可:true,默认,表示支持动态加入新字段;false,表示忽略该字段的后续索引等操做,可是索引仍是成功的;strict支持不支持未知字段,直接抛错。

1四、ES 数据快照到 HDFS

ES 作快照和使用 ES-Hadoop 导数据是彻底的两种不一样的方式,使用 ES-Hadoopp 后期导入的成本可能也不小。

  • 若是要恢复快,固然是作快照和还原的方式最快,速度彻底取决于网络和磁盘的速度;
  • 若是为了节省磁盘,快照的时候,能够选 6.5 最新支持的 source_only 模式,导出的快照要小不少,不过恢复的时候要进行重建,速度慢。

1五、segment.memory 简介

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

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

3、社区文章精选


Any Code,Code Any!

扫码关注『AnyCode』,编程路上,一块儿前行。

相关文章
相关标签/搜索