Yurna beobachten: Fehler, Laufzeiten und Verfügbarkeit

Der Bot ist online, das Dashboard erreichbar und die Prozessorauslastung niedrig. Trotzdem warten Mitglieder auf Tickets, die nicht fertig angelegt werden. Ein ausschließlich technischer Überblick kann in dieser Situation grün bleiben. Er misst dann, ob Prozesse existieren, aber nicht, ob die beabsichtigte Arbeit gelingt. Für Yurna sollte Beobachtung deshalb bei konkreten Nutzerwegen beginnen: Eine Interaktion wird angenommen, ein Vorgang verarbeitet und ein Ergebnis verständlich zurückgegeben. Erst danach werden Ressourcenwerte als mögliche Erklärung hinzugefügt.

Im untersuchten Quellstand gibt es einen periodischen Bot-Metrikjob. Er erfasst unter anderem Prozessressourcen, Laufzeit, Gateway-Ping, Cachegrößen und Befehlszähler und speichert Momentaufnahmen. Das Datenmodell sieht außerdem API-Verkehrsdaten mit Laufzeitkennzahlen vor. Diese vorhandenen Messpunkte sind nützlich, müssen aber korrekt benannt und eingeordnet werden. Ein Wert aus einem lokalen Cache ist beispielsweise nicht automatisch die tatsächliche Zahl aktiver Mitglieder. Der Artikel entwickelt einen ergänzenden Entwurf für aussagekräftige Betriebsentscheidungen, ohne aktuelle Messwerte zu veröffentlichen.

Mit einem konkreten Dienstversprechen beginnen

Für eine Ticketöffnung lautet das Versprechen nicht „der Prozess läuft“. Es lautet, dass eine berechtigte Anfrage zeitnah bestätigt und schließlich mit einem nutzbaren Ticket oder einer verständlichen Ablehnung beantwortet wird. Daraus lassen sich zwei getrennte Zeiten ableiten: bis zur ersten Rückmeldung und bis zum fachlichen Abschluss. Eine schnelle Bestätigung kann eine langsame Hintergrundarbeit verdecken, wenn nur die erste Zeit beobachtet wird. Umgekehrt kann ein schneller Abschluss trotzdem wie ein Fehler wirken, wenn die Interaktion vorher nicht korrekt beantwortet wurde.

Der Entwurf beobachtet deshalb die einzelnen Phasen. Für jede angenommene Ticketöffnung wird gezählt, ob sie abgeschlossen, fachlich abgelehnt oder wegen eines technischen Problems beendet wurde. Noch laufende Vorgänge bleiben als eigene Menge sichtbar. Diese Aufteilung hilft bei der Interpretation. Viele fachliche Ablehnungen wegen bereits vorhandener Tickets sind etwas anderes als viele Datenbankfehler. Eine allgemeine Fehlerquote ohne Kategorien würde beide Situationen vermischen und zu falschen Reaktionen führen.

Die erwartete Qualität wird zunächst als interne Arbeitsgröße festgelegt. Dafür sind keine erfundenen Verfügbarkeitsversprechen nötig. Das Team kann aus repräsentativen Messungen ableiten, welche Dauer normalerweise üblich ist und ab wann eine Abweichung untersucht werden soll. Wichtig ist, dass die Definition stabil bleibt. Wird die Messung bei einem Update an einen anderen Zeitpunkt verschoben, müssen alte und neue Werte entsprechend gekennzeichnet werden. Sonst sieht eine geänderte Messmethode wie eine plötzliche Verbesserung aus.

Metriken, Ereignisse und Ablaufspuren verbinden

Eine Metrik fasst viele Vorgänge zusammen, etwa die Anzahl erfolgreicher Ticketöffnungen. Ein Ereignis beschreibt einen bestimmten Fehler. Eine Ablaufspur kann zeigen, welche Schritte zu einem einzelnen Ergebnis geführt haben. Die OpenTelemetry-Dokumentation zu Signalen erläutert diese unterschiedlichen Beobachtungsformen. Daraus folgt nicht, dass Yurna zwingend eine bestimmte zusätzliche Plattform benötigt. Der nützliche Gedanke ist, jede Form für die Frage zu verwenden, die sie tatsächlich gut beantwortet.

Für das Beispiel zeigt eine Metrik, dass mehr Ticketöffnungen warten als gewöhnlich. Ein dazugehöriger Fehlerdatensatz nennt die externe Kanalerstellung als betroffenen Schritt. Ein Vorgangsbezug verbindet ihn mit der lokalen Vorbereitung. Damit kann die Untersuchung vom allgemeinen Problem zu einem konkreten Ablauf wechseln. Ohne diesen Zusammenhang müsste das Team nach ähnlichen Zeitstempeln suchen und hoffen, dass die richtigen Zeilen zusammengehören. Eine kleine stabile Korrelation spart hier viel Interpretationsarbeit.

// Beispiel eines begrenzten technischen Ereignisses.
type OperationObservation = {
  operationRef: string;
  operation: "ticket.open";
  phase: "validate" | "persist" | "discord" | "respond";
  outcome: "ok" | "rejected" | "error";
  durationMs: number;
  errorCode?: string;
};

Diese Struktur enthält bewusst keinen Tickettext und keine vollständige Discord-Antwort. Für die technische Untersuchung reichen häufig Phase, Dauer und ein stabiler Fehlergrund. Personen- und Serverbezüge können in einem geschützten Detailkontext verfügbar sein, sollten aber nicht unkontrolliert als Beschriftungen jeder Zeitreihe vervielfältigt werden. Beobachtbarkeit braucht Zusammenhänge, nicht wahllose Datenkopien. Eine begrenzte Form bleibt leichter auswertbar und reduziert gleichzeitig die Menge sensibler Inhalte in Betriebswerkzeugen.

Mittelwerte nicht allein verwenden

Eine durchschnittlich schnelle Antwort kann einzelne sehr langsame Vorgänge verdecken. Wenn die meisten Anfragen sofort fertig sind, fällt eine kleinere Gruppe langer Wartezeiten im Mittel möglicherweise wenig auf. Deshalb sollte die Verteilung betrachtet werden. Perzentile können beschreiben, bis zu welcher Dauer ein bestimmter Anteil der beobachteten Vorgänge abgeschlossen ist. Sie brauchen jedoch eine klar definierte Stichprobe und einen passenden Zeitraum. Ein einzelner Wert ohne Anzahl der Beobachtungen kann irreführend sein.

Die Prometheus-Dokumentation zu Histogrammen und Zusammenfassungen erläutert verschiedene Verfahren für solche Verteilungen. Für Yurnas Entwurf wird zuerst die benötigte Frage festgelegt: Wie unterscheiden sich gewöhnliche und besonders langsame Ticketöffnungen? Danach wird ein geeignetes Messformat gewählt. Bereits aggregierte Perzentile verschiedener Prozesse sollten nicht beliebig gemittelt werden. Das würde nicht automatisch das gemeinsame Perzentil aller ursprünglichen Anfragen ergeben. Die Art der Zusammenfassung gehört zur Bedeutung der Kennzahl.

Auch die Trennung nach Operation ist wichtig. Eine kleine Einstellungsabfrage und eine aufwendige Rangkarte haben unterschiedliche Arbeit. Ein gemeinsames Latenzdiagramm kann eine Verschiebung der Nutzung mit einer Leistungsänderung verwechseln. Der Entwurf verwendet deshalb wenige verständliche Operationsgruppen. Zu feine Unterteilungen erzeugen wiederum unübersichtliche Datenmengen. Die richtige Auflösung ermöglicht konkrete Entscheidungen: Welche Funktion ist langsamer geworden und an welcher Phase sollte die Untersuchung beginnen?

Vorhandene Ressourcenwerte korrekt lesen

Der Yurna-Metrikjob berechnet Prozessorauslastung aus Prozesszeit und vergangener Zeit und berücksichtigt die Zahl logischer Prozessoren. Eine solche Zahl muss in der Oberfläche entsprechend beschriftet werden. Sie ist nicht ohne Weiteres mit jeder anderen CPU-Anzeige vergleichbar. Ebenso beschreibt der erfasste residente Speicher einen anderen Blick als ausschließlich der JavaScript-Heap. Eine klare Benennung verhindert, dass das Team aus scheinbar widersprüchlichen Anzeigen einen Fehler ableitet, obwohl lediglich unterschiedliche Größen gemessen werden.

Der Gateway-Ping sagt etwas über einen Teil der Discord-Verbindung, aber nicht unmittelbar über die Laufzeit jeder REST-Anfrage oder einer Datenbankabfrage. Ein guter Wert beweist deshalb keine vollständige Funktionsfähigkeit. Er kann bei der Untersuchung helfen, wenn gleichzeitig andere Signale auffällig sind. Die Beobachtung sollte diese Grenzen sichtbar halten. Ein einzelner prominenter Pingwert darf nicht zum allgemeinen Gesundheitsurteil werden, nur weil er leicht zu erfassen und angenehm darzustellen ist.

Cachegrößen benötigen ebenfalls ehrliche Namen. Der untersuchte Code liest Mengen aus Discord-Clientcaches. Diese Werte zeigen, welche Objekte der Prozess derzeit kennt, nicht zwangsläufig wie viele Menschen gerade aktiv sind. Eine Bezeichnung wie „aktive Nutzer“ kann dadurch mehr versprechen als die Messung liefert. Für eine brauchbare Betriebsansicht werden technische Cachezahlen als solche benannt. Soll tatsächliche Aktivität gemessen werden, braucht es eine eigene definierte Beobachtung mit einem klaren Zeitraum und begrenztem Datenumfang.

Wartende Arbeit als eigenes Signal

Eine Hintergrundfunktion kann still stehen, obwohl neue Aufträge weiterhin angenommen werden. Deshalb werden nicht nur abgeschlossene Vorgänge gezählt. Der Entwurf beobachtet die Anzahl offener Aufgaben und das Alter der ältesten noch nicht erledigten Arbeit. Ein wachsender Bestand kann auf zu wenig Verarbeitungskapazität oder eine externe Störung hinweisen. Ein einzelner sehr alter Auftrag kann dagegen ein ungültiges Ziel oder einen verlorenen Bearbeitungszustand zeigen. Beide Muster verdienen unterschiedliche Reaktionen.

Für die Ticketöffnung wird eine vorbereitete lokale Anfrage ohne fertigen Kanal als offene Arbeit geführt. Wenn mehrere solcher Vorgänge gleichzeitig altern, wird die externe Erstellungsphase untersucht. Wenn nur einer betroffen ist, liegt möglicherweise ein spezieller Konfigurationsfehler vor. Das Team kann gezielt diesen Vorgang prüfen, statt vorsorglich alle Prozesse neu zu starten. Ein Neustart ohne Diagnose kann offene Arbeit zusätzlich verwirren und beseitigt selten eine dauerhaft ungültige Zielkonfiguration.

Auch Messlücken sind ein Signal. Ein Diagramm ohne neue Punkte bedeutet nicht automatisch, dass alles ruhig ist. Vielleicht funktioniert die Sammlung oder Speicherung nicht mehr. Der Yurna-Job protokolliert Fehler beim Speichern seiner Momentaufnahmen. Eine Betriebsansicht sollte zusätzlich das Alter der letzten erfolgreichen Beobachtung zeigen. So kann die Person unterscheiden, ob ein Wert aktuell niedrig oder lediglich alt ist. Veraltete grüne Anzeigen sind besonders problematisch, weil sie Sicherheit vermitteln, während gerade die Beobachtung ausgefallen ist.

Warnungen an Handlungen knüpfen

Eine Warnung sollte erklären, welche Funktion betroffen ist und was als Nächstes geprüft werden kann. „CPU hoch“ ist ohne Dauer und Zusammenhang oft zu wenig. „Ticketöffnungen warten ungewöhnlich lange auf die externe Erstellung“ nennt dagegen eine konkrete Auswirkung. Die zugrunde liegenden Schwellen werden anhand des normalen Verhaltens und des gewünschten Reaktionsbedarfs festgelegt. Kurzzeitige Spitzen müssen nicht dieselbe Dringlichkeit erhalten wie anhaltende Verschlechterungen. Sonst entsteht eine Flut von Meldungen, die niemand mehr sorgfältig liest.

Für jede Warnung wird ein kurzer Untersuchungsweg hinterlegt. Bei alten Ticketvorbereitungen wären das die betroffene Phase, aktuelle externe Fehler und die Zahl weiterer wartender Vorgänge. Bei fehlenden Metrikpunkten wird zunächst der Sammler untersucht. Eine Meldung, auf die niemand eine sinnvolle Handlung kennt, sollte überarbeitet werden. Das Ziel ist nicht möglichst frühes Rauschen, sondern rechtzeitige Aufmerksamkeit für einen Zustand, bei dem eine Entscheidung tatsächlich nötig ist.

Der Entwurf benachrichtigt bei einer relevanten Zustandsänderung und bei Wiederherstellung, nicht bei jedem unveränderten Messpunkt. Eine offene Störung bleibt in der Übersicht sichtbar. Zusätzliche Erinnerungen können für lange ungelöste Fälle bewusst vorgesehen werden, sollten aber einen klaren Zweck haben. So wird die Benachrichtigung zum Hinweis auf Handlungsbedarf, während das Dashboard die laufende Beobachtung übernimmt. Beide Kanäle müssen nicht dieselbe Information in derselben Häufigkeit wiederholen.

Eine Störung kontrolliert nachstellen

Die Abnahme beginnt mit einer künstlich verzögerten Discord-Erstellung. Die erste Nutzerbestätigung bleibt schnell, die fachliche Abschlussdauer steigt und offene Vorgänge altern. Die Beobachtung soll genau dieses Muster zeigen. Danach wird die Datenbankphase verzögert. Nun muss eine andere Ursache erkennbar sein, obwohl beide Fälle für Mitglieder ähnlich aussehen können. Diese kontrollierten Versuche prüfen, ob die Messpunkte tatsächlich an den richtigen Grenzen liegen und nicht nur irgendeine Gesamtdauer erfassen.

Ein weiterer Test unterbricht die Speicherung der Metriken. Die Betriebsansicht darf die letzten Werte nicht unbegrenzt als aktuell präsentieren. Anschließend wird eine unerwartete Fehlermeldung mit künstlichem sensiblem Inhalt erzeugt und ihre bereinigte Darstellung geprüft. Auch die Aufbewahrung wird betrachtet: Detailereignisse und aggregierte Messwerte können unterschiedliche Lebensdauern besitzen. Die Beobachtung selbst darf nicht zu einer unkontrolliert wachsenden Datenquelle werden, die später den Betrieb belastet.

Yurna wird dadurch nicht allein mit mehr Diagrammen verständlicher. Entscheidend ist die Verbindung zwischen Nutzerwirkung, Arbeitsphase und technischen Ursachen. Die vorhandenen Ressourcen- und Verkehrsmessungen liefern dafür Ausgangspunkte. Ergänzt um aktuelle Fachzustände und klare Warnungen entsteht eine Beobachtung, die konkrete Entscheidungen unterstützt: warten, einen Vorgang korrigieren, eine Abhängigkeit untersuchen oder eine Änderung zurücknehmen. Ein grünes Symbol bleibt dann eine begründete Aussage statt einer bloßen Bestätigung, dass irgendwo noch ein Prozess läuft.