WordPress 站点监控：该监控哪些指标、怎么告警

可用性之外要看什么

HTTP 200 不代表站点能用。2026 年的 WordPress 站点多数开着页面缓存、对象缓存与 CDN，首页可能长期命中缓存返回 200，但后台发布、WooCommerce 下单、REST API 已经 500 了。可用性监控必须分层。

除了根路径，你至少要监控：/wp-login.php 返回 200 或 302、/wp-admin/ 登录后 200、/wp-json/wp/v2/posts 返回 200 且 JSON 可解析、WooCommerce 的 /checkout 或 /cart 能加载。用 curl 做黑盒探测最直接。

curl -s -o /dev/null -w '%{http_code} %{time_total}n' -A 'Mozilla/5.0' https://example.com/wp-json/wp/v2/posts?per_page=1
curl -s https://example.com/wp-json/wp/v2/posts?per_page=1 | head -c 200

为什么这么做：REST API 是 WordPress 自身能力的探针，它挂了通常意味着 PHP-FPM、数据库或重写规则出问题，而静态首页还活着。做法是把这些 URL 加进 Uptime Kuma、Better Uptime 或自建 Prometheus Blackbox Exporter，每 60 秒探一次。

还要看资源层指标：CPU load、内存、PHP-FPM 队列、MySQL 连接数、Redis 命中率。以 PHP-FPM 为例，盯 listen queue 和 active processes：

sudo sed -i 's/^;pm.status_path.*/pm.status_path = /fpm-status/' /etc/php/8.3/fpm/pool.d/www.conf
sudo systemctl reload php8.3-fpm
curl -s 'http://127.0.0.1:8080/fpm-status?json' | head -c 400

2026 年主流环境是 PHP 8.2/8.3，Ubuntu 24.04 或 Debian 12，路径多为 /etc/php/8.3/fpm/pool.d/www.conf。验证做对了：在状态页里看到 listen queue 长期为 0、active processes 未打满 pm.max_children；一旦队列大于 5 持续两分钟就说明要扩容或调 pm.max_children。

常见踩坑：把监控探针放在同一台机器上，宿主机网络一断全变误报。回退方法是用外部节点探测，至少两个地理区域；本地资源指标用 node_exporter 采，但可用性一定走外网。

如果你遇到的是网关层超时而不是应用层 200 假象，可以对照 Nginx 504 与 PHP-FPM 卡死：从日志到定位 里的排查顺序，两者共用同一套 PHP-FPM 状态指标。

证书到期与磁盘

证书和磁盘是「平时没感觉、爆了就全站瘫」的两类指标。Let’s Encrypt 证书 90 天过期，2026 年 certbot 多数已用 systemd timer 而非 cron，但续期失败仍常见：DNS 插件改了、Webroot 路径变了、Nginx 没 reload。

做法是用 openssl 取剩余天数，低于 21 天告警：

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -subject

写成一个检查脚本放进 cron 每天跑：

#!/bin/bash
end=$(echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
left=$(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 ))
if [ "$left" -lt 21 ]; then
  logger -t sslcheck "cert expires in $left days"
fi

验证做对了：手动把 /etc/letsencrypt/live/example.com/fullchain.pem 备份后临时替换成一张自签短证（仅在测试机做），脚本应立刻输出告警；恢复原文件后告警消失。

磁盘方面要盯三块：根分区、/var/log、数据库卷。WordPress 常见撑爆点是 debug 日志、Nginx access log 未切割、以及 wp-content/uploads 无上限增长。

挂载点	告警阈值	常见元凶
/	>80%	核心更新残留、旧内核
/var/log	>75%	debug.log、access.log 未轮转
/var/lib/mysql	>85%	postmeta、options 表膨胀

用 df -h 和 du -sh /var/log/* | sort -h | tail 定位。2026 年仍推荐 logrotate 默认 14 天保留：

sudo nano /etc/logrotate.d/nginx
# 内容示例
/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload nginx
    endscript
}

验证：执行 sudo logrotate -d /etc/logrotate.d/nginx 看 dry-run 无错，再 sudo logrotate -f /etc/logrotate.d/nginx 强制跑一次，确认日志被切且 Nginx 仍 200。踩坑是 postrotate 里写错服务名导致 Nginx 不重载、磁盘继续涨；回退是先手动 systemctl reload nginx 再修脚本。

当磁盘或证书引发的是整站不可访问，而你需要一套持续有人盯的托管方案时，WordPress 网站代维与运维 覆盖了证书轮转、日志清理与资源扩容的响应流程。

PHP 错误日志

WordPress 的 PHP 错误日志分两层：PHP-FPM 自身日志，和 WordPress 的 WP_DEBUG 日志。两层都要看，落点不同。

PHP-FPM 错误日志通常在 /var/log/php8.3-fpm.log 或由 pool 里 php_admin_value[error_log] 指定。WordPress 侧在 wp-config.php 里开：

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/www/html/wp-content/debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

为什么：生产环境不能 WP_DEBUG_DISPLAY 为 true，否则把路径和栈信息吐给访客。做法是写到非 web 可访问路径，比如 /var/log/wp/example.com-debug.log，再用 filebeat 或 tail 脚本送进集中日志。

监控动作：用 tail -f 观察，或用 grep 统计致命错误：

tail -f /var/log/wp/example.com-debug.log
grep -c 'PHP Fatal error' /var/log/wp/example.com-debug.log
grep 'Uncaught' /var/log/wp/example.com-debug.log | tail -20

2026 年 WordPress 6.7/6.8 环境下，常见致命错误来自插件与新版 PHP 不兼容，比如 Uncaught TypeError、弃用函数 create_function 已彻底移除。验证做对了：在测试环境故意写一个调用不存在函数的 mu-plugin，日志应立刻出现 PHP Fatal error 且前台仍返回 200（因为 display 关了）；删掉 mu-plugin 文件即回退。

还要配告警规则：5 分钟内 Fatal error 出现超过 3 次就通知。Prometheus 侧可用 mtail 或 grok exporter 把日志转成指标。官方文档对调试常量的说明见 WordPress Debugging。

告警噪音怎么压下来

告警噪音来自三个源头：阈值太敏感、没做收敛、没分级。压下来的核心是「持续时长 + 多条件 + 分级路由」。

做法一：所有告警都带 for 持续时间。Prometheus 规则示例，磁盘 85% 持续 10 分钟才告警：

groups:
- name: wordpress
  rules:
  - alert: DiskWillFillIn4Hours
    expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.15
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "disk low on {{ $labels.instance }}"

做法二：多条件。API 500 且同时 PHP-FPM active 进程打满才升级为紧急；单是 500 先发 warning。做法三：分级路由，warning 进 Slack 频道，critical 才打电话或短信。

为什么：一次 CDN 抖动会让 HTTP 探测 30 秒内全红，如果 for: 0m 就是半夜叫醒你。加了 for: 5m 后抖动自愈，不产生告警。验证做对了：用 stress 或临时占满磁盘生成条件，观察告警是否在设定时长后才触发，恢复后 resolved 是否发出。

# 测试磁盘告警（用后立即删）
fallocate -l 1G /tmp/bigfile
dd if=/dev/zero of=/tmp/fill bs=1M count=2000
rm -f /tmp/fill /tmp/bigfile

常见踩坑：Alertmanager 的 group_wait 设成 0 导致同一故障拆成几十条。回退方法是先设 group_wait: 30s、group_interval: 5m、repeat_interval: 4h，再逐步收紧。另一个坑是把 warning 和 critical 都发到同一个手机号，结果真故障时反而被静音。

实施步骤

下面把整套 WordPress 站点监控按落地顺序拆成可勾选流程：

1. 梳理监控对象清单：根路径、wp-login、REST API、checkout，写入外部可用性探针。
2. 开启 PHP-FPM status 页面并接入 exporter，采集 queue 与 active processes。
3. 配置 SSL 到期检查脚本与 logrotate，纳入每日 cron。
4. 在 wp-config.php 开启 WP_DEBUG_LOG 到非 web 路径，接入日志采集。
5. 编写 Prometheus 告警规则，全部带 for 时长与 severity 标签。
6. 做故障演练：制造磁盘、证书、500 三类事件，验证告警触发与恢复通知。

常见问题

监控探针应该放在内网还是外网？

可用性探测必须放外网、至少两个区域；资源指标用内网 exporter 采。同机探测会在宿主机断网时全部误报。

WP_DEBUG_LOG 会不会拖慢站点？

写入频繁会有轻微 IO 开销。2026 年 SSD 环境可忽略，但要确保路径不在 wp-content 可被 web 直读，并配合 logrotate 切割。

告警还是太多怎么办？

先给所有规则加 for 时长，再按「持续 + 多条件」合并，最后把 warning 与 critical 路由到不同渠道。

如果你希望有人替你盯证书、磁盘、PHP 日志并做季度演练，WordPress 网站代维与运维 提供完整托管；更多技术文章见 技术栏目首页。

• 今天就给 REST API 加一条外部可用性探针。
• 本周把 disk 与 ssl 检查脚本放进 cron 并验证一次。
• 把 WP_DEBUG_LOG 移到非 web 路径并接日志采集。
• 给现有告警规则全部补上 for 时长与 severity。

需要落地这套监控？查看代维服务，我们帮你把告警从吵变成准。

参考资料与延伸阅读

• WordPress 开发者文档
• WordPress 主题开发手册
• WordPress 插件开发手册