在 Kubernetes 集群里部署 Prometheus，真正容易卡住的通常不是 Pod 能不能启动，而是监控目标有没有被发现、数据能不能持久保存，以及告警和可视化组件是否使用了同一套数据源。下面按从准备到排查的顺序梳理一套实践路径，并比较 Helm 与手动部署的取舍。
部署前先确定监控范围
先列清楚要采集哪些对象：集群节点、工作负载、控制面组件，还是业务服务。不同目标的发现方式和权限要求并不完全相同。尤其要确认被监控服务是否暴露了 Prometheus 可抓取的指标，以及 Prometheus 所在的命名空间和权限能否访问这些目标。
生产环境还应提前考虑数据保留与持久化。Prometheus 的本地时序数据会占用存储；如果使用临时存储，Pod 重建或迁移可能导致历史数据丢失。存储容量、保留策略和资源限制应结合集群规模及采集范围评估，不宜直接照搬测试环境配置。
开始部署前，建议检查以下事项：
- 目标服务是否已暴露指标，网络路径是否可达。
- Prometheus 需要发现哪些命名空间和服务，权限范围是否足够。
- 是否需要持久化数据，以及存储资源是否已准备好。
- 是否计划使用 ServiceMonitor；如果使用，需要确认集群具备相应的自定义资源定义和控制器。
- Grafana 将连接到哪个 Prometheus 实例，访问权限如何管理。
Helm 部署与手动部署怎么选
Helm 的优势是安装、升级和回滚路径较集中，常见组件之间的关联也更容易统一管理。对于希望尽快获得 Prometheus、Grafana 及服务发现能力的团队，基于 Helm 的监控套件通常更省力。代价是需要理解其配置层级和默认资源，定制时也要确认修改的是正确的配置入口，避免升级后覆盖手工改动。
手动部署则更适合希望逐项掌握组件职责、精简安装内容，或已有既定资源管理流程的团队。它能让权限、存储、抓取规则和服务暴露方式更明确，但相关对象需要自行维护；组件之间的版本兼容、配置关联和升级顺序也需要额外关注。
两种方式并非“自动化”和“可控”的简单对立。若团队已有稳定的 Helm 配置管理流程，Helm 可以兼顾可重复部署和可追踪变更；如果集群中的权限边界、资源命名或发布流程有特殊要求，手动管理可能更容易逐项审查。关键是把安装配置纳入版本管理，避免长期依赖临时命令或集群内手工修改。
无论选哪种方式，配置文件都应围绕同一组决策组织：Prometheus 的采集目标、服务发现范围、存储设置和资源限制；Grafana 的数据源与访问方式；以及相关服务的权限和网络策略。实际部署时，应将这些项目写入对应的 Helm 配置或 Kubernetes 资源清单，并根据集群环境填入命名空间、标签和存储配置。由于这些值依赖集群实际情况，不应直接套用不匹配的示例参数。
配置 ServiceMonitor 时重点检查发现链路
ServiceMonitor 不是 Prometheus 本身的通用配置项，而是由 Prometheus Operator 一类控制器识别的自定义资源。若集群只有独立运行的 Prometheus，却没有相应的自定义资源定义和控制器，仅创建 ServiceMonitor 并不会自动产生采集任务。
配置时需要把几层关系对应起来：ServiceMonitor 选择目标 Service，目标 Service 再将流量指向实际工作负载；Prometheus 实例还必须允许发现该 ServiceMonitor 所在的命名空间或标签范围。只要其中一层的标签或选择范围不匹配，资源可能创建成功，但目标仍不会出现在采集列表中。
可以把配置示例拆成三部分维护，而不是只检查一份清单：
- 工作负载提供指标端点，并能被集群网络访问。
- Service 对应工作负载，并正确暴露指标端口。
- ServiceMonitor 选择该 Service，且 Prometheus 的发现范围包含它。
排查时从目标 Service 的标签和端口开始，再检查 ServiceMonitor 的选择条件，最后核对 Prometheus 对 ServiceMonitor 的发现范围。不要仅凭自定义资源状态正常就判断采集链路已经打通。
Grafana 可视化与数据源验证
Grafana 的面板能否显示数据，首先取决于它是否连接到正确的 Prometheus 数据源。部署完成后，先验证数据源连接，再查看是否能查询到目标指标；如果数据源可用但面板空白，应继续判断是查询表达式不匹配、目标未被采集，还是所选时间范围内没有数据。
面板应服务于具体运维判断，而不是单纯堆叠图表。集群资源、工作负载状态和业务指标可以分开组织，并明确每张面板对应的问题。例如，资源曲线用于观察变化，状态信息用于定位异常对象。告警阈值和面板展示也应基于实际服务要求设置，不要把示例环境的数值直接视为生产标准。
数据源、面板和告警规则应纳入可重复管理。否则 Grafana 实例重建后，手工配置可能无法恢复，也难以审查变更。部署方式不同，配置管理的具体做法会有差异，但应避免只把关键设置留在界面操作记录里。
常见问题排查路径
Prometheus 已运行，但没有监控目标。 先确认目标服务是否暴露指标，再检查 Service 是否选中对应工作负载、ServiceMonitor 是否选中该 Service，以及 Prometheus 是否允许发现相关资源。若使用手动部署，还要核对抓取配置是否包含目标；若使用 Helm 管理，则确认实际生效的配置与预期一致。
ServiceMonitor 已创建，但没有采集数据。 优先排查控制器和自定义资源是否存在，再核对命名空间范围、标签选择条件及服务端口关联。问题往往不是资源创建失败，而是发现链路中的选择条件没有匹配。
Grafana 显示无数据。 先区分数据源连接失败和查询结果为空。连接失败时检查数据源地址及网络访问；查询为空时回到 Prometheus 验证目标状态和指标是否存在，再检查面板查询条件。直接更换面板通常不能解决采集端的问题。
Pod 重建后历史数据消失。 检查 Prometheus 是否使用持久化存储，以及存储卷是否与工作负载正确关联。若数据存放在临时空间，重建后丢失并不意外；应先明确保留需求，再调整存储设计。
采集权限过宽或目标范围过大。 重新审视命名空间发现范围和访问权限。监控系统需要足够权限才能发现目标，但不应因此默认授予不必要的集群范围权限。范围变化后，还要验证原有目标是否仍被发现。
部署完成的判断标准不是组件都处于运行状态，而是目标能够被发现、指标能够查询、Grafana 能展示数据，并且数据存储与权限符合预期。先用少量代表性目标验证完整链路，再逐步扩大采集范围，比一次性铺开后再追查配置遗漏更稳妥。
