验证prometheus.yml合法需运行prometheus --config.file=路径 --dry-run，返回码0即通过；常见错误是tab缩进、scrape_configs漏“-”、rule_files路径或格式错误。
直接上结论：用二进制包 + systemd 是 Linux 生产环境最稳的安装方式，但prometheus.yml写错缩进、--web.listen-address没放开、rule_files路径配错这三处，占了 80% 的启动失败和告警不触发问题。
怎么验证 prometheus.yml 配置是否合法
Prometheus 启动前必须做语法校验，否则只会报 failed to load configuration，连哪行出错都不告诉你。
- 运行
prometheus --config.file=/usr/local/prometheus/prometheus.yml --dry-run，返回码为 0 才算通过 - 常见报错
yaml: line 12: did not find expected key，90% 是用了 tab 而不是空格缩进，或scrape_configs下漏写了- - 如果用 CI/CD 自动部署，务必把
--dry-run加进 pre-check 步骤，别等上线才发现配置崩了
为什么 targets 页面看不到自己的 prometheus 实例
默认配置里 scrape_configs 写 localhost:9090，本地单机部署时大概率采集不到——因为 Prometheus 进程监听的是 127.0.0.1:9090，而它的抓取请求走的是本机网络栈，但某些系统（比如启用了 IPv6 或容器环境）下 localhost 解析可能不稳定。
- 改成
127.0.0.1:9090最可靠，前提是启动时加了--web.listen-address="0.0.0.0:9090"（不能只写localhost:9090） - 如果用 Docker，
host.docker.internal在 Desktop 版可用，但在 Linux 服务器上得手动加--add-host=host.docker.internal:host-gateway -
honor_labels: true会覆盖job和instance标签，导致目标识别混乱，调试阶段建议先关掉
alert.rules.yml 加载后没反应怎么办
改完规则文件，Prometheus 不会自动重载，而且即使重载成功，规则也不一定生效——路径、结构、命名全得踩对点。
-
prometheus.yml中的rule_files必须是数组：rule_files: ["/usr/local/prometheus/alert.rules.yml"]，写成字符串会静默失败 -
alert.rules.yml文件开头必须是groups:，每个 group 包含name和rules，缺一不可；alert名称只能含字母、数字、下划线，不能有空格或点号（CPUHigh可以，CPU.High不行） - 改完规则后执行
curl -X POST http://127.0.0.1:9090/-/reload，但前提是启动时加了--web.enable-lifecycle，否则返回 405
systemd 启动后日志里报 permission denied
这是权限配置最常卡住的地方：Prometheus 进程以非 root 用户（如 prometheus）运行，但数据目录、配置文件、二进制本身权限不对，就会在 journalctl -u prometheus 里看到一堆 permission denied。
- 确保
/usr/local/prometheus目录及其子目录全部归prometheus:prometheus所有：sudo chown -R prometheus:prometheus /usr/local/prometheus -
prometheus.yml和alert.rules.yml至少要有644权限，不能是600（用户私有） - 二进制文件
/usr/local/prometheus/prometheus需要可执行权限：sudo chmod +x /usr/local/prometheus/prometheus - 如果开了
--storage.tsdb.path，对应目录（比如/usr/local/prometheus/data）也得归prometheus用户所有，且不能挂载在 noexec 或 nosuid 的文件系统上
真正难的不是装上 Prometheus，而是让它持续稳定地拉取、存储、查询、触发告警。很多故障不是配置写错了，而是某次磁盘满了没监控到、某条 rate() 表达式没加 [5m] 导致瞬时毛刺被放大、或者 Alertmanager 的 group_wait 设得太长，关键告警延迟了两分钟才发出来——这些细节，才是线上跑稳的关键。
