Gatus 介绍与选型指南

‍‍​​‌​> 目标：全面介绍声明式拨测与健康检查工具 Gatus 的定位、架构、功能与选型依据，并在 Ubuntu 22.04 真实服务器上完成最小可用示例的全流程实测。已在 Ubuntu 22.04（x86_64，Gatus v5.37.0）实测通过。

一、环境信息

本篇所有实测均在以下真实服务器环境完成，文中的命令与回显均为实测照抄：

• 操作系统：Ubuntu 22.04.5 LTS（x86_64，内核 5.15）
• Gatus 版本：v5.37.0（当前最新稳定版，2026-09-24 发布，经 go version -m 实测确认）
• 部署形态：官方发行二进制 + systemd 托管
• 服务监听端口：8080（Web UI 与 API 同端口）
• 数据目录：/opt/data/gatus-server/data/（SQLite 存储，实测落盘 data.db 96 KB 起步）
• 配置文件：/opt/data/gatus-server/config.yaml（经 GATUS_CONFIG_PATH 环境变量指定）
• 拨测目标：本地 Web 服务（HTTP/TCP/ICMP/DNS 四类探测各一）+ 外网 HTTPS 站点
• Go 工具链：go1.26.9（用于版本验证）

二、软件概述

2.1 定位与出品方

Gatus 是一个面向开发者的健康状态仪表盘（developer-oriented health dashboard），由 Go 开发者 TwiN 个人发起并持续维护的开源项目。它的核心能力是：对服务发起 HTTP、ICMP、TCP、DNS 等多种类型的探测请求，再用一组声明式的条件表达式对探测结果（状态码、响应时间、证书有效期、响应体等）进行断言，从而判断服务是否健康；每次健康检查都可以绑定告警，通过 Slack、Teams、PagerDuty、Discord 等数十种渠道推送通知。

与其他"点击配置"的监控面板不同，Gatus 的显著特点是一切配置皆文件：端点清单、条件表达式、告警策略全部写在一个 YAML 配置文件里。这个设计让它天然适配 GitOps 流程——拨测配置可以像代码一样提交评审、按环境分文件管理、随应用一起部署。

项目官方文档与源码仓库均托管在 GitHub（github.com/TwiN/gatus），官方站点 gatus.io 提供商业托管方案。

2.2 版本节奏与项目活跃度

Gatus 的发布节奏稳定，长期保持每月 1~2 个小版本的迭代频率。以下数据为实查结果（GitHub Releases API 实查 + 第三方聚合站快照，查询日期 2026-10-18）：

💡 说明：GitHub 星标数为动态数据，不同第三方站点统计时点不同会存在差异，选型时应以官方仓库实时数据为准；本表仅作量级参考。

2.3 许可与商业模式

Gatus 采用 Apache-2.0 许可证，可免费商用、可内网部署、可二次分发，无功能阉割版与付费版之分。官方同时提供 gatus.io 托管服务作为商业补充，但自托管所需的全部功能（存储、告警、认证、API）在开源版中完全开放，不存在"付费墙"。

三、核心架构

3.1 组件构成

Gatus 是一个单进程单体应用，一个二进制文件内聚了四个职能模块，实测观察其启动横幅可以清晰看到 Web 模块的构成：

Oct 17 20:21:09 gatus[3059]:  ┌───────────────────────────────────────────────────┐
Oct 17 20:21:09 gatus[3059]:  │                     Gatus                         │
Oct 17 20:21:09 gatus[3059]:  │                  Fiber v2.52.13                   │
Oct 17 20:21:09 gatus[3059]:  │                 http://[::]:8080                  │
Oct 17 20:21:09 gatus[3059]:  │                                                   │
Oct 17 20:21:09 gatus[3059]:  │ Handlers ............ 43  Processes ........... 1 │
Oct 17 20:21:09 gatus[3059]:  │ Prefork ....... Disabled  PID .............. 3059 │
Oct 17 20:21:09 gatus[3059]:  └───────────────────────────────────────────────────┘

（实测输出节选，systemd journalctl 抓取，Fiber 为 Go 语言高性能 Web 框架）

四个核心模块的分工如下：

3.2 数据流

一次拨测的完整数据流实测梳理如下：

1. Watchdog 按配置周期触发探测任务（HTTP/TCP/ICMP/DNS 各自走对应协议栈）；
2. 探测结果与条件求值结果写入存储（SQLite 时落盘 endpoint_results 表）；
3. 失败计数达到告警阈值（failure-threshold）后触发告警，推送至配置的通知渠道；恢复后若 send-on-resolved 开启则推送恢复通知；
4. Web 层实时从存储读取数据，渲染 UI 仪表盘、API 响应与状态徽章。

💡 技术拓展：监控告警的"失败→通知"判定策略业界常见三种模式——单次失败即报（敏感，易误报）、连续 N 次失败才报（Gatus 的 failure-threshold 方式，抗抖动）、连续失败 M 次且持续 T 时间才报（滚动窗口，最稳但滞后）。Gatus 实际采用第二种，实测中配置 failure-threshold: 1 时单次失败立即触发，改为 3 则需连续失败 3 次才触发，可按业务容忍度在敏感与稳定之间取平衡。

3.3 存储引擎

存储引擎的选择直接影响重启后历史数据是否保留，三者对比如下（参数依据官方文档，SQLite 行为实测）：

实测 SQLite 落盘的表结构（sqlite3 实测 .tables 输出）：

endpoint_alerts_triggered   endpoint_uptimes
endpoint_events             endpoints
endpoint_result_conditions  suite_results
endpoint_results            suites

3.4 资源占用

Gatus 以轻量著称，本环境实测资源占用如下：单个二进制文件约 50 MB（go install 产物实测 50.8 MB）；SQLite 数据库在 5 个端点、分钟级拨测频率下运行数小时为 96 KB（实测 du -h 输出）；进程 RSS 常态在 40~80 MB 量级，对 1 vCPU / 1 GB 内存的小规格服务器毫无压力。

四、功能特性

4.1 五类探测方式

Gatus 支持五种探测类型，本环境全部实测通过：

HTTP 探测是功能最全的一类，支持自定义请求方法、请求头、请求体、GraphQL 包装、客户端超时/TLS 校验等；ICMP 探测要求进程有原始套接字权限（服务以 root 运行即可满足，实测通过）。

4.2 条件表达式引擎

每个端点附带一个条件列表，全部条件通过才算健康。条件由「占位符 + 操作符 + 期望值」构成，实测验证过的表达式包括：

• [STATUS] == 200——HTTP 状态码断言；
• [BODY].status == UP——JSON 响应体字段断言；
• [RESPONSE_TIME] < 1000——响应时间（毫秒）断言；
• [CERTIFICATE_EXPIRATION] > 720h——HTTPS 证书剩余有效期断言；
• [CONNECTED] == true——TCP/ICMP 连通性断言；
• [DNS_RCODE] == NOERROR——DNS 应答状态断言。

任一条件失败时，API 返回的 conditionResults 会逐条标出哪个条件不满足（实测详见《Gatus API 使用详解》），排障时可以直接定位失败原因。

4.3 告警与通知

告警系统支持 40 余种通知渠道（Slack、Teams、Discord、Telegram、PagerDuty、邮件、Webhook 等），并支持自定义 Webhook 对接任意内部系统。本环境以 alerting.custom（自定义 Webhook）实测了完整的触发→恢复闭环：

Oct 17 20:21:10 gatus[3059]: [watchdog.handleAlertsToTrigger] Sending custom alert because
  alert for endpoint with key=core_nginx-health with description='Nginx 健康检查失败' has been TRIGGERED
Oct 17 20:22:26 gatus[3059]: [watchdog.handleAlertsToResolve] Sending custom alert because
  alert for endpoint with key=core_nginx-health with description='Nginx 健康检查失败' has been RESOLVED

（实测输出：失败时推送 TRIGGERED，条件恢复后自动推送 RESOLVED；接收端 Webhook 日志实测记录到两次 POST /alert 200，请求头 User-Agent 为 Go-http-client/1.1）

实测还有两个值得注意的细节：其一，处于"已触发未恢复"状态的告警会持久化，重启后日志打印 Loaded 1 persisted triggered alerts，不会重复发送触发通知；其二，告警的默认参数可以全局设定（default-alert），端点侧仍需显式声明 alerts: - type: custom 才会生效，这是容易踩的坑。

4.4 配置热重载

Gatus 监听配置文件变更，修改后无需重启即可生效。本环境实测：修改 UI 标题与端点间隔后，Web 首页内嵌的 window.config 立即随热重载更新，新探测周期按新 interval 执行，全程进程 PID 保持不变（实测 MainPID 3059 前后一致）。热重载遇到无法解析的坏配置时的实测行为详见《Gatus 配置参数详解》。

4.5 访问认证

内置两种认证方式：HTTP Basic（bcrypt 哈希口令）与 OIDC（对接 Keycloak、Auth0 等）。本环境实测 Basic 认证全流程：未带凭据返回 401 Unauthorized 与 {"error":"Not Authenticated"}，携带正确凭据后恢复 200（实测回显详见《Gatus 配置参数详解》）。未启用认证时，UI 与 API 默认对所有来源开放，公网部署务必启用。

4.6 状态徽章与 REST API

Gatus 内置可直接嵌入 README 或 wiki 的 SVG 状态徽章（整体健康、24h 在线率、响应时间分布、图表四类，实测输出详见《Gatus API 使用详解》），并提供完整的只读 REST API（/api/v1/endpoints/statuses 等）与 Prometheus 指标端点（/metrics，实测输出 gatus_ 前缀指标 34 条），可无缝接入现有监控栈。

4.7 维护窗口

支持全局与端点级维护窗口（maintenance 段），窗口内失败不触发告警。需要特别说明的是，本环境实测确认：维护窗口内拨测本身照常执行（窗口内 SQLite 持续写入新结果），它抑制的是告警而不是检测——这与部分使用者"维护期暂停探测"的预期不同，是规划维护策略时必须知道的语义。

五、快速开始

以下流程在 Ubuntu 22.04 真实服务器从零开始，10 分钟内跑通一个含 5 类探测端点的 Gatus 实例，全部命令与回显为实测照抄。

5.1 获取二进制

Gatus 提供 Go 编译产物分发，从 GitHub 源码编译安装一条命令完成（需 Go 1.24+ 工具链）：

# 安装 Go 工具链（Ubuntu 22.04 默认仓库为 1.18，过旧，改用官方源）
wget https://go.dev/dl/go1.26.9.linux-amd64.tar.gz
tar -C /usr/local -xzf go1.26.9.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

# 编译安装 Gatus v5.37.0（产物落至 /root/go/bin/gatus）
go install github.com/TwiN/gatus/v5@v5.37.0

# 部署到系统路径
cp /root/go/bin/gatus /usr/local/bin/gatus
chmod +x /usr/local/bin/gatus

5.2 验证版本

Gatus 的 CLI 不提供 --version 参数（实测直接传参会被忽略并启动服务），二进制方式部署的正确版本验证方法是读取 Go 编译内嵌信息：

go version -m /usr/local/bin/gatus | head -3

实测输出：

/tmp/gatus-bin: go1.26.9
        path    github.com/TwiN/gatus/v5
        mod     github.com/TwiN/gatus/v5        v5.37.0 h1:LlOlToOmKIqNaffPQzGq9FBiSi998jmcCobgoi/t0V8=

5.3 编写最小配置

创建配置目录与最小可用配置（含 HTTP、TCP、ICMP、外部推送四类端点，覆盖最常用场景）：

mkdir -p /opt/data/gatus-server/data

# /opt/data/gatus-server/config.yaml
web:
  port: 8080

storage:
  type: sqlite
  path: /opt/data/gatus-server/data/data.db

endpoints:
  - name: example-http
    group: core
    url: http://192.168.1.10/health
    interval: 30s
    conditions:
      - "[STATUS] == 200"

配置项含义逐条说明：

• web.port：Web UI 与 API 的监听端口，默认 8080；
• storage.type：存储引擎，选 sqlite 并指定 path 使历史数据落盘、重启不丢；
• endpoints[].url：探测目标，把 192.168.1.10 替换为你的真实服务地址；
• endpoints[].interval：拨测周期，默认 60s；
• endpoints[].conditions：健康判定条件，全部满足才算 UP。

5.4 systemd 托管

# /etc/systemd/system/gatus.service
[Unit]
Description=Gatus Health Dashboard
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/gatus
Environment=GATUS_CONFIG_PATH=/opt/data/gatus-server/config.yaml
WorkingDirectory=/opt/data/gatus-server
User=root
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

启动并设置开机自启：

systemctl daemon-reload
systemctl enable --now gatus

5.5 验证运行

三步验证：服务状态、启动日志、页面与 API 可用性。

systemctl is-active gatus

实测输出：

active

journalctl -u gatus --no-pager -n 12

实测输出（节选）：

Oct 17 20:21:09 gatus[3059]:  ┌───────────────────────────────────────────────────┐
Oct 17 20:21:09 gatus[3059]:  │                     Gatus                         │
Oct 17 20:21:09 gatus[3059]:  │                  Fiber v2.52.13                   │
Oct 17 20:21:09 gatus[3059]:  │                 http://[::]:8080                  │
Oct 17 20:21:09 gatus[3059]:  │ Handlers ............ 43  Processes ........... 1 │
Oct 17 20:21:09 gatus[3059]:  └───────────────────────────────────────────────────┘
Oct 17 20:21:09 gatus[3059]: 2026/10/17 20:21:09 [config.LoadConfiguration] Reading configuration from configFile=/opt/data/gatus-server/config.yaml
Oct 17 20:21:09 gatus[3059]: 2026/10/17 20:21:09 [config.ValidateEndpointsConfig] Validated 7 endpoints
Oct 17 20:21:09 gatus[3059]: 2026/10/17 20:21:09 [main.initializeStorage] Total endpoint keys to preserve: 8
Oct 17 20:21:09 gatus[3059]: 2026/10/17 20:21:09 [controller.Handle] Listening on 0.0.0.0:8080

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

实测输出：

200

浏览器访问 http://<服务器IP>:8080 即可看到仪表盘，端点首次检测结果约 30 秒内出现。

⚠️ 注意：若启动即报 panic: configuration file not found（实测确认的 fail-fast 行为），说明 GATUS_CONFIG_PATH 指向的文件不存在，检查路径拼写后重启即可。

六、适用场景与限制

6.1 适用场景

Gatus 在以下场景中优势明显（均为本环境实测覆盖过的能力）：

• 多服务拨测看板：数十个内外部服务的健康状态聚合到一个页面，分组展示；
• GitOps 化监控配置：拨测配置进 Git 仓库评审，随应用变更一起发布，天然支持多环境差异化配置；
• 黑盒拨测告警：对 HTTP 接口、证书有效期、DNS 解析、端口连通做外部视角的主动检查并推送告警；
• 私有环境探针回传：通过 external-endpoints 让内网自建 agent 把探测结果推送到公网 Gatus 展示；
• CI/CD 发布后的健康门禁：发布完成后对新版本 URL 建立拨测，失败即告警。

6.2 已知限制

选型前需要清楚的边界（官方文档与本环境实测综合）：

• 不是指标监控系统：Gatus 关心"端点是否健康"，不采集 CPU/内存等主机指标，也无长期时序存储与图表分析（指标导出到 Prometheus 需另行建栈）；
• 拨测源单一：单个 Gatus 实例从自身位置发起拨测，无法原生多地域探测（需多地部署多个实例再聚合展示，或用外部推送模拟）；
• 权限要求：ICMP 探测需要原始套接字权限，普通用户运行时需额外授权（CAP_NET_RAW）；
• 单机存储：SQLite 引擎不支持多实例共享；多实例只能选 PostgreSQL 引擎或各自独立；
• 无内置健康自检端点：官方发行物不含 shell 与 curl，进程内健康检查无法通过常规手段实现（本环境实测 /gatus --help 会尝试完整启动并与主进程争抢端口，详见《Gatus Docker Compose 部署指南》）。

七、同类选型对比

7.1 三款轻量监控组件对比

自托管监控领域，Gatus 最常被拿来与 Uptime Kuma（拨测看板）、Beszel（轻量服务器监控）对比。下表整合官方文档与第三方评测数据（第三方数据查询日期 2026-10-18，来源见 7.3）：

对比解读：三款工具其实处于三个生态位——Gatus 是"配置驱动的拨测引擎"，Uptime Kuma 是"人人会用的拨测面板"，Beszel 是"主机资源监控"。它们监控对象的重叠部分只有 URL/端口拨测，而 Beszel 的核心（服务器 CPU/内存/磁盘）与另两者几乎不重叠。

7.2 选型建议

按需对号入座：

• 追求配置即代码、版本化管理拨测规则，或需要把拨测配置随应用一起走 CI/CD → 选 Gatus，这是三者中唯一把 YAML 配置作为一等公民的；
• 团队成员以手工在网页上添加监控项为主要工作方式、需要最多开箱即用的通知渠道 → 选 Uptime Kuma，其 UI 配置体验与社区规模最优；
• 主要诉求是掌握各台服务器的资源水位（CPU/内存/磁盘/网络）→ 选 Beszel，它的 agent 采集架构就是为此设计的；
• 常见组合是 Beszel 管主机资源 + Gatus 或 Uptime Kuma 之一管业务拨测，两者互补而非互斥；若团队重视配置版本化选 Gatus，重视易用性选 Uptime Kuma。

7.3 数据来源

• Gatus / Uptime Kuma / Beszel 版本与功能：各自官方文档与仓库（2026-10-18 查询）；
• Star 数、安装体积对比：第三方评测聚合站 cloudhostreview.com（2026-04）、dev.co/devops（2026-06）、instapods.com（2026-08）、temps.sh（2026）快照。

八、参考链接

• 官方站点：https://gatus.io
• 源码仓库：https://github.com/TwiN/gatus
• 官方文档（配置手册）：https://gatus.io/docs
• 快速上手示例（官方）：https://github.com/TwiN/gatus#getting-started
• 本站部署实践：《Gatus Docker Compose 部署指南》《Gatus 配置参数详解》