ES集群机器磁盘IO过高告警分析
文章目录
- ES集群机器磁盘IO过高告警分析
- 现象
- 分析思路与手段
- 获取告警机器的磁盘高IO时的文件
- 通过IO文件确认索引
- 分析思路
- 优化
- 第一步：每个data实例用不同的磁盘
- 第二步：业务调整数据写入的集中程度
- 第三步：扩容
反爬标记
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-csifras2/nodes/0/indices/UkSfmgG7QdW8EPPHvtYqSg/3/translog/translog-120.tloglrwx------ 1 es es 64 May 31 10:39 755 -> /data02/es-csifras2/nodes/0/indices/WMewOUANTBuA-73pcCp6Cw/16/translog/translog-220.tloglrwx------ 1 es es 64 May 31 10:39 748 -> /data02/es-csifras2/nodes/0/indices/Jrz75tNiTwORzqYTwqO4NQ/4/translog/translog-151.tloglrwx------ 1 es es 64 May 31 10:39 747 -> /data02/es-csifras2/nodes/0/indices/HySK9kG3T2C-lVZ6fVVh0A/3/translog/translog-17.tloglrwx------ 1 es es 64 May 31 10:39 1670 -> /data02/es-csifras2/nodes/0/indices/1YyrYIYHSKmziclNUsI9kw/9/translog/translog-142.tloglrwx------ 1 es es 64 May 31 10:39 1847 -> /data02/es-csifras2/nodes/0/indices/nkJsv_bTQVqtgQhyH5zw5g/5/translog/translog-49.tlogl-wx------ 1 es es 64 May 31 11:03 2145 -> /data02/es-csifras2/nodes/0/indices/nkJsv_bTQVqtgQhyH5zw5g/5/index/_rh9q.fdtlrwx------ 1 es es 64 May 31 11:33 1615 -> /data02/es-csifras2/nodes/0/indices/Rlk8B28tRDupMfAcU6XRdA/5/translog/translog-39.tlogl-wx------ 1 es es 64 May 31 12:44 1917 -> /data02/es-csifras2/nodes/0/indices/dfwY8zOsS9CAynyx3K5gkg/17/index/_krzz.fdxlrwx------ 1 es es 64 May 31 12:46 1127 -> /data02/es-csifras2/nodes/0/indices/VawhPPxBRH2aN_V7WRn6jQ/0/translog/translog-2537.tlog
l-wx------ 1 es es 64 May 31 10:39 677 -> /data02/es-csifras/nodes/0/indices/vifaaVG4QLWpcqh2iOjtXg/8/index/write.lockl-wx------ 1 es es 64 May 31 10:39 664 -> /data02/es-csifras/nodes/0/indices/dfwY8zOsS9CAynyx3K5gkg/1/index/write.locklrwx------ 1 es es 64 May 31 10:39 651 -> /data02/es-csifras/nodes/0/indices/mvDt36FTTveVVIZzo8u8iA/10/translog/translog-129.tlogl-wx------ 1 es es 64 May 31 10:39 635 -> /data02/es-csifras/nodes/0/indices/0kcg3d0hQVeazy9pxQpEYg/0/index/write.lockl-wx------ 1 es es 64 May 31 10:39 599 -> /data02/es-csifras/nodes/0/indices/j0f6ENhbT-26n5lgwuiXZg/10/index/write.locklrwx------ 1 es es 64 May 31 10:39 575 -> /data02/es-csifras/nodes/0/indices/InJZHhdiT2mRkHljuwewTw/13/translog/translog-128.tlogl-wx------ 1 es es 64 May 31 10:39 557 -> /data02/es-csifras/nodes/0/indices/Oc7SkzkSTHyTC9ge75PRaw/0/index/write.lockl-wx------ 1 es es 64 May 31 10:39 707 -> /data02/es-csifras/nodes/0/indices/KamjP2kPS-mOxyZF8MutNg/4/index/write.locklrwx------ 1 es es 64 May 31 10:39 1049 -> /data02/es-csifras/nodes/0/indices/kOT7Y0F6Qgm3DVctqUtWTQ/12/translog/translog-17.tloglrwx------ 1 es es 64 May 31 10:42 1567 -> /data02/es-csifras/nodes/0/indices/1YyrYIYHSKmziclNUsI9kw/4/translog/translog-142.tlogl-wx------ 1 es es 64 May 31 12:48 638 -> /data02/es-csifras/nodes/0/indices/UkSfmgG7QdW8EPPHvtYqSg/8/index/_klcg.fdx
通过IO文件确认索引
文件路径中存在着索引的编码，例如第一条/data02/es-csifras2/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告警，就需要进行扩容了。