ELK Tips 主要介绍一些 ELK 使用过程当中的小技巧,内容主要来源为 Elastic 中文社区。html
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 操做。filter {
ruby {
code => "event.set('kpi', ((event.get('a') + event.get('b'))/(event.get('c')+event.get('d'))).round(2))"
}
}
复制代码
if ![updateTime]
复制代码
date {
match => ["logtime", "yyyy-MM-dd HH:mm:ss.SSS","yyyy-MM-dd HH:mm:ss,SSS"]
target => "logtime_utc"
}
复制代码
一般状况下咱们会使用 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"}
]
}
复制代码
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" }
}
}
复制代码
得分计算脚本:算法
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 }
;报错信息:编程
[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
核心功能:缓存
当某个节点短期离开集群时,通常是不会影响总体系统运行的,能够经过下面的请求延迟索引分片的再分配。性能优化
PUT _all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
复制代码
默认是 1 秒可见,若是你的需求必定要写完就可见,那在写的时候增长 refresh 参数,强制刷新便可,但强烈建议不这么干,由于这样会把整个集群拖垮。
当 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"
}
]
}
复制代码
报错信息:
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"]
复制代码
Filter cache 被重命名为 Node Query Cache,也就是说 Query cache 等同于 Filter cache;Query Cache 采用了 LRU 的缓存方式(当缓存满的时候,淘汰旧的不用的缓存数据),Query Cache 只缓存被用于 filter 上下文的内容。
Lucene 底层没有这个大小的限制,20-40GB 的这个区间范围自己就比较大,经验值有时候就是拍脑壳,不必定都好使。
Elasticsearch 默认是 Dynamic Mapping,新字段会自动猜想数据类型,并自动 merge 到以前的 Mapping,你能够在 Mapping 里面能够配置字段是否支持动态加入,设置参数dynamic便可:true,默认,表示支持动态加入新字段;false,表示忽略该字段的后续索引等操做,可是索引仍是成功的;strict支持不支持未知字段,直接抛错。
ES 作快照和使用 ES-Hadoop 导数据是彻底的两种不一样的方式,使用 ES-Hadoopp 后期导入的成本可能也不小。
source_only
模式,导出的快照要小不少,不过恢复的时候要进行重建,速度慢。segment 的大小,和 indexing buffer 有关,有三种方式会生成 segment:
Any Code,Code Any!
扫码关注『AnyCode』,编程路上,一块儿前行。