Prometheus Helm Chart部署中探针失败的排查与解决

在Kubernetes环境中使用Helm部署Prometheus时，经常会遇到容器探针(Readiness/Liveness Probe)失败的情况。本文将以一个典型故障案例为基础，深入分析问题原因并提供解决方案。

问题现象

用户在使用Helm Chart部署Prometheus时，发现Pod的Readiness和Liveness探针持续失败。具体表现为：

• 直接访问9090端口返回200状态码
• 访问/-/ready端点却返回404错误
• 容器日志没有明显错误信息
• 部署环境为K3s集群（Raspberry Pi 4节点）

根本原因分析

经过排查发现，这是由于Prometheus的baseURL配置不当导致的。当用户自定义了baseURL但没有相应调整探针路径时，就会导致健康检查端点无法访问。

Prometheus的健康检查机制：

1. 默认健康检查路径为/-/healthy和/-/ready
2. 这些端点用于Kubernetes的Readiness和Liveness检查
3. 当baseURL被修改时，实际端点路径会变为${baseURL}/-/ready

解决方案

1. 检查values.yaml配置：确认server.baseURL是否被意外修改
2. 两种修复方式：
   • 恢复baseURL为默认值（空字符串）
   • 同步调整探针配置，使其包含baseURL前缀

推荐配置示例：

server:
  baseURL: ""  # 保持默认空值
  
  # 或者明确指定探针路径
  readinessProbe:
    httpGet:
      path: "/-/ready"
  livenessProbe:
    httpGet:
      path: "/-/healthy"

经验总结

1. 修改任何监控组件的URL前缀时，必须同步考虑健康检查路径
2. 在K3s等轻量级环境中部署时，资源限制可能影响探针响应时间
3. 建议先使用默认配置验证基本功能，再逐步添加自定义配置
4. 通过kubectl exec进入容器手动测试端点可达性是有效的排查手段

最佳实践建议

1. 生产环境中建议：
   • 适当延长探针的initialDelaySeconds
   • 调整failureThreshold和periodSeconds参数
2. 对于资源受限环境：
   • 考虑降低Prometheus的资源请求量
   • 监控容器实际内存使用情况
3. 使用Helm dry-run模式验证配置变更：

   helm install --dry-run --debug prometheus prometheus-community/prometheus
   

通过系统性地分析配置依赖关系，可以有效避免这类端点访问问题，确保Prometheus在Kubernetes环境中稳定运行。