Gérer la capacité des sandboxes

Ouvre Paramètres > Sandboxes lorsqu’un agent ou une analyse de site ne peut pas obtenir d’environnement d’exécution. La page distingue les limites de travail de ton organisation de l’infrastructure réelle du déploiement. Les Propriétaires et Admins peuvent modifier les limites et décider quand les espaces de travail inutilisés sont supprimés. Les Développeurs lisent les limites et la capacité globale, sans accéder aux détails privés des espaces de travail.

Identifier la limite concernée

Ces valeurs limitent le travail simultané, pas le nombre de tâches ni les dépenses. Un agent qui travaille sur trois tâches à la fois occupe trois workers d’agent ; une exécution qui les trouve tous occupés en attend un et démarre d’elle-même dès qu’un worker se libère. Sous Workers d’agent, les Propriétaires et les Admins voient combien d’exécutions d’agent attendent un worker libre : celles qu’une limite plus haute démarrerait tout de suite. Les limites ne réservent pas d’infrastructure : toutes les organisations partagent la capacité du déploiement.

Modifier une limite d’activité

1. Vérifie les places allouées à l’activité et les mesures d’infrastructure en dessous.
2. Saisis un entier de 1 à 500 pour la limite concernée. Le total affiché recalcule la somme des trois champs.
3. Maintiens cette somme dans la capacité du déploiement, puis choisis Enregistrer dans l’en-tête. Abandonner rétablit les valeurs enregistrées.
4. Rouvre la page pour vérifier les limites enregistrées, puis observe si de nouvelles tâches obtiennent une allocation.

Les valeurs initiales totalisent 6. Avec une capacité de déploiement de 8, un total de 8 est accepté et 9 est refusé. Le serveur vérifie à nouveau la capacité à l’enregistrement ; sa valeur peut donc différer de la première observation. Les appareils connectés de ton organisation ajoutent au plafond les sandboxes qu’ils exécutent : avec un appareil qui en exécute 4, le total peut atteindre 12.

Une baisse concerne les prochains démarrages et n’interrompt pas le travail en cours. Si les mesures d’infrastructure manquent, les réductions restent possibles, mais une augmentation demande une nouvelle observation de capacité. Si l’opérateur a abaissé la capacité sous ton total actuel, réduis les limites avant d’enregistrer à nouveau. Lorsque les allocations de l’organisation elles-mêmes ne peuvent pas être chargées, les champs restent indisponibles au lieu de présenter des valeurs par défaut modifiables.

Lire les mesures d’infrastructure

Les mesures s’actualisent toutes les 15 secondes. Actualiser demande une nouvelle observation ; vérifie sa date avant de l’interpréter. L’utilisation du CPU est la différence entre deux relevés ; la première observation après une longue interruption prend environ une seconde de plus. Un hôte distant peut fournir les totaux sans l’utilisation. L’accès au namespace Kubernetes ne fournit pas les mesures de l’hôte. Indisponible signifie inconnu, pas zéro.

Distinguer allocation et environnement inactif

Les Propriétaires et Admins peuvent examiner les espaces de travail. Chaque ligne identifie l’agent ou l’exécution, l’état de l’environnement, celui de l’allocation et les tâches en cours. Un agent a une ligne par worker : sous son nom, Worker 2 indique de quel worker il s’agit, et Worker de membre 2 désigne un worker qui exécute l’agent pour un Membre qui a démarré ses exécutions. Tâches en cours nomme chaque tâche par sa clé et son titre, et l’ouvre. Ces états répondent à des questions différentes : un conteneur peut rester actif pour être réutilisé après avoir libéré sa place dans l’organisation. L’espace de travail d’un worker reste affiché tant qu’il est inactif, avec l’état Arrêtée et Quota libéré, jusqu’à ce que tu le supprimes ou que Tale le supprime : quand personne ne l’a utilisé pendant le nombre de jours fixé par ton organisation, ou quand son agent, son projet ou le membre concerné est retiré. Si l’agent lui-même a été supprimé, la ligne indique Agent supprimé jusqu’à ce que Tale ait supprimé l’espace. L’espace d’une exécution de workflow est récupéré peu après la fin de l’exécution. Si un environnement sur le serveur Tale disparaît de lui-même, par exemple après un redémarrage de l’hôte ou faute de mémoire, son espace de travail garde ses fichiers et passe à l’état Arrêtée, et l’exécution suivante s’y poursuit. Cela ne vaut pas pour un environnement sur un appareil connecté.

Les dépenses additionnent le coût mesuré des échanges terminés. Un échange en cours est ajouté lorsqu’il se termine. Les environnements temporaires du crawler comptent dans la capacité même sans ligne d’espace de travail permanent.

Si le déploiement est plein, Tale peut récupérer un environnement inactif non épinglé, dont l’allocation est libérée et qui confirme n’avoir aucun travail en cours. Ses fichiers persistants restent disponibles au prochain démarrage. Les environnements occupés, épinglés ou sans réponse sont exclus. Sans candidat approprié, le nouveau travail doit attendre de la capacité. Un environnement dont la tâche ou l’exécution est terminée s’arrête après quelques minutes d’inactivité, si bien que sa place se libère peu après la fin du travail. Un environnement d’agent qui fait tourner Docker garde tout son délai d’inactivité, pour que le tour suivant n’ait pas à retélécharger ses images.

Gérer un espace de travail existant

Les Propriétaires et Admins disposent du menu de chaque ligne :

Tale enregistre durablement les changements d’épinglage et réessaie de les transmettre si le runtime ne les confirme pas, même après un redémarrage d’un worker backend ou une panne de l’appareil. Chaque tentative applique la dernière valeur souhaitée à la même instance de session. Répéter le détachement ne repousse pas son expiration.

Arrête la tâche si le travail doit cesser mais que ses fichiers doivent rester. Avant une suppression, conserve les résultats nécessaires et lis la confirmation. La récupération automatique de capacité inactive préserve les fichiers ; la suppression explicite ou automatique les retire.

Supprimer automatiquement les espaces de travail inutilisés

Un agent de projet garde ses fichiers d’une exécution à l’autre dans les espaces de travail de ses workers : un pour chaque tâche sur laquelle il a travaillé en même temps, que ses tâches suivantes réutilisent, et des espaces distincts pour chaque Membre qui démarre ses exécutions. L’espace de chaque worker compte ses jours sans utilisation séparément. Tale supprime un espace de travail que personne n’a utilisé pendant le nombre de jours fixé par ton organisation ; Supprimer retire toujours un espace immédiatement. Les Propriétaires et Admins définissent cette règle dans Nettoyage des espaces de travail, juste au-dessus de la liste Espaces de travail. Les Développeurs ne voient pas cette section.

1. Laisse Supprimer les espaces de travail inutilisés activé, comme par défaut. Tant que ce réglage est désactivé, Tale ne supprime aucun espace de travail pour cause d’inutilisation.
2. Dans Jours sans utilisation, saisis un entier de 1 à 3650 ; la valeur par défaut est 30. Les jours se comptent à partir de la dernière fois que l’agent a travaillé dans l’espace de travail, ou de son détachement.
3. Choisis Enregistrer dans l’en-tête. Abandonner rétablit les valeurs enregistrées.

Une modification ne fait jamais disparaître un espace de travail avant l’heure. Quand tu actives la suppression ou raccourcis la période, aucun espace de travail n’est supprimé pour cause d’inutilisation avant que ce nombre de jours ne se soit entièrement écoulé depuis la modification. La même attente suit la mise à jour qui a introduit ce réglage. Allonger la période ne relance pas cette attente ; désactiver puis réactiver la suppression la relance.

Dans la liste Espaces de travail, un espace d’agent arrêté affiche sous son état le jour de sa suppression : Suppression prévue le …, sauf nouvelle utilisation. Une nouvelle exécution dans l’espace relance le décompte. Un espace épinglé, ou protégé par une conservation légale, n’affiche aucune date et n’est jamais supprimé pour cause d’inutilisation.

Comprendre pourquoi un espace de travail a disparu

En plus des espaces inutilisés, Tale supprime un espace de travail dès que ce à quoi il appartient est retiré, quel que soit le réglage de nettoyage :

• La suppression d’un agent de projet efface les espaces de travail de tous ses workers, y compris ceux des Membres. La suppression d’un projet fait de même pour chacun de ses agents.
• Retirer un membre de l’organisation supprime ses propres espaces de travail avec tous les agents. Si tu le passes plutôt en Désactivé, ils sont conservés.
• Effacer les données d’une personne supprime ses propres espaces de travail sans attendre la fin du travail qui s’y exécute.
• La suppression de l’organisation efface toutes ses sandboxes et leurs fichiers, révoque les clés de passerelle qui leur ont été remises, supprime ses clés de fournisseur de modèle de la passerelle, déconnecte ses appareils et retire les caches de compilation et de paquets conservés pour elle.

Cela se produit en une minute environ ou, si une tâche s’exécute encore dans l’espace, après la fin de celle-ci. Un espace épinglé est supprimé lui aussi, mais une conservation légale garde tous les espaces de travail qu’elle couvre : celle de l’organisation les garde tous, celle qui vise une personne garde les espaces de travail propres à cette personne. Un nettoyage exécuté toutes les heures supprime aussi les restes que plus rien ne possède, comme l’espace d’une exécution de workflow jamais récupéré.

Chaque espace de travail que Tale supprime de lui-même, pour l’une de ces raisons ou pour cause d’inutilisation, apparaît dans le journal d’audit, sous Paramètres > Gouvernance > Journaux, avec l’action Espace de travail de sandbox supprimé. C’est un événement système de la catégorie Données, dont les métadonnées indiquent la raison : agent_deleted, member_removed, member_erased, unused ou orphaned. L’événement est enregistré une fois que Tale a confirmé la suppression des fichiers de l’espace, ce qui peut prendre un moment pour un grand espace. Sous Kubernetes, il est enregistré une fois le volume de l’espace remis au provisionneur de stockage du cluster, qui le supprime selon la reclaimPolicy de sa StorageClass ; les métadonnées indiquent ce qui s’est produit (deletion : done ou handed_off). Si la suppression des fichiers échoue, l’événement apparaît avec le statut Échec, et la suppression est retentée jusqu’à ce que les fichiers aient disparu. Un service de sandbox ou un appareil qui n’est pas encore passé à cette version ne peut confirmer aucune suppression : Tale n’enregistre aucun événement pour ses espaces et continue d’essayer jusqu’à sa mise à jour. Un reste que plus rien ne possède peut se terminer sans événement : si ses fichiers sont encore en cours de suppression quand le nettoyage horaire passe à la suite, le service de sandbox termine de les supprimer, mais Tale ne les vérifie plus.

Résoudre un démarrage bloqué

Un démarrage qui ne trouve pas de place attend, et sa tâche indique pourquoi sous Exécution : En attente d’un worker quand tous les workers d’agent de ton organisation sont occupés, En attente de place quand le déploiement est plein ou manque de mémoire ou d’espace disque, En attente d’un espace de travail pendant qu’un administrateur supprime l’espace que l’exécution utiliserait, et En attente de sa sandbox pendant que sa sandbox termine un processus précédent. Les Propriétaires et les Admins reçoivent aussi un lien vers cette page quand tous les workers d’agent sont occupés. Quand les limites de ton organisation sont occupées, ou que le déploiement est plein ou manque de mémoire, le travail démarre de lui-même dès qu’une place se libère, sans rien te demander. L’espace disque fait exception : arrêter un travail inactif n’en libère pas, car un espace de travail arrêté garde ses fichiers. Tale supprime les caches de build qu’aucune session n’utilise, s’il y en a ; si cela ne suffit pas, le démarrage attend que des espaces de travail soient supprimés, par exemple ceux que tu supprimes parce que tu n’en as plus besoin, ou que l’opérateur libère de l’espace disque. Quand le déploiement lui-même est plein, sa place va au travail qui attend depuis le plus longtemps, quelle que soit son organisation, et chaque démarrage en attente sait quand vient son tour :

• Une exécution de tâche attend dans la file. Elle est relancée dès qu’une session se termine, dans ton organisation ou dans une autre du même déploiement. Quand le déploiement est plein, elle est aussi relancée quand vient son tour. Toutes les deux minutes, Tale relance aussi quelques exécutions en attente de chaque organisation. Un worker libéré va d’abord à l’agent qui a le moins d’exécutions en cours, puis à l’exécution qui attend depuis le plus longtemps. Une exécution qui ne trouve pas de place dans les 12 heures suivant son démarrage échoue en indiquant qu’elle a attendu trop longtemps un worker libre.
• L’étape d’agent d’une automatisation réessaie sans consommer ses nouvelles tentatives : quand vient son tour si le déploiement est plein, sinon après une pause qui s’allonge tant que l’étape attend, jusqu’à environ deux minutes. L’exécution affiche entre-temps En attente d’une place de sandbox. Après deux heures sans place, l’exécution échoue avec cette raison. Un espace de travail qu’un administrateur supprime n’est pas un manque de place : l’étape échoue alors aussitôt, comme décrit plus haut pour Supprimer.
• L’exploration attend son tour, puis reprend avec son lot suivant.

Augmente une limite uniquement lorsque ses allocations sont occupées et que le nouveau total tient dans la capacité partagée. Si le déploiement est plein, augmenter la limite de l’organisation ne crée pas d’infrastructure. Pour ajouter ta propre capacité, connecte un appareil : les nouveaux espaces de travail y démarrent. Sinon, demande à l’opérateur d’examiner la capacité et les ressources de l’hôte. Une place libre ne garantit pas assez de CPU, de mémoire ou d’espace disque.

Pour un refus d’identifiants ou de modèle, consulte Fournisseurs IA. Pour un refus de dépense, consulte Politiques et limites. Les opérateurs auto-hébergés trouveront le réglage du déploiement dans la référence d’environnement.