Sandbox-Kapazität verwalten

Öffne Einstellungen > Sandboxes, wenn Agenten oder Website-Scans keine Ausführungsumgebung erhalten. Die Seite trennt die Arbeitsgrenzen deiner Organisation von der tatsächlichen Infrastruktur des Deployments. Inhaber und Admins dürfen Limits ändern und festlegen, wann ungenutzte Arbeitsbereiche gelöscht werden. Entwickler sehen Limits und zusammengefasste Kapazität, aber keine privaten Workspace-Details.

Das relevante Limit erkennen

Die Werte begrenzen gleichzeitige Arbeit, nicht die Anzahl der Aufgaben oder die Ausgaben. Ein Agent, der an drei Aufgaben gleichzeitig arbeitet, belegt drei Agenten-Worker; ein Lauf, der alle belegt vorfindet, wartet auf einen und startet von selbst, sobald einer frei ist. Unter Agenten-Worker sehen Inhaber und Admins, wie viele Agentenläufe auf einen freien Worker warten: die Läufe, die ein höheres Limit sofort starten würde. Die Limits reservieren keine Infrastruktur: Alle Organisationen teilen sich die Deployment-Kapazität.

Ein Arbeitslimit ändern

1. Prüfe die belegten Plätze der Arbeitsart und die Infrastrukturwerte darunter.
2. Gib beim passenden Limit eine ganze Zahl von 1 bis 500 ein. Die angezeigte Gesamtzahl berechnet die Summe aller drei Felder neu.
3. Halte die Summe innerhalb der Deployment-Kapazität und wähle Speichern im Kopfbereich. Verwerfen stellt die gespeicherten Werte wieder her.
4. Öffne die Seite erneut, prüfe die gespeicherten Limits und beobachte, ob neue Arbeit einen Platz erhält.

Die Standardwerte ergeben zusammen 6. Bei einer Deployment-Kapazität von 8 ist eine Summe von 8 erlaubt, 9 wird abgelehnt. Der Server prüft die Kapazität beim Speichern erneut. Der aktuelle Wert kann deshalb von der ersten Beobachtung abweichen. Die verbundenen Geräte deiner Organisation erhöhen die Obergrenze um die Sandboxes, die sie ausführen: Mit einem Gerät, das 4 ausführt, darf die Summe 12 erreichen.

Eine Senkung betrifft künftige Starts und unterbricht keine laufende Arbeit. Sind Infrastrukturwerte nicht verfügbar, bleiben Senkungen möglich; Erhöhungen brauchen einen aktuellen Kapazitätswert. Hat der Betreiber die Kapazität unter deine bisherige Summe gesenkt, reduziere die Limits vor dem nächsten Speichern. Lassen sich bereits die Organisationsbelegungen nicht laden, bleiben die Felder gesperrt, statt bearbeitbare Standardwerte anzuzeigen.

Die Infrastrukturwerte lesen

Die Werte aktualisieren sich alle 15 Sekunden. Mit Aktualisieren forderst du eine neue Beobachtung an. Prüfe den Zeitstempel. Die CPU-Auslastung ist die Differenz zweier Messungen; die erste Beobachtung nach einer längeren Pause dauert etwa eine Sekunde länger. Entfernte Hosts liefern gegebenenfalls nur Gesamtwerte. Namespace-Zugriff unter Kubernetes liefert keine Host-Messungen. Nicht verfügbare Werte sind unbekannt, nicht null.

Belegte und inaktive Workspaces unterscheiden

Inhaber und Admins können Arbeitsbereiche prüfen. Jede Zeile nennt den zugehörigen Agenten oder Workflow-Lauf, Laufzeitstatus, Belegungsstatus und laufende Aufgaben. Ein Agent hat eine Zeile pro Worker: Unter seinem Namen sagt Worker 2, welcher seiner Worker die Zeile ist, und Mitglieder-Worker 2 kennzeichnet einen, der den Agenten für ein Mitglied ausführt, das seine Läufe gestartet hat. Aktuelle Aufgaben nennt jede Aufgabe mit Schlüssel und Titel und öffnet sie. Die Zustände beantworten unterschiedliche Fragen: Ein Container kann für die Wiederverwendung weiterlaufen, obwohl er seinen Organisationsplatz bereits freigegeben hat. Der Arbeitsbereich eines Workers bleibt auch im Leerlauf aufgeführt, als Gestoppt mit Kontingent freigegeben, bis du ihn löschst oder Tale ihn löscht: wenn ihn niemand während der von deiner Organisation festgelegten Anzahl Tage genutzt hat oder wenn sein Agent, sein Projekt oder das zugehörige Mitglied entfernt wird. Wurde der Agent selbst gelöscht, steht in der Zeile Gelöschter Agent, bis Tale den Arbeitsbereich gelöscht hat. Der Arbeitsbereich eines Workflow-Laufs wird kurz nach dem Ende des Laufs zurückgefordert. Verschwindet eine Umgebung auf dem Tale-Server von selbst, etwa nach einem Neustart des Hosts oder weil ihr der Speicher ausgegangen ist, behält ihr Arbeitsbereich seine Dateien und steht auf Gestoppt; der nächste Lauf arbeitet darin weiter. Für eine Umgebung auf einem verbundenen Gerät gilt das nicht.

Die Ausgaben enthalten die gemessenen Kosten abgeschlossener Durchläufe. Ein noch laufender Durchlauf wird nach seinem Ende eingerechnet. Vorübergehende Crawler-Umgebungen zählen zur Kapazität, auch ohne eigene dauerhafte Workspace-Zeile.

Ist die Deployment-Kapazität voll, kann Tale eine nicht angeheftete, inaktive Umgebung zurückfordern, deren Belegung freigegeben ist und die bestätigt, dass keine Arbeit mehr läuft. Die dauerhaften Workspace-Dateien bleiben für den nächsten Start erhalten. Beschäftigte, angeheftete oder nicht erreichbare Umgebungen kommen nicht infrage. Ohne geeigneten Kandidaten braucht neue Arbeit freie Kapazität. Eine Umgebung, deren Aufgabe oder Lauf beendet ist, stoppt nach einigen Minuten im Leerlauf, sodass ihr Platz bald nach dem Ende der Arbeit frei wird. Eine Agent-Umgebung, in der Docker läuft, behält ihre volle Leerlaufzeit, damit der nächste Durchgang ihre Images nicht erneut laden muss.

Einen bestehenden Arbeitsbereich verwalten

Inhaber und Admins finden im Zeilenmenü diese Aktionen:

Tale speichert Änderungen am Anheftstatus dauerhaft und wiederholt die Übertragung, wenn die Laufzeit sie nicht bestätigt, auch nach einem Neustart eines Backend-Workers oder einem Geräteausfall. Jeder Versuch überträgt den zuletzt gewünschten Wert an dieselbe Session-Instanz. Wiederholtes Lösen verlängert deren Ablaufzeit nicht.

Stoppe die Aufgabe, wenn die Arbeit enden, ihre Dateien aber bleiben sollen. Sichere vor dem Löschen benötigte Ergebnisse und lies die Bestätigung. Automatische Rückgewinnung inaktiver Kapazität bewahrt Workspace-Dateien; ausdrückliches und automatisches Löschen entfernen sie.

Ungenutzte Arbeitsbereiche automatisch löschen

Ein Projekt-Agent bewahrt seine Dateien zwischen den Läufen in den Arbeitsbereichen seiner Worker auf: einem für jede Aufgabe, an der er gleichzeitig gearbeitet hat, den seine späteren Aufgaben wiederverwenden, und getrennten für jedes Mitglied, das seine Läufe startet. Der Arbeitsbereich jedes Workers zählt seine Tage ohne Nutzung für sich. Tale löscht einen Arbeitsbereich, den niemand während der von deiner Organisation festgelegten Anzahl Tage genutzt hat; Löschen entfernt einen Arbeitsbereich weiterhin sofort. Inhaber und Admins legen diese Regel unter Bereinigung der Arbeitsbereiche fest, direkt über der Liste Arbeitsbereiche. Entwickler sehen diesen Abschnitt nicht.

1. Lass Ungenutzte Arbeitsbereiche löschen eingeschaltet, wie es voreingestellt ist. Solange der Schalter aus ist, löscht Tale keinen Arbeitsbereich wegen Nichtnutzung.
2. Gib bei Tage ohne Nutzung eine ganze Zahl von 1 bis 3650 ein; voreingestellt sind 30. Die Tage zählen ab dem Zeitpunkt, an dem der Agent zuletzt im Arbeitsbereich gearbeitet hat, oder ab dem Lösen seiner Anheftung.
3. Wähle Speichern im Kopfbereich. Verwerfen stellt die gespeicherten Werte wieder her.

Nach einer Änderung wird nie ein Arbeitsbereich vorzeitig gelöscht. Schaltest du das Löschen ein oder verkürzt du den Zeitraum, wird kein Arbeitsbereich wegen Nichtnutzung gelöscht, bevor seit der Änderung die volle Anzahl Tage vergangen ist. Dieselbe Wartezeit folgt auf das Update, das die Einstellung eingeführt hat. Ein längerer Zeitraum startet die Wartezeit nicht neu, Aus- und erneutes Einschalten dagegen schon.

In der Liste Arbeitsbereiche zeigt ein gestoppter Agenten-Arbeitsbereich unter seinem Status, wann er gelöscht wird: Wird am … gelöscht, falls weiterhin ungenutzt. Ein neuer Lauf im Arbeitsbereich startet die Zählung neu. Ein angepinnter Arbeitsbereich oder einer, den ein Legal Hold bewahrt, zeigt kein Datum und wird nie wegen Nichtnutzung gelöscht.

Klären, warum ein Arbeitsbereich verschwunden ist

Neben ungenutzten Arbeitsbereichen löscht Tale einen Arbeitsbereich auch, sobald entfernt wird, wozu er gehört, unabhängig von der Bereinigungseinstellung:

• Das Löschen eines Projekt-Agenten löscht die Arbeitsbereiche aller seiner Worker, auch die der Mitglieder. Das Löschen eines Projekts tut dasselbe für jeden Agenten darin.
• Entfernst du ein Mitglied aus der Organisation, werden seine eigenen Arbeitsbereiche mit allen Agenten gelöscht. Setzt du es stattdessen auf Deaktiviert, bleiben sie erhalten.
• Die Löschung der Daten einer Person entfernt ihre eigenen Arbeitsbereiche, ohne auf laufende Arbeit darin zu warten.
• Das Löschen der Organisation entfernt alle ihre Sandboxes samt Dateien, widerruft die dafür ausgegebenen Gateway-Schlüssel, entfernt ihre Modell-Provider-Schlüssel aus dem Modell-Gateway, trennt ihre Geräte und löscht die für sie angelegten Build- und Paket-Caches.

Das geschieht innerhalb von etwa einer Minute oder, falls im Arbeitsbereich noch eine Aufgabe läuft, nach deren Ende. Auch ein angepinnter Arbeitsbereich wird dann gelöscht, doch ein Legal Hold bewahrt jeden Arbeitsbereich, den er abdeckt: Eine Sperre der Organisation bewahrt alle, eine Sperre für eine Person deren eigene Arbeitsbereiche. Eine stündliche Bereinigung löscht außerdem Überreste, die niemandem mehr gehören, etwa den Arbeitsbereich eines Workflow-Laufs, der nie zurückgefordert wurde.

Jeden Arbeitsbereich, den Tale von selbst löscht, aus einem dieser Gründe oder wegen Nichtnutzung, verzeichnet das Audit-Log unter Einstellungen > Richtlinien > Protokolle als Sandbox-Arbeitsbereich gelöscht. Das ist ein Systemereignis der Kategorie Daten, dessen Metadaten den Grund nennen: agent_deleted, member_removed, member_erased, unused oder orphaned. Das Ereignis wird erfasst, sobald Tale bestätigt hat, dass die Dateien des Arbeitsbereichs gelöscht sind, was bei einem großen Arbeitsbereich eine Weile dauern kann. Unter Kubernetes wird es erfasst, sobald das Volume des Arbeitsbereichs an den Storage-Provisioner des Clusters übergeben ist, der es gemäß der reclaimPolicy seiner StorageClass löscht; die Metadaten nennen, was geschehen ist (deletion: done oder handed_off). Schlägt das Löschen der Dateien fehl, erscheint das Ereignis mit dem Status Fehlgeschlagen, und das Löschen wird erneut versucht, bis die Dateien entfernt sind. Ein Sandbox-Dienst oder Gerät, das noch nicht auf diese Version aktualisiert ist, kann keine Löschung bestätigen: Tale erfasst für seine Arbeitsbereiche kein Ereignis und versucht es weiter, bis es aktualisiert ist. Ein Überbleibsel, das niemandem mehr gehört, kann ohne Ereignis enden: Werden seine Dateien noch gelöscht, wenn die stündliche Bereinigung weitergeht, löscht der Sandbox-Dienst sie zu Ende, doch Tale prüft sie nicht noch einmal.

Einen blockierten Start klären

Ein Start ohne freien Platz wartet, und seine Aufgabe zeigt unter Lauf, warum: Wartet auf einen Worker, wenn alle Agenten-Worker deiner Organisation belegt sind, Wartet auf freien Platz, wenn das Deployment voll ist oder zu wenig Arbeitsspeicher oder Speicherplatz hat, Wartet auf einen Arbeitsbereich, solange ein Administrator den Arbeitsbereich löscht, den der Lauf nutzen würde, und Wartet auf seine Sandbox, solange seine Sandbox einen früheren Prozess beendet. Inhaber und Admins bekommen außerdem einen Link auf diese Seite, wenn alle Agenten-Worker belegt sind. Sind die Limits deiner Organisation belegt oder ist das Deployment voll oder knapp an Arbeitsspeicher, startet die Arbeit von selbst, sobald Platz frei wird, und du musst nichts tun. Bei Speicherplatz ist das anders: Wird ungenutzte Arbeit angehalten, wird keiner frei, denn ein angehaltener Arbeitsbereich behält seine Dateien. Tale entfernt Build-Caches, die keine Sitzung nutzt, sofern es welche gibt; reicht das nicht, wartet der Start, bis Arbeitsbereiche gelöscht werden, etwa solche, die du löschst, weil du sie nicht mehr brauchst, oder bis der Betreiber Speicherplatz freigibt. Ist das Deployment selbst voll, geht sein Platz an die Arbeit, die am längsten wartet, egal aus welcher Organisation, und jeder wartende Start erfährt, wann er an der Reihe ist:

• Ein Aufgabenlauf wartet in der Warteschlange. Er wird erneut versucht, sobald eine Sitzung endet, in deiner Organisation oder in einer anderen auf demselben Deployment. Ist das Deployment voll, wird er auch versucht, wenn er an der Reihe ist. Zusätzlich versucht Tale alle zwei Minuten einige wartende Läufe jeder Organisation. Ein frei gewordener Worker geht zuerst an den Agenten mit den wenigsten laufenden Läufen und dann an den Lauf, der am längsten wartet. Findet ein Lauf innerhalb von 12 Stunden nach seinem Start keinen Platz, schlägt er fehl und meldet, dass er zu lange auf einen freien Worker gewartet hat.
• Der Agent-Schritt einer Automatisierung versucht es erneut, ohne seine Wiederholungen zu verbrauchen: wenn er an der Reihe ist, falls das Deployment voll ist, sonst nach einer Pause, die länger wird, solange der Schritt weiter wartet, bis zu etwa zwei Minuten. Der Lauf zeigt währenddessen Wartet auf einen Sandbox-Platz. Findet er zwei Stunden lang keinen Platz, schlägt der Lauf mit diesem Grund fehl. Ein Arbeitsbereich, den ein Administrator löscht, ist kein fehlender Platz: Der Schritt schlägt dann sofort fehl, wie oben bei Löschen beschrieben.
• Das Crawling wartet, bis es an der Reihe ist, und setzt dann mit dem nächsten Stapel fort.

Erhöhe ein Arbeitslimit nur, wenn seine Plätze belegt sind und die neue Summe in die gemeinsame Kapazität passt. Ist das Deployment voll, schafft ein höheres Organisationslimit keine Infrastruktur. Für eigene Kapazität verbindest du ein Gerät: Neue Arbeitsbereiche starten dann darauf. Andernfalls lass den Betreiber Kapazität und Host-Ressourcen prüfen. Ein freier Containerplatz garantiert noch nicht genügend CPU, Arbeitsspeicher oder Speicherplatz.

Bei Zugangs- oder Modellproblemen hilft KI-Provider, bei Ausgabengrenzen Richtlinien und Limits. Self-Hosted-Betreiber finden die Deployment-Einstellung in der Umgebungsreferenz.