Applications — tracker des apps + EAT de redémarrage

Le système Applications fait trois choses :

Suit ce qui doit tourner sur un host (par app : type, identifier, état attendu)
Compare l’état réel depuis l’inventaire toutes les 60 s à l’attendu
Vous donne un seul bouton pour signer un EAT de redémarrage gated TOTP pour une app spécifique

Dans le tableau de bord — enregistrer une app

Sidebar → Applications (sous ACTION)
Bouton en haut à droite + Track an app
Renseignez :
- Agent — quel host doit faire tourner cette app
- Type — systemd unit / docker container / docker compose service / raw process
- Name — étiquette libre pour les listes (ex. “MyApp web”)
- Identifier — identifier concret par type :
  - systemd : nom d’unité (nginx.service)
  - docker : nom de conteneur (mycontainer)
  - compose : <project>::<service> (flowd_dev::app)
  - process : chemin absolu vers le binaire (/opt/myapp/start.sh)
Documentation (facultative mais recommandée pour handover MSP) :
- Owner email — qui contacter quand l’app casse
- Runbook URL — lien vers docs internes
- Notes — texte libre (pipeline deploy, dépendances, channel slack)
Sous Discovered on host vous voyez la liste live des unités systemd + conteneurs docker que l’agent vient de rapporter. Cliquez sur une ligne pour auto-remplir Type + Identifier + Name
Cliquez sur le bouton noir Track this app en bas

À partir de maintenant : le worker liveness démarre dans les 60 s, état attendu = running (modifiable plus tard sur la page détail de l’app).

Ce qui se passe ensuite (par app, toutes les 60 s)

Phase	Quoi
1. observe	Worker lit l’état actuel depuis le DERNIER snapshot inventaire de l’agent
2. compare	`expected_state` vs observé (running/stopped/unknown)
3. mismatch	Sur différence : émet signal `app.state_mismatch` + incrémente compteur `consecutive_mismatch`
4. alert	Après 3 mismatches consécutifs : alerte avec sévérité warning
5. dashboard	Ligne app montre pixel rouge + timestamp `last_state_change`

unknown (worker ne trouve pas de ligne pour cet identifier dans le dernier snapshot) ne compte pas comme mismatch — l’agent est peut- être brièvement down ou c’est un nouveau déploiement. Compte seulement après quatre unknowns consécutifs.

Redémarrage via EAT (Emergency Action Token)

Chaque ligne app a un bouton Restart. Cliquer → prompt TOTP → le hub signe un EAT Ed25519 niveau 2 et le pousse via WebSocket à l’agent. L’agent exécute monsys-action restart-app <id> en utilisateur dédié (pas de root permanent) et le wrapper choisit :

systemd : systemctl restart <unit>
docker : docker restart <container>
compose : docker compose -p <project> restart <service>
process : la restart_command configurée (chemin absolu requis)

Le résultat (exit_code + stdout/stderr) est repoussé et atterrit dans audit_log + transparency_log comme preuve — même flux que toutes les autres actions EAT sur la plateforme.

Tags + groupement

Les apps héritent des tags de leur agent. Une app sur un host avec tag production-db apparaît dans chaque filtre/moteur SLA qui filtre sur ce tag. Vous voulez grouper apps par environnement ? Taguez le host (pas l’app).

Ou via API (avancé — pour automatisation)

# Lister toutes les apps pour un tenant
curl https://app.monsys.ai/api/v1/apps \
  -H "Authorization: Bearer $TOKEN"

# Enregistrer une 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":     "Déploie via GitOps · slack #platform · dépend de redis-prod"
  }'

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

# Redémarrer (requiert header TOTP)
curl -X POST https://app.monsys.ai/api/v1/apps/<id>/restart \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-TOTP-Code: 123456" \
  -d '{"reason": "Fuite mémoire selon ticket TKT-9001"}'

# Arrêter le tracking
curl -X DELETE https://app.monsys.ai/api/v1/apps/<id> \
  -H "Authorization: Bearer $TOKEN"

Liste Discovered vide — que faire

L’agent n’a pas encore envoyé d’extended inventory : nouveaux agents poussent toutes les 6 h (default inventory_interval_secs). Attendez ou déclenchez manuellement avec monsys-agent --once sur le host
Agent offline : vérifiez /agents/<id> → last_seen_at. Les agents stale ne rapportent pas
Agent sur un binaire plus ancien que v0.1.0+20260519 : l’extended inventory existe depuis. Déclenchez auto-update ou upgrade manuel
Bug corrigé le 2026-05-20 : la requête discovery manquait le scope latest-snapshot ET le tenant guard. Les deux sont maintenant dans le hub. Hard-refresh votre navigateur après ce fix

Ce qui n’est PAS sur cette page

Inventaire lui-même (tous services + packages + ports) → voir onglet Inventaire sur la page détail de l’agent
Scan CVE applicatif (deps npm/pip/composer/go) → voir Application CVEs
Alertes app-level (cpu/mem/restart-count) → voir Alert builder