当 OpenClaw 作为 7×24 网关跑在 租用的远程 Mac 上，「昨天还能用」不是可观测性策略。本篇给出 最小可复现路径：用文档化的 健康 URL 证明进程可用，以 Prometheus 兼容方式拉取或派生时间序列（也可经 OpenTelemetry Collector 转发），配置 阈值告警，并把告警与 结构化日志对齐便于排障。部署与加固基线见《Docker 部署与生产加固》；暴露面与令牌轮换见《Tailscale 子网与令牌轮换》；出站白名单见《技能沙箱与出站域名白名单》。
思路对照：拉取指标、推送链路，同一套事故
Prometheus 习惯按间隔 抓取 HTTP；OpenTelemetry 常通过 OTLP 导出。二者可桥接：用 OTel Collector 的 Prometheus receiver 抓网关（或 sidecar），再导出到后端。租用机上建议先收三类信号：(1) /healthz、/readyz 的合成可用性；(2) 主机 CPU/内存/磁盘（node_exporter 或供应商 Agent）；(3) 网关结构化日志，在探针变红时回答「为什么」。若上游后续提供 /metrics 或原生 OTLP，请保持 env、instance、service_name=openclaw-gateway 等标签稳定，避免仪表盘与规则频繁改动。
步骤 1 — 网关健康端点（可复现 curl）
网关监听（常见 18789）提供轻量探针。先在 租用机本机 shell 验证，排除路径歧义：
# 存活：进程与 HTTP 栈在响应
curl -fsS http://127.0.0.1:18789/healthz
# 就绪：依赖满足到可接活（语义随版本以官方为准）
curl -fsS http://127.0.0.1:18789/readyz笔记本侧经 SSH 隧道镜像同一检查（网关仅绑 loopback 时推荐）：
ssh -N -L 18789:127.0.0.1:18789 user@租用主机
curl -fsS http://127.0.0.1:18789/healthz在运行手册中写明 期望状态码与正文。readyz 失败而 healthz 正常时，视为 降级：进程在跑但不宜接新会话——结合磁盘满、子进程卡住或上游 API 异常，到日志里对齐时间窗。
步骤 2 — 指标抓取间隔（Prometheus 任务示意）
将 Prometheus（或 OTel Collector 的 prometheus receiver）指向相同 URL。常见两种：
- 原生抓取 — 若网关暴露 Prometheus 文本格式（如 /metrics），直接 scrape。
- Blackbox 探测 — 仅有 HTTP 探针时，用 blackbox_exporter 的 http_2xx 模块打 /healthz、/readyz。
间隔建议： 交互控制面可 15s；平衡默认 30s；Mac 超卖或跨高延迟 tailnet 时用 60s。统一设置 global.scrape_interval 与按任务的 scrape_interval；evaluation_interval 应不大于你要 enforce 的最细告警窗口，或与其成简单倍数关系。
scrape_configs:
- job_name: openclaw_gateway_health
scrape_interval: 30s
metrics_path: /probe
params:
module: [http_2xx]
static_configs:
- targets:
- http://127.0.0.1:18789/healthz
- http://127.0.0.1:18789/readyz
labels:
service: openclaw-gateway
env: prod-rental-mac
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- target_label: __address__
replacement: 127.0.0.1:9115 # blackbox_exporter 监听地址Docker 安装时把 127.0.0.1 换成 compose 文档中的宿主机端口或桥接地址。先保证「能否打到网关」单一真源，再投资 RED 类指标。
步骤 3 — 告警规则示例（PromQL 风格）
下列假设系列名为 blackbox 的 probe_success；若抓取原生 exposition，请替换为对应 counter/histogram。
groups:
- name: openclaw_gateway
interval: 30s
rules:
- alert: OpenClawHealthzDown
expr: probe_success{job="openclaw_gateway_health"} == 0
for: 2m
labels:
severity: page
annotations:
summary: "OpenClaw 健康探针持续失败"
description: "目标 {{ $labels.instance }} 已 down >2m。"
- alert: OpenClawReadyzDegraded
expr: probe_success{job="openclaw_gateway_health", instance=~".*readyz.*"} == 0
for: 5m
labels:
severity: ticket
annotations:
summary: "OpenClaw 就绪失败（接活可能不安全）"
- alert: OpenClawProbeSlow
expr: probe_duration_seconds > 2
for: 5m
labels:
severity: warning
annotations:
summary: "网关探针耗时超过 2s"后续若有请求计数或延迟直方图，可叠加经典 SLO：5xx/工具失败 错误率、p95 延迟超预算。共享租用机务必控制标签基数，避免按用户 id 爆炸。
步骤 4 — 与 OpenClaw 日志字段对齐
指标回答 何时 异常；日志回答 为何。建议统一字段，告警深链一跳到位：
- 时间戳 — RFC3339 带时区；租用机开启 sntp 对齐。
- level — info/warn/error；error 对接 paging 策略。
- request_id 或 trace_id — 串联多跳工具调用。
- channel / session — 命中网关的入口（控制台、消息桥、CI Webhook 等）。
- tool 或 skill_pack — 失败代码路径。
- upstream — 模型厂商、HTTP 主机或本机 loopback 目标。
- duration_ms — 与探针延迟尖峰对照。
- error_class — 超时、429、鉴权、沙箱拒绝等，映射到 playbook。
在 Loki/ES 中保存查询模板：service="openclaw-gateway" AND level="error"，并与 Prometheus 侧同一 env 标签；429 或预算风暴时再到网关侧限流与熔断策略对齐。
生产注意：网关令牌与出站限制
令牌。 OPENCLAW_GATEWAY_TOKEN（或等价项）不要写进 Prometheus 指标标签。放在 launchd 环境文件、Docker secret 或保险库 sidecar；与 Tailscale/API 密钥同一日历轮换。禁止把密钥拼进抓取 URL——配置与 exporter 日志是高泄露面。探针必须鉴权时，在本机反代终结 TLS/mTLS，抓取仍走 loopback。
出站。 租用 Mac 作 Agent 岛时常配技能 域名白名单。观测栈（OTLP、Grafana Cloud、远程 remote_write）也是出站目的地：请 显式加入白名单 或放到管理网，否则「指标断了」实为防火墙尽责，易被误判为网关挂了。
频率与基数。 高频抓取叠加 debug 日志会抢 CPU。生产默认 info，debug 采样；标签维度封顶，多租户网关尤甚。
FAQ
告警是否应跑在租用机本机？ 更推荐外部评估器（托管 Prometheus、云监控），以便主机宕机仍能 paging。本机仅保留极简 watchdog 作最后手段。
当前只有日志怎么办？ 先接入日志栈，用日志派生错误计数，再补 Prometheus 探针——事故流程一致，信号质量逐步提升。
小结
租用远程 Mac 跑 OpenClaw，当 /healthz 与 /readyz 落在 文档化的抓取路径 上、间隔匹配 SLO 胃口、PromQL 式规则 覆盖存活与就绪、结构化日志 闭环因果，运维才可预期。同时加固 令牌 与 出站，避免可观测性反成安全短板。
公开 价格、购买/租用 与 帮助 支持免登录浏览；需要把本栈钉到稳定 Mac 容量时，请使用下方站内页。