去年帮一个做跨境电商的网站朋友处理服务器故障，他的监控独立站突然打不开，客户在WhatsApp上炸了锅。源码查了半天，网站发现是监控PHP-FPM进程池耗尽。问题本身不复杂，源码但发现问题的网站过程太被动了——他的监控全靠服务商发邮件，延迟至少十分钟。监控从那次起，源码我开始认真折腾网站监控源码，网站用PHP写了一套轻量级方案，监控跑了大半年，源码还算稳。网站

市面上监控工具不少，监控UptimeRobot、源码阿里云监控都能用。但有些场景必须自己写：需要监控内网接口、想自定义报警逻辑、或者单纯不想把服务器状态交给第三方。PHP做这件事有天然优势——大部分网站本身就是PHP环境，不用额外装Python或Go，扔个文件就能跑。

核心逻辑：定时请求 + 状态判定

监控的本质就一句话：定期发请求，看返回结果是否正常。用PHP实现，最直接的方式是写一个cron脚本。我习惯把被监控的URL和预期状态码存成数组，循环去file_get_contents或curl。curl更可控，能设超时、能拿HTTP状态码、能检查响应内容里的关键字。

$targets = [ 'https://example.com' => ['code' => 200, 'keyword' => 'Welcome'], 'https://api.example.com/health' => ['code' => 200, 'keyword' => '"status":"ok"'], ]; 

判断逻辑要分层。先看连接是否超时，再看HTTP状态码，最后检查内容。三层都过了才算健康。任何一层失败，记录日志、发报警。报警我用的是Telegram Bot API，比邮件实时，手机推送也快。发消息的代码就几行curl，比接短信网关省事。

数据存储与展示

监控数据不需要MySQL。我直接用SQLite，一个文件搞定，备份也方便。建两张表：一张存每次检测的原始记录，一张存当前状态汇总。原始记录表只保留最近7天，用cron每天凌晨清理一次，避免文件膨胀。

展示页面用了一个简单的HTML+Chart.js。PHP读出SQLite数据，输出JSON给前端。页面刷新时显示每个站点的当前状态、最近24小时可用率、以及响应时间曲线。响应时间曲线特别有用——有些服务器不是直接挂掉，而是响应越来越慢，曲线能提前暴露问题。

几个实际踩过的坑

第一个坑是超时设置。默认curl超时是无限等待，有一次监控脚本卡死在一个不响应的IP上，导致后续所有检测延迟。后来统一设了5秒连接超时、10秒总超时。第二个坑是误报。有些站点会返回200但内容其实是错误页，所以关键字检查不能省。第三个坑是频率。一开始设了每分钟检测一次，结果被CDN当成攻击，封了IP。现在改成5分钟一次，关键接口单独用更短的间隔。

还有一点：监控脚本本身也要被监控。我写了个简单的守护逻辑——如果监控脚本超过15分钟没更新心跳文件，就用另一个独立的cron发报警。这算是“谁监控监控者”的土办法，但管用。

代码结构参考

整个项目就四个文件：config.php存目标列表和报警配置，check.php是核心检测逻辑，report.php输出JSON给前端，index.php是展示页。没有框架，没有Composer依赖，纯PHP加SQLite。部署时把文件扔到web目录，加一条cron，五分钟跑一次check.php，完事。

这套东西不完美，没有分布式探针，没有复杂的告警收敛。但对于个人站长或小团队，够用了。关键是代码在自己手里，想改哪里改哪里。上次朋友想加一个“检测到故障自动重启PHP-FPM”的功能，我花了十分钟就接上了。用第三方监控，这种需求只能提工单等排期。

如果你也打算自己写，建议从最简单的单文件版本开始。先跑通“请求-判断-报警”这个闭环，再考虑加数据库和图表。别一上来就设计架构，容易烂尾。