要让 Prometheus 成为运维底座，须从权限隔离、配置规范、数据可靠和可观测闭环四方面落地：以非 root 用户运行并隔离目录；规范 prometheus.yml 配置，合理划分 job 与 scrape 节奏；正确部署验证 Exporter；通过 Alertmanager 与 Grafana 实现告警与可视化闭环。
要让 Prometheus 真正成为运维底座，关键不是“装上就行”，而是从权限隔离、配置规范、数据可靠和可观测闭环四个层面扎实落地。它不只是一套工具，更是运维思维的具象化表达。
权限与目录隔离：安全运行的第一道防线
Prometheus 服务必须以非 root 用户运行，避免因配置错误或漏洞导致系统级风险。创建专用用户并严格限定其权限范围是生产环境的硬性要求。
- 执行 sudo useradd --no-create-home --shell /bin/false prometheus 创建无登录能力的系统用户
- 创建三类独立目录：/etc/prometheus（配置）、/var/lib/prometheus（TSDB 数据）、/usr/local/bin（二进制），并统一归属 prometheus 用户
- 数据目录建议挂载到 SSD 或高性能 NVMe 分区，避免与系统日志共用磁盘，防止 I/O 竞争影响抓取稳定性
核心配置规范化：让监控可读、可维护、可扩展
prometheus.yml 不是启动脚本，而是监控策略的声明式契约。一份好的配置需兼顾基础可用性与未来扩展性，尤其注意 job 划分逻辑和 scrape 节奏控制。
- global 段中，scrape_interval 建议设为 15s～30s，evaluation_interval 保持与之同步；过短会增加目标压力，过长则延迟告警响应
- scrape_configs 按语义拆分 job：例如 'node'（主机指标）、'api'（业务服务）、'mysql'（数据库），每个 job 明确 target 来源（静态列表或服务发现）
- 对高可用目标（如 Kubernetes Pod），优先使用 service discovery（如 kubernetes_sd_configs），而非写死 IP；对固定节点（如物理服务器），用 static_configs 并加注释说明用途
Exporter 部署与验证：指标采集的真实起点
Exporter 是 Prometheus 的“感官延伸”。没有正确部署和暴露指标的 Exporter，Prometheus 就是空转的引擎。重点在于端口可达性、指标格式合规性与采集节奏匹配。
- Node Exporter 必须在每台被监控主机上运行，监听 9100 端口；确认 curl http://localhost:9100/metrics 可返回文本格式指标（以 # HELP 开头）
- GPU 监控需额外部署 nvidia_gpu_exporter（DeOldify 等 AI 服务必备），确保 nvidia-smi 可执行且驱动版本兼容
- 所有 Exporter 启动后，立即访问 Prometheus 的 /targets 页面，检查状态是否为 UP；若为 DOWN，优先排查防火墙、SELinux、target 地址解析问题
告警与可视化闭环：让监控真正产生价值
采集数据只是开始，触发有效告警、呈现清晰趋势、支持快速定位，才算完成可观测闭环。这需要 Alertmanager 和 Grafana 的协同配合，而非孤立部署。
- Alertmanager 配置需定义清晰的路由规则：按 severity 分组（warning/critical），设置抑制规则（如 kernel panic 触发时屏蔽衍生磁盘告警），对接企业通知渠道（钉钉/飞书 Webhook）
- Grafana 中导入标准仪表盘（如 Node Exporter Full），但必须基于实际业务调整阈值——CPU 使用率 80% 是否真需告警？取决于该服务的负载特征和 SLA 承诺
- 为关键服务（如 DeOldify API）单独建 dashboard，展示请求延迟 P95、GPU 显存占用、失败率等业务强相关指标，而非仅看系统层数据
