oodle-ai/agent-skills

oodle-synthetic

Create and manage Oodle synthetic monitors — HTTP and TCP health checks with assertions and configurable intervals.

Voir la source
Document Skill original

Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.

Oodle Synthetic Monitors — HTTP / TCP Checks

This skill teaches the agent to configure synthetic monitors that actually catch failures: assertions, sane intervals, and update-without-overwrite.

Prerequisites

bash
brew install oodle-ai/oodle/oodle
oodle configure

Confirm the synthetic-monitors endpoint works:

bash
oodle synthetic-monitors list -o json | jq 'length'

Command Execution Order

Before running any oodle command:

  1. Check whether the target URL or hostport is already in context.
  2. If not, ask the user to confirm the target.
  3. Test the target manually (curl -I <url>) to confirm it is reachable from the public internet.
  4. Run oodle synthetic-monitors create -f monitor.json.
  5. After creation, verify the first run succeeded with oodle synthetic-monitors get <id> -o json.

Quick Reference

TaskCommand
List monitorsoodle synthetic-monitors list -o json
Get monitoroodle synthetic-monitors get <id> -o json
Create monitoroodle synthetic-monitors create -f monitor.json
Update monitoroodle synthetic-monitors update <id> -f monitor.json
Delete monitoroodle synthetic-monitors delete <id> --force

Common Operations

Synthetic monitor schema (HTTP)

json
{
  "name": "API health check",
  "type": "http",
  "target": "https://api.example.com/health",
  "interval": 60,
  "assertions": [
    {"type": "statusCode",   "value": "200"},
    {"type": "responseTime", "value": "2000"}
  ]
}
FieldMeaning
typehttp or tcp
targetURL (HTTP) or host:port (TCP)
intervalSeconds between probes; minimum 30, recommended ≥ 60
assertions[].typestatusCode, responseTime, bodyContains, headerEquals
assertions[].valueString form of the expected value (e.g. "200", "2000", "ok")

Synthetic monitor schema (TCP)

json
{
  "name": "Postgres reachability",
  "type": "tcp",
  "target": "postgres.example.com:5432",
  "interval": 60,
  "assertions": [
    {"type": "responseTime", "value": "1000"}
  ]
}

Creating a monitor

bash
# ✅ CORRECT — manual reachability test, then create
curl -sSfI https://api.example.com/health
oodle synthetic-monitors create -f monitor.json

# ❌ WRONG — creating against an unreachable target leaves a permanently-failing monitor
oodle synthetic-monitors create -f monitor.json

Updating a monitor

bash
# ✅ CORRECT — get → edit → update preserves all assertions
oodle synthetic-monitors get syn_123 -o json > monitor.json
jq '.interval = 30' monitor.json > monitor.new.json
oodle synthetic-monitors update syn_123 -f monitor.new.json

# ❌ WRONG — partial payload removes assertions
oodle synthetic-monitors update syn_123 -f <(echo '{"interval":30}')

Deleting a monitor

bash
# ✅ CORRECT
oodle synthetic-monitors get syn_123 -o json > /dev/null
oodle synthetic-monitors delete syn_123 --force

# ❌ WRONG — name-grep delete
oodle synthetic-monitors delete "$(oodle synthetic-monitors list | grep health | awk '{print $1}')" --force

Best Practices

Use interval: 60 (or higher) for non-critical endpoints

A 10-second interval on every endpoint multiplies cost and noise. Reserve short intervals for critical user-facing flows.

bash
# ✅ CORRECT — 60s interval for a /health endpoint
"interval": 60

# ❌ WRONG — 10s on dozens of internal endpoints
"interval": 10

Always include at least one statusCode assertion

A monitor with no assertions only checks TCP reachability — it will pass even if the app returns 500 to every request.

bash
# ✅ CORRECT
"assertions": [{"type":"statusCode","value":"200"},{"type":"responseTime","value":"2000"}]

# ❌ WRONG — monitor "succeeds" on a 500 response
"assertions": []

Add a responseTime assertion to catch slow dependencies

A 200 response that takes 30 seconds is still a failure for users.

bash
# ✅ CORRECT
"assertions": [
  {"type":"statusCode","value":"200"},
  {"type":"responseTime","value":"2000"}
]

# ❌ WRONG — only checks status code, doesn't catch latency regressions
"assertions": [{"type":"statusCode","value":"200"}]

Always get before update to preserve assertions

Update is a full-document replace.

bash
# ✅ CORRECT
oodle synthetic-monitors get syn_123 -o json > m.json
jq '.assertions += [{"type":"bodyContains","value":"ok"}]' m.json > m.new.json
oodle synthetic-monitors update syn_123 -f m.new.json

# ❌ WRONG — drops `assertions` and `target`
oodle synthetic-monitors update syn_123 -f <(echo '{"interval":120}')

Use a stable name per environment

Encode env in the name (API health check (prod), API health check (staging)) so the alert recipient knows which env to investigate.

bash
# ✅ CORRECT
"name": "API health check (prod)"

# ❌ WRONG
"name": "health"

Failure Handling

ErrorCauseFix
401 UnauthorizedInvalid or missing API keyRun oodle configure or set OODLE_API_KEY
404 Not FoundSynthetic monitor ID does not existVerify with oodle synthetic-monitors list -o json
connection refusedWrong OODLE_DEPLOYMENT URLCheck OODLE_DEPLOYMENT env var
Monitor permanently redTarget unreachable from the probe egresscurl -I from the public internet; check firewall, DNS, TLS cert
Monitor flapsinterval too aggressive or responseTime assertion too tightRaise interval to 60s; raise responseTime to p95+headroom
Assertions silently droppedupdate was called with a partial payloadRe-create from the last get snapshot; always get → edit → update
429 Too Many RequestsMany probes scheduled at the same secondStagger by editing interval per monitor; use --retries 3 for bulk operations

References

du même dépôt

Autres Skills

Tous les Skills