Gatus：一个把健康检查写成配置文件的轻量状态页

它解决的是状态页的维护负担

常见的状态页方案是拿一个静态页面，出问题时手动改状态。Gatus 把这件事自动化了。它用 YAML 定义一组检查，每个检查可以针对 HTTP、ICMP、TCP 或 DNS 查询，然后根据条件判断服务是否健康。条件可以看状态码、响应时间、证书过期时间、响应体内容等。这等于把监控逻辑和展示逻辑放在同一个文件里。适合的人群是那些已经用容器或 Kubernetes 跑服务、不想为状态页单独维护一套数据库和后端的开发者。

配置即检查：从 YAML 到告警的路径

Gatus 的核心是一个配置目录，通常是 config.yaml。每个 endpoint 块定义一个检查目标、一个间隔和一组 conditions。conditions 是表达式的列表，比如 [STATUS == 200, RESPONSE_TIME < 300]。所有条件都满足才算健康，任何一个失败就触发状态变更。告警配置挂在同一个 endpoint 下，指定渠道和触发条件。这意味着一个服务的检查、阈值和通知规则都在一处，不需要在多个系统间同步。文档里提到配置支持环境变量，也支持按组组织 endpoint。这种设计让配置可以进 Git，变更走 review 流程。

部署：一个容器，一个端口

Gatus 的快速开始只需要一条命令：docker run -p 8080:8080 --name gatus ghcr.io/twin/gatus:stable。它默认监听 8080 端口，没有外部数据库。官方也提供 Helm chart 和 Terraform 的部署方式，说明它把 Kubernetes 当作一等公民。配置目录可以挂载为卷，修改后支持热重载，不用重启容器。这比大多数需要配数据库和消息队列的监控工具轻得多。如果你只想在本地试一下，跑这条命令然后访问 8080 就能看到默认状态页。

告警渠道多，但配置方式值得留意

README 里列出了 30 多种告警渠道，从 Slack、Discord 到 PagerDuty、Twilio，还包括一些不那么常见的如 Signal、Zulip 和 Webex。每个渠道都有独立的配置章节，说明它们不是简单地发个 webhook，而是各自有参数。比如 Teams 的旧版配置已经标记为 deprecated，改用 Teams Workflow。这意味着如果你依赖某个渠道，得留意它的维护状态。告警可以设置默认告警模板，让所有 endpoint 复用同一套通知设置，减少重复配置。但渠道多也意味着配置项多，初次上手需要翻文档确认某个渠道的必填字段。

存储和 UI 的边界

Gatus 的存储默认是内存加 SQLite，没有内置的长期指标存储。它能显示最近一段时间的健康状态，但不提供像 Prometheus 那样的历史趋势查询。UI 是自带的状态页，可以分组展示，也支持自定义路径和端口。文档提到可以暴露在自定义路径下，这对放在反向代理后面很实用。但它不是一个完整的监控平台，没有告警历史管理，也没有用户权限体系（除了 basic auth 和 OIDC）。如果你需要多人协作的告警追踪，Gatus 的 UI 可能不够。

限制与容易踩的坑

Gatus 的 condition 语法虽然灵活，但表达能力有限。比如要检查 JSON 响应体里的某个嵌套字段，文档里提到可以用 GraphQL 请求，但没给出通用的 JSONPath 支持。这意味着某些复杂断言可能写不出来。另一个限制是它默认的检查间隔建议在 FAQ 里有说明，但如果你把间隔设得太短，可能对目标服务造成压力。还有并发控制，文档里有专门的章节，说明默认并发可能不够用或过高，需要根据 endpoint 数量调整。最后，如果你监控的是 UDP 或 SCTP 这类协议，文档里虽然有章节，但实现可能不如 HTTP 检查成熟。

替代方案：与 Uptime Kuma 的差异

一个常被拿来比较的项目是 Uptime Kuma。Uptime Kuma 提供 Web UI 来创建监控项，不需要写 YAML，适合非开发者或不想碰配置文件的人。Gatus 则把配置当作代码，适合已经用 Git 管理基础设施的团队。另一个区别是 Gatus 支持 ICMP 和 DNS 检查，而 Uptime Kuma 主要偏 HTTP 和 TCP。告警渠道方面，两者都覆盖主流平台，但 Gatus 的渠道列表更长。如果你更看重可视化配置和内置的证书状态展示，Kuma 可能更顺手；如果你想把监控定义放进 CI/CD 流程，Gatus 的 YAML 模型更直接。

维护与升级成本

Gatus 的发布节奏看起来稳定，最近几个版本间隔大约三个月。它是 Apache-2.0 许可，可以自由使用和修改。升级时主要需要关注配置格式是否有破坏性变更，比如 Teams 告警的废弃就属于这类。由于配置是 YAML，升级前最好在测试环境跑一遍，确认没有新警告。项目的文档更新比较频繁，特别是告警渠道部分，建议升级后查看 changelog 或 README 的变更。整体来说，单二进制部署让升级成本很低，替换容器镜像即可。

编辑结论

Gatus 适合那些已经有 Kubernetes 或 Docker 环境、愿意用 YAML 表达监控逻辑、不想引入完整监控平台的开发团队。它不适合需要历史趋势分析、多租户隔离或复杂告警路由的场景，因为它的存储和 UI 都比较简单。如果你决定采用，先验证三件事：你的检查条件能否用 Gatus 的 condition 语法表达，告警渠道是否在你的网络里可用，以及你能否接受状态页数据只保留在本地 SQLite 或内存中。Gatus 的配置即代码模式在小型基础设施里很顺手，但它的边界也恰好在这里。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes