# Monitoring & observability (spec §58) ## Mät- och larmpunkter | Signal | Källa | Larmtröskel (initial) | | --------------------- | --------------------------------------------- | ------------------------ | | API-fel (5xx-andel) | API-loggar (pino) → CloudWatch | > 2 % över 5 min | | API-latens p95 | reverse proxy-loggar | > 1 500 ms över 10 min | | Workerfel | worker-loggar (`✗`-rader) | > 5 fel / 10 min | | Köns längd | `GET /admin/v1/jobs/overview` (queue.waiting) | > 100 väntande i 10 min | | Outbox-eftersläp | samma endpoint (outboxPending) | > 500 i 15 min | | DB-anslutningar | RDS CloudWatch | > 80 % av max | | Redis-minne | Redis INFO | > 80 % av maxmemory | | AAMOS-hälsa | `GET /admin/v1/system/health` (aamos.ok) | fel i 3 kontroller i rad | | AI-kostnad | scan_jobs.cost_usd summerat per dag | > budgettak per dag | | Subscription-webhooks | store_notifications (processed=false ålder) | äldst > 30 min | | Sync-konflikter | app-telemetri (senare fas) | – | | Abuse | rate limit-träffar per IP | manuell granskning | ## Correlation ID Varje request får/vidarebefordrar `x-correlation-id` (spec §58). ID:t följer med i: API-loggar → jobbdata → AAMOS-anrop (`metadata.correlationId`) → audit logs. Sök på ID:t i loggarna för att följa ett flöde genom hela systemet. ## Healthchecks - `GET /healthz` – liveness (alltid 200 när processen lever) - `GET /readyz` – readiness (DB-ping; 503 vid fel) - Docker HEALTHCHECK på API-containern - `GET /admin/v1/system/health` – DB, Redis, AAMOS, connectors (admin-token) ## Steg 1-implementation (befintlig server) 1. CloudWatch Agent läser Docker json-file-loggar under `/var/lib/docker/containers`. 2. Metric filters på `"level":50` (error) och `✗`-rader → larm till befintlig SNS-kanal. 3. Cron-jobb kör `curl /readyz` varje minut → larm efter 3 fel. ## Steg 3 (egen VPC/ECS) CloudWatch Container Insights + RDS Performance Insights + strukturerade loggar till CloudWatch Logs Insights. Dashboards definieras som kod i denna katalog.