概述

这里我简单描述了一下我遇到的一次 prometheus hang 住但是却不太完全的一个定位过程。虽然不是一个完整的定位过程,但是,却是一个参考方向,那就是存储会很影响 prometheus 的功能。

问题现象

图 1:Prometheus 进程状态

但是,却不提供服务且 9090 端口无法访问:

图 2:prometheus API 无法访问

定位过程

看是否存在网络访问

首先得检查一下内部状态,看是完全卡死了还是说只是提供 Web 服务的接口不响应了:

[[email protected]]# lsof -p 18244

发现卡住了居然没响应,心中有些不妙,怀疑系统问题了,于是先 top 一把看看:

[[email protected]]# top

发现有很多进程大量占用 CPU:

图 3:进程大量占用 CPU

先确认一下 Prometheus 的 cgroup 是否配置在相同的 CPU 核上:

[[email protected]]# cat /proc/18244/cgroup 
... ...
10:cpuset:/xxx/app
... ...
[[email protected]]# cat /etc/cgconfig.conf | grep -A 3 app
group xxx/app {
    cpuset {
        cpuset.cpus = "4,5";
        cpuset.mems = "0-1";

然后看 top 中对应 CPU 核心的使用情况,发现情况好像有些糟糕,体现在内核的 CPU 使用率不低,等待 IO 的也不少:

图 4:CPU 核心情况(top,按 1)

下一步就是要看一下 prometheus 自己是什么状态了

看 prometheus 自身状态

嗯!?进程不存在了。

结局

测试同学把我的服务重启了。。。。

图 5:服务被重启了

但是看到了一些问题,挂载存储失败了,所以怀疑是存储的问题,转而定位存储的问题:

图 6:存储服务日志异常

然后就算结尾了,可惜了我的定位过程没有完成。