ES集群故障排查记录

这两天线上的ES集群总是有问题,开始查找原因
发现这段时间各个机器的负载都很高,本来希望通过jstack找到一些信息,但居然提示‘Unable to open socket file: target process not responding or HotSpot VM not loaded’,度娘提示
应该是机器很久没有重启了,没办法,只能放弃这种方式。第一步就没有走通。
继续查发现几台机器 cpu 内存 都很高, 但是硬盘不太对劲,有一台机器硬盘使用下降的厉害,而另外几台硬盘使用都是上升的,初步判断是这台机器出现问题后,开始转移分片导致,
登录到这台机器,查找日志,发现很多报错, 直觉告诉我很可能是这台机器,拖垮了集群,报错的内容大致是,无法与主节点建立连接。继续查为什么这台机器会好好的失联了呢,
继续看监控,发现网络io没有特别的变化, 应该不是大批量的访问造成的,但是线程数却增加的很厉害,突然想到ES还有一个慢查询的日志,翻看一看,果然有几个查询,特别耗时
有的甚至达到了2分钟才返回结果,至此初步判断是这种耗时的查询,压垮了这台机器。让对应的业务修改完后,继续观察。

原文地址:https://blog.51cto.com/12597095/2392327

时间: 2024-10-29 22:07:10

ES集群故障排查记录的相关文章

蓝的成长记——追逐DBA(18):小机上WAS集群故障,由一次更换IP引起

原创作品.出自 "深蓝的blog" 博客,欢迎转载,转载时请务必注明出处.否则追究版权法律责任. 深蓝的blog:http://blog.csdn.net/huangyanlong/article/details/47720043 [简单介绍] 个人在oracle路上的成长记录,当中以蓝自喻.分享成长中的情感.眼界与技术的变化与成长.敏感信息均以其他形式去掉,不会泄露不论什么企业机密,纯为技术分享. 创作灵感源于对自己的自省和记录.若能对刚刚起步的库友起到些许的帮助或共鸣,欣慰不已.

ELK简介 es集群部署 es插件应用

Top NSD ARCHITECTURE DAY03 案例1:ES集群安装 案例2:ES集群安装配置 案例3:练习curl命令 案例4:练习插件 案例5:插入,增加,删除查询数据 案例6:安装Kibana 1 案例1:ES集群安装 1.1 问题 本案例要求: 准备1台虚拟机 部署elasticsearch第一个节点 访问9200端口查看是否安装成功 1.2 方案 1)ELK是日志分析平台,不是一款软件,而是一整套解决方案,是三个软件产品的首字母缩写,ELK分别代表: Elasticsearch:

EFK教程(5) - ES集群开启用户认证

基于ES内置及自定义用户实现kibana和filebeat的认证 作者:"发颠的小狼",欢迎转载 目录 ? 用途 ? 关闭服务 ? elasticsearch-修改elasticsearch.yml配置 ? elasticsearch-开启服务 ? elasticsearch-建立本地内置用户 ? kibana-创建私钥库 ? kibana-WEB界面确认用户 ? filebeat-在WEB界面创建角色及用户 ? filebeat-服务器上创建密钥库 ? filebeat-配置file

ES集群性能调优链接汇总

ES集群稳定性: 1. 集群稳定性的一些问题(一定量数据后集群变得迟钝) https://elasticsearch.cn/question/84 2.ELK 性能(2) - 如何在大业务量下保持 Elasticsearch 集群的稳定 http://www.cnblogs.com/richaaaard/p/6117089.html

LVS+NGINX+TOMCAT_集群实施操作记录.docx

LVS IP: Eth0:192.168.100.115 Eth1:192.168.100.215 Vi  /etc/init.d./lvs #!/bin/sh # # lvs      Start lvs # # chkconfig: 2345 08 92 # description:  Starts, stops and saves lvs # SNS_VIP=192.168.100.215 SNS_RIP1=192.168.100.114 SNS_RIP2=192.168.100.113

高可用mongodb集群的学习记录(四mongodb分片集群搭建)

无论oracle还是mysql数据库都有分区的概念,即同一张表物理上不在同一台机器上,有效缓解了表都集中存在一台机器的压力.当然,mongodb也有类似的机制,即是分片.具体理论知识大家可以参考网上文档,我这里只记录下具体操作步骤 参考网络上一个图.我选用的是2个副本集+1个仲裁.实际上我这里分片集群需要3个mongos,3个config server,数据分片3个shard server,对应着还有3个副本,3个仲裁节点,总共需要15个实例.因为我资源确实紧张,又不想影响实验效果.冥思苦想了一

elasticsearch(es) 集群恢复触发配置(Local Gateway参数)

elasticsearch(es) 集群恢复触发配置(Local Gateway) 当你集群重启时,几个配置项影响你的分片恢复的表现. 首先,我们需要明白如果什么也没配置将会发生什么. 想象一下假设你有 10 个节点,每个节点只保存一个分片,这个分片是一个主分片或者是一个副本分片,或者说有一个有 5 个主分片/1 个副本分片的索引.有时你需要为整个集群做离线维护(比如,为了安装一个新的驱动程序), 当你重启你的集群,恰巧出现了 5 个节点已经启动,还有 5 个还没启动的场景. 假设其它 5 个节

ES集群修改index副本数报错 :index read-only / allow delete

ES集群修改index副本数,报错 :index read-only / allow delete (api) 原因: es集群数据量增速过快,导致个别es node节点磁盘使用率在%80以上,接近%90 ,由于ES新节点的数据目录data存储空间不足,导致从master主节点接收同步数据的时候失败,此时ES集群为了保护数据,会自动把索引分片index置为只读read-only. 故障处理办法: 1:集群加节点,简单粗暴: 2:降低集群index副本数量: 3:其它:增加磁盘.删除历史数据等:

ES 集群关键状态指标

ES监控状态指标分三个级别: 1:集群级别:集群级别的监控主要是针对整个ES集群来说,包括集群的健康状况.集群的状态等.2:节点级别:节点级别的监控主要是针对每个ES实例的监控,其中包括每个实例的查询索引指标和物理资源使用指标.3:索引级别:索引级别的监控主要是针对每个索引来说,主要包括每个索引的性能指标. 1集群级别: 查看方法: api获取:http://ip:9200/_cluster/health?pretty 或者 Kibana的开发工具Dev Tools中执行 : 查看集群健康状态