本文教你如何从零搭建一套基于 Prometheus 与 Grafana 的服务器监控体系，解决主机指标采集、服务可用性探测、告警分级与可视化看板这四个核心问题。读完你能拿到 node_exporter、blackbox_exporter、Alertmanager 的完整部署清单，以及生产环境直接可用的 Grafana 看板与告警规则模板，覆盖单机到多机的常见运维场景。
一、监控体系的整体架构
为什么很多团队上了 Prometheus 仍然在线上漏报？根本原因是把监控当成了”装个 agent 然后看图”，没有把采集、存储、可视化、告警四层拆清楚。Prometheus 的 pull 模型意味着它主动去各个 exporter 抓数据，时序数据落本地 TSDB；Grafana 负责把这些数据画成图；Alertmanager 单独承担告警分组、抑制与路由。
落地一套监控体系，最小可用形态是一台 Prometheus 主机外加各业务节点的 node_exporter。规模再大一点，建议把 Prometheus 与 Alertmanager 拆到独立主机，避免它自身宕机时连告警都发不出去。机房与节点选型可参考 云服务器选购指南。
二、Prometheus 主控的部署要点
Prometheus 主控建议跑在独立的 systemd 服务里，配置文件 prometheus.yml 至少包含三段：global 段控制 scrape_interval 与 evaluation_interval 默认 15 秒；rule_files 段引入告警规则；scrape_configs 段定义每个 job 的目标列表与采集间隔。
存储方面，本地 TSDB 默认保留 15 天，生产建议 30 天起步并打开 --storage.tsdb.retention.size 防止磁盘撑爆。如果要长期保留指标，把数据通过 remote_write 写到 Thanos 或 VictoriaMetrics，本地只做热数据。VPS 节点上线流程可参考 美国 VPS 部署教程。
三、node_exporter 与服务探测
node_exporter 是采集主机层指标的标配，覆盖 CPU、内存、磁盘 I/O、网络与文件系统几十个维度。部署时建议：
- 用 systemd 启动并加
--collector.systemd收集服务状态 - 通过
--web.listen-address绑定到内网 IP，不要暴露公网 - 在 Prometheus 端加 relabel 给每个目标补 instance 与 region 标签
- 关闭无用 collector（如 textfile）降低指标基数
- 配 firewall 仅允许 Prometheus 主控 IP 访问 9100 端口
服务可用性探测用 blackbox_exporter，它支持 HTTP、HTTPS、TCP、ICMP 多种探针。HTTP 探针建议加 status code 校验与正文关键字匹配两道关卡，光看 200 不够，应用错误页也是 200。结合 Nginx 反向代理时连通性排查请参考 Nginx 反向代理与负载均衡。
四、Grafana 看板与变量
Grafana 看板设计的关键是变量化。新手最常犯的错是给每台主机画一张图，机器一多看板就乱。正确做法是用 $instance 变量做下拉选择，一张图覆盖所有节点。
看板分层建议：第一层总览看板放集群级别指标如总 CPU、总内存、节点在线数；第二层主机看板用 instance 变量切换单机详情；第三层业务看板按服务维度组织。每张图都要写 description 说明指标含义与告警阈值，方便新人接手。
Grafana 自带的 Node Exporter Full 看板（ID 1860）可以直接用做主机看板基线，再按需要裁剪。不建议直接生产用默认面板，因为指标基数大、面板多，加载慢。
五、Alertmanager 告警分级
告警最常见的失败模式是”告警太多没人看”。Alertmanager 用三种机制对抗：分组（group_by）把同一类告警合并成一条；抑制（inhibit_rules）让父告警自动屏蔽子告警，比如主机宕机时不再发服务告警；静默（silence）支持临时屏蔽，运维窗口期不被打扰。
告警分级建议：P0 立即电话或短信，覆盖主控宕机、磁盘 100% 满；P1 工作时间 IM，覆盖服务降级、CPU 持续高位；P2 仅记录到看板，覆盖慢趋势与容量预警。每条告警规则写 runbook_url 链接到处理文档。SSH 与基础加固相关内容可参考 SSH Fail2ban 加固实战。
六、生产环境常见坑
整理一组生产里高频踩的坑。第一，时间不同步导致指标错乱，Prometheus 与所有 exporter 节点必须 chrony 同步到同一个 NTP 源。第二，标签基数爆炸，给每个请求打 user_id 作为标签会让本地 TSDB 撑爆，标签必须是有限枚举值。
第三，scrape 超时导致漏点，默认 scrape_timeout 是 10 秒，慢节点要单独调大或缩小采集范围。第四，告警评估窗口太短，CPU 一秒尖刺就告警没意义，加 for: 5m 给真实持续异常留时间。第五，远端存储链路抖动会让本地 WAL 堆积撑爆磁盘，remote_write 队列参数与 max_shards 要按吞吐量算。
七、容量规划与高可用
单台 Prometheus 的容量上限大概是百万级活跃序列，按主机一台 200 个序列估算大约能扛 5000 台机器。规模再大用 federation 做分级聚合或直接上 Thanos / VictoriaMetrics 做横向扩展。
高可用方案最简单的是双主控并行 scrape，前面再放 Thanos Query 做去重查询，Alertmanager 必须做集群（gossip 协议）避免单点。配置变更上线建议走 git 仓库加 CI/CD，每次 reload 前用 promtool check rules 验证规则文件语法，避免规则坏掉而不自知。
八、日常巡检脚本
监控体系本身也需要被监控，建议每天跑一次巡检：用 up 指标统计有多少 exporter 实际在采集；用 prometheus_tsdb_head_series 看序列数趋势防止基数爆炸；用 Alertmanager 的 alertmanager_notifications_total 看告警发送是否正常；用 prometheus_rule_evaluation_failures_total 看规则评估失败数。这套自监控能在问题真正影响业务前拦住八成隐患。
九、与日志告警的整合
Prometheus 只解决指标维度，日志维度建议用 Loki 或 Elasticsearch 配合。Grafana 同时接 Prometheus 与 Loki 数据源可以在同一张看板里看指标曲线和日志详情，告警触发时点击告警直接跳到对应时段的日志，定位速度比纯翻日志快很多。
对于关键服务的错误日志，建议用 promtail 把日志推到 Loki 并设阈值告警，比如同一错误模式 5 分钟出现超过 50 次就发 P1 告警。这样指标和日志两条线互补，单看指标看不出来的代码异常会被日志告警先发现，单看日志看不出来的资源饱和会被指标告警先发现。每条告警都写好处理 runbook，让值班工程师拿到告警就能跟着步骤排查，不必每次都从头摸索。
总结与建议
把 Prometheus 与 Grafana 落地的关键是从最小可用开始迭代：先一台主控加 node_exporter 跑起来，再补 blackbox 与告警，最后才是高可用与长期存储。建议先把 30 天数据保留与 P0 告警链路打通，再扩展业务指标。如果你需要更稳的生产监控，可以考虑给主控本身做双副本，并把告警通道分到两个独立的发送渠道。这套体系前期投入两三天，能在线上事故中省下数十小时的盲查时间。每次扩容新机器都按这套规范接入，长期保持监控覆盖率不掉队，等业务量上来时不会临阵抓瞎。