elasticsearch问题集锦

index.highlight.max_analyzed_offset

为高亮显示请求分析的最大字符偏移量。 起因：存储es中索引的字段message（意为原始日志）大小为20M，出现搜索无日志的情况 原因：message字段超出了字符偏移量上限。

解决

可以尝试修改index.highlight.max_analyzed_offset，增大设置，但是不建议修改很大，会导致es内存问题，默认上限为1000000，这里修改为6000000解决

curl -XPUT "127.0.0.1:9200/mason*/_settings" -H Content-Type: application/json -d {
    "index" : {
        "highlight.max_analyzed_offset" : 1000000
    }
}

事件结果成功返回，请求产生响应被截断的问题，后续继续处理。

=====================================================================

分析

根据es的报错提示，推荐使用offsets或者terms高亮，这个意思是，设置offsets使用posting highlighter或者使用"term_vector": “with_positions_offsets”，即会使用Fast vector highlighter 后期我试验了offsets方式和增大偏移量设置方式。

当使用全文检索时，两种高亮器的性能出现差距，posting明显慢于plain，也许文本还不够大？

测试plain highlighter和posting highlighter

1m日志offset的mappings和settings是这样的：

1m日志的是这样的： 查询结果：

看看10M------------- posting高亮

不使用全文检索时，plain高亮 offset快一些 两个使用全文检索是都超过了120s

测试fast vector highlighter

测试结果：第一次搜索时会比较耗时，40多s,后面就非常快了

最终放弃支持大于1M日志，前端渲染性能也是不足以支持，会导致长时间卡顿。

使用plain高亮，索引模式中将index.highlight.max_analyzed_offset设置为1100000，支持1M, 做实验同时写入1M日志、2M日志、<1M日志.发现es读取时会产生数据丢失，数据丢失的情况不使用高亮查询则不出现

原因，大于1M的日志在进行检索高亮时，超出了最大偏移量，那么这个分片就是失败的，同时存储在这个分片上的其他文档也将不会返回，如此导致了读取的数据部分丢失的情况。这样对用户来说是绝对不认可的。 可以看到当我多写入大于1M的日志后，该日志文档会被均衡分配到索引的分片，那么基本每个分片都将会有这个原因而导致失败信息，其他的小日志都不会显示。

最终方案

解决：

1. 修改index.highlight.max_analyzed_offset为1100000
2. logstash的filter ruby 插件可以支持写代码来控制大日志不写入es，即写入的日志都将<=1M大小，解决。

查阅有关资料，得到的信息：

1. es将10K扩展为支持1M
2. Kibana有做高亮的设置，当文档过大时可提供给用户选择禁用高亮(也是一种方式)
3. 有提到支持文档过大时，截取为max_analyzed_offset的大小返回，analyzed_text_limit或者trancate_analyzed_text,但是似乎没有通过，还是采取给用户以警告的方式，错误中更新返回索引、索引id、字段名称。

记录一下fragment_size: 设置要显示出来的fragment文本判断的长度，默认是100

如果有大神知道更好的解决方式，欢迎评论~~

有关es其他设置参数说明

链接: .

有关这个话题讨论的相关信息

elasticsearch对于高亮方面提交所做的改动