概述
Es在启动的过程中, 由于获取不到cgroup的系统资源控制的信息, 导致启动失败, 下面对该问题进行具体排查
解决方案
重启异常的机器, 执行reboot
异常信息
从异常的堆栈中发现在, readSysFsCgroupCpuAcctCpuAcctCfsQuota, getCgroupMemoryLimitInBytes等操作时发生空指针异常, 从PathUtil, UnixFileSystem这些信息来看是和操作系统相关, 会出现空指针, 一般来说应该是这个文件不存在
排查过程
粗略查看Es的源码这块的处理逻辑, 定位异常
参考 聊聊Elasticsearch的OsProbe, 概括的说就是去获取cgroup的资源信息, 主要是cpu、cpuacct和memory; 用作Es的资源监控, 如cat接口的机器负载信息, 磁盘超过阈值后触发写入拒绝操作等等
Cgroup 是 Linux kernel 的一项功能：它是在一个系统中运行的层级制进程组，你可对其进行资源分配（如 CPU 时间、系统内存、网络带宽或者这些资源的组合）。通过使用 cgroup，系统管理员在分配、排序、拒绝、管理和监控系统资源等方面，可以进行精细化控制。硬件资源可以在应用程序和用户间智能分配，从而增加整体效率。
执行命令对比
cat /proc/self/cgroup(或cat /proc/cgroup) --> cd /sys/fs/group/memory
从结果来看, 异常机器的确缺失了大部分的cgroup信息, memory目录为空, 例如刚才的异常中需要获取的memory.limit_in_bytes;
既然缺失这些文件, 那么从正常机器copy过去便可以了, 上传的时候会提示失败 failed to upload; 查看权限得知该目录支持目录创建和读取, 不支持其他的操作, 也无法通过chmod授权; 在正常机器，memory下可以创建目录, 创建时下图右下角的那些文件也会一同创建; 但是在异常的机器上, 创建失败，提示只读文件系统, 这里可以进一步确定是机器环境的问题
查看操作系统日志
在/sys/fs/group/memory下无法创建目录, 目录下也没有文件, 那应该是操作系统级别的异常了; 这时候应该去查看一下系统的操作日志, 根据一些关键字进行grep, 如fail, error,bar,cgroup等 ; Linux的日志作用说明, 可参考 在linux中怎么查看错误日志,
这里重点关注 message和dmesg日志, message的日志包含了dmesg的部分; dmesg同时还是一个Linux命令, 用法很简单, 在出现问题的时候, 可以实时查看操作记录
过滤dmesg和message日志
执行 more dmesg | egrep -i 'error|fail|bar' , 在dmesg中出现no space for [io size 0x100] , failed to assign,
那应该是和io或者磁盘空间有关, 查看df -hl空间足够, 那么no space的嫌疑可以初步排除; 使用刚才的命令过滤messages日志, 找到异常的时间点, 和相关人员确定发生问题的时间点, 确定在这个时间点有在做es的大量读写操作
依照我的理解, 这时候系统IO请求过于密集, 加上虚拟机的性能比较差, 导致短时间内系统进入部分瘫痪状态;在重启机器后, cgroup的信息获取恢复正常,memory下也可以创建目录 , Es启动成功
