概述

这里我简单描述了一下我遇到的一次 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：存储服务日志异常

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