Monitoring-Engine mit deinem eigenen Speicher
“Metriken deines MySQL, gespeichert in deinem MySQL.”
Historisches Monitoring, ohne Prometheus zu installieren.
Ein dedizierter Kollektor schreibt Snapshots auf einen Speicherserver deiner Wahl und provisioniert Tabellen für Messwerte (CPU, Arbeitsspeicher, Verbindungen, QPS) und Ereignisse (Schwellenwert-Überschreitungen, Replikationsverzögerung). Automatische Aufbewahrung.
Interaktives Visual EXPLAIN
“Dein Query-Plan als atmendes Diagramm.”
Erkenne das ALL, das deine Query umbringt, ohne JSON von Hand zu lesen.
Nimmt EXPLAIN FORMAT=JSON und zeichnet es als Baum. Farbcodiert nach Zugriffstyp: Full Scan, Range / Index Merge, optimiert, Sort, Join. Tooltips mit access_type, geschätzten Zeilen und Zeiten. Zoomen mit dem Mausrad, mit dem Trackpad-Kneifen oder mit den Schaltflächen der Leiste — der Maßstab ist immer sichtbar, und ⌘+ / ⌘− / ⌘0 tun dasselbe ohne Trackpad. Verschieben durch Ziehen.
Query-Profiler
“Sieh, wo du die Millisekunden verlierst.”
Finde heraus, welche Phase der Query die Zeit frisst.
Aufgebaut auf SHOW PROFILE. Tabelle plus Balkendiagramm pro Phase (starting, Sending data, usw.) mit Zeiten in Millisekunden.
Langsame Abfragen, auf der Engine, mit der du gerade arbeitest
“Was dein Server über die zu langsamen Abfragen längst notiert hat.”
Du liest, was der Server aufgezeichnet hat — von allen Clients, die sich mit ihm verbinden, nicht nur von Calíope — und schaltest auf derselben Seite das Protokoll ein, verschiebst den Schwellwert und leerst es. Ein Knopf schickt die Abfrage in den Editor, und der Profiler ist genau dort.
Jede Engine in ihrem eigenen Vokabular. MySQL und MariaDB: die Einträge kommen aus mysql.slow_log, wenn der Server in eine Tabelle schreibt, und die Zusammenfassung pro Anweisung aus performance_schema; der Schwellwert ist long_query_time. PostgreSQL: pg_stat_statements, aggregiert nach Anweisungsform statt einer Zeile pro Ausführung, und den Schwellwert schreibt ALTER SYSTEM plus pg_reload_conf() — einer, der aus der Kommandozeile des Serverstarts kommt, wird als von hier nicht änderbar ausgewiesen, statt stillschweigend zu scheitern. MongoDB: ein eigenes Werkzeug, denn der Profiler gilt pro Datenbank. Eine leere Liste ist nie die Antwort: schreibt der Server sein Protokoll in eine Datei auf seiner Maschine, ist performance_schema aus oder ist die Extension in dieser Datenbank nicht angelegt, steht genau dieser Grund auf dem Bildschirm. Auf Aurora sind die Einstellungen nur lesbar — sie liegen in der Parametergruppe des Clusters. Keine Diagramme, und nichts wird nach Calíope kopiert: du siehst das Fenster, das der Server führt, mit der Uhr des Servers.
Process List mit geführtem KILL
“Ein KILL für die Query, die deine Produktion aufgehängt hat.”
Beende eine außer Kontrolle geratene Query, ohne ein Terminal zu öffnen.
SHOW FULL PROCESSLIST mit Spalten für id, user, host, database, command, time, state und info. Aktionen für KILL QUERY und KILL CONNECTION.
Replikationsmonitor (MySQL 8 und Legacy)
“Replikate von MySQL 8 und 5.7, im selben Panel.”
Beobachte die Verzögerung des Replikats, ohne dich mit dem Vokabular von Legacy vs. 8.0 herumzuschlagen.
SHOW REPLICA STATUS (MySQL 8) mit automatischem Fallback auf SHOW SLAVE STATUS (MariaDB 10.5 / MySQL 5.7). Metriken: IO/SQL running, Sekunden hinter der Source, letzte Fehler mit Zeitstempel, GTID-Sets, Log-Positionen. Konfigurierbares Auto-Refresh.
Replikationstopologie
“Eine Replika kann null Sekunden melden, während sie Stunden hinterherhinkt. Hier sieht man es.”
Du siehst die ganze Gruppe auf einmal und vertraust keinem „0 Sekunden“ mehr, das in Wahrheit „ich habe gerade neu verbunden“ heißt.
Du deklarierst, welche Maschine die primäre ist und welche die Replikate sind. Nichts wird automatisch erkannt: SHOW REPLICA HOSTS sieht nur, was in diesem Augenblick verbunden ist, also würde sich eine erkannte Gruppe von selbst ändern und „diese Replika ist weg“ wäre nicht von „diese Replika ist ausgefallen“ zu unterscheiden. Diese Abfrage dient dazu, eine widersprüchliche Konfiguration zu widerlegen, nie sie umzukonfigurieren. Ob eine Replika von einer anderen Maschine liest, entscheidet die server_id, niemals der Hostname — hinter Docker, NAT, VPN oder Tunnel ergibt ein Zeichenkettenvergleich eine dauerhafte und falsche Warnung. Ein gestoppter IO-Thread ist kritisch, auch wenn der Rückstand null anzeigt, und daneben steht der GTID-Drift, der pro Ursprung gezählt und nicht subtrahiert wird. Ein Mitglied, das nicht antwortet, reißt die anderen nicht mit: „7 von 9“ ist eine normale Anzeige, und die fehlenden werden benannt. Sie liest nur — sie operiert nie an der Gruppe. Das Diagramm trägt eine Tabelle als barrierefreie Alternative, und kein Zustand wird allein durch Farbe unterschieden.
Binlog-Betrachter mit Filtern und PURGE
“Dein Binlog, filterbar und purge-bar — aus der App.”
Prüfe, welche Ereignisse deine Statements erzeugt haben, ohne zu mysqlbinlog hinabzusteigen.
SHOW BINLOG EVENTS mit Kategorisierung in DDL / DML / System, Textsuche und einem konfigurierbaren Zeilenlimit (standardmäßig 300). Unterstützt verschlüsselte Binlogs (MySQL 8.0.14+). PURGE BINARY LOGS TO mit ausdrücklicher Bestätigung.
Dashboard, Server Info und Health
“Der Puls deines MySQL, in einer einzigen Ansicht.”
Bündelt die Server-Gesundheit, ohne fünf Clients zu öffnen.
Mehrtabbige Server Info (globale und Sitzungs-Variablen, globaler und Sitzungs-Status, HDD-Nutzung), Server Dashboard mit Live-Diagrammen und ein Server Health Monitor.
Live-Benchmark
“Zwei Queries auf der Waage; eine gewinnt.”
Wähle zwischen zwei Queries mit Belegen, nicht mit Bauchgefühl.
Vergleicht die Ausführungszeiten von Query-Varianten nebeneinander.
Alerts und lokale Benachrichtigungen
“Dein Mac warnt dich, wenn das Replikat zurückfällt.”
Das System warnt dich — du musst nicht auf die App starren.
Schwellenwert-Alerts für CPU, Arbeitsspeicher, Verbindungen und Replikationsverzögerung. Native Benachrichtigungen von macOS/iOS.
Alles, was läuft, an einem Ort
“Was läuft, verschwindet nicht mehr beim Tabwechsel.”
Abfragen, Backups, Migrationen und geplante Jobs werden an einer Stelle registriert, mit verstrichener Zeit, Ziel und einem Stopp, der wirklich stoppt. Sichtbar aus dem Fuß der Seitenleiste, aus dem arbeitenden Tab und aus dem Server-Umschalter.
Operationen tragen sich selbst ein — nichts fragt fremde Flags ab, denn ein Register, das rät, lügt am Ende in beide Richtungen. Aufgaben (die beginnen und enden) und Modi (die an bleiben, bis jemand sie ausschaltet) sind verschiedene Typen, also hat ein Modus weder Fortschrittsbalken noch Stoppuhr. Ein Lauf überlebt die Zerstörung seiner View: der Controller lebt in einem Store, indiziert nach Tab, nicht im State der View. Schwelle von 0,8 s, bevor überhaupt etwas erscheint — eine Abfrage von 40 ms ist kein Prozess.
Fehler, die sich erklären — und die dein Telefon lesen kann
“Ein Fehler mit Ursache, Vorschlag und Eintrag.”
Wenn etwas schiefgeht, sagt Calíope, was passiert ist, schlägt vor, was zu prüfen ist, und verlinkt das passende Hilfethema. Alles landet in einem Protokoll mit Datum und Gerät, das die iPhone-App von überall lesen kann.
Kein Fehlercode nennt eine Engine: die Tabelle der nativen Codes lebt bei ihrem Provider, eine hinzuzufügen heißt also, ein Protokoll zu implementieren. Die native Nummer wird aus dem typisierten Paket gelesen, nicht aus der Meldung gekratzt — MySQLNIO schreibt sie nicht, weshalb ein Zugangsdaten-Fehler früher als Verbindungsfehler eingestuft wurde und dich den Port prüfen ließ. Das Telefon liest nur: Aufräumen und Löschen bleiben am Schreibtisch. Und «keine Fehler» ist eine Aussage — sechs verschiedene Gründe für einen leeren Bildschirm werden unterschieden, denn die gute Nachricht zu geben, während der Kanal schlicht zu ist, ist eine eigene Art von Lüge.