【ES实战】ES集群机器磁盘IO过高告警分析

已于 2024-06-12 11:46:19 修改
阅读量1k 收藏 9
点赞数 13
分类专栏： Elastic实战 文章标签： elasticsearch 大数据
于 2024-05-31 19:18:14 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43820556/article/details/139358424
版权

ES集群机器磁盘IO过高告警分析

文章目录

反爬标记
2024年5月31日
原文首发：https://blog.csdn.net/weixin_43820556/article/details/139358424

现象

集群的某台机器出现磁盘IO告警。磁盘IO使用率长时间处于60%以上。

分析思路与手段

获取告警机器的磁盘高IO时的文件

查看某个进程打开了哪些文件,命令：ls -l /proc/进程号/fd/

procfs是一种文件系统，通常会挂载在/proc上。ls /proc 可以看到很多以进程ID命名的文件夹，每个进程运行时的信息都记录在相应的文件夹下，而内核运行时信息直接记录在/proc下，大多是只读文件，如meminfo，cpuinfo，cmdline等，非数字命名的文件夹，是内核各子系统相关部分,如

  • drivers 驱动信息(只读)
  • fs 文件系统特别信息(只读)
  • ide IDE接口信息(只读)
  • irq IRQ信息(只读)
  • net 网络子系统信息(只读)
  • scsi SCSI系统信息(只读)
  • sysvipc IPC子系统信息(只读)
  • tty tty子系统信息(只读)
  • sys 系统内核可调参数 (可调)

通过访问这些文件和文件夹，我们可以实时查询到当前系统的运行信息，甚至是某一进程的运行时信息。

lrwx------ 1 es es 64 May 31 10:22 1605 -> /data02/es-demo2/nodes/0/indices/UkSfmgG7QdW8EPPHvtYqSg/3/translog/translog-120.tlog

lrwx------ 1 es es 64 May 31 10:39 755 -> /data02/es-demo2/nodes/0/indices/WMewOUANTBuA-73pcCp6Cw/16/translog/translog-220.tlog

lrwx------ 1 es es 64 May 31 10:39 748 -> /data02/es-demo2/nodes/0/indices/Jrz75tNiTwORzqYTwqO4NQ/4/translog/translog-151.tlog

lrwx------ 1 es es 64 May 31 10:39 747 -> /data02/es-demo2/nodes/0/indices/HySK9kG3T2C-lVZ6fVVh0A/3/translog/translog-17.tlog

lrwx------ 1 es es 64 May 31 10:39 1670 -> /data02/es-demo2/nodes/0/indices/1YyrYIYHSKmziclNUsI9kw/9/translog/translog-142.tlog

lrwx------ 1 es es 64 May 31 10:39 1847 -> /data02/es-demo2/nodes/0/indices/nkJsv_bTQVqtgQhyH5zw5g/5/translog/translog-49.tlog

l-wx------ 1 es es 64 May 31 11:03 2145 -> /data02/es-demo2/nodes/0/indices/nkJsv_bTQVqtgQhyH5zw5g/5/index/_rh9q.fdt

lrwx------ 1 es es 64 May 31 11:33 1615 -> /data02/es-demo2/nodes/0/indices/Rlk8B28tRDupMfAcU6XRdA/5/translog/translog-39.tlog

l-wx------ 1 es es 64 May 31 12:44 1917 -> /data02/es-demo2/nodes/0/indices/dfwY8zOsS9CAynyx3K5gkg/17/index/_krzz.fdx

lrwx------ 1 es es 64 May 31 12:46 1127 -> /data02/es-demo2/nodes/0/indices/VawhPPxBRH2aN_V7WRn6jQ/0/translog/translog-2537.tlog

l-wx------ 1 es es 64 May 31 10:39 677 -> /data02/es-demo/nodes/0/indices/vifaaVG4QLWpcqh2iOjtXg/8/index/write.lock

l-wx------ 1 es es 64 May 31 10:39 664 -> /data02/es-demo/nodes/0/indices/dfwY8zOsS9CAynyx3K5gkg/1/index/write.lock

lrwx------ 1 es es 64 May 31 10:39 651 -> /data02/es-demo/nodes/0/indices/mvDt36FTTveVVIZzo8u8iA/10/translog/translog-129.tlog

l-wx------ 1 es es 64 May 31 10:39 635 -> /data02/es-demo/nodes/0/indices/0kcg3d0hQVeazy9pxQpEYg/0/index/write.lock

l-wx------ 1 es es 64 May 31 10:39 599 -> /data02/es-demo/nodes/0/indices/j0f6ENhbT-26n5lgwuiXZg/10/index/write.lock

lrwx------ 1 es es 64 May 31 10:39 575 -> /data02/es-demo/nodes/0/indices/InJZHhdiT2mRkHljuwewTw/13/translog/translog-128.tlog

l-wx------ 1 es es 64 May 31 10:39 557 -> /data02/es-demo/nodes/0/indices/Oc7SkzkSTHyTC9ge75PRaw/0/index/write.lock

l-wx------ 1 es es 64 May 31 10:39 707 -> /data02/es-demo/nodes/0/indices/KamjP2kPS-mOxyZF8MutNg/4/index/write.lock

lrwx------ 1 es es 64 May 31 10:39 1049 -> /data02/es-demo/nodes/0/indices/kOT7Y0F6Qgm3DVctqUtWTQ/12/translog/translog-17.tlog

lrwx------ 1 es es 64 May 31 10:42 1567 -> /data02/es-demo/nodes/0/indices/1YyrYIYHSKmziclNUsI9kw/4/translog/translog-142.tlog

l-wx------ 1 es es 64 May 31 12:48 638 -> /data02/es-demo/nodes/0/indices/UkSfmgG7QdW8EPPHvtYqSg/8/index/_klcg.fdx

通过IO文件确认索引

文件路径中存在着索引的编码，例如第一条/data02/es-demo2/nodes/0/indices/UkSfmgG7QdW8EPPHvtYqSg/3/translog/translog-120.tlog中UkSfmgG7QdW8EPPHvtYqSg，就是索引的唯一编码。

通过ES的APIGET _cat/indices?v&s=index ，来得到集群的索引列表

health status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   .kibana                         S5jrM7mpTPaucEcOZoig2A   1   1          1            0      7.7kb          3.8kb
green  open   .monitoring-data-2              TmP7dYptQAqwniPcaDF27g   1   1         11       171731     11.4mb          5.7mb
green  open   .triggered_watches              jvBeA2uhRzq_DNvKN1PB5Q   1   1          0            0     50.3mb         25.1mb
green  open   .watches                        8N-2aka1Sx-NhYnEMv2sww   1   1          0            0       320b           160b
green  open   data_source-202405              UkSfmgG7QdW8EPPHvtYqSg  10   1  104486864            0    448.3gb          223gb

可以发现索引的uuid就在路径中。

分析思路

通过上面的众多索引，分析出索引都是正常读写，都是一些当月索引，判断是月末或月初，一些数据集中处理了，属于正常业务范畴。

再分析路径，发现有/data02/es-demo和/data02/es-demo2, 判断集群是单机器双data实例部署。通过检查ES的elasticsearch.yaml文件中的data.path和查询集群节点情况GET _cat/nodes?v&s=ip，发现确实是单集群双data实例部署时共用了磁盘，这就导致了磁盘的IO过高的概率大大提升了。

GET _cat/nodes?v&s=ip结果：

ip            heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.1.1             67          97  21    8.99    9.31     9.54 di        -      bdes02-demo-prd
192.168.1.1             64          97  21    8.99    9.31     9.54 di        -      bdes02-demo-prd2
192.168.1.1             15          97  22    8.99    9.31     9.54 mi        -      bdes02-demo-prd-master
192.168.1.149           66          97  22   12.65   15.18    17.33 di        -      bdes64-prd1
192.168.1.149           68          97  21   11.14   14.93    17.26 di        -      bdes64-prd2
192.168.1.149           10          97  20   11.14   14.93    17.26 mi        -      bdes64-prd1-master
192.168.1.150           71          97  17    9.11    8.44     8.75 di        -      bdes65-prd2
192.168.1.150           65          97  17    9.11    8.44     8.75 di        -      bdes65-prd1
192.168.1.151           67          97   7    5.07    5.40     5.81 di        -      bdes66-prd2
192.168.1.151           68          97   7    5.07    5.40     5.81 di        -      bdes66-prd1
192.168.1.2             14          98  24    9.31    9.83     9.82 mi        *      bdes03-demo-prd-master
192.168.1.2             70          98  19    9.31    9.83     9.82 di        -      bdes03-demo-prd
192.168.1.2             65          98  23    9.31    9.83     9.82 di        -      bdes03-demo-prd2
192.168.1.3             67          98  17    7.61    8.71     8.81 di        -      bdes04-demo-prd2
192.168.1.3             69          98  16    7.61    8.71     8.81 di        -      bdes04-demo-prd

优化

第一步：每个data实例用不同的磁盘

方式一：扩容式重启节点，先扩容对应机器，迁移数据，修改源data实例配置，滚动重启各个data实例，回迁数据。卸载扩容机器。操作周期短，影响时间短。但是需要借用额外的机器。

方式二：滚动式重启节点，集群类原机器，可以在减少一台机器的情况下，容纳索引数据，进行单机器排除数据后，修改配置，重启节点。操作周期长，影响时间短长。

第二步：业务调整数据写入的集中程度

需要梳理具体业务，分散数据写入的集中程度。若难度较大，且资源允许的情况下，可以先做第三步。

第三步：扩容

在达成第一步后，若还经常发生IO告警，就需要进行扩容了。

顧棟
关注
  • 13
    点赞
  • 踩
  • 9
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Kinbase ES 优化之IO优化
lyu1026的博客
09-18 73
IO 资源作为目前服务器中最昂贵的资源之一，是目前绝大部分业务系统主要的瓶颈资源，原因就在于服务器相关的硬件资源中IO资源的性能提升是难度最大的。存储的发展步伐远低于内存和CPU的发展。 在数据库管理系统中，IO是十分宝贵的，所以在数据库管理系统中我们希望操作尽可能在内存中完成，如果在一次事务中发生过多的IO就意味着性能的下降。 所以如何保证IO资源的性能最大化也是数据库管理系统优化的重中之重。...
基于以太网 IO 报警系统实现
10-26
在工业领域中,尤其是数据采集及控制不再独立,两者往往是相互制约,互为条件。比 如,工业现场的温度,水压,等等在现场设备出现故障后到达某设定时,监控室警告灯及警告声音启动。
ES CPU和磁盘IO升高
weixin_30435261的博客
01-12 1536
问题 ES监控出现偶尔的波动，CPU和磁盘IO升高 有时候在凌晨，业务请求比较低，也没有慢查询，GC也比较正常，没有出现Full GC ES内部的merge segment会占用CPU和磁盘资源，怀疑是这个导致，现针对merge segment做一下优化; 优化 ES是准实时的搜索，往ES插入数据时，先会写内存，内存的数据不可搜索，会定时将内存中的数据flush到磁盘，默认时间是1S...
记录elasticsearch 磁盘io过高的排查
qq_43753286的博客
01-09 3690
GET index/settings |grep refresh_interval 查看索引设置的刷新策略的间隔 当数据添加到索引后并不能马上被查询到，等到索引刷新后才会被查询到。 refresh_interval 配置的刷新间隔。 refresh_interval 的默认值是 1s。 GET index/settings |grep flush_threshold 默认设置为：每 30 分钟主动进行一次 flush，或者当 translog 文件大小大于 512MB 时主动触发flush。
ES7.5升级7.17后在写多读少场景下CPU、IO飙升
qq_33999844的博客
09-29 2102
ES PAAS管理的集群升级了100+，从7.5升级到7.17 （保证每个大版本最终仅维护一个小版本集群），由于业务使用差异大，也出了不少问题，前面的文章也有提到过Integer类型字段使用terms查询效率低的情况...
磁盘IO告警问题排查记录-MyBatis日志源码分析
执笔晓浮沉的博客
12-20 766
背景 业务凌晨收到磁盘IO告警，每秒内IO操作时长平均占用比例大于90% 分析 查看磁盘IO监控指标 发现有一个操作，该操作导致大量的磁盘读写IO。 cpcatalina.outcatalina.out-2021-12-18 了解背后的原因发现，业务日志大量输出到了tomcat的catalina.out中，期间有收到磁盘满的告警，因此才做了这样的一个日志轮转：先拷贝一份，然后旧的日志清空。 分析结果：业务日志写入tomcatcatalina.out中，导致磁盘占满，所以做了日志轮转策...
携程新一代监控告警平台Hickwall架构演进
01-27
总的来说，Hickwall的架构演进体现了携程在监控告警领域的技术探索与创新，从最初的ElasticSearch到自研Influxdb集群，再到Incluster的分布式解决方案，都是为了提高系统的稳定性和效率，确保对线上状态的实时监控...
elasticsearch-head.zip
08-01
Elasticsearch Head 插件是由 Gravitee.io 团队开发的，它作为一个轻量级的Web应用，可以通过浏览器直接访问来查看和操作Elasticsearch集群。以下是Head插件的主要功能： 1. **集群视图**：展示集群的整体状态，...
elasticsearch插件
08-20
其中，Elasticsearch-head便是这样一个强大的可视化插件，它提供了直观的界面，使得用户可以更轻松地管理和监控Elasticsearch集群。 **Elasticsearch-head介绍** Elasticsearch-head是一款基于Web的Elasticsearch...
ES优化1
08-08
Elasticsearch(ES) 是一款高性能的全文搜索引擎，广泛应用于数据...通过以上优化策略，可以显著提升Elasticsearch集群的运行效率，保证数据的安全性和检索性能。在实际部署中，应根据具体环境和需求灵活调整各项配置。
Linux ❀ 磁盘IO较大故障告警排查确认方法
无糖可乐没有灵魂
10-10 840
在日常运维工作中，经常会遇到Linux服务器出现Disk磁盘I/O（ I/O 英文全称是 Input/Output，中文译为 输入与输出，通常指存储器与其他设备之间的数据交换操作）过大告警问题需要紧急处理，本文将详细介绍此问题的排查方法与技巧。数值为100%，必然触发告警，但现网中并没有高额的数据写入，因此只能判断为误报。iotop具有与top相似的UI回显，其中包括PID、用户、I/O、进程等相关信息。例如：某个磁盘/dev/sda1在1s内持续写入1b/s，此时。功能是用于监视系统I/O设备使用情况。
关于定位elasticsearch某个节点IO读异常高
qq_45136592的博客
06-16 1658
关于定位elasticsearch某个节点IO读异常高 1.背景 公司一家客户更新最新的搜索的代码后，搜索的时候读写偶尔飙升到很高，后面运维将给elasticsearch的堆内存给到了12g后，IO一直飙升到很高，一直维持在那个水平 2.思考 刚开始一点头绪没有，尝试了重启该节点，可是一起来，I/O就维持到很高的水平，从网上查资料很多人说是合并段的问题，但是对底部的概念不是很熟的话不敢乱操作 3.查资料 原来elasticsearch搜索的时候会先将搜索的内容加载到filesysystem cache中，如
Elasticsearch实战-磁盘IO被打满
xiexiaojing的博客
09-09 3252
背景事情是这样的。一天下午4点42分左右。业务反馈我开发的服务在测试环境出现问题，返回资源数据是0。查日志发现是ES访问超时。相当于数据库挂了。持续了20多分钟自己恢复。...
大数据量 导入 数据校验_ES大数据量同步，如何又快又稳？
weixin_39804629的博客
12-04 603
01 背景 需求要根据商家名称、经纬度对商家列表进行地理位置检索和全文检索，目前这部分数据是缓存在 MongoDB 上，虽然说 MongoDB 支持全文索引，但是对于中文检索，MongoDB 似乎做的还不是非常好，线上也会经常出现查询超时的情况。所以经过考虑研究后，决定改用 Elasticsearch 作为搜索引擎。目前线上的百万数据需要同步到 Elasticsearch，...
elasticsearch 索引搜索和索引性能优化配置——思路：去掉不必要的数据，减小数据的磁盘空间占用，同时提升性能...
djph26741的博客
06-02 156
压缩配置： index.codec: best_compression 合并索引： curl –XPOST localhost:9200/hec_test3/_forcemerge’ 配置mapping： curl -XPUT 'http://localhost:9200/hec_test3' -d ' { "mappings": { "hec_t...
ElasticSearch优化建议
BUGdeQD的博客
10-10 278
原文链接：https://blog.csdn.net/qq_35977237/article/details/79870158 1.调大系统的“最大打开文件数”，建议32k甚至64k - ulimit -a (查看) - ulimit -n 32000(设置) 2. 修改配置文件调整es的jvm内存大小 修改bin/elasticsearch.in.sh中ES_MIN_MEM和ES_MAX_...
【Elasticsearch】 实际生产中的监控及调优
东方鲤鱼 博客
06-20 3807
一个 Elasticsearch 集群至少包括一个节点和一个索引。或者它可能有一百个数据节点、三个单独的主节点，以及一小打客户端节点——这些共同操作一千个索引（以及上万个分片）。不管集群扩展到多大规模，你都会想要一个快速获取集群状态的途径。API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好，或者警告你集群某个地方有问题。
Elasticsearch利用cat api快速查看集群状态、内存、磁盘使用情况
weixin_30737363的博客
10-22 1549
使用场景 当Elasticsearch集群中有节点挂掉，我们可以去查看集群的日志信息查找错误，不过在查找错误日志之前，我们可以通过elasticsearch的cat api简单判断下各个节点的状态，包括磁盘，heap，ram的使用情况，先做初步判断。 在浏览器中输入： localhost:9200/_cat/nodes?v&h=http,version,jdk,disk.tot...
selenium知乎反爬
最新发布
05-07
Selenium是一个自动化测试工具，可以模拟用户在浏览器中的操作。知乎作为一个知识分享社区，为了保护用户的隐私和防止恶意爬取，采取了一些反爬措施。以下是一些可能用于反爬的措施： 1. 动态加载：知乎使用了Ajax等技术进行页面内容的动态加载，使得页面内容不是一次性全部加载出来的。这样可以防止简单的爬虫直接获取到所有内容。 2. 验证码：知乎在一些敏感操作或者频繁请求时会出现验证码，需要用户手动输入验证码才能继续操作。这种方式可以有效防止自动化程序的访问。 3. 用户行为分析：知乎可能会通过分析用户的行为模式来判断是否是爬虫。例如，如果一个IP地址在短时间内频繁访问大量页面，可能会被认为是爬虫。 4. Cookie验证：知乎可能会使用Cookie来验证用户的身份和行为。如果没有正确的Cookie信息，可能无法正常访问页面。 需要注意的是，以上只是一些可能的反爬措施，具体的反爬策略可能会根据实际情况而有所不同。为了避免触发反爬机制，建议使用合理的访问频率、模拟真实用户行为，并且遵守网站的使用规则。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

顧棟

若对你有帮助，望对作者鼓励一下

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值