最近一直在折腾自己博客周边的一些东西，像服务监控、日志、告警这些。原因也很简单：站点平时看着没问题，但真要是哪天挂了、证书过期了、响应特别慢了，如果没有监控，很可能是等别人来告诉你“你网站打不开了”，你才后知后觉。
于是我就顺手给自己的博客加了一套轻量级可用性监控：用 Docker 部署 Gatus，定时检查 https://blog.lj2508.com/ 是否能正常访问，并在异常或恢复时通过邮箱发送通知。Gatus 本身就是一个面向开发者的健康检查和状态页工具，支持 HTTP、TCP、DNS、ICMP 等多种检测方式，也支持按状态码、响应时间、证书到期时间等条件来判断服务是否健康，同时还能接入 Email 等告警渠道。
我这次监控的目标是自己的博客首页 https://blog.lj2508.com/。这个地址目前可以正常打开，是一个标准的 HTTP 网站场景，所以非常适合拿来作为 Gatus 的入门示例 以下是博客的状态页 http://status.lj2508.com/
为什么我最后选了 Gatus？
一开始其实也看过别的监控方案，比如一些功能更全的可视化监控工具，甚至也想过直接用 Prometheus 体系。但最后还是选了 Gatus，主要是因为它足够轻、足够直接。
Gatus 官方定位就是一个开发者导向的状态页和健康检测工具，最核心的能力就是：定时探测服务、按条件判断健康状态、异常时触发告警。而且它本身就提供官方 Docker 镜像，部署方式很简单，配置也基本靠一个 YAML 文件就能搞定。对于个人博客、小型站点或者一些轻量服务来说，这种方案非常合适。
还有一点我比较喜欢：Gatus 的“健康”不是只有“能不能打开”这么粗糙。它支持用 [STATUS] == 200 来要求返回状态码必须正常，也支持用 [RESPONSE_TIME] < 3000 这种条件限制响应时间，甚至还能检测证书剩余有效期。也就是说，它不是简单 ping 一下，而是可以更接近“用户实际访问体验”地去判断网站状态。
我的目标很明确
这次部署，我的需求其实非常简单：
用 Docker 跑一个 Gatus；
监控
https://blog.lj2508.com/是否正常访问；要求 HTTP 状态码必须是
200；响应时间不能太慢；
如果连续检测失败，就给我发邮件；
恢复后，再发一封恢复通知。
Gatus 的告警机制本身就支持这种方式。官方文档里把告警拆成两部分：
一部分是 provider，也就是“通过什么渠道发通知”，比如 Email；另一部分是 endpoint alert，也就是“什么情况下触发告警”，比如连续失败几次才发、恢复后是否通知等。Email provider 需要配置收件人、发件人、SMTP 主机、端口、用户名和密码，而 failure-threshold、success-threshold、send-on-resolved 这些参数则决定了告警什么时候发、恢复后发不发。
开始部署：目录准备
因为我服务器上本来就已经装好了 Docker，所以这里就直接开始部署了。
为了后面好维护，我把 Gatus 的文件统一放在 /opt/gatus：
mkdir -p /opt/gatus
cd /opt/gatus
这个目录里后面会放三个核心文件：
docker-compose.ymlconfig.yaml.env
编写 docker-compose.yml
Gatus 官方镜像既可以用 GitHub Container Registry 的 ghcr.io/twin/gatus:stable，也可以用 Docker Hub 的 twinproduction/gatus:stable。我这里选的是前者。官方说明里也提到，默认配置文件路径是 config/config.yaml，如果要自定义路径，可以通过 GATUS_CONFIG_PATH 指定。像我这种最简单的 Docker Compose 部署方式，直接把本地配置文件挂载到 /config/config.yaml 就行。
我的 docker-compose.yml 是这样写的：
services:
gatus:
image: ghcr.io/twin/gatus:stable
container_name: gatus
restart: unless-stopped
ports:
- "8080:8080"
env_file:
- .env
volumes:
- ./config.yaml:/config/config.yaml:ro这里没什么特别复杂的地方：
用官方稳定版镜像；
映射
8080端口；用
.env管理邮箱敏感信息；把
config.yaml挂载到容器里。
如果你服务器上的 8080 已经被占用了，把左边改成别的端口就行，比如 18080:8080。
编写 Gatus 配置
真正决定监控逻辑的，是 config.yaml。
Gatus 的核心配置是 endpoints，也就是“我要监控哪些目标”。每个 endpoint 都要至少有一个 condition，不然 Gatus 没法判断它健康不健康。官方文档给的示例里就有类似 [STATUS] == 200 和 [RESPONSE_TIME] < 300 这样的写法。
我这里给博客首页配置了一个最基础、也最实用的检测规则：
alerting:
email:
to: "${ALERT_TO}"
from: "${SMTP_FROM}"
username: "${SMTP_USERNAME}"
password: "${SMTP_PASSWORD}"
host: "${SMTP_HOST}"
port: ${SMTP_PORT}
endpoints:
- name: "blog.lj2508.com 首页"
group: "website"
url: "https://blog.lj2508.com/"
interval: 1m
conditions:
- "[STATUS] == 200"
- "[RESPONSE_TIME] < 3000"
alerts:
- type: email
failure-threshold: 2
success-threshold: 1
send-on-resolved: true
description: "blog.lj2508.com 访问异常：状态码不是 200 或响应时间超过 3 秒"这份配置的意思很直白：
每分钟检测一次博客首页；
状态码必须等于
200；响应时间必须小于
3000ms；如果连续失败两次，发送邮件；
如果恢复成功，再发一封恢复邮件。
这些参数的语义和 Gatus 官方告警机制是一致的，failure-threshold和success-threshold分别控制触发阈值和恢复阈值，而send-on-resolved: true则表示恢复后也发送通知。
邮箱信息放到 .env 里（注意，修改这个文件需要重新docker compose up -d）
因为 SMTP 用户名、密码这些信息比较敏感，我不太想直接写死在 config.yaml 里，所以就放到了 .env 文件里。
Gatus 官方支持在配置文件中引用环境变量，所以这种做法是完全没问题的。
.env 示例：
[email protected]
[email protected]
[email protected]
SMTP_PASSWORD=your_smtp_password_or_app_password
SMTP_HOST=smtp.example.com
SMTP_PORT=587这里要特别注意一点：很多邮箱服务商并不支持你直接用网页登录密码走 SMTP，而是要求你使用SMTP 授权码或者应用专用密码。如果配置没问题但还是发不出去邮件，十有八九就卡在这里。Gatus 的 Email provider 本身要求的字段就是 to / from / username / password / host / port 这一套，所以出问题一般就是这些参数没配对。
启动容器
文件都准备好后，直接启动：
docker compose up -d
然后可以查看容器状态：
docker compose ps
再看日志确认有没有报错：
docker logs -f gatus
正常的话，Gatus 就会开始定时检测 https://blog.lj2508.com/。而且它自带 Web UI，你可以直接在浏览器里看每次检测结果、最近状态、响应时间等信息。Gatus 本身就是一个状态页工具，这也是它相对很多“纯命令行探测工具”来说更顺手的地方。
访问 Gatus 面板
如果你映射的是默认端口，那浏览器直接访问：
就能看到 Gatus 页面。
如果你改成了别的端口，比如 18080，那就访问：
我个人的习惯是，部署完监控工具后，先不急着说“搞定了”，而是一定要做一次告警验证。
我是怎么测试告警是否生效的？
监控系统最怕的就是“看起来在运行，实际上告警根本发不出来”。
所以部署完成后，我建议一定做一次主动测试。Gatus 的健康状态是由 conditions 决定的，而告警是否触发，则由 alert 里的阈值配置决定。 我觉得最好用的测试方法，是故意把状态码条件改错。当然，我测试是直接把博客停了一会，然后在恢复，这样可以直接测试失败和恢复
比如把：
- "[STATUS] == 200"
临时改成：
- "[STATUS] == 201"
然后重启容器：
docker compose restart gatus
因为博客首页正常情况下返回的应该是 200，所以它会连续检测失败。根据我上面的配置，连续失败两次后，就应该收到一封异常邮件。测试完成以后，把条件改回 200，再重启容器，稍后应该还能收到恢复通知，因为我配置了 send-on-resolved: true。这也是 Gatus 官方推荐的告警触发逻辑：先进入触发状态，恢复后再执行 resolved 通知。
还有一种测试方式也很简单，就是把 URL 临时改成一个不存在的路径，例如：
url: "https://blog.lj2508.com/not-found-test"
只要返回不是 200，一样会触发告警。
以下是测试结果
后续可以加上的优化
虽然这次只是监控首页能不能访问，但其实 Gatus 还能做得更多。
比如它支持用 [CERTIFICATE_EXPIRATION] > 168h 这种条件检查 HTTPS 证书剩余有效期，这样就能在证书快过期时提前报警，而不是等证书真过期了用户才反馈。Gatus 官方 README 里也明确提到支持证书到期时间相关的监控条件。
如果后面我继续完善，我大概率会再加下面几类监控：
博客归档页；
RSS 地址；
证书有效期；
关键接口响应时间。
这样监控就不只是“首页活着”，而是更接近整站健康状况。
踩坑提醒
最后顺手总结几个容易踩的点：
1. 邮件发不出去
先不要怀疑 Gatus，先去看日志：
docker logs -f gatus
重点检查 SMTP 主机、端口、用户名、密码/授权码是否正确。很多时候不是工具问题，而是邮箱服务商的 SMTP 权限没开，或者密码填成了网页登录密码。Email provider 的必要参数本来就只有那几项，所以排查起来其实不难。
2. 明明网站能打开，却老是告警
大概率是你把响应时间条件写得太严了。
比如 [RESPONSE_TIME] < 3000 在网络抖动时就可能误判，如果你的站点偶尔慢一点，可以适当放宽。Gatus 对 endpoint 的判断是“所有 conditions 都要通过才算健康”，所以只要有一条不满足，就会判失败。
3. 只监控一个首页不够
这个问题严格来说是真的。首页只能说明“最基础访问链路还活着”，不代表整站完全没问题。
不过对个人博客来说，先从首页监控做起已经很实用，而且 Gatus 支持配置多个 endpoints，后续想扩展也很方便。
总结
这次用 Docker 部署 Gatus 的体验还是挺不错的。
对我来说，它最大的优点不是“功能有多花”，而是刚刚好：够轻、够简单、够实用。官方镜像现成可用，配置文件清晰直观，支持 HTTP 状态码、响应时间、证书到期时间等多种判断条件，也原生支持 Email 告警。对于博客、个人网站、小型服务这种场景来说，真的非常合适。
现在这套配置跑起来之后，如果 blog.lj2508.com 出现异常，我基本上就能第一时间收到邮件，不至于再靠“访客反馈”来发现问题了。对于一个自维护的小站点来说，这种己安心感还是很值的。站点当前是可以正常访问的，所以后面继续扩展成多页面、多条件监控也完全没问题。
评论区