Prometheus 运维中实际的故障案例以及解决办法

目录

案例一：数据收集问题 - Prometheus 无法从某些 exporter 收集数据

案例二：安装问题 - 采用 Docker 进行 Prometheus server 端安装时报错

案例三：Prometheus 占用大量内存故障

案例四：告警配置问题 - 告警规则未触发或触发不准确

案例五：Prometheus 节点内存暴涨并频繁重启

案例六：K8s 中内置的 Prometheus 异常不断重启

---

案例一：数据收集问题 - Prometheus 无法从某些 exporter 收集数据

异常信息：

get http://192.168.90.177:9100/metrics: context deadline exceeded

问题原因：

可能是 exporter 未正确安装并运行，或者 Prometheus 配置文件中 exporter 的地址和端口配置错误，也可能是系统端口未开放。

解决办法：

1. 确认 exporter 是否已正确安装并运行。
2. 检查 Prometheus 配置文件中的 scrape_configs 部分，确保 exporter 的地址和端口配置正确。
3. 若系统端口未开放，可指定其他端口或者更改防火墙访问策略。例如在 CentOS 系统中，可使用以下命令永久开放 9100 端口：firewall-cmd --zone=public --add-port=9100/tcp --permanent，然后重新载入配置使其生效：firewall-cmd --reload；在 Ubuntu 系统中，可使用命令sudo ufw allow 9100。

 

案例二：安装问题 - 采用 Docker 进行 Prometheus server 端安装时报错

异常信息：

在持久化映射目录下没有 prometheus.yml 文件因此会被临时创建一个目录文件导致出错，或者因为持久化的数据目录权限问题，报错信息类似于level=err ts=2021-04-30t07:50:11.241z caller=query_logger.go:109 component=active_query_tracker msg="failed to create directory for logging active queries"。

解决办法：

在映射的持久化目录下创建 prometheus.yml 文件并进行相应权限配置。例如执行命令chmod +777 /nfsdisk-31/monitor/prometheus，然后使用正确的映射启动 Docker 容器，如：docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml -v /nfsdisk-31/monitor/prometheus:/prometheus prom/prometheus。需注意 Prometheus 2.x 版本容器的数据目录是 /prometheus 而非 /prometheus-data 目录。

案例三：Prometheus 占用大量内存故障

问题现象：

服务器频繁发生 I/O 负载过高，内存耗尽的问题，导致服务器短暂性失联，直到服务重启后，内存、I/O 等指标才逐渐恢复正常。

问题原因：

Prometheus 默认 2 小时会将采集的监控指标数据从内存中落到硬盘中，内存数据落盘时导致突发性 I/O 增高，由于数据首先写入内存，所以内存也逐渐耗尽。而获取节点监控指标的频率过高（本案例中为 15 秒），导致内存积累的数据过大。

解决办法：

在不考虑硬件扩容的情况下，将本地存储改为远端的时序数据库降低本地 I/O，但发现尽管配置了 remote_write / remote_read，本地还是会落盘。之后通过查看配置文件，将获取节点监控指标的频率 scrape_interval 由 15 秒调整为 1 分钟（即 1m），降低了数据采集频率，情况好转，目前内存一直稳定在 65-80%，落盘时内存会增大到最高点，数据回写完成后，降到最低点。

案例四：告警配置问题 - 告警规则未触发或触发不准确

问题原因：

告警规则的配置文件中 PromQL 表达式错误，或者告警规则中的阈值设置不合理；也可能是告警通知的配置不正确，如邮件服务器设置、Slack 集成等有问题。

解决办法：

1. 检查告警规则的配置文件，确保 PromQL 表达式正确无误。
2. 确认告警规则中的阈值设置是否合理，根据实际情况进行调整。
3. 查看 Prometheus 的告警日志，检查是否有与告警相关的错误信息。
4. 确保告警通知的配置正确，如邮件服务器的设置（包括用户名、密码、SMTP 服务器等）、Slack 集成的相关参数等。

例如，配置使用企业邮箱进行报警时显示 email.login.auth failed: 530 must issue a starttls command first 错误，这通常是因为邮件服务器要求使用 STARTTLS 加密，但没有正确配置。解决方法是在邮件客户端或相关设置中启用 STARTTLS，并确保端口和其他设置正确。

例如，显示 starttls failed: x509: certificate signed by unknown authority 错误，这可能是证书不受信任的原因。需要检查证书是否有效，或者尝试信任相关证书颁发机构的证书。

例如，若遇到 notify retry canceled after 2 attempts: *email.login.auth.auth: 535 error: 错误信息，可能是邮箱登录认证的问题，需检查邮箱用户名和密码是否正确。

 

案例五：Prometheus 节点内存暴涨并频繁重启

问题现象：

Prometheus 节点内存出现暴涨，通过内存升配暂时解决，但一段时间后内存再次拉满，且 Prometheus 每次加载 segment 期间都出现了重启。

问题原因：

Prometheus 配置的 node_exporter.yml 配置由运维平台动态生成，当天出现了 bug，每台机器都出现了重复的监控节点，导致数据异常。

解决办法：

通过查看 /var/log/message 日志找到并怀疑是异常的 node_exporter 配置影响，最后清理 Prometheus 数据目录下的 wal 目录部分当天数据，得以成功拉起 Prometheus。

 

案例六：K8s 中内置的 Prometheus 异常不断重启

解决办法：

1. 找到 Prometheus 的数据卷，清空里面的内容（Prometheus 不断重启往往是储存的数据过多引起的，程序被拖死或者无法同步）。执行命令：kubectl get pv | grep “prometheus”
2. 根据名字找到不断重启的 Prometheus 项目，打开配置文件，找到节点和路径。执行命令：kubectl get pv pvc-cb0b2232-0ddb-4828-ac5b-706916d8de63 -o yaml
3. 先关掉 Prometheus，命令：kubectl edit prometheus -n kubesphere-monitoring-system k8s-system（注意命令最后的 k8s-system，是根据需要选择 k8s 或 k8s-system），然后将其实例数从 2 设置为 0（记得记录下原值）。
4. 到 PV 所在节点的机器上，打开所在目录（上一步命令中查看到的路径），执行命令：cd /var/openebs/local/pvc-cb0b2232-0ddb-4828-ac5b-706916d8de63，再执行命令：ls，删除 promethes-db 目录，命令：rm -rf promethes-db
5. 回到主节点，恢复 Prometheus 的实例数。命令：kubectl edit prometheus -n kubesphere-monitoring-system k8s-system（注意命令最后的 k8s-system，是根据需要选择 k8s 或 k8s-system），然后将其实例数从 0 设置为 2（恢复原值）。

需注意，此处理方式会进行数据的删除，并且多实例情况下最好都进行操作。如果有多个实例，比如 Prometheus-k8s-0 和 Prometheus-k8s-1，若 Prometheus-k8s-0 一直重启，则不光需要操作 Prometheus-k8s-0，也需要对 Prometheus-k8s-1 进行处理。同理，如果是 Prometheus-k8s-system0 出问题，也需要把 Prometheus-k8s-system1 一并处理，因为它们有同步机制。