Operator-Panel

Das Operator-Panel liegt unter /operator und ist die Sicht des Betreibers. Es ist bewusst eine eigene Welt: eigene Konten, eigener Token, eigene Rollen. Ein Mandanten-Login kommt hier nie hinein, und ein Operator-Login öffnet keine Mandanten-Anwendung.

Wie die Trennung technisch hält

Bis Juli 2026 trennte der Name des Cookies die beiden Welten — ein Operator-Cookie konnte an einer Mandanten-Route gar nicht erst ankommen. Seit die Anmeldung im Authorization-Header reist, benutzen beide denselben Transportweg, und die Trennung hängt an einem Feld in der Sitzung: dem Geltungsbereich (operator bzw. leer für Mandanten).

Geprüft wird er an jedem Eingang, nicht nur dort, wo es auffiele. Beide Richtungen sind als Test festgeschrieben: ein Operator-Token an einer Mandanten-Route ergibt 401, ein Mandanten-Token am Panel ebenso.

Erreichbar ist es nur über den direkten Link — in der normalen Oberfläche gibt es keinen Verweis darauf.

Konten und Rollen

Rolle	Darf
admin	alles, inklusive Verwaltung der Operator-Konten
consult	Registry und Auswertungen
support	Mandanten-Benutzer betreuen (Kontaktdaten, Passwort-Reset)

Das erste Konto entsteht beim ersten Start aus DNSE_OPERATOR_USER und DNSE_OPERATOR_PASSWORD und ist ein Administrator. Weitere legt ein Administrator im Panel an.

Jedes Operator-Konto kann sich unter Mein Konto mit TOTP-Zwei-Faktor absichern; das Deaktivieren verlangt das aktuelle Passwort. Angesichts der Reichweite dieser Konten ist das dringend zu empfehlen.

Was das Panel zeigt

Dashboard — Kennzahlen über Organisationen, Benutzer, Zonen und Accounts sowie die Verteilung über die Tarife.

Organisationen — die Registry: je Mandant Tarif, Kennzahlen und Benutzerliste. Von hier aus lassen sich Tarife ändern, Kontaktdaten korrigieren und Passwörter zurücksetzen. Bei konfigurierten Backups kommen Wiederherstellungspunkte und Jetzt exportieren dazu (Backup und Restore).

System — die Konfiguration als Nur-Lese-Ansicht, seit Runde 63 in drei Reitern innerhalb der Seite: Konfiguration, Knoten, Latenzen. Der Reiter Konfiguration zeigt zuerst die Kern-Einstellungen, danach die Umgebung: jede Variable, mit der diese Installation konfiguriert ist, nach Gruppen sortiert und mit ihrer Bedeutung und Vorgabe. Knoten-spezifische Gruppen (Lauschadresse/ TLS, Datenbank) fehlen hier bewusst — ihre Werte gelten je Knoten, nicht für den Cluster, und die Ansicht eines einzelnen Knotens würde in die Irre führen. Geheimnisse (Passwörter, Schlüssel, der Datenbank-DSN) melden nur, dass sie gesetzt sind — ihr Wert verlässt den Prozess nie.

Der Reiter Regionen zeigt den Regionenkatalog: je Region Kürzel, Bezeichnung, die vorgesehenen Domains (Frontend, Backend, DynDNS, Agents) und die Zahlen — wie viele Organisationen und Benutzer dort liegen. Darunter der geladene Katalog: woher er stammt (Datei, Umgebung oder eingebaut), sein Fingerabdruck und die geltenden Lebensdauern für Sitzungen und DNS-Einträge.

Gezeigt wird ausdrücklich der Stand, den dieser Knoten im Speicher hat, nicht die Datei auf der Platte. Die Datei kennt man ohnehin; was man nicht sieht, ist ein Knoten, der sie nie gelesen hat. Darum darunter der Katalog je Knoten: laufen sie mit unterschiedlichen Fingerabdrücken, steht oben eine deutliche Warnung — der Rollout ist dann halb passiert, und verschiedene Knoten können verschiedene Backend-Domains ausgeben. Bearbeiten lässt sich hier nichts: maßgeblich ist die ausgerollte Datei.

Der Reiter Knoten zeigt die laufenden Knoten: Name, Region, Adresse, Version und Lebenszeichen, daneben die Regionentabelle mit den Knoten, die eine Region bedienen.

Darunter die Laufzeit zwischen den Knoten als Matrix — der Knoten der Zeile misst zum Knoten der Spalte. Beide Richtungen stehen getrennt, denn ein unsymmetrisches Bild ist das interessante: wenn A nach B schnell antwortet, aber B nach A nicht, liegt das Problem selten in der Mitte. Gemessen wird alle 60 Sekunden mit einem Aufruf von /healthz; scheitert er, steht statt der Zeit der Fehler in der Zelle.

Ein Knoten gilt als offline, sobald sein Lebenszeichen älter als 90 Sekunden ist. Das entscheidet die Anzeige, nicht der Knoten selbst — ein abgestürzter Prozess kann sich nicht abmelden. Nach sieben Tagen ohne Lebenszeichen verschwindet ein Knoten samt seiner Messwerte.

Damit die Messung funktioniert, muss jeder Knoten wissen, unter welcher Adresse ihn die anderen erreichen. Er leitet sie aus DNSE_LISTEN und der eigenen Netzadresse ab; wo das nicht passt (NAT, mehrere Netze), setzt man DNSE_NODE_ADDR. Der Anzeigename kommt aus DNSE_NODE_NAME, sonst vom Rechnernamen.

Protokoll — jeder zeitgesteuerte Hintergrundlauf mit Ergebnis, Dauer und ausführendem Knoten: Drift-Abgleich, Zertifikatsausstellung, Propagationsprüfung, Ablauf-Erinnerungen, der Monats-Rechnungslauf und die nächtlichen Exporte. Filtern lässt sich nach Auftragsart, Knoten, Ergebnis und Zeitraum.

Über den Karten steht die Verdichtung je Auftragsart — Läufe und Probleme über den ganzen gewählten Zeitraum, nicht nur über die angezeigte Seite; Arten mit Fehlern stehen vorn, mit dem Zeitpunkt des jüngsten Problems. So unterscheidet sich ein einmaliger Ausrutscher von einem Dauerproblem.

Ein Klick auf eine Zeile öffnet den Verlauf des Laufs: was der Auftrag Schritt für Schritt getan hat, mit Zeitstempeln relativ zum Start — bei der Fehlersuche zählt, wann im Lauf etwas passierte, nicht die Uhrzeit. Dazu der wievielte Versuch es war und wann der nächste ansteht; auf „ging schief” folgt meist die Frage, was als Nächstes passiert. Ein abgestürzter Auftrag trägt seinen Absturz mit im Verlauf.

Erfolgreiche Läufe bleiben 30 Tage, fehlgeschlagene 180 — ein Problem bleibt lesbar, wenn der Lärm längst weg ist. Das Aufräumen erledigt ein eigener täglicher Lauf, der selbst im Protokoll steht.

Knotenlast

Der Reiter Knoten zeigt neben Region, Adresse und Version, was ein Anwendungsknoten gerade leistet: Anfragen je Sekunde, Fehler je Sekunde, gerade laufende Anfragen, CPU-Anteil, belegter Speicher und die Zahl der Goroutinen. Die Werte schreibt jeder Knoten selbst bei seinem Lebenszeichen (alle 15 Sekunden) in seine Zeile.

Die Raten beziehen sich auf die Spanne seit dem vorigen Lebenszeichen, nicht auf die Gesamtlaufzeit — ein Zähler seit Prozessstart sagt über die jetzige Last nichts. Ein frisch gestarteter Knoten zeigt deshalb einen Strich statt einer Null: es gibt noch keinen Vergleichspunkt, und eine gedruckte Null würde eine Messung vortäuschen, die nicht stattgefunden hat. Eine stetig steigende Goroutinen-Zahl ist der übliche erste Hinweis auf ein Leck oder hängende Aufrufe.

Datenbank — die YugabyteDB hinter der Installation, gelesen über ihre eigenen Systemsichten (yb_servers(), yb_servers_metrics()) und, wo konfiguriert, über die Master-Oberfläche. Oben die Kennzahlen: erreichbare Knoten, Regionen, Zonen, offene Verbindungen, Lese- und Schreiboperationen je Sekunde. Dann die Platzierung — welcher Datenbankknoten welche Region bedient, und welche Anwendungsknoten in derselben stehen. Darunter je Knoten Verbindungen, Operationen, Tablet-Führung, Plattenbelegung, CPU-Last, Speicherbelegung und Heartbeat-Verzug.

Master, Folger und Tablet-Führung

Zwei Zahlen, die regelmäßig missverstanden werden.

Master sind nicht gleich Master. Auf einer Anlage mit drei Knoten laufen drei Master-Prozesse — aber zu jedem Zeitpunkt führt genau einer. Die anderen beiden sind Folger: sie halten denselben Stand und übernehmen, wenn der Führende ausfällt. Die Seite nennt den Führenden beim Namen und schreibt dazu, wie viele Ausfälle die Anlage verkraftet (bei drei Mastern: einer; für eine Wahl braucht es die Mehrheit von zwei).

Master verwalten den Katalog und die Verteilung der Datenscheiben. Die Daten selbst liegen auf den TServern — das sind die Knoten in der unteren Tabelle.

Tablet-Führung ist die eigentliche Lastverteilung. Die Spalte zeigt geführt / gehalten. Nur der Führende einer Datenscheibe nimmt Schreibvorgänge an; die übrigen Repliken kosten fast nichts. Bei Replikationsfaktor 3 ist die Zahl der gehaltenen Repliken cluster-weit rund dreimal so hoch wie die der Führungen — das ist kein Fehler, sondern die Definition von RF3. Interessant wird es, wenn sich die Führungen ungleich verteilen: dann trägt ein Knoten die Schreiblast der anderen mit.

Abfragelast

Was der SQL-Teil je Knoten verarbeitet, liest die Seite aus den YSQL-Metriken (DNSE_YB_METRICS_PORT, Vorgabe 13000): Anweisungen je Art (SELECT, INSERT, UPDATE, DELETE), die durchschnittliche Laufzeit einer Abfrage, wie viele Zeilen eine Abfrage im Mittel zurückgibt, und die Zahl der Transaktionen.

Die Rate (Anweisungen je Sekunde) bildet sich aus der Spanne seit dem letzten Öffnen dieser Seite. Beim ersten Aufruf steht deshalb ein Strich, beim zweiten eine Zahl. Die Gesamtzähler daneben laufen seit Prozessstart.

Beide Zusatzquellen — Master-Oberfläche und Metrikport — sind eigene Netzwege. Fehlen sie, fehlen genau diese Spalten; die Knotenliste steht unverändert.

Die Platzierung der Datenbank (--placement_region der yb-Prozesse) und die Region der Anwendung (DNSE_REGION) sind zwei getrennte Angaben — passen sie zusammen, steht in der Tabelle das sprechende Regionslabel, sonst nur die rohe Kennung. Das ist Absicht: eine stille Umdeutung würde eine Fehlkonfiguration verstecken.

Was eine Region verspricht — und was nicht

Eine Region ist erst ein Angebot, wenn dort Daten liegen können. Das entscheidet allein die Datenbankplatzierung: Steht in einer Region kein YugabyteDB-Knoten, lässt sich dort keine Organisation anlegen — die Bereitstellung weist das ab, statt eine Organisation ohne Speicherort entstehen zu lassen. Fehlt dagegen nur ein Anwendungsknoten, ist das kein Hindernis: die Daten liegen richtig, bedient wird von anderswo. Beides steht in der Abdeckungsspalte der Seite.

Ist keine Cluster-Datenbank im Spiel (Einzelinstanz, SQLite), gibt es keine Platzierung zu prüfen. „Unbekannt” heißt dann ausdrücklich nicht „verboten” — sonst könnte eine frische Installation nichts anlegen.

Was heute noch nicht gilt: Die Daten tragen ihre Region und das Ereignis-Log ist nach Region partitioniert, aber die Partitionen sind noch nicht an regionale Tablespaces gebunden. Physisch liegen die Bytes also weiterhin dort, wo YugabyteDB sie hinlegt. Für echte Datenresidenz fehlen zwei Dinge: die Bindung der Partitionen an Tablespaces und mindestens drei Knoten je Region, sonst ist RF3 innerhalb einer Region nicht möglich.

Für Gesundheitszustand (tote Knoten, unterreplizierte Tablets), Master-Rollen und Arbeitslast braucht es die Master-Oberfläche: DNSE_YB_MASTER_ADDR=<host>:7000. Ohne sie funktioniert die Seite unverändert, nur diese Angaben fehlen.

Sitzungen — wer in diesem Moment angemeldet ist, über alle Organisationen hinweg: Benutzer, Organisation und deren Region, Adresse, Programm, der Knoten, der die Anmeldung angenommen hat, sowie Anmeldezeitpunkt, letzte Aktivität und Ablauf. Die Liste frischt sich alle 20 Sekunden auf.

Der Sitzungstoken erscheint nirgends. Jede Zeile trägt stattdessen einen Fingerabdruck — genug, um zwei Sitzungen auseinanderzuhalten, aber nicht umkehrbar. Eine Liste gültiger Tokens wäre eine Liste übernehmbarer Anmeldungen, auch für den, der nur zuschaut.

Die Ansicht braucht einen auflistbaren Sitzungsspeicher, also Valkey (DNSE_VALKEY_ADDR). Läuft die Installation ohne, sagt die Seite das — eine leere Liste wäre gelogen: es gibt Sitzungen, sie sind nur nicht einsehbar.

Zur Adressspalte: Sie zeigt, was am Knoten ankommt. Steht DNSE_TRUSTED_PROXIES auf 0.0.0.0/0, glaubt die Anwendung jedem X-Forwarded-For — auch einem selbst gesetzten. Und sie kann nur anzeigen, was der Reverse Proxy weitergibt: überschreibt der den Header mit $remote_addr, statt ihn mit $proxy_add_x_forwarded_for anzuhängen, steht hier die Adresse des vorherigen Sprungs und nicht die des Anwenders.

Einstellungen und Nachrichten — die Plattform-Ebene: Kern-Einstellungen und Portalnachrichten, die als Banner bei allen Mandanten erscheinen. Beides pflegt der Betreiber einmal zentral; in den Mandanten-Admin-Panels sind diese Seiten ausgeblendet. Der SMTP-Ausgang lässt sich je Region setzen (smtp.<region>.* — ein Knoten nimmt den Block seiner Region und fällt ohne einen solchen auf die globalen smtp.*-Werte zurück). DynDNS-Hostnamen und die öffentliche Adresse tauchen hier nicht mehr auf: in der Cloud kommen sie aus dem Regionenkatalog.

Datenresidenz und Umzug

Wählt man eine Organisation aus, zeigt der Abschnitt Datenresidenz, wo ihre Daten wirklich liegen: die erklärte Heimatregion laut Tarif gegen die tatsächliche Verteilung der Ereignisse, gezählt über alle Ereignistabellen.

Die Auswertung beantwortet drei Fragen, die vorher niemand beantworten konnte:

• Ein Kunde fragt, wo seine Daten liegen. Bisher ließ sich nur die Absicht nennen, nicht der Zustand.
• Läuft die Absicht auseinander? Im Betrieb fällt das nicht auf, weil die Anwendung beim Lesen nie auf Geo filtert.
• Ist ein Umzug wirklich fertig? Ohne Zählung wäre „fertig” eine Behauptung.

Sie läuft nur auf Abruf — die Zählung geht über alle Ereignistabellen und gehört nicht in die Übersichtsliste.

Zwei Nullen sind nicht dasselbe. Ist die Zählung nicht zu holen, steht das da — und nicht „0 Ereignisse anderswo”. Nicht gezählt ist nicht dasselbe wie sauber.

Übergangen werden org_plan und plan_acceptance. Sie tragen zwar eine Mandanten-Kennung, beschreiben aber die Organisation, statt ihre Daten zu sein: sie liegen in der primären Region und ziehen bei einem Umzug nicht mit. Der Bericht nennt sie, damit sichtbar bleibt, worüber er nicht spricht.

Der Umzug

Daneben steht die Regionsauswahl mit Organisation umziehen (nur für die Rolle admin). Der Umzug verlegt alle Daten der Organisation — Ereignisprotokoll, Archiv, Snapshots und Read-Model gemeinsam.

Die Reihenfolge ist Absicht: zuerst wird die Heimatregion umgeschrieben, dann gezogen. Damit landen Schreibvorgänge während des Umzugs schon am Ziel, statt dass der Umzug einem Ziel hinterherjagt, das sich bewegt.

Die Antwort ist kein „fertig”, sondern die Zählung danach. Nur außerhalb der erklärten Region: 0 belegt einen vollständigen Umzug. Bricht der Lauf ab, bleibt „Ziel erklärt, Daten teils noch dort” stehen — der ehrliche Zustand, und ein sichtbarer. Wiederholen setzt fort; der Aufruf ist idempotent.

Ein Umzug in die bereits erklärte Region ist erlaubt und kein Leerlauf: er räumt die Reste weg, die ein abgebrochener Lauf oder eine Organisation aus der Zeit vor den Regionen hinterlassen hat.

Die übrigen Knoten übernehmen die neue Zuordnung binnen einer halben Minute (gemerkte Zuordnung, regionCacheTTL). Solange schreiben sie noch in die alte Region — genau dafür ist der Umzug wiederholbar.

Keine DNS-Daten

Die Registry zeigt Zahlen, keine Zonen. Ein Operator sieht, dass eine Organisation 42 Zonen verwaltet — nicht welche. Wer inhaltlich unterstützen soll, braucht eine reguläre Freigabe im betroffenen Projekt.

Maschinenzugriff

DNSE_OPERATOR_TOKEN erlaubt den Zugriff auf die Operator-API ohne Anmeldung (Header X-Operator-Token) und gilt dabei als Administrator. Gedacht ist das für das Checkout-Frontend und Automatisierung — nicht als bequemer Zugang für Menschen. Wo es nicht gebraucht wird, gehört es weggelassen.