Applications — apps tracken + restart-EAT

Het Applications-systeem doet drie dingen:

Houdt bij wat hoort te draaien op een host (per app: type, identifier, expected state)
Vergelijkt elke 60 s de werkelijke state uit de inventory met de verwachte
Geeft je één knop om met TOTP een restart-EAT te tekenen voor een specifieke app

In het dashboard — een app registreren

Sidebar → Applicaties (onder ACTIE)
Knop + Track an app rechtsboven
Vul in:
- Agent — welke host hoort deze app te draaien
- Type — systemd unit / docker container / docker compose service / raw process
- Name — vrije naam voor in lijsten (bv. “MyApp web”)
- Identifier — concrete identifier per type:
  - systemd: unit-naam (nginx.service)
  - docker: container name (mycontainer)
  - compose: <project>::<service> (flowd_dev::app)
  - process: absoluut pad naar binary (/opt/myapp/start.sh)
Documentatie (optioneel maar aangeraden voor MSP-handover):
- Owner email — wie te poken als de app stuk gaat
- Runbook URL — link naar interne docs
- Notes — vrije tekst (deploy-pipeline, dependencies, slack-channel)
Onder Discovered on host zie je de live lijst systemd units + docker containers die de agent net rapporteerde. Klik op een rij om Type + Identifier + Name automatisch in te vullen
Klik op de zwarte Track this app knop onderaan

Vanaf nu: liveness-worker start binnen 60 s, verwachte state = running (kan je later wijzigen op de detailpagina van de app).

Wat er hierna gebeurt (per app, elke 60 s)

Fase	Wat
1. observe	Worker leest huidige state uit de LATEST inventory snapshot van de agent
2. compare	`expected_state` vs observed (running/stopped/unknown)
3. mismatch	Bij verschil: emit `app.state_mismatch` signal + verhoog `consecutive_mismatch` counter
4. alert	Na 3 consecutive mismatches: alert met severity warning
5. dashboard	App-row toont rood pixel + `last_state_change` timestamp

unknown (worker vindt geen rij voor deze identifier in latest snapshot) telt niet als mismatch — agent is misschien even down of het is een nieuwe deployment. Tellt pas mee na vier consecutieve unknowns.

Restart via EAT (Emergency Action Token)

Elke app-row heeft een Restart knop. Klik → TOTP-prompt → hub tekent een Level-2 Ed25519 EAT en pusht via WebSocket naar de agent. Agent runt monsys-action restart-app <id> als dedicated user (geen permanent root) en de wrapper kiest:

systemd: systemctl restart <unit>
docker: docker restart <container>
compose: docker compose -p <project> restart <service>
process: het opgegeven restart_command (absolute path verplicht)

Resultaat (exit_code + stdout/stderr) wordt teruggepusht en zit in audit_log + transparency_log als evidence — dezelfde flow als alle andere EAT-acties op het platform.

Tags + grouping

Apps erven de tags van hun agent. Een app op een host met tag production-db verschijnt in alle filters/SLA-engines die op die tag filteren. Wil je apps per environment groeperen? Tag de host (niet de app).

Of via API (geavanceerd — voor automatisering)

# Lijst alle apps voor een tenant
curl https://app.monsys.ai/api/v1/apps \
  -H "Authorization: Bearer $TOKEN"

# Registreer een app
curl -X POST https://app.monsys.ai/api/v1/apps \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id":  "<agent_uuid>",
    "name":      "MyApp web",
    "app_type":  "docker",
    "identifier": "eurooffice",
    "owner_email": "jeroen@gotrust.be",
    "runbook_url": "https://wiki.example.com/runbooks/myapp",
    "notes":     "Deploys via GitOps · slack #platform · dependency op redis-prod"
  }'

# Wijzig expected_state
curl -X PATCH https://app.monsys.ai/api/v1/apps/<id> \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"expected_state": "stopped"}'

# Restart (vereist TOTP-header)
curl -X POST https://app.monsys.ai/api/v1/apps/<id>/restart \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-TOTP-Code: 123456" \
  -d '{"reason": "Memory leak per ticket TKT-9001"}'

# Stop met tracken
curl -X DELETE https://app.monsys.ai/api/v1/apps/<id> \
  -H "Authorization: Bearer $TOKEN"

Discovered list is leeg — wat nu

Agent heeft nog geen extended inventory gerapporteerd: nieuwe agents pushen die elke 6 u (default inventory_interval_secs). Wacht of trigger handmatig via monsys-agent --once op de host
Agent is offline: kijk op /agents/<id> → last_seen_at. Stale agents reporteren niet
Agent draait een binary ouder dan v0.1.0+20260519: extended inventory shipped sindsdien. Trigger auto-update of upgrade handmatig
Bug die per 2026-05-20 gefixed is: discovery query miste latest- snapshot scope én tenant guard. Beide nu in de hub. Hard refresh je browser na deze fix

Wat NIET op deze pagina hoort

Inventory zelf (alle services + packages + ports) → zie Inventaris tab op de agent-detail pagina
Application-CVE scanning (npm/pip/composer/go deps) → zie Application CVEs
App-level alerts (cpu/mem/restart-count) → zie Alert builder