Den betroffenen Dienst finden

Grenze eine Störung anhand der Dienstzuständigkeit ein, bevor du Container änderst. Der mitgelieferte Stack fasst Anwendungs- und Wissensdatenbank in db zusammen; Compose aus dem Quellcode kann knowledge-db separat betreiben. Prüfe deinen tatsächlichen Aufbau mit tale status oder der Dienstübersicht deines Orchestrators.

Die ersten Protokolle auswählen

Nutze logische Dienstnamen mit tale logs <service>. Für deinen eigenen Compose-Stack gilt docker compose logs --tail=200 <service>. Erzeugte Containernamen können Projekt, Farbe und Replikatnummer enthalten.

Einer interaktiven Chatanfrage folgen

1. Der Browser erreicht proxy. Webdateien gehen an platform, Anwendungs- und Anmeldeanfragen an backend-api.
2. Die API prüft Sitzung und Organisation, ermittelt Modell und Zugangsdaten und führt den interaktiven Turn aus. Fortschritt wird in der Anwendungsdatenbank gespeichert.
3. Der Browser liest Fortschritt über den Stream-Endpunkt des Chats. /events liefert Hinweise zum erneuten Laden von Daten und enthält nicht den Token-Stream.
4. Wissenswerkzeuge verwenden die Wissensverbindung der anfragenden Organisation. Originaldateien werden über deren Speicherkonfiguration gelesen.
5. Ein Turn mit einer Agent-Laufzeit benötigt eine Sandbox-Sitzung und das Modell-Gateway. Eingereihte Aufgaben, Workflow-Agent-Jobs und REST-Chat-Turns können außerdem Worker benötigen.

Ein Worker-Ausfall hat daher einen anderen Umfang als ein API-Ausfall. Daraus folgt aber nicht, dass sämtliche Chat- oder Agentenarbeit weiterläuft. Prüfe Einstiegspunkt und Ausführungstyp des betroffenen Ablaufs. Sichere den ursprünglichen Fehler, bevor du einen Turn wiederholst, der Tokens verbrauchen oder externe Aktionen ausführen könnte.

Abhängigkeiten der Sandbox verstehen

sandbox ist ein Spawner mit Zugriff auf den Docker-Daemon des Hosts. Er erstellt vorübergehende Container aus dem festgelegten Sandbox-Runtime-Image und bindet deren Arbeitsverzeichnisse ein. Diese Sitzungen verwenden ein isoliertes Netzwerk: Webanfragen laufen über sandbox-egress, Modellaufrufe über den begrenzten Sitzungszugriff des Gateways.

Die Laufzeit stellt auch Chromium und Playwright für Seitenrendering und Dokumenterzeugung bereit. Eine funktionierende Weboberfläche beweist daher nicht, dass die Ausführungsebene funktioniert. Prüfe Image-Verfügbarkeit, Workspace-Mounts, gemeinsames Sandbox-Token und Gateway-Zugangsdaten, bevor du ein einzelnes Skript untersuchst.

Der Egress-Dienst blockiert private Adressen und Metadatenziele und kann eine Hostnamen-Freigabeliste erzwingen. Ein ausgefallener Ausgang kann Verweigerungen oder Netzwerkfehler verursachen; die genaue Meldung hängt von der Operation ab. Härtung beschreibt die Regeln, Compose selbst betreiben die nötigen Rechte und Mounts.

Sitzungen über einen Docker-Neustart erhalten

Sandbox-Sitzungen und der Spawner laufen als Container des Docker-Daemons auf dem Host. Ohne Live Restore des Daemons stoppt ein Neustart, etwa für ein Paket-Upgrade oder eine Änderung an /etc/docker/daemon.json, alle diese Container: Laufende Agent-Turns, Builds und Seitenrenderings brechen ab, ihre Arbeitsverzeichnisse bleiben erhalten. Tale ändert die Daemon-Konfiguration des Hosts nicht; der Spawner protokolliert beim Start eine Warnung, solange Live Restore ausgeschaltet ist.

Zum Einschalten ergänzt du die Einstellung in /etc/docker/daemon.json und behältst die übrigen Einträge der Datei:

{
  "live-restore": true
}

Lade den Daemon danach mit sudo systemctl reload docker neu, oder sende auf einem Host ohne systemd SIGHUP an dockerd. Das Neuladen übernimmt die Einstellung, ohne Container zu stoppen. Live Restore hält Container über einen Daemon-Neustart und ein Patch-Release-Upgrade hinweg am Laufen; ein Upgrade auf eine neue Docker-Release-Linie kann sie trotzdem stoppen, plane es deshalb wie ein Wartungsfenster. Live Restore ist mit dem Swarm-Modus nicht vereinbar: Plane Daemon-Neustarts auf einem Swarm-Knoten stattdessen als Wartung ein. Dockers Anleitung zu Live Restore nennt die übrigen Grenzen.

Reparaturen des Wissensindex erkennen

Ein beschädigter BM25-Index kann Importe scheitern lassen, obwohl die Dokumenttabellen noch lesbar sind. Das Backend prüft Wissensindizes mit pdb.verify_index. Ein Advisory Lock koordiniert Reparaturversuche pro Datenbank. Organisationsspezifische Datenbanken werden bei ihrer ersten Verwendung geprüft.

Reparaturen können die Audit-Aktionen knowledge_index_repaired, knowledge_index_rebuild_scheduled oder knowledge_index_repair_failed und Admin-Benachrichtigungen auslösen. Ein fehlgeschlagener Neuaufbau beweist keinen Verlust der Quelldokumente. Ein erfolgreicher Neuaufbau ersetzt kein Datenbank-Backup.

KNOWLEDGE_INDEX_REPAIR_DISABLED=1 schaltet die automatische Prüfung ab und behebt keine Beschädigung. Wiederkehrende Schäden nach Neustarts erfordern eine Untersuchung des Herunterfahrens und des Speichers. Bevorzuge reguläres Stoppen mit der eingestellten Wartezeit statt erzwungenem Beenden. Fehlerbehebung enthält die lesende Indexprüfung und Hinweise zur Wiederherstellung.