Exploiter Mem0 et Cognee

L'exploitation technique des deux moteurs appartient au Navin Manager. Navin Enterprise ne lance aucune commande système ; il lit seulement la santé d'un moteur par GET /v1/memory/engines/{engine_id}/health (voir Intégration).

Démarrer, arrêter, redémarrer

Chaque composant tourne comme une unité systemd du Manager, navin-<service>-<composant>.service, qu'il soit natif ou Podman (Quadlet) :

Service	Unités
Mem0	navin-mem0-mem0-server, navin-mem0-request-log-pruner
Cognee	navin-cognee-api, navin-cognee-ui (si ui_enabled), navin-cognee-mcp (si mcp_enabled)

Les actions de démarrage, d'arrêt et de redémarrage passent par la fiche du service dans le Manager. Un paramètre marqué « redémarrage » dans la page générée ne s'applique qu'après un redémarrage. La purge du journal des requêtes de Mem0 démarre après le serveur, sur le même hôte.

Santé et commandes

Service	Commande du descripteur	Effet
Mem0	configuration	configuration effective (GET /configure, secrets masqués par le serveur)
Mem0	prune_request_logs	purge immédiate du journal des requêtes
Mem0	migrate	migrations Alembic de la base applicative (faites aussi à chaque démarrage)
Mem0	logs	dernières lignes du journal du serveur
Cognee	health_detailed	santé de chaque stockage et de la passerelle vue par l'API (GET /health/detailed)
Cognee	migrate	migrations alembic et révisions du graphe et des vecteurs (cognee-cli upgrade, méthode python ; avec podman l'API les applique à son démarrage)
Cognee	logs, ui_logs, mcp_logs	dernières lignes du journal de l'API, de l'interface, du serveur MCP

Les contrôles de santé et de disponibilité sont décrits dans Installation.

Consoles : l'interface de Cognee (port 8421, chemin /dashboard) s'ouvre depuis le registre des consoles du Manager quand ui_enabled est actif, avec les comptes de Cognee ; le Manager ne l'intègre jamais dans une iframe, elle s'ouvre dans un nouvel onglet, et le navigateur appelle directement l'API Cognee, qu'il faut donc publier avec elle. Mem0 n'a pas de console : son tableau de bord n'est pas livré et la page Swagger /docs n'est pas une interface d'administration.

Mise à jour et retour arrière

Les deux descripteurs déclarent un service avec état et une sauvegarde obligatoire avant la mise à jour (backup_before: true). Ce sont les premières versions du catalogue : aucune version antérieure n'est encore listée comme source d'une mise à jour (from: []).

• Mem0 : après la sauvegarde, l'étape alembic_head applique les migrations Alembic de la version (idempotente à la tête, vérifiée par test_mem0_real.py).
• Cognee : après la sauvegarde, l'API applique à son démarrage les migrations alembic et les révisions du format de stockage LadybugDB (ENABLE_AUTO_MIGRATIONS).

Le retour arrière automatique n'est pas pris en charge : les migrations ne vont qu'en avant et le Manager ne les annule jamais. Le chemin de retour est la restauration de la sauvegarde prise avant la mise à jour, avec les artefacts de la version précédente, que le hub garde disponibles (ADR-0174).

Sauvegarde et restauration

Service	Sauvegarde	Restauration
Mem0 (mem0-pgdump)	pg_dump format custom, sans propriétaire ni privilège, des bases mem0 et mem0_app (memories.dump, app.dump) et sauvegarde SQLite en ligne du fichier d'historique (history.db) ; la vérification lit la table des matières de chaque sauvegarde et contrôle l'intégrité d'une copie de l'historique	serveur arrêté, pg_restore --clean --if-exists en une transaction par base, puis remplacement du fichier d'historique
Cognee (cognee-pgdump-ladybug)	API arrêtée (son arrêt écrit le journal de chaque fichier LadybugDB), pg_dump de la base cognee, archives tar de la racine système (graphes LadybugDB, cache des sessions) et de la racine des données, manifeste sha256, puis redémarrage ; la vérification contrôle chaque sha256, la table des matières et chaque membre des archives	API arrêtée, DROP OWNED BY du rôle de Cognee et objets de la sauvegarde en une transaction, puis remplacement des deux racines

L'extension vector reste celle du provisionnement. Les deux cycles sauvegarde, perte, restauration ont été exécutés réellement (test_mem0_real.py, test_cognee_real.py) : une mémoire supprimée après la sauvegarde revient, une mémoire écrite après disparaît ; un jeu de données Cognee supprimé revient avec son graphe et ses vecteurs. La sauvegarde de Cognee arrête l'API pendant sa durée.

Rétention

Donnée	Réglage	Défaut
Journal des requêtes de Mem0 (request_logs de mem0_app)	request_log_retention_days, purge toutes les prune_interval_hours par le composant request-log-pruner	30 jours, toutes les 24 heures
Historique des sessions de recherche de Cognee	session_ttl_days	7 jours
Mémoires Mem0, jeux de données, graphes et vecteurs Cognee	gardés jusqu'à leur suppression par l'API	-

La santé de la purge exige une exécution réussie depuis moins de deux intervalles. La rétention métier des mémoires (durée de vie, conservation légale) est fixée par la politique de l'agent dans Navin Enterprise.

Supervision : sondes, alertes et journaux

Aucun des deux moteurs ne sert de métriques Prometheus à sa version épinglée : le serveur Mem0 2.2.1 n'a pas de route /metrics, Cognee 1.6.6 ne pousse des métriques OpenTelemetry que par OTLP et seulement avec le traçage. Aucun composant ne déclare donc de cible de collecte. La supervision repose sur :

• les sondes blackbox de /openapi.json et /auth/setup-status pour Mem0, de /health et de la vérification authentifiée pour Cognee ;
• l'état des unités systemd collecté par le node exporter (node_systemd_unit_state), dans le groupe de règles navin-memory ;
• les journaux de chaque unité et des conteneurs Podman de Cognee, gardés par Alloy (job journal, étiquette unit) ;
• les traces OpenTelemetry de Cognee quand tracing_enabled est actif et l'otel-collector lié (méthode python).

Alerte	Condition	Sévérité
NavinMemoryEngineDown	une unité navin-(mem0|cognee)-* n'est pas active depuis 2 minutes	critique
NavinMemoryEngineFailed	systemd a marqué l'unité en échec depuis 1 minute	critique
NavinMemoryEngineRestarting	plus de 4 changements d'état en 15 minutes	avertissement

Les règles sont vérifiées par promtool check rules et promtool test rules dans test_catalog_memory_observability.py. Sans unité de mémoire sur le cluster, elles restent silencieuses.

Ce qui n'est pas observable

Faute de métriques natives, ni le nombre de requêtes, ni leur latence, ni les erreurs par route, ni le nombre de mémoires ou de jeux de données, ni la durée d'un cognify ne sont mesurés par Prometheus. Les sondes disent si le moteur répond, pas s'il répond bien. Pour Mem0, aucune trace n'est émise (pas d'OpenTelemetry dans le serveur 2.2.1). Ces informations se lisent dans les journaux, dans la santé détaillée de Cognee et dans les événements d'audit de Navin Enterprise.