Ga naar inhoud
monsys.ai

DevOps — SLO's, supply chain, LLM observability

1. SLO + error budget per applicatie

In het dashboard

  1. Sidebar → Apps → klik je applicatie → tab SLO
  2. Knop ‘Define SLO’ → target 0.999 + window 30 dagen
  3. Burn-down sparkline verschijnt direct in dezelfde tab
  4. Knop ‘Embed badge’ kopieert markdown voor je README

Definieer een applicatie en bind metrics aan:

Of via API (geavanceerd — voor automatisering)

Terminal window
curl -X POST https://app.monsys.ai/api/v1/apps \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "name":     "checkout-api",
    "type":     "http",
    "agent_id": "<agent_uuid_of_web_lb>",
    "endpoint": "https://checkout.example.com/healthz",
    "interval_seconds": 30
  }'

Stel SLO + window:

Terminal window
curl -X POST https://app.monsys.ai/api/v1/apps/<app_id>/slo \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "target":         0.999,
    "window_days":    30,
    "minimum_data":   0.95
  }'

/operations/mttr toont per applicatie:

  • Huidige rolling 30d uptime (% en minutes-down)
  • Error budget remaining (in minutes)
  • Burn-down sparkline (huidige burn rate vs. target)
  • “Days until budget exhausted” als je deze week zo door blijft branden

Voor je sprint review: download de SLO-CSV via /api/v1/apps/<id>/slo/history?days=90. Voor je deploy-gate kun je checken of burn rate < 2.0 was in de laatste uur.

2. Slack/ntfy alert wanneer container > 3x restart in een uur

In het dashboard

  1. Sidebar → Settings → Alert rules → ‘Nieuwe regel’
  2. Metric: container_restart_count, operator >, threshold 3, window 1h
  3. Webhook URL veld: https://hooks.slack.com/services/T0/B0/xxx
  4. WebhookDispatchWorker doet retries + lekken nooit secrets

monsys.ai stuurt zelf niets naar Slack — wel naar ntfy (self-host) of via een webhook. Slack-webhook voorbeeld:

Of via API (geavanceerd — voor automatisering)

Terminal window
curl -X POST https://app.monsys.ai/api/v1/alert-rules \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "name":     "Container flapping",
    "metric":   "container_restart_count",
    "operator": ">",
    "threshold": 3,
    "window":   "1h",
    "severity": "warning",
    "group_by": ["agent_id", "container_name"],
    "webhook_url": "https://hooks.slack.com/services/T0/B0/xxx"
  }'

WebhookDispatchWorker doet de outgoing POST met een minimal JSON body ({title, severity, agent, link}) — geen prompt content of geheimen. Retries 3× met backoff. Logs in /audit-log event_type webhook_delivery.

3. Auto-update CVE-quetsbare npm-deps, behalve onze DB-driver

In het dashboard

  1. Sidebar → Aanbevelingen → tab ‘Application CVEs’
  2. Per kwetsbaar package: knop ‘Auto-update’ of ‘3-dots → Suppress this fix’
  3. Bij suppression: vul expires_at + reden in
  4. Future Auto-update-all toont skip met reden in maandelijkse evidence

Application dependency CVE scanning loopt elk uur. Open /recommendations → “Application CVEs” → je ziet bv. 12 packages met beschikbare fixes.

Klik “Auto-update all” — voorwaarden:

  • TOTP required
  • Capped op 25 EATs per click (vermijdt fleet-wide blast)
  • Per (project, ecosystem) krijgt elke host één EAT met de combined package list

Wil je een package pinnen (bv. mysql2@2.3.0 omdat 2.4.x een breaking ABI change heeft)? Voeg een suppression:

Of via API (geavanceerd — voor automatisering)

Terminal window
curl -X POST https://app.monsys.ai/api/v1/cve-suppressions \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "package_name":  "mysql2",
    "ecosystem":     "npm",
    "version_range": ">=2.4.0",
    "reason":        "ABI break — see PROD-123 ticket",
    "expires_at":    "2026-09-01"
  }'

Toekomstige auto-update-all skipt deze upgrade én noteert in evidence dat hij genegeerd is met de opgegeven reden.

4. Detecteer npm-maintainer wisseling (supply-chain attack indicator)

In het dashboard

  1. Sidebar → Inventaris → tab Dependencies → filter ‘Maintainer changed (7d)’
  2. Per package: huidige + vorige maintainer set
  3. Klik verdacht package → ‘Pin version’ of ‘Investigate’
  4. Hit triggert automatisch webhook naar je incident tooling

Sinds schema 076 trackt monsys de set van publish-emails per npm package waar je een dependency op hebt. Wijziging = alert.

Of via API (geavanceerd — voor automatisering)

SELECT package_name,
       ecosystem,
       maintainers,
       deprecated,
       last_maintainer_change_at,
       seen_at
  FROM supply_chain_maintainer_cache
 WHERE tenant_id = $1::UUID
   AND last_maintainer_change_at >= NOW() - INTERVAL '7 days'
 ORDER BY last_maintainer_change_at DESC;

Workflow op een hit:

  1. Check of de nieuwe maintainer een legitieme org-collaborator is (vaak ja → accept de change via UI)
  2. Zo niet: pin de huidige version via cve_suppressions + open een ticket bij upstream
  3. Optioneel: trigger een IsolateNetwork EAT op staging-hosts die het package al hadden geïnstalleerd

5. Terraform-managed config vs. drift detection

In het dashboard

  1. Sidebar → Settings → API tokens → genereer scoped readonly token
  2. Sidebar → AI Insights → ‘Deploy gate template’ → copy bash snippet
  3. Plak in je CI yaml vóór de deploy stap
  4. Test met —dry-run — toont Trust Score + open critical alerts

We assumeren dat Terraform de waarheid is voor /etc/ssh/sshd_config. Een drift = iemand heeft handmatig iets gewijzigd.

Of via API (geavanceerd — voor automatisering)

Terminal window
# Na elke succesvolle terraform apply: bump de baseline
curl -X POST https://app.monsys.ai/api/v1/agents/<id>/config-hashes/rebase \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "paths": ["/etc/ssh/sshd_config", "/etc/nginx/nginx.conf"],
    "reason": "terraform apply commit 7a3c…"
  }'

Drift binnen 7 dagen na een baseline-rebase die door iemand anders dan de Terraform-service-user is gedaan = automatisch ticket in je issue-tracker via WebhookDispatch.

6. LLM-cost per team via SDK

In het dashboard

  1. Sidebar → AI → tab ‘Per team’
  2. Standaard groepering op ‘team’ tag uit SDK
  3. Filter descending op kosten OF p95 latency
  4. Knop ‘Export CSV maand’ voor financiële cross-charge

Of via API (geavanceerd — voor automatisering)

# In je Python service
from monsys_ai import MonsysClient


client = MonsysClient(
    hub_url="https://hub.monsys.ai",
    api_key=os.environ["MONSYS_AI_TOKEN"],
    tenant="acme",
    team="checkout",        # → tag op elke trace
)


with client.trace("price-lookup") as t:
    resp = openai.chat.completions.create(...)
    t.add_llm_call(
        model=resp.model,
        prompt_tokens=resp.usage.prompt_tokens,
        completion_tokens=resp.usage.completion_tokens,
    )

In /ai/quadrant zie je per team de breakdown: cost, p95 latency, top 3 modellen, refusal-rate. CSV-export voor maandelijkse cross-charge.

PII redaction gebeurt in de SDK, niet op de hub. De agent ziet nooit de raw prompt — alleen tokens-counts en een SHA256-hash van het prompt voor dedup.

7. Deploy-gate: blokkeer release als kritieke alert open is

In het dashboard

  1. Sidebar → Webhooks → ‘Register endpoint’
  2. URL + shared HMAC secret + events filter (alert.created, alert.resolved)
  3. Min severity = warning + agent_filter op tag
  4. Retries 3× met backoff; failures landen in audit_log

Voor je CI pipeline:

Of via API (geavanceerd — voor automatisering)

#!/usr/bin/env bash
# Voor `helm upgrade` / `kubectl apply` etc.
OPEN_CRITICAL=$(curl -s \
  "https://app.monsys.ai/api/v1/alerts?severity=critical&is_resolved=false&tag=production" \
  -H "Authorization: Bearer $MONSYS_TOKEN" | jq '. | length')


if [[ "$OPEN_CRITICAL" -gt 0 ]]; then
  echo "✗ refusing deploy: $OPEN_CRITICAL critical alerts open on production"
  exit 1
fi


# Trust Score gate
SCORE=$(curl -s "https://app.monsys.ai/api/v1/trust-score/v12/tenant" \
  -H "Authorization: Bearer $MONSYS_TOKEN" | jq '.final_score')


if [[ "$SCORE" -lt 70 ]]; then
  echo "✗ refusing deploy: Trust Score $SCORE/100 below threshold 70"
  exit 1
fi


echo "✓ Trust Score $SCORE, no open critical alerts — proceeding"

Dit voorkomt het “nu ook maar deployen want pas later kijken naar alerts” anti-pattern.

8. Webhook-integratie met je eigen incident-response tooling

In het dashboard

  1. Sidebar → Settings → ‘Embed badge’ (Trust Score panel)
  2. Kopieer SVG-URL met je tenant_id
  3. Plak markdown in README of internal status-page
  4. Update elke 30 min, geen JavaScript, geen tracking

WebhookDispatchWorker POSTet bij elke alert met severity ≥ warning. Custom endpoint registreren:

Of via API (geavanceerd — voor automatisering)

Terminal window
curl -X POST https://app.monsys.ai/api/v1/webhooks \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "url":            "https://incidents.acme.com/api/v1/intake",
    "secret":         "shared-hmac-secret",
    "events":         ["alert.created","alert.resolved"],
    "min_severity":   "warning",
    "agent_filter":   {"tag":"production"}
  }'

Body shape:

{
  "event": "alert.created",
  "alert": {
    "id": "…",
    "severity": "critical",
    "category": "cpu",
    "title": "Host CPU > 95% sustained 10min",
    "agent": { "id": "…", "hostname": "web-03", "tags": ["production"] }
  },
  "tenant_id": "…",
  "timestamp": "2026-05-19T20:34:00Z"
}

Headers:

  • X-Monsys-Signature: sha256=… (HMAC over body with secret)
  • X-Monsys-Delivery: <uuid> (idempotency key)
  • X-Monsys-Event: alert.created

Re-tries: 3× met exponential backoff (10s / 60s / 5min). Final failure landt in /audit-log als webhook_delivery_failed en jouw endpoint zit in een 10-min cooldown om hot-loops te vermijden.

9. Trust Score in je README/dashboard inbedden

Of via API (geavanceerd — voor automatisering)

![Trust Score](https://badge.monsys.ai/tenant/<tenant_id>/trust-score.svg)

Server-rendered SVG. Updates elke 30 minuten (Trust Score worker cycle). Het badge toont kleur per band: <50 rood, 50-70 oranje, 70-85 groen,

85 donkergroen. Geen JavaScript, geen tracking — direct vanuit TimescaleDB gerendered.

Tip voor multi-tenant orgs: gebruik per repo de tenant-id van het project (DEV, STG, PROD apart) en zet 3 badges naast elkaar — meteen zichtbaar of staging anders presteert dan productie.