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 一并处理,因为它们有同步机制。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值