Monitoring, Kosten und Fehlerdiagnose

Monitoring, Kosten und Fehlerdiagnose

0:00 Willkommen zu Modul dreizehn. Lotsenhaus läuft, die Assistenten antworten, die Werkzeuge sind angebunden und abgesichert. Jetzt kommt die Frage, die im Alltag eines Plattformteams über Vertrauen entscheidet: Woran merken Sie, dass etwas nicht stimmt, und wie schnell finden Sie heraus, warum? In diesem Modul trennen wir zuerst die verschiedenen Arten von Aufzeichnungen, schalten dann Telemetrie über OpenTelemetry ein, schauen uns an, was Open WebUI zu Kosten liefert und was nicht, und bauen schließlich einen Diagnosepfad, der von einem Symptom zuverlässig zu einer Ursache führt.

0:33 In der Übung verfolgen Sie eine echte Störung im Labor, und zwar mit Beleg, nicht mit Bauchgefühl.

Monitoring, Kosten und Fehlerdiagnose

0:39 Der fünfte Tag schließt mit dem Betrieb ab. Der Satz auf dieser Folie setzt den Maßstab: Gute Überwachung misst sich nicht an der Menge der Logzeilen, sondern daran, wie schnell eine Störung eine Ursache bekommt. Viele Daten sammeln ist leicht. Die richtigen Daten für die richtigen Leute bereitzuhalten, ist die eigentliche Arbeit. Genau dorthin arbeiten wir uns heute vor.

Logs unterscheiden

1:01 Bevor wir irgendetwas einschalten, eine Ordnungsfrage. Nicht jede Aufzeichnung dient demselben Zweck, und nicht jede gehört in dieselben Hände. Stellen Sie sich ein Krankenhaus vor. Die Haustechnik schaut auf Strom und Heizung, die Verwaltung auf Zugangsprotokolle, die Ärzte auf die Behandlung. Niemand käme auf die Idee, alles in einen Ordner zu legen. Bei Lotsenhaus ist es genauso.

1:24 Das Betriebslog beantwortet, ob die Anwendung fehlerfrei läuft, und gehört dem Plattformbetrieb. Das Auditlog hält fest, wer was verändert hat, und ist Sache von Informationssicherheit und Revision. Die Qualitätsauswertung, also Bewertungen und Nutzungszahlen, liegt bei der fachlichen Verantwortung. Diese Trennung ist kein Formalismus.

1:44 Sie verhindert, dass das Plattformteam nebenbei Einblick in Chatinhalte bekommt, den es für seine Arbeit schlicht nicht braucht. Hier sehen Sie die Konfiguration aus der Produktionsumgebung, und das Wichtigste steht in der Fußzeile: Ohne ausdrückliche Einstellung gibt es gar kein Auditlog. Wir setzen es auf die Stufe der Metadaten, schicken es über die Standardausgabe an den vorhandenen Log-Collector und verzichten auf eine lokale Datei, die ohnehin niemand einsammelt.

2:12 Lesende Anfragen lassen wir weg, uns interessieren Änderungen. Die Größe mitgeschriebener Inhalte wird begrenzt, das Format ist JSON, damit Maschinen es auswerten können. Und eine Zeile verdient besondere Aufmerksamkeit: Die ausführliche Diagnose in Tracebacks bleibt aus. Sie ist bequem bei der Fehlersuche, schreibt aber Variablen samt Inhalt ins Log.

2:33 Die vier Stufen sind im Grunde ein Schieberegler zwischen Nachvollziehbarkeit und Datensparsamkeit. Ganz links gibt es nichts, und damit auch keine Antwort auf die Frage, wer etwas geändert hat. Ganz rechts landen Anfrage und Antwort im Log, also die Chatinhalte ein zweites Mal, an einem Ort, an dem keine Löschfrist der Plattform greift.

2:52 Die Empfehlung der Härtungsseite liegt deshalb bewusst bei den Metadaten. Beruhigend ist der Hinweis in der Fußzeile: Anmeldungen werden immer protokolliert, und die Chatpfade sind standardmäßig ausgenommen. Wer höher geht, sollte einen konkreten Anlass und eine Absprache mit dem Datenschutz haben. Die typischen Fehler entstehen fast alle aus guter Absicht.

3:13 Man schaltet die volle Protokollierung vorsorglich ein, um im Ernstfall alles zu haben, und hat damit eine zweite, unkontrollierte Kopie aller Gespräche geschaffen. Man hält die Rotationsgröße der Logdatei für eine Aufbewahrungsfrist, dabei regelt die Frist das Log-System dahinter. Man aktiviert die ausführliche Diagnose für eine Fehlersuche und vergisst sie, bis Tokens und Prompts in Tracebacks auftauchen.

3:36 Und man baut Auswertungen je Person, ohne das mit Betriebsrat und Datenschutz geregelt zu haben. Die Faustregel: Jede zusätzliche Aufzeichnung braucht einen Zweck, eine Frist und eine Freigabe.

Telemetrie

3:48 Logs erzählen, was passiert ist. Telemetrie zeigt, wie es dem System gerade geht, und zwar über einen offenen Standard, den Ihre vorhandene Überwachung bereits versteht. Die gute Nachricht zuerst: Open WebUI spricht OpenTelemetry von Haus aus. Sie müssen also keine eigene Überwachung erfinden, sondern docken an den Collector an, den Ihr Betrieb vermutlich schon hat. Die Konfiguration folgt einem einfachen Muster.

4:13 Ein Hauptschalter, dann je ein Schalter für Traces, Metriken und Logs, dazu der Endpunkt des Collectors, ein Dienstname und ein Attribut, das die Umgebung kennzeichnet, damit Produktion und Test im Dashboard nicht durcheinandergeraten. Das Exportintervall steht auf einer Minute. Beachten Sie die Fußzeile: Standardmäßig ist alles aus.

4:33 Wer sich auf das Beispiel-Compose verlässt, hat Telemetrie, wer frei konfiguriert, muss sie bewusst einschalten. Der Weg der Daten ist eine Kette mit klarer Arbeitsteilung. Open WebUI sendet, kümmert sich aber um nichts weiter. Der Collector ist die Weiche: Er filtert, was nicht weiter soll, und verteilt den Rest. Dahinter speichern spezialisierte Systeme, Prometheus die Metriken, Tempo die Traces, Loki die Logs.

4:58 Ganz am Ende stehen zwei sehr verschiedene Leser: Grafana für das Plattformteam und das SIEM für die Sicherheit. Der Vorteil dieser Reihenfolge ist, dass Sie an einer einzigen Stelle entscheiden, was wohin fließt. Und wenn morgen ein anderes Speichersystem kommt, ändert sich nur die Verteilung im Collector, nicht Lotsenhaus.

5:18 Diese Tabelle lohnt einen zweiten Blick auf die rechte Spalte. Traces sind enorm hilfreich, weil sie eine Anfrage durch Webserver, Datenbank und Redis verfolgen. Sie enthalten aber auch die Datenbankabfragen und Redis-Argumente, und darin können personenbezogene Werte stecken. Telemetrie ist also nicht automatisch harmlos, auch sie braucht eine Datenschutzprüfung.

5:39 Die Metriken beschreiben Anfragen und Antwortzeiten, sagen aber nichts über Tokens oder Kosten, darauf kommen wir gleich zurück. Und das Auditlog nimmt seinen Weg ins SIEM über die Standardausgabe und den Log-Collector. So entsteht aus vier Quellen ein Bild, ohne dass eine davon alles können muss. Ein gutes Dashboard prüft von außen nach innen, wie ein Arzt, der erst den Puls fühlt und dann genauer hinsieht. Erreichbarkeit allein sagt wenig.

6:06 Deshalb kommen dazu: Gibt es mindestens ein erreichbares Modell, kommt eine echte Testanfrage durch, wie hoch ist die Fehlerquote, wie entwickelt sich die Latenz, und hat der Host noch Reserven. Die Ziele sind bewusst pilottauglich gewählt, Bürozeiten statt rund um die Uhr, ein stabiler Trend statt harter Millisekunden.

6:24 Ein Detail aus der Fußzeile: Die Zeit bis zum ersten Token liefert Open WebUI nicht als Metrik. Ihre Testanfrage misst sie mit, und genau das macht sie so wertvoll. Vier Fallen, die man im Monitoring häufig sieht. Erstens bekommt das Monitoring-Konto Admin-Rechte, weil es schneller geht, obwohl die Doku ein eingeschränktes Konto empfiehlt.

6:45 Ein Überwachungskonto ist ein Dauerzugang, und der sollte so wenig dürfen wie möglich. Zweitens überwacht man nur den Gesundheits-Endpunkt. Der meldet zufrieden gesund, während kein einziges Modell antwortet. Drittens wandert eine unverschlüsselte Exporteinstellung aus dem Beispiel in die Produktion. Und viertens bleibt das Exportintervall auf zehn Sekunden stehen. Das klingt nach Gründlichkeit, erzeugt aber Datenmengen, die die Monitoring-Plattform teuer bezahlen lässt.

Kosten steuern

7:13 Damit zu einer Frage, die spätestens die Geschäftsführung stellt: Was kostet uns das eigentlich? Die ehrliche Antwort beginnt mit einer Klarstellung, wer hier zählt und wer begrenzt. Open WebUI ist hier eher Stromzähler als Sicherung. Es zählt Tokens je Modell und Gruppe über wählbare Zeiträume, aber es kennt keine Preise, setzt keine Budgets und schlägt keinen Alarm.

7:36 Ein Detail kann Ihre Zahlen verfälschen: Beim Streaming kommen Tokenwerte nur an, wenn das Modell die Fähigkeit Usage gesetzt hat. Fehlende Werte erscheinen als null, und null sieht verdächtig nach günstig aus. Wer exportieren will, nutzt die REST-API, einen Knopf dafür gibt es nicht. Die Kostenformel in der Fußzeile ist simpel, Tokens mal Preis, getrennt nach Ein- und Ausgabe. Die Preise pflegen Sie allerdings selbst.

8:02 Dieser Vergleich zeigt eine klare Arbeitsteilung. Links Open WebUI: Es zählt, mehr nicht. Rechts ein Gateway, hier am Beispiel LiteLLM, das zwischen Plattform und Modellanbieter sitzt. Dort lassen sich Kosten je Schlüssel, Team und Nutzer rechnen, harte Budgets für einen Zeitraum setzen, eine Vorwarnung vor dem Limit auslösen und Anfragen sowie Tokens pro Minute begrenzen.

8:25 Das Bild dazu ist die Prepaid-Karte im Gegensatz zur Kreditkarte. Mit Prepaid kann das Geld nicht unbemerkt davonlaufen. Für Lotsenhaus heißt das: Wer echte Ausgabegrenzen braucht, plant sie im Gateway, nicht in der Oberfläche. Kosten entstehen nicht pauschal, sondern je Anwendungsfall, und zwar in sehr unterschiedlicher Form.

8:45 Die Schreibhilfe und der Richtlinienlotse laufen lokal, dort kostet der Betrieb von inferenz-01 und beim Lotsen zusätzlich die Indexierung. Externe Recherche bekommt eine eigene Verbindung mit eigenem Gateway-Schlüssel, damit ihre Tokenkosten sauber getrennt bleiben. Die Störmelder-Abfragen sind teurer, als sie aussehen, weil jede Antwort mehrere Modellrunden braucht.

9:07 Und die Hintergrundaufgaben, also Titel, Tags und Folgefragen, werden fast immer übersehen. Die Fußzeile mahnt noch zur Vorsicht: Wer Benutzerinformationen an Modelldienste weitergibt, um Kosten zuzuordnen, klärt das vorher mit dem Betriebsrat. Der häufigste Irrtum zuerst: Man sucht in Open WebUI nach einem Budget. Die Doku beschreibt Zählung und Schätzung, aber keine Ausgabegrenze, und wer das übersieht, wiegt sich in falscher Sicherheit.

9:33 Ähnlich tückisch ist die vergessene Fähigkeit Usage am Modell, denn gestreamte Antworten zählen dann null Tokens. Dann der externe Schlüssel ohne Limit beim Anbieter, hinterlegt mit dem Gedanken, das Gateway komme ja noch. Bis dahin ist das Limit beim Anbieter Ihre einzige Bremse. Und schließlich: Kosten je Person auszuwerten, ist heikel und hilft der Entscheidung wenig. Entschieden wird je Anwendungsfall, also sollte auch dort gerechnet werden.

Fehlerdiagnose

10:01 Jetzt wird es handfest. Irgendwann meldet jemand, dass Lotsenhaus nicht tut, was es soll. Dann zählt, ob Sie systematisch vorgehen oder raten. Eine Alarmregel ist im Kern ein Rauchmelder mit eingebauter Geduld. Diese hier rechnet über fünf Minuten den Anteil der Serverfehler an allen Anfragen aus und schlägt an, wenn er über fünf Prozent liegt, aber erst, wenn das zehn Minuten lang so bleibt.

10:25 Diese Wartezeit ist kein Zögern, sondern Absicht: Ein einzelner Ausreißer soll niemanden nachts wecken. Der Schweregrad sorgt dafür, dass der Alarm tatsächlich jemanden erreicht, die Zusammenfassung sagt in einem Satz, worum es geht. Wichtig ist die Fußzeile: Metrik- und Labelnamen entstehen erst bei der Umsetzung aus OTLP im eigenen Backend. Prüfen Sie sie, bevor die Regel scharf geht.

10:48 Diese Tabelle ist ein Spickzettel, den Sie sich ins Runbook übernehmen sollten. Das Muster dahinter: Fast jedes Symptom hat eine Handvoll typischer Ursachen, und die liegen selten in Open WebUI selbst. Beim Login sind es Sitzung, Cookie oder eine Redirect-Adresse, die nicht zur konfigurierten Adresse passt. Fehler, die nur mit mehreren Instanzen auftreten, deuten fast immer auf nicht geteilten Zustand.

11:12 Beim Retrieval ist es ein zu kleines Kontextfenster oder ein gewechseltes Embedding-Modell ohne Neuindexierung. Und beim Streaming steckt oft der Proxy dahinter, der puffert oder Header verschluckt. Wer diese Ebenen kennt, sucht gezielt statt überall. Der Diagnosepfad ist das, was gute Werkstätten tun: erst zuhören, dann von außen nach innen prüfen, dann gezielt öffnen.

11:35 Sie grenzen zunächst ein, wer betroffen ist, welcher Assistent und seit wann. Dann prüfen Sie Schicht für Schicht, ob die Plattform lebt, ob Modelle da sind, ob eine Anfrage durchkommt. Der Trace zeigt Ihnen, an welcher Station die Anfrage hängen bleibt, das Betriebslog liefert die Details, ausführliches Logging nur befristet.

11:54 Am Ende stehen Behebung, Regressionstest und ein dokumentierter Befund im Störmelder. Merken Sie sich die Fußzeile: Ein vorschneller Neustart löscht oft genau die Spur, die Sie gebraucht hätten.

Übung

12:06 Zeit, das Gelernte zusammenzuführen. Ein Dashboard, drei Alarme und eine echte Störung warten im Labor auf Sie. In dieser Übung geht es um eine Fähigkeit, die man nicht aus Folien lernt: den Zustand einer KI-Plattform aus Telemetrie und Logs zu lesen und eine Störung bis zu ihrer Ursache zu verfolgen. Sie bauen ein Dashboard, das Verfügbarkeit, Fehlerquote, Latenz und Tokens zeigt, und testen drei Alarme. Dann nehmen Sie sich das Ticket SM-4823 vor.

12:36 Der Richtlinienlotse liefert seit einer Änderung in lotsenhaus-betrieb verstümmelte Antworten. Was dahintersteckt, verrate ich nicht. Nur so viel: Die Fehlerbilder aus diesem Modul sind ein guter Ausgangspunkt. Erfolgreich sind Sie, wenn die Ursache mit Beleg benannt ist. Der Ablauf baut von unten nach oben auf. Zuerst schalten Sie auf dem Laborsystem Telemetrie und Auditlog ein, denn ohne Daten gibt es nichts zu sehen.

13:03 Dann entsteht das Dashboard, danach die drei Alarmregeln, und jede davon lösen Sie mit einem gezielten Fehler einmal aus. Ein Alarm, der nie geklingelt hat, ist nur eine Vermutung. Erst dann gehen Sie an SM-4823, Schritt für Schritt entlang des Diagnosepfads, mit einem Beleg für jeden Schritt. Die Fußzeile ist ernst gemeint: Gezählt wird der Nachweis, nicht der Treffer.

13:26 Im nächsten Modul, am sechsten Tag, sorgen wir dafür, dass Lotsenhaus Ausfälle, Datenverlust und Upgrades übersteht.