Operations
Worauf zu alarmieren ist, welche Metriken zählen, und die Oncall-Checkliste, wenn sich eine Tale-Instanz schlecht zu benehmen anfängt.
3 min read
Die Operations-Seite ist das Alert-Playbook — welche Signale es wert sind, jemanden zu wecken, welche eine Kaffee-Runde überstehen können und wie die ersten fünf Minuten eines Vorfalls aussehen. Die Metrik-Oberfläche von Tale lebt hinter METRICS_BEARER_TOKEN; diese Seite nimmt an, dass du Prometheus und Grafana gemäss Observability-Konfiguration verdrahtet hast und jetzt wissen musst, welche Zahlen du beobachtest.
Der symptomorientierte Index ist in Troubleshooting. Diese Seite ist die proaktive Seite — Signale zuerst, Oncall-Checkliste zweitens.
Signale, auf die zu alarmieren sich lohnt
| Signal | Schweregrad | Warum es zählt |
|---|---|---|
tale-proxy-Health-Probe scheitert > 1 Min | page | Jeder Benutzer sieht einen Verbindungsfehler |
tale-platform HTTP-5xx-Rate > 5 % | page | Die UI ist für einen relevanten Anteil der Anfragen kaputt |
tale-convex WebSocket-Reconnect-Storm | page | UI lädt, aber keine Daten fliessen |
| Postgres-Verbindungen > 80 % des Pools | warn | Die nächste Spitze fängt an zu blockieren |
db-data-Volume > 80 % voll | warn | Das operative Postgres geht bei voll auf read-only |
knowledge-db-data-Volume > 80 % voll | warn | Ingestion scheitert, wenn die Korpus-Datenbank voll ist |
tale-knowledge-db von convex unerreichbar | warn | Wissens-Suche liefert leer; Ingestion stockt |
| Anbieter-Anfrage-Fehlerrate > 20 % | warn | Der Upstream-LLM-Anbieter hat einen schlechten Tag |
| Tägliches Backup nicht geschrieben | page | Restore-Drill scheitert zum schlimmsten Zeitpunkt |
| TLS-Cert-Erneuerung gescheitert | warn | Erneuert 30 T vor Ablauf — du hast Zeit |
Die ersten zwei Pages sind die wirklich kundenwirksamen. Die warns fangen Trends, bevor sie ins Page-Gebiet kippen.
Log-Signale, nach denen man greppen sollte
Logs kommen über stdout pro Container, aufgefangen vom json-file-Driver von Docker. Die vier Phrasen, die konsistent Ärger bedeuten:
panicoderunexpected errorintale-convex-Logs — Convex-Action-Crash.decryption failedintale-platform-Logs — SOPS-age-Schlüssel-Mismatch mit der Datei auf Platte.429 Too Many Requestswiederholt von einem Anbieter — Rate-Limit getroffen, Agents fangen an zu scheitern.connection refusedoderECONNREFUSEDzuknowledge-dbintale-convex-Logs — das Backend erreicht die Korpus-Datenbank nicht; Ingestion und Wissens-Suche scheitern.
Leite diese als abgeleitete Alerts an deinen Aggregator weiter; die Metric-Endpoints zeigen sie nicht als Gauges.
Oncall-Checkliste
Wenn eine Page landet, folgen die ersten fünf Minuten jedes Mal derselben Form.
- Bestätige, dass der Alert echt ist. Öffne
$SITE_URLim Browser. Lädt die UI und Chat funktioniert, schaust du auf ein Metrik- oder Scraper-Problem, nicht ein kundenwirksames. - Identifiziere den Container.
docker compose pszeigt, welcher unhealthy ist;docker compose logs --tail=200 <service>zeigt den letzten Fehler. - Starte den wahrscheinlichsten Schuldigen neu.
docker compose restart <service>löst einen überraschenden Anteil der Vorfälle — Prozess-Crashes, abgestandene File-Watcher, erschöpfte Verbindungs-Pools. Die Architektur ist gebaut, um einen einzelnen Container-Restart sauber zu überleben. - Prüf Upstream-Anbieter.
https://status.openai.com,https://status.anthropic.com, etc. Brennt der Anbieter, scheitern Agents; Tale ist nicht die Ursache. - Page die diensthabende Ingenieurin, wenn das benutzerwirksame Symptom nach einem Restart bleibt. Nicht früher eskalieren — die meisten Vorfälle lösen sich in den ersten drei Schritten.
Was Oncall nicht braucht
Ein tale-knowledge-db-Ausfall ist ein warn, kein page. Der Web-Crawl-Plan absorbiert Stunden von Downtime ohne Benutzerwirkung, und die Dokument-Ingestion versucht es erneut, statt Arbeit zu verwerfen — Uploads sitzen in „indexing", bis die Korpus-Datenbank zurück ist. Die Wissens-Suche liefert in der Zwischenzeit leer, aber Chats, die kein Wissen abrufen, arbeiten weiter. Fang das im warn-Band und fix es zu Geschäftszeiten.
Wo das hingehört
Die Signale oben sind die proaktive Seite des Betreibens einer Tale-Instanz; die reaktive Seite ist Troubleshooting, und die Konfiguration, die die Metriken in Prometheus bekommt, ist Observability-Konfiguration. Hast du METRICS_BEARER_TOKEN noch nicht gesetzt, ist jede Schwelle oben unbeobachtet — fang dort an.