當 OpenClaw 在租用遠端 Mac上以常駐閘道運行時，「昨天還能用」不是可觀測性策略。本篇 HowTo 給一條最小可複現路徑：用文件化的 /healthz、/readyz 證明閘道存活；以 Prometheus 相容方式拉取或衍生時序（必要時經 OpenTelemetry Collector 橋接）；設定閾值告警；並把告警與可操作的日誌行對齊。部署基底請先完成站內Docker 安裝與加固；暴露與憑證輪換請交叉對照Tailscale、Funnel 與令牌輪換，技能出站則見沙箱與出站白名單。
心智模型：拉取指標、推送追蹤，同一套事故流程
Prometheus 慣例是依間隔拉取 HTTP 端點；OpenTelemetry 常由應用或 Collector 以 OTLP 匯出到後端——兩者可橋接：執行 OTel Collector，以 prometheus receiver 抓取閘道（或 sidecar），再轉到你的供應商。對租賃 Mac 而言，先把爆炸半徑壓在三類訊號：（1）以 /healthz、/readyz 做合成可用性；（2）以 node_exporter 或供應商代理取得 CPU、記憶體、磁碟；（3）結構化閘道日誌承載因果，當探針轉紅時能回答「為什麼」。
若上游日後提供第一類 /metrics 或原生 OTLP，仍建議沿用一致的 job 標籤（env、instance、service_name=openclaw-gateway），避免儀表板與規則頻繁改寫。
步驟一：閘道健康端點（可複現的 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在 Runbook 中寫死預期本文與狀態碼，讓值班知道何謂「綠」。若 readyz 失敗而 healthz 仍成功，視為降級：行程在跑但不宜接新工作階段——請對照磁碟滿、子程序卡住、或上游 API 中斷等日誌線索。
步驟二：指標抓取間隔（Prometheus 任務草圖）
將 Prometheus（或 OTel Collector 的 prometheus receiver）指向相同 URL。常見兩種模式：
- 原生抓取——若閘道在諸如 /metrics 路徑提供 Prometheus 文字格式，可直接 scrape 該 target。
- Blackbox 式探針——僅有 HTTP 探針時，以 blackbox_exporter 的 http_2xx 模組打 /healthz 與 /readyz。
間隔建議：15s 適合分鐘級盲區就不可接受的互動控制面；30s 為平衡預設；60s 適用於 Mac 已超賣或 scrape 需穿越高延遲 tailnet 路徑。請讓 global.scrape_interval 與各 job 的 scrape_interval 一致；evaluation_interval 應不大於你要強制的最細告警視窗。
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 文件記載的宿主埠或 bridge IP。目標是先有單一事實來源回答「我們能否打到閘道？」再投資 RED 類進階指標。
步驟三：告警規則範例（PromQL 風格）
以下假設指標為 blackbox 的 probe_success；若改抓原生 exposition，請替換為對應的 histogram／counter 表達式。
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 }} 已超過 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: "閘道探針延遲超過 2 秒"日後若加入請求計數或延遲直方圖（閘道原生、或 Envoy／Caddy sidecar），可延伸經典 SLO 規則：錯誤率（5xx 或工具失敗）與p95 延遲超預算。共用租賃主機上務必控制標籤基數——按使用者 id 爆炸會同時拖垮 Prometheus 與帳單。
步驟四：與 OpenClaw 日誌欄位對齊告警
指標告訴你何時出事；日誌告訴你為何。建議欄位標準化，讓任一告警能一跳進入調查：
- 時間戳——RFC3339 含時區；租賃 Mac 請對齊 sntp。
- level——info／warn／error；error 對應升級分派政策。
- request_id 或 trace_id——串聯多跳工具呼叫。
- channel／session——哪個介面打到閘道（主控台、訊息橋、CI webhook）。
- tool 或 skill_pack——失敗程式路徑名稱。
- upstream——模型供應商、HTTP 宿主或本機迴環目標。
- duration_ms——與探針延遲尖峰對照。
- error_class——逾時、429、認證、沙箱拒絕等，對應修復劇本。
在 Grafana Loki 或 Elastic 建立範本查詢：例如 service="openclaw-gateway" AND level="error"，並與 Prometheus 的 env 標籤一致。若遇 429 風暴，可與站內多專案 API 預算／熔斷文互補，避免告警與花費政策打架。
生產注意：閘道令牌與出站限制
令牌。OPENCLAW_GATEWAY_TOKEN（或等效設定）不應成為 Prometheus 標籤。請放在 launchd 環境檔、Docker secret 或 vault sidecar；輪換節奏對齊 Tailscale 或上游 API 金鑰。切勿把密鑰拼進 scrape URL——設定檔與 exporter 日誌都是高洩漏面。探針若必須認證，請在本機反向代理終止 TLS／mTLS，並讓 scrape 僅走 loopback。
出站。租賃 Mac 作為 Agent 島時，技能常跑網域白名單。你的可觀測堆疊（OTLP 端點、Grafana Cloud、託管 Prometheus remote_write）也是一種出站目的地：請顯式加入白名單，或把 Collector 放在管理網路。否則「指標斷流」會被誤判成閘道掛掉，實際上是防火牆盡責。
頻率與基數。高頻 scrape 疊加除錯級日誌會搶佔 Agent 所需的同一 CPU 預算。生產預設 info、除錯採樣，並限制標籤維度——多租戶閘道尤甚。
FAQ
告警評估器要放在租賃機上嗎？建議使用外部評估（託管 Prometheus、雲端監控），主機全掛時仍能通知。僅在萬不得已時保留極簡 watchdog 腳本。
目前只有日誌怎麼辦？先將日誌送入既有堆疊，以 log-based metrics 衍生錯誤計數；就緒後再補 Prometheus 探針——事故流程相同，訊號品質階梯上升。