背景
前面整理过一遍正确重启Elasticsearch 集群的文章,作为一个运维重启能解决的问题那必然是首选解决方案。不过如果经常靠重启解决问题未必就太Low了,而且重启多了势必会掩盖一些问题,问题积累严重了,导致重大故障也不少见。所以想成长为一个有深度的攻城狮,首先要学会的技能就是分析问题。
经验分享
下面分享下平时分析问题的一些经验
核心:
- 状态数据
- 日志
一、状态数据(这块不细说)
这块侧重指监控层面的数据,包括
- 主机(cpu、内存、磁盘等)
- 网络
- 进程(cpu、内存、并发读写等)
二、服务日志
慢查询日志
每个系统以及服务都有其自身的日志系统,平时协助管理员排忧解难,Elasticsearch也一样https://www.elastic.co/guide/en/elasticsearch/reference/6.0/index-modules-slowlog.html
慢日志配置说明
/etc/elasticsearch/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
#入库索引慢记录(写)
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
#输出路径
path.logs: /var/log/elasticsearch
配置完需要重启节点服务,个人建议如果数据分片数=node节点数,开启一个节点的慢日志即可,集群的查询请求是分发进行的,如果数据分布均匀的情况,各个节点执行的查询是一样的。所以平时排查一个节点的慢日志基本可以评估到对应查询语句的性能。同时减轻其它节点开启日志记录的性能消耗。
集群服务日志输出
$path.logs/$cluster_name.log
日常配置异常,gc等信息会在上面日志输出。
总结:
分析问题尽可能关注日志,系统日志、服务日志结合监控状态,一把撸就是了。如果撸不起来就回去巩固基础,不停的发现问题,循环回去学习,问题总会解决!