企业官网建设流程全解析

一个 YAML 文件盯住你的消息队列：Gatus 监控实战

【免费下载链接】gatusAutomated developer-oriented status page with alerting and incident support项目地址: https://gitcode.com/GitHub_Trending/ga/gatus

Gatus 是一个 Go 写的服务状态监控工具：单二进制、YAML 驱动，自带健康看板和告警。拿它做消息队列监控刚好合适——几行配置就能盯住 RabbitMQ 的连接、管理接口和队列深度，异常时推 Slack 或邮件。适合想给队列加一道 7×24 监控、又不想上重型监控栈的团队。

一、Gatus 是什么：单二进制 + 一个 YAML

Gatus 的核心循环很直接：你告诉它"盯哪些地址、每多久看一次、什么算不健康"，它就按间隔发起请求，拿结果去逐条比对条件表达式，任何一条不满足就判定该端点不健康。

三个特点决定它轻量：

• 全部配置就是一个 YAML，改完保存，它 30 秒内自动重载；
• 检查端点可以是 HTTP、TCP、ICMP，甚至 DNS 查询；
• 看板、告警、Prometheus 指标都内置，默认监听 8080 端口，不依赖外部组件。

二、把 Gatus 跑起来

源码构建只需两条命令：

git clone https://gitcode.com/GitHub_Trending/ga/gatus && cd gatus make build && GATUS_CONFIG_PATH=./config.yaml ./gatus

make build产出单文件二进制./gatus；GATUS_CONFIG_PATH指明配置位置，不设置时它默认找config/config.yaml。

最小可用的config.yaml，先让一个 RabbitMQ 端点转起来：

endpoints: - name: rabbitmq-health url: "http://rabbitmq:15672/api/healthchecks/node" interval: 30s conditions: - "[STATUS] == 200"

跑起来后浏览器打开http://localhost:8080，看板里这个端点的状态会随检查结果刷新。

三、给消息队列配"体检项"

队列的健康分三个层次：进程活着、管理接口活着、业务指标正常。Gatus 对应三种检查方式，一个端点可以同时挂多条。

先确认端口活着：TCP 检查

URL 加tcp://前缀即可。对 RabbitMQ，AMQP 端口 5672 是最底层的健康信号——broker 挂了或网络不通，连不上就是连不上：

endpoints: - name: rabbitmq-amqp url: "tcp://rabbitmq:5672" interval: 30s conditions: - "[CONNECTED] == true"

注意[CONNECTED] == true只证明"有东西在监听这个端口"，不代表队列本身没问题，所以它只能当第一道粗筛。

管理接口健康：HTTP + JSON 断言

RabbitMQ 的 management 插件自带 healthchecks 接口，返回{"status":"ok"}。用[BODY].xxx路径就能对响应体里的任意字段下断言，状态码、响应时间也都能写进条件：

endpoints: - name: rabbitmq-health url: "http://rabbitmq:15672/api/healthchecks/node" interval: 30s conditions: - "[STATUS] == 200" - "[BODY].status == ok" - "[RESPONSE_TIME] < 300"

[RESPONSE_TIME] < 300表示响应时间压到 300ms 以内，节点开始变慢时你比用户先知道。

如果管理接口开了认证，Gatus 会收到 401。先建一个只读管理账号，再在端点里带上请求头（在endpoints[]下加headers: {"Authorization": "Basic xxx"}），条件不变。

四、异常了怎么第一时间知道

告警分两层：全局定义渠道，端点引用渠道。比如全局写一次 Slack webhook，之后任意端点用type: slack引用即可：

alerting: slack: webhook-url: "https://hooks.slack.com/services/xxx/xxx/xxx"

触发策略在端点的alerts里控制：failure-threshold定义连续失败几次才告警（默认 3 次，天然滤掉单次抖动），send-on-resolved: true则会在问题恢复后补一条通知，形成闭环。邮件渠道同理，把alerting.slack换成alerting.email，配上 SMTP 的 host、port 和收发件地址；PagerDuty 适合接 on-call 电话升级。

各渠道的实现代码都在 alerting/provider/ 目录下，按渠道分文件夹存放，比如 alerting/provider/slack/、alerting/provider/email/、alerting/provider/pagerduty/。想加一个内部系统通知，照着这个模式写个新 provider 就行。

五、看板与深挖

自带看板

8080 端口就是看板：每个端点的当前状态、最近若干次检查结果、条件是否逐条通过一目了然。端点多时用group字段分组，配合按组筛选，队列相关的几个端点可以聚成一屏。

接 Grafana 看长期趋势

看板看当下，趋势得靠指标。配置里加一行metrics: true，Gatus 就会在/metrics暴露 Prometheus 格式指标，Grafana 加个 Prometheus 数据源就能画成功率和响应时间的长期曲线：

条件表达式还能怎么写

条件不止==和<。函数有len（数组长度）、has（字段是否存在）、any（命中任一值）、pat（模式匹配）。消息堆积这类业务指标，可以直接对着 management 的 queue 接口下断言：

• [BODY].messages < 1000：messages即队列里等待消费的消息数，超过阈值说明消费跟不上；
• [BODY].message_stats.publish_rate > 10：确认生产者还在正常发消息，区分"没流量"和"消费停滞"。

阈值按你的业务水位定，消费能力不足时调小它，告警会更早。

先给队列加两条检查：TCP 端口 + healthchecks 接口，配上 Slack 告警；跑稳之后再叠消息堆积条件，消息队列监控就闭环了。

【免费下载链接】gatusAutomated developer-oriented status page with alerting and incident support项目地址: https://gitcode.com/GitHub_Trending/ga/gatus