Prometheus 告警不是把 CPU、内存、磁盘曲线全部接进工具就算完成。真正有价值的监控，应该解决“谁在异常、影响什么、下一步如何处理”这三个问题。本文会用一套适合中小网站和业务服务器的实战路径，帮助你从 Prometheus 指标采集、Grafana 看板整理，到 Alertmanager 通知分级，搭建一个能发现问题、能定位问题、也能复盘优化的监控闭环。
如果你已经看过基础的服务器性能排查文章，本文的重点会更靠近“落地”：少讲抽象概念，多讲部署顺序、配置边界、告警阈值和验证动作。我们不会追求一次覆盖所有指标，而是先把最容易影响线上访问的资源、服务和通知流程跑通。
先定监控边界：哪些指标真的需要触发告警
很多团队第一次接入 Prometheus 时，会把所有 exporter 都装上，几天后收到几十条通知，却没有一条能指导处理。更稳妥的做法，是先把告警分成资源层、服务层和业务入口三类。资源层关注 CPU、内存、磁盘、网络；服务层关注 Web、数据库、队列等进程是否可用；业务入口关注 HTTP 状态码、接口响应时间和健康检查结果。
对一台承载网站的 Linux 服务器来说，第一批指标可以控制在 8 到 12 个。CPU 使用率连续 10 分钟高于 85%，说明需要排查进程竞争；可用内存低于 10% 且 swap 持续增长，说明应用可能出现泄漏或缓存失控；磁盘使用率超过 85%，应当天处理日志、备份或扩容；HTTP 健康检查连续 3 次失败，则要进入紧急排障。阈值必须带持续时间，否则一次备份任务或短时爬虫流量就会制造大量噪音。
在 VPS（虚拟专用服务器，Virtual Private Server）场景里，资源隔离程度、磁盘容量和业务峰值差异较大，所以建议先用 7 天基线校准阈值。如果每天 10:00 到 11:00 都有固定高峰，告警规则应看“是否超过历史同时间段 2 倍”，而不是只看瞬时百分比。这样能减少误报，也能让告警更接近真实风险。
安装采集链路：先让 Prometheus 稳定拿到数据
边界确定后，再进入安装会更稳。Prometheus 本身负责定时拉取指标，Node Exporter 负责暴露 Linux 主机指标，Grafana 负责展示趋势，Alertmanager 负责通知路由。对单站点或小团队来说，可以先把 Prometheus 与 Grafana 放在一台管理节点上，再让被监控服务器只开放采集端口给管理节点访问。这样既便于维护，也能减少指标接口暴露在公网的风险。
常见部署顺序是先安装 Node Exporter，再配置 Prometheus 的 scrape_configs，最后接入 Grafana 数据源。采集间隔不建议一开始就设成 1 秒，普通网站服务器用 15 秒或 30 秒已经能发现持续性问题。采集过密会增加 Prometheus 存储压力，也会让短时毛刺显得更吓人。安装完成后，先查询 up 指标；返回 1 代表目标可采集，返回 0 说明网络、防火墙或服务进程仍有问题。
下面是一段最小化拉取配置，适合先验证链路。实际环境应把 targets 换成你的管理网地址，并用 env、role 这类标签区分生产、测试和数据库节点。
scrape_configs:
- job_name: "node"
scrape_interval: 15s
static_configs:
- targets: ["10.0.0.21:9100"]
labels:
env: "prod"
role: "web"
配置变更后，不要直接重启生产服务。先执行 promtool check config prometheus.yml 检查语法，再重载 Prometheus。进入查询页面后，连续观察 5 分钟，确认 up{job="node"} 稳定为 1，并且 node_cpu_seconds_total、node_memory_MemAvailable_bytes、node_filesystem_size_bytes 都能返回数据。只有采集链路稳定，后面的看板和告警才有意义。
如果你的站点部署在VPS（虚拟专用服务器，Virtual Private Server）上，建议同时限制 9100 端口来源。比如只允许监控节点 IP 访问采集端口，其他来源拒绝。这个动作不复杂，却能避免指标接口被无关扫描访问。
整理 Grafana 看板：第一屏只放能排障的内容
Grafana 看板容易越做越复杂。真正用于排障的第一屏，不需要塞满所有曲线，而是要让维护人员在 30 秒内判断问题属于资源瓶颈、服务不可用、网络异常还是磁盘风险。我们建议第一屏控制在 6 到 8 个面板：CPU 使用率、系统负载、可用内存、磁盘使用率、磁盘 I/O、网络收发、HTTP 健康检查、关键服务状态。
在看板命名上，避免只写“CPU”“Memory”这类泛标题。更实用的写法是“prod-web CPU 使用率”“db 磁盘剩余空间”“入口健康检查”。当告警消息带着同样的标签和面板名称时，值班人员能快速跳转到对应位置。对于正在做网站性能优化的团队，还可以把服务器指标和页面响应时间放在相邻区域，便于判断慢访问是主机资源问题，还是应用、数据库或外部接口问题。
编写告警规则：每条通知都要能对应行动
Prometheus 告警规则不应只写“超过阈值就通知”。一条可处理的告警，至少包含指标表达式、持续时间、严重等级和第一步排查方向。比如 CPU 高不是结论，真正要判断的是它是否持续影响服务；磁盘使用率高也不是同一种风险，日志盘、数据盘和备份盘的处理方式不同。规则越贴近行动，通知越不容易被忽略。
可以先从 4 条规则起步：up == 0 持续 3 分钟先查服务器、采集进程和防火墙；磁盘超过 85% 持续 10 分钟先执行 df -h 与 du -sh /var/log/*；可用内存低于 10% 先执行 free -m 与 ps aux --sort=-%mem | head；HTTP 健康检查连续 3 次失败则检查 Web 服务、反向代理和最近变更。
下面是一个磁盘告警示例。它排除了常见临时文件系统，并用 for: 10m 过滤短时波动。生产环境应按不同挂载点和业务角色调整阈值，不要把所有服务器都套同一条规则。
groups:
- name: node-alerts
rules:
- alert: NodeDiskUsageHigh
expr: (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100 > 85
for: 10m
labels:
severity: warning
annotations:
summary: "Disk usage is high"
runbook: "Check df -h and clean old logs or backups"
配置通知路由：分级、降噪和升级机制要提前写清楚
Alertmanager 的价值在于把告警变成可管理的通知流，而不是把所有问题都推到同一个群里。建议把告警分成提醒、警告和紧急三级。提醒类用于趋势风险，比如磁盘 7 天后可能满；警告类用于当天需要处理的问题，比如磁盘超过 85%；紧急类用于已经影响访问的问题，比如健康检查失败或核心服务不可用。
通知渠道也要匹配严重程度。提醒类可以进入邮件或工单；警告类进入即时消息；紧急类才使用电话、短信或高优先级通知。这样做不是降低重视程度，而是保护团队注意力。所有问题都用最高优先级，最后会导致真正严重的事故被淹没。
降噪要靠规则和路由一起做。Alertmanager 可以通过 group_by 合并同一服务器、同一服务的多条告警，通过 repeat_interval 控制重复提醒间隔。比如同一台 Web 节点同时出现 CPU 高、内存低、健康检查失败，不应每 30 秒刷屏三条消息，而应合并成同一组，并突出最影响访问的告警。每周复盘一次误报和漏报，把不准确的阈值调到更贴近业务高峰，是比盲目增加规则更有效的做法。
对于资源需要独占、业务峰值更明显的站点，可以结合独立服务器方案评估长期容量。Hostease 在这类场景中更适合作为基础设施承载方，是否升级仍应以 30 天以上监控趋势、访问峰值和预算为依据，而不是只因为一次短时告警就调整规格。
上线后的复盘：把告警变成持续改进流程
Prometheus 告警体系上线后，第一周不要急着扩展功能，而是观察三件事：采集是否稳定、通知是否及时、处理动作是否清楚。每条告警都应能追溯到负责人、处理记录和结果。如果告警消息只写“服务器异常”，没有实例、指标值、持续时间和建议动作，值班人员仍然要重新查一遍，响应速度不会真正提升。
建议建立一个简单的告警复盘表，记录触发时间、服务器角色、指标值、是否误报、处理命令和最终原因。一个月后，你会看到哪些规则最常触发，哪些规则从未触发，哪些阈值太敏感。比如 CPU 85% 每天都在备份窗口触发，可以改成排除固定计划任务时间，或把持续时间从 5 分钟提高到 15 分钟；磁盘告警如果每次都来自日志增长，就应该改进日志轮转，而不是每次人工清理。
如果你的业务还包含 WordPress 站点、营销落地页或内容型网站，监控也应和WordPress主机的缓存、插件、数据库慢查询一起看。服务器资源正常但页面仍然慢时，问题可能在主题、插件、外部脚本或数据库查询；资源曲线异常但页面体验正常时，则可以先观察趋势，再决定是否优化或扩容。
总结：从可验证的小闭环开始
Prometheus 告警落地的关键，不是安装了多少组件，而是能不能形成“采集指标、观察看板、触发通知、执行排障、复盘优化”的闭环。你可以先从 8 到 12 个核心指标、6 到 8 个 Grafana 第一屏面板、4 条可行动告警规则开始，运行 7 天后再调整阈值和通知路由。这样既能避免初期噪音，也能让团队逐步建立统一处理方式。
如果你需要为网站或业务服务器建立监控体系，我们建议先选择 1 到 2 台关键服务器试点：确认 Prometheus 采集稳定，Grafana 看板能在 30 秒内定位方向，Alertmanager 通知能到达负责人。等试点验证通过后，再扩展到数据库、缓存、队列和外部接口。这样推进，监控工具才会真正帮助运维，而不是变成另一套没人维护的复杂系统。