站点监控怎么做？从HTTP状态检测到主机监控的完整入门方案

有个客户找我帮他看服务器为什么”总是出问题”。我登录一看，MySQL连接数满了，Nginx worker进程僵死，磁盘使用率95%——这些问题已经持续了将近两周，但因为没人看，直到网站彻底打不开了才发现。

他对我说：”我以为服务器买了就不用管了。”

很多人都是这个心态。服务器买完、网站上线、以为完事了。但服务器不是买完就不用管的，至少你得知道它什么时候出了问题。

监控分三个层次

搞清楚你要监控什么，才知道该用什么工具。

站点层。网站能不能正常打开，返回的HTTP状态码是不是200。这是用户最直接能感知到的——能打开还是打不开。

接口层。API接口的响应时间和错误率。如果你有前后端分离的架构，页面可能能打开（前端正常），但接口报错导致数据加载不出来。站点层监控检测不到这种问题，需要专门监控接口。

主机层。CPU使用率、内存占用、磁盘空间、网络流量。这些是服务器的底层健康指标，很多时候网站出问题的根本原因在主机层——比如磁盘满了导致数据库写不进去。

三层监控各管各的，缺一不可。

站点层监控是最容易实现的，推荐用UptimeRobot。

注册UptimeRobot，免费版支持50个监控点。添加你要监控的URL，监控类型选HTTP(s)，检测间隔设为5分钟。

它会从全球多个节点定期访问你的网站，检查HTTP状态码。如果返回200就正常，返回5xx或者连续超时就告警。

配置的时候有几个细节要注意：监控路径不要只写域名，建议具体到某个页面（比如 /health 或者你的首页）；关键词检测可以设一个页面上的固定文字，如果页面能打开但内容变成了错误页，关键词检测也能发现问题。

如果你有API接口需要监控，UptimeRobot也支持，但更推荐用Checkly或者自建方案。

Checkly（checklyhq.com）免费版支持API监控，可以设置期望的响应时间（比如200ms以内）、检查返回的JSON字段是否包含特定值。适合有REST API需要监控的场景。

另一种方式是用curl脚本定时跑接口检查，配合cron任务执行，失败时发送告警。这个方案完全免费，但需要自己写脚本。

主机层监控方案比较多，按难度排列。

宝塔面板（最简单）。如果你装了宝塔，它自带资源监控看板，实时显示CPU、内存、磁盘、网络的占用情况。缺点是没有主动告警（除非装了付费插件）。

Node Exporter + Grafana（中等难度）。在服务器上装一个Node Exporter采集数据，然后用Grafana展示。搭建一次大概需要30分钟，之后可以看各种历史数据和趋势图。告警需要配合Alertmanager配置。

云厂商自带监控（零配置）。很多云厂商自带基础监控（CPU、内存、网络），可以在控制台查看。比如萤光云的控制台就有服务器资源概览，不用额外安装任何东西。

监控的核心价值不在看数据，而在出问题的时候能及时通知你。

告警渠道建议至少配两个：邮件（必选）+ 一个即时通讯工具（微信/Telegram/钉钉）。邮件作为兜底，即时通讯工具确保你能在几分钟内看到。

告警阈值不要设太敏感。UptimeRobot默认连续2次失败才告警，这个设置比较合理。主机层监控的CPU告警建议设85%以上持续5分钟，不要一超过50%就报警，否则告警疲劳之后你会直接关掉通知。

告警分级。网站完全打不开（5xx）是紧急告警，响应变慢（3秒以上）是警告告警，SSL证书快过期（30天内）是提醒告警。不同级别用不同方式通知。

对于个人站点和小团队，推荐这套免费组合：

如果需要监控API接口，加一个Checkly免费版。这套组合覆盖了绝大多数中小站点的监控需求，总成本为零。

如果你还没有服务器或者想找一个监控和业务一起跑的稳定节点，可以看看萤光云，他们的控制台自带基础资源监控，配合UptimeRobot就能搭建一套完整的监控体系。

别等到网站挂了客户投诉了才发现问题。10分钟配好监控，能帮你省掉很多不必要的损失。