Prometheus 运维中实际的故障案例以及解决办法
目录
案例一：数据收集问题 - Prometheus 无法从某些 exporter 收集数据
案例二：安装问题 - 采用 Docker 进行 Prometheus server 端安装时报错
案例六：K8s 中内置的 Prometheus 异常不断重启
案例一：数据收集问题 - Prometheus 无法从某些 exporter 收集数据
异常信息：
get http://192.168.90.177:9100/metrics: context deadline exceeded问题原因：
可能是 exporter 未正确安装并运行，或者 Prometheus 配置文件中 exporter 的地址和端口配置错误，也可能是系统端口未开放。
解决办法：
- 确认 exporter 是否已正确安装并运行。
- 检查 Prometheus 配置文件中的
scrape_configs部分，确保 exporter 的地址和端口配置正确。- 若系统端口未开放，可指定其他端口或者更改防火墙访问策略。例如在 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 集成等有问题。
解决办法：
- 检查告警规则的配置文件，确保 PromQL 表达式正确无误。
- 确认告警规则中的阈值设置是否合理，根据实际情况进行调整。
- 查看 Prometheus 的告警日志，检查是否有与告警相关的错误信息。
- 确保告警通知的配置正确，如邮件服务器的设置（包括用户名、密码、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 异常不断重启
解决办法：
- 找到 Prometheus 的数据卷，清空里面的内容（Prometheus 不断重启往往是储存的数据过多引起的，程序被拖死或者无法同步）。执行命令：
kubectl get pv | grep “prometheus”- 根据名字找到不断重启的 Prometheus 项目，打开配置文件，找到节点和路径。执行命令：
kubectl get pv pvc-cb0b2232-0ddb-4828-ac5b-706916d8de63 -o yaml- 先关掉 Prometheus，命令：
kubectl edit prometheus -n kubesphere-monitoring-system k8s-system（注意命令最后的k8s-system，是根据需要选择k8s或k8s-system），然后将其实例数从 2 设置为 0（记得记录下原值）。- 到 PV 所在节点的机器上，打开所在目录（上一步命令中查看到的路径），执行命令：
cd /var/openebs/local/pvc-cb0b2232-0ddb-4828-ac5b-706916d8de63，再执行命令：ls，删除promethes-db目录，命令：rm -rf promethes-db- 回到主节点，恢复 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 一并处理，因为它们有同步机制。
原文地址：https://blog.csdn.net/LS19990712/article/details/140555484
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！