使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/fagnerlopes/cloud-weaver --skill cloud-weaver-monitor開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Monitor
Confirm the deployed recipe is healthy. Called optionally after cloud-weaver-repo-setup completes — when the GHA pipeline succeeds but the user wants an explicit health confirmation, or when diagnosing a problem.
In the v2 flow the pipeline itself waits for kamal deploy to finish, so in the happy path this skill is a belt-and-suspenders check, not a required step.
1. Determine the health URL and SSH key
Required inputs (passed from start-cloud or cloud-weaver-repo-setup):
| Variable | Example |
|---|---|
PUBLIC_IP | 200.1.2.3 |
REPO_NAME | meu-hermes |
Each recipe exposes a health endpoint:
| Recipe | Health check URL |
|---|---|
hermes-agent | https://${PUBLIC_IP}.nip.io/health |
waha | https://${PUBLIC_IP}.nip.io/api/health |
SSH key path (per-repo, generated by cloud-weaver-repo-setup):
SSH_KEY="$HOME/.ssh/cw-${REPO_NAME}"2. Poll the health endpoint
Run the poller (pure stdlib, no dependencies). It waits a grace period for containers to boot, then probes with exponential backoff until HTTP 200 or the timeout budget runs out:
python3 <this-skill-dir>/scripts/health-check.py \
--url "https://${PUBLIC_IP}.nip.io/health" \
--timeout 600 --initial-delay 30Give the user plain-language status updates while it runs (Estou aguardando a aplicação subir…). On success the script exits 0. Use --output report.json when the caller wants the attempt history.
3. On success — proceed
Report to the user that the app is healthy. Hand off to the final report.
4. On failure — diagnose via SSH
If the health check times out or never returns 200, collect VM diagnostics:
bash <this-skill-dir>/scripts/diagnose.sh \
--ssh-key "$HOME/.ssh/cw-${REPO_NAME}" --ip "$PUBLIC_IP"This gathers: docker ps, /data disk usage, memory, the Docker daemon log and uptime. Read the output and reason out loud:
- Containers not running → check Kamal service logs on the VM:
ssh -i "$HOME/.ssh/cw-${REPO_NAME}" root@"$PUBLIC_IP" \
"docker ps -a && docker logs \$(docker ps -lq) --tail 50"- Container restarting → view its logs for the exit reason.
- Disk/memory pressure → the plan may be too small; suggest a larger VM plan.
- Docker daemon down →
systemctl status dockeron the VM.
Use the per-repo SSH key (~/.ssh/cw-<repo-name>, user root, -o StrictHostKeyChecking=accept-new) for any follow-up commands. Report findings to the user in plain PT-BR and recommend the next action.
Rollback
Automated rollback is not implemented. If diagnostics show the VM itself cannot be recovered, tell the user clearly — then offer to run cloud-weaver-teardown and start fresh.
Bundled Resources
- `scripts/health-check.py` — HTTP poller (stdlib, backoff, report JSON)
- `scripts/diagnose.sh` — SSH diagnostics collector (
--dry-runsupported)
