Elasticsearch慢查询分析

本文介绍了Elasticsearch中如何识别和分析慢查询及慢写入操作,通过设置阈值记录慢查询日志和慢写入日志。慢查询日志包括queryphase和fetchphase的阈值设置,而慢写入日志也有相应的阈值配置。日志格式和存储可通过log4j2.properties进行定制。运维人员应定期检查这些日志,发现问题查询并通知开发人员进行性能优化。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

es里面的操作,主要分为两种,一种写入(增删改),另一种是查询(搜索)

我们分别要识别出来,哪些写入操作性能比较慢,哪些查询操作性能比较慢,先要识别出来有性能问题的这些慢查询,慢写入,然后才能去考虑如何优化写入的性能,如何优化搜索的性能

搜索慢查询日志

无论是慢查询日志,还是慢写入日志,都是针对shard级别的,因为大家应该知道,无论你是执行增删改,还是执行搜索,都是对某个数据执行写入或者是搜索,其实都是到某个shard上面去执行的

shard上面执行的慢的写入或者是搜索,都会记录在针对这个shard的日志中

阈值的意思,就是说,什么叫做慢?搜索,5s叫做慢?还是10s叫做慢?或者是1s叫做慢?

比如说,你设置一个阈值,5s就是搜索的阈值,5s就叫做慢,那么一旦一个搜索请求超过了5s之后,就会记录一条慢搜索日志到日志文件中

shard level的搜索慢查询日志,会将搜索性能较慢的查询写入一个专门的日志文件中。可以针对query phase和fetch phase单独设置慢查询的阈值,而具体的慢查询阈值设置如下所示:

在elasticsearch.yml中,设置

index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms

index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug: 500ms
index.search.slowlog.threshold.fetch.trace: 200ms

而慢查询日志具体的格式,都是在log4j2.properties中配置的,比如下面的配置:

appender.index_search_slowlog_rolling.type = RollingFile
appender.index_search_slowlog_rolling.name = index_search_slowlog_rolling
appender.index_search_slowlog_rolling.fileName = ${sys:es.logs}_index_search_slowlog.log
appender.index_search_slowlog_rolling.layout.type = PatternLayout
appender.index_search_slowlog_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c] %.10000m%n
appender.index_search_slowlog_rolling.filePattern = ${sys:es.logs}_index_search_slowlog-%d{yyyy-MM-dd}.log
appender.index_search_slowlog_rolling.policies.type = Policies
appender.index_search_slowlog_rolling.policies.time.type = TimeBasedTriggeringPolicy
appender.index_search_slowlog_rolling.policies.time.interval = 1
appender.index_search_slowlog_rolling.policies.time.modulate = true

logger.index_search_slowlog_rolling.name = index.search.slowlog
logger.index_search_slowlog_rolling.level = trace
logger.index_search_slowlog_rolling.appenderRef.index_search_slowlog_rolling.ref = index_search_slowlog_rolling
logger.index_search_slowlog_rolling.additivity = false

索引慢写入日志

可以用如下的配置来设置索引写入慢日志的阈值:

index.indexing.slowlog.threshold.index.warn: 10s
index.indexing.slowlog.threshold.index.info: 5s
index.indexing.slowlog.threshold.index.debug: 2s
index.indexing.slowlog.threshold.index.trace: 500ms
index.indexing.slowlog.level: info
index.indexing.slowlog.source: 1000

用下面的log4j.properties配置就可以设置索引慢写入日志的格式:

appender.index_indexing_slowlog_rolling.type = RollingFile
appender.index_indexing_slowlog_rolling.name = index_indexing_slowlog_rolling
appender.index_indexing_slowlog_rolling.fileName = ${sys:es.logs}_index_indexing_slowlog.log
appender.index_indexing_slowlog_rolling.layout.type = PatternLayout
appender.index_indexing_slowlog_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c] %marker%.10000m%n
appender.index_indexing_slowlog_rolling.filePattern = ${sys:es.logs}_index_indexing_slowlog-%d{yyyy-MM-dd}.log
appender.index_indexing_slowlog_rolling.policies.type = Policies
appender.index_indexing_slowlog_rolling.policies.time.type = TimeBasedTriggeringPolicy
appender.index_indexing_slowlog_rolling.policies.time.interval = 1
appender.index_indexing_slowlog_rolling.policies.time.modulate = true

logger.index_indexing_slowlog.name = index.indexing.slowlog.index
logger.index_indexing_slowlog.level = trace
logger.index_indexing_slowlog.appenderRef.index_indexing_slowlog_rolling.ref = index_indexing_slowlog_rolling
logger.index_indexing_slowlog.additivity = false

把这个东西记录好了以后,就可以什么呢?es集群运维管理员,就需要经常每天去看看,正常情况下,慢查询应该是比较少数的。所以比如你每天检查一次,如果发现某个查询特别慢,就要通知写这个查询的RD,开发人员,让他们去优化一下性能。



 

参考:

https://www.jianshu.com/p/3e58d27a37fb

ElasticSearch数据库配置慢查询日志_IT_狂奔者的博客-CSDN博客_elasticsearch慢查询日志

https://www.jianshu.com/p/3d3e05e70425

<think>嗯,用户想分析Elasticsearch中的慢查询日志,找出原因和解决方案。首先,我需要回忆一下Elasticsearch的慢日志机制。记得有索引慢日志和搜索慢日志两种,用户的问题是关于查询的,所以应该关注搜索慢日志。系统指令里提到的引用[1]也提到这一点,所以需要确认是否正确。 然后,用户需要知道如何开启和配置慢日志。根据引用[1],慢日志的配置是在索引级别设置的,可以通过修改索引设置来开启。可能需要用PUT请求更新索引配置,设置阈值,比如将search.slowlog.threshold.query.warn设为5秒。这部分需要详细说明步骤,确保用户能正确配置。 接下来是分析慢查询日志的位置。日志通常位于Elasticsearch的日志目录下,文件名包含_index_search_slowlog.log。用户可能需要查看这些日志文件,或者通过Kibana的日志查看功能更方便地分析,引用[2]提到Kibana是Elasticsearch的可视化工具,可以推荐使用。 然后要分析常见原因。分几个方面,比如查询复杂度,是否有大范围的通配符查询或者模糊查询;分片问题,比如分片过多或分布不均;硬件资源不足,比如CPU、内存或磁盘IO;索引设计不合理,比如缺少合适的映射或未使用分片策略;还有集群状态问题,比如脑裂,引用[3]中的脑裂问题可能影响性能,需要检查集群健康状态。 解决方案部分,要针对每个原因给出对应的解决办法。比如优化查询语句,避免通配符,使用过滤器;调整分片数量和大小;扩容集群或增加节点;优化索引设计,使用时间分区;定期监控集群状态,防止脑裂。引用[3]中的curl命令可以检查集群健康,需要提醒用户使用。 最后,生成相关问题时要涵盖配置、工具、索引设计、集群优化等方面,确保用户能进一步探索。检查是否所有引用都正确应用,比如引用[1]关于慢日志类型,引用[2]关于Elasticsearch和Kibana,引用[3]关于脑裂和集群健康检查。确保回答结构清晰,步骤正确,解决方案具体可行。</think>### Elasticsearch慢查询日志分析及解决方案 #### 一、慢查询日志的配置与启用 1. **日志类型区分** Elasticsearch慢查询日志属于搜索慢速日志(search slow logs),需在索引级别配置。通过调整阈值参数可控制日志记录条件: ```json PUT /my_index/_settings { "index.search.slowlog.threshold.query.warn": "5s", "index.search.slowlog.threshold.query.info": "2s" } ``` 当查询耗时超过设定阈值时,日志会记录详细信息[^1]。 2. **日志文件定位** 慢查询日志默认存储在Elasticsearch日志目录(如`/var/log/elasticsearch`),文件名格式为`{cluster_name}_index_search_slowlog.log`。可通过Kibana的日志管理功能直接查看结构化日志[^2]。 #### 二、慢查询的常见原因分析 1. **复杂查询语句** - 使用通配符查询(`wildcard`)、模糊查询(`fuzzy`)或正则表达式 - 未优化的嵌套聚合(nested aggregations)或多层桶聚合 - 未启用分页导致全量结果返回(如`size: 10000`) 2. **分片相关问题** - 分片数量过多(单个索引超过50个分片) - 分片分布不均衡(通过`GET _cat/shards?v`检查) - 跨分片查询未合并缓存(`query_then_fetch`模式效率低) 3. **硬件资源瓶颈** - 磁盘IOPS不足(SSD硬盘可提升性能) - JVM堆内存不足引发频繁GC(通过`GET _nodes/stats/jvm`监控) - CPU利用率持续高于80% 4. **索引设计缺陷** - 未使用合适的数据类型(如将数值字段设为`text`) - 缺乏时间分区(time-based index pattern) - 未启用`doc_values`导致聚合效率低下 5. **集群状态异常** - 脑裂问题导致节点间通信延迟(通过`GET _cluster/health`检查`status`字段)[^3] - 未关闭的索引占用资源(`close index`可减少内存消耗) #### 三、系统性优化方案 1. **查询语句优化** - 用`term`查询替代`match`查询过滤精确值 - 使用`filter context`替代`query context`跳过相关性算分 ```json { "query": { "bool": { "filter": [{"range": {"timestamp": {"gte": "now-1d/d"}}}] } } } ``` 2. **分片策略调整** - 单个分片大小控制在10-50GB(通过`GET _cat/indices?v`检查) - 使用`routing`参数将相关文档分配到相同分片 - 冷热数据分离部署(hot-warm架构) 3. **硬件与配置优化** - 设置JVM堆内存为物理内存的50%(不超过32GB) - 启用查询缓存(`indices.queries.cache.size: 10%`) - 升级到最新版本(如7.x以上版本优化了并发查询性能) 4. **索引设计改进** - 对时序数据采用滚动索引(Rollover Index) - 对高基数字段禁用`fielddata` - 使用`keyword`类型替代`text`+`keyword`双字段(若无需分词) 5. **集群运维监控** - 定期执行`_forcemerge`减少segment数量 - 使用Elasticsearch的Profiling API分析查询耗时分布 - 通过APM工具(如Elastic APM)跟踪全链路性能 #### 四、诊断工具推荐 1. **内置命令** ```bash # 查看热点线程 GET _nodes/hot_threads # 分析索引性能 GET _index_stats ``` 2. **可视化工具** - Kibana的Search Profiler - Cerebro集群管理工具 - Prometheus+Granfa监控体系
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值