监控与可观测 · 入门

站点可用性探测

用 Uptime Kuma 建立独立探测点,验收健康检查、故障通知、状态页和数据目录备份,而不是只确认首页能打开。

Docker告警治理监控告警

场景目标

完成一个受控探测点:试点健康检查持续可探测,测试故障与恢复通知送达指定接收人,状态页仅含批准公开的服务,data 目录备份能在隔离路径启动。

环境要求

需要一台可运行 Docker Engine 与 Compose 插件的 Linux 主机、本地磁盘数据目录,以及可解析的测试域名或本机绑定端口。通知测试使用独立接收端,不直接接入生产值班群。对外访问准备反向代理和证书;探测目标必须是该实例网络可达的地址。估时 120 分钟覆盖部署、首个监控、通知演练和备份验证,不含全量对象接入和长期基线观察。实施前约定维护窗口和中止人。

参考架构 · 非实时拓扑

探测点、通知与状态页的逻辑架构

由独立探测点主动检查业务入口,把心跳写入本地数据目录,再经反向代理发布状态页,并把故障与恢复送到指定接收端。

  • 数据 / 请求
  • 控制 / 管理
  • 观测 / 查询

点击组件,在图下方查看职责;连线编号对应流向解读。小屏可横向滚动,或直接展开文字说明。

探测点、通知与状态页的逻辑架构:组件关系图由独立探测点主动检查业务入口,把心跳写入本地数据目录,再经反向代理发布状态页,并把故障与恢复送到指定接收端。 Uptime Kuma → 探测对象:主动探测;Uptime Kuma → data 目录:写入心跳;反向代理 → Uptime Kuma:转发 WebSocket;状态页 → Uptime Kuma:读取公开状态;Uptime Kuma → 通知渠道:故障与恢复事件;通知渠道 → 测试接收人:送达确认。箭头说明见下方流向解读。
逻辑参考图,表示建议的探测与通知职责,不是本站或目标环境的真实部署;探测成功不等于全部用户可用。

探测对象

服务组件

业务健康检查接口、公开站点、TCP 端口或 Push 心跳。容器内 localhost 指向探测容器自身,目标必须写成该实例实际可达的地址。

全部组件职责 7 个组件
探测对象
业务健康检查接口、公开站点、TCP 端口或 Push 心跳。容器内 localhost 指向探测容器自身,目标必须写成该实例实际可达的地址。
Uptime Kuma
按监控项间隔、超时和重试从本实例网络发起检测,保存状态并触发通知。一个探测点不能代表所有故障域。工具介绍 Uptime Kuma
反向代理
将独立域名转到本机 3001 端口,并转发 Upgrade、Connection。官方不支持把完整应用放在子路径。管理端口不要直接对公网开放。
data 目录
默认保存数据库和上传文件。必须使用本地磁盘;NFS 不受支持。2.x 以复制该目录为备份方式,不再使用 JSON 导出。
状态页
只展示适合公开的服务名称与分组。发布前需用未登录视角检查,避免出现内部地址、令牌或管理入口。
通知渠道
可使用邮件、Telegram、钉钉、飞书、企业微信等。先向测试接收端验证,再绑定正式值班通道;维护窗口避免把计划发布当成故障。
测试接收人
确认故障和恢复消息实际送达,并核对应答时限。通知日志成功不等于接收人看到消息。
流向解读 6 条连接
  1. 1

    Uptime Kuma 探测对象

    观测 / 查询 · 主动探测

    由探测点发起 HTTP、TCP、Ping 或等待 Push 心跳,结果只说明该规则是否满足。

  2. 2

    Uptime Kuma data 目录

    数据 / 请求 · 写入心跳

    把检测历史和配置写入本地数据目录,备份前应停止实例以保持 SQLite 一致。

  3. 3

    反向代理 Uptime Kuma

    控制 / 管理 · 转发 WebSocket

    浏览器经代理访问管理界面和状态页;缺少 Upgrade 头时常见表现是无法登录或状态不刷新。

  4. 4

    状态页 Uptime Kuma

    观测 / 查询 · 读取公开状态

    状态页从同一实例读取选定监控项,不构成第二条探测链路。

  5. 5

    Uptime Kuma 通知渠道

    观测 / 查询 · 故障与恢复事件

    状态变化后按绑定渠道发送。模板在 2.x 使用 LiquidJS,变量区分大小写。

  6. 6

    通知渠道 测试接收人

    观测 / 查询 · 送达确认

    由指定接收人确认失败和恢复消息,而不是只看应用日志。

从架构到实施

  1. 01

    先固定探测点与对象清单

    写清探测网络、目标、期望规则和公开范围,避免把内部地址放进状态页。

  2. 02

    部署实例并核对探测路径

    本机绑定启动,数据落本地磁盘,再用真实可达的健康检查做试点,确认不是容器内的 localhost。

  3. 03

    演练通知、发布状态页并备份

    向测试接收端验证失败与恢复,经反向代理发布批准的状态页,停止实例后复制 data 目录并在隔离路径启动。

故障域与操作边界

探测成功不等于用户可用

单个探测点只反映它所在网络的可达性。证书、关键词和业务逻辑需要单独规则;主机指标和日志不在本图范围内。

Docker socket 等于宿主机控制权

容器监控需要挂载 docker.sock。该实例若对公网开放,攻击者可能控制 Docker。没有该需求就不要挂载。

架构依据与版本核对 2 篇官方资料

图解是本站基于官方资料整理的逻辑参考;实施前仍需核对实际部署版本、组件支持范围与变更审批。

方案说明

适用架构

在独立主机或已有 Docker 环境中部署一个 Uptime Kuma 探测点,对网站、健康检查接口、TCP 端口或定时任务心跳做可用性巡检,并把故障和恢复通知送到测试接收端。数据保存在本地 data 目录,对外入口经反向代理提供 HTTPS 与 WebSocket。

不适用边界

本场景不替代主机指标、日志检索或链路追踪,也不覆盖多活探测点的全局可用率统计。探测成功不等于业务正确;Docker 容器监控需要挂载 docker.sock,不适合把该实例暴露到公网。文中命令和配置均待目标环境验证。

全局验收

试点对象连续多个检测周期状态稳定,测试故障能改变状态并送达指定接收人,恢复通知可核对。状态页仅含批准公开的服务名称。备份可在隔离目录启动,升级记录包含镜像版本与回退路径。

配套知识

官方参考

工具编排

1 个关联工具
  1. Uptime Kuma探测、通知与状态页从本实例所在网络发起检测,保存历史、发送通知并发布选定服务的状态页。

实施步骤

共 6 步
  1. 01

    划定探测点、对象与通知边界

    登记探测主机所在网络、故障域和出站限制,列出首批目标:至少一个业务健康检查接口,以及是否包含公开站点、内部 TCP 入口或定时任务 Push。为每个对象写明期望状态码或关键词、间隔、超时、重试,以及失败后的处理人。公开状态页只允许出现已批准的服务名称,内部地址和令牌不得进入页面文案。

    验证标准

    清单包含探测点位置、目标地址、期望规则、接收人和状态页公开范围;健康检查接口由业务负责人确认代表该服务可用性,而不是随意挑选首页。

    停止与回退

    本步骤只做盘点。目标或通知范围不清时停止部署,保留清单草稿,不创建公开状态页,也不向正式值班通道发送测试消息。

    返回步骤起点
  2. 02

    部署独立实例并固定数据目录

    在独立目录使用 2.x 镜像启动实例,端口仅绑定本机,数据目录放在本地磁盘。:2 为浮动标签,启动后记录实际镜像摘要。不要把 data 放到 NFS。

    services:
      uptime-kuma:
        image: louislam/uptime-kuma:2
        restart: unless-stopped
        ports:
          - "127.0.0.1:3001:3001"
        volumes:
          - ./data:/app/data
    docker compose up -d
    docker compose ps
    docker compose logs --tail=100 uptime-kuma
    验证标准

    容器持续运行,本机 http://127.0.0.1:3001 可打开安装向导并创建管理员;data 目录出现在本地路径且不属于网络文件系统。镜像摘要已写入实施记录。

    停止与回退

    删除本次 Compose 项目前确认没有其他服务使用该目录。保留 compose.yaml 与失败日志。尚未写入监控配置时,停止容器即可,不必恢复其他系统。

    返回步骤起点
  3. 03

    接入试点健康检查并核对探测路径

    添加 HTTP(S) 监控,目标填写探测实例真实可达的健康检查 URL,不要使用容器内的 localhost 去指向宿主机或其他服务。设置超时、重试和间隔后观察至少三个周期。若状态码不足以代表健康,再加关键词或 JSON 查询。需要 Docker 容器监控时才挂载 docker.sock,并确认该实例不会对公网开放。

    验证标准

    试点对象在多个周期内状态与手工访问结果一致;失败原因可区分超时、证书、关键词和网络不可达。探测路径、间隔和超时已写入对象清单。

    停止与回退

    删除或停用本次新增监控项,不改业务服务。若误挂 docker.sock,去掉该卷并重建容器,确认宿主机 Docker 未被额外暴露。

    返回步骤起点
  4. 04

    配置通知并演练失败与恢复

    先接入测试用 SMTP、钉钉、飞书或 Telegram 等渠道,向指定测试接收端发送。将通知绑定到试点监控,经授权后只对该测试对象制造一次失败(例如临时改成不可达地址),再恢复正确目标。记录状态变化、首次通知和恢复通知时间。计划内变更使用维护窗口,避免把发布当成故障。

    验证标准

    测试接收人确认收到失败与恢复消息,时间线与看板状态一致;正式值班通道在演练期间未被误发。维护窗口的范围和结束时间可核对。

    停止与回退

    立即恢复试点监控的正确目标,关闭或解绑测试通知。若误发到正式通道,由接收人确认后标记为演练,不扩大通知范围。

    返回步骤起点
  5. 05

    发布状态页并核对反向代理

    创建状态页,只加入批准公开的服务。用未登录会话打开页面,确认没有内部主机名、令牌或管理入口。对外域名经反向代理转到 127.0.0.1:3001,必须转发 WebSocket。

    location / {
        proxy_pass         http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
        proxy_set_header   Host $host;
        proxy_read_timeout 3600s;
    }

    若仅能通过代理访问,打开 Trust Proxy。需要指标抓取时再启用 /metrics,并限制来源。

    验证标准

    未登录可打开状态页且内容符合公开清单;登录管理界面实时状态可刷新。代理访问与本机直连的监控状态一致。

    停止与回退

    撤回本次域名与代理配置,管理入口回到本机绑定。下线状态页或去掉未批准的服务分组,保留探测与测试通知不受影响。

    返回步骤起点
  6. 06

    备份数据目录并完成交接

    停止实例后复制完整 data 目录到离机位置,再在隔离目录用同一主版本镜像尝试启动。确认可登录且试点监控仍在。记录升级命令与回退镜像。将探测点位置、对象清单、通知测试结果、状态页范围和备份位置交给值班人员。

    docker compose stop
    # 复制 ./data 到离机备份后:
    docker compose start
    验证标准

    隔离启动后管理员可登录,试点监控配置仍在;备份位置、镜像摘要和回退步骤写入交接记录。未完成的对象接入有负责人和日期。

    停止与回退

    隔离验证失败时继续使用原实例和原备份,不把失败的副本当作主数据。升级未通过则回到记录的旧镜像与升级前备份,避免旧程序读取已迁移数据。

    返回步骤起点

DOUYA OPS ECOSYSTEM

体验豆芽自研工具与场景能力

部分场景提供体验环境,用于功能验证、测试和技术交流。