Motor de monitoreo con tu propio almacenamiento
“Métricas de tu MySQL, guardadas en tu MySQL.”
Monitoreo histórico sin instalar Prometheus.
Un colector dedicado escribe snapshots en un servidor de almacenamiento que tú eliges, provisionando tablas para muestras (CPU, memoria, conexiones, QPS) y eventos (rupturas de umbral, lag de replicación). Retención automática.
Visual EXPLAIN interactivo
“Tu plan de consulta como un diagrama que respira.”
Detecta el ALL que está matando tu consulta sin leer JSON a mano.
Toma EXPLAIN FORMAT=JSON y lo dibuja como un árbol. Codificado por color según el tipo de acceso: full scan, range / index merge, optimizado, sort, join. Tooltips con access_type, filas estimadas y tiempos. Zoom con la rueda, con el pellizco del trackpad o con los botones de la barra — la escala está siempre a la vista, y ⌘+ / ⌘− / ⌘0 hacen lo mismo sin trackpad. Pan arrastrando.
Perfilador de consulta
“Ve dónde estás perdiendo los milisegundos.”
Localiza qué fase de la consulta se está llevando el tiempo.
Construido sobre SHOW PROFILE. Tabla más gráfico de barras por fase (starting, Sending data, etc.) con tiempos en milisegundos.
Consultas lentas, en el motor que toque
“Lo que tu servidor ya apuntó de las consultas que tardaron de más.”
Lees lo que el servidor registró —de todos los clientes que se conectan a él, no sólo de Calíope— y desde la misma pantalla enciendes el log, mueves el umbral y lo vacías. Un botón lleva la consulta al editor, y el perfilador está allí mismo.
Cada motor con su vocabulario. MySQL y MariaDB: las entradas salen de mysql.slow_log cuando el servidor escribe a tabla, y el resumen por sentencia de performance_schema; el umbral es long_query_time. PostgreSQL: pg_stat_statements, agregado por forma de sentencia y no una fila por ejecución, y el umbral se escribe con ALTER SYSTEM más pg_reload_conf() —uno que vino de la línea de órdenes con la que se arrancó el servidor se declara imposible de cambiar desde aquí en vez de fallar sin decirlo—. MongoDB: herramienta propia, porque el profiler es por base de datos. Una lista vacía nunca es la respuesta: si el log va a un archivo de la máquina del servidor, si performance_schema está apagado o si la extensión no está creada en esa base, ese motivo exacto se lee en pantalla. En Aurora los ajustes son de sólo lectura —viven en el parameter group del clúster—. Sin gráficos, y nada se copia a Calíope: ves la ventana que el servidor guarda, con el reloj del servidor.
Process List con KILL guiado
“Un KILL para la consulta que colgó tu producción.”
Termina una consulta descontrolada sin abrir una terminal.
SHOW FULL PROCESSLIST con columnas para id, user, host, database, command, time, state e info. Acciones para KILL QUERY y KILL CONNECTION.
Monitor de replicación (MySQL 8 y legacy)
“Réplicas de MySQL 8 y 5.7, en el mismo panel.”
Observa el lag de la réplica sin pelearte con el vocabulario legacy vs. 8.0.
SHOW REPLICA STATUS (MySQL 8) con fallback automático a SHOW SLAVE STATUS (MariaDB 10.5 / MySQL 5.7). Métricas: IO/SQL running, segundos por detrás del source, últimos errores con timestamp, GTID sets, posiciones de log. Auto-refresh configurable.
Topología de replicación
“Una réplica puede decir cero segundos mientras va horas por detrás. Aquí se ve.”
Ves el grupo entero de una vez, y dejas de fiarte de un «0 segundos» que en realidad significa «acabo de reconectar».
Declaras qué máquina es la primaria y cuáles son las réplicas. Nada se autodetecta: SHOW REPLICA HOSTS sólo ve lo conectado en ese instante, así que un grupo detectado cambiaría solo y «esta réplica ya no está» sería indistinguible de «esta réplica está caída». Esa consulta se usa para contradecir una configuración incoherente, nunca para reconfigurarla. Que una réplica lea de otra máquina se decide por server_id, jamás por nombre de host — detrás de Docker, NAT, una VPN o un túnel, comparar cadenas da un aviso permanente y falso. Un hilo IO parado es crítico aunque el retraso diga cero, y a su lado va la deriva de GTID, que se cuenta por origen en vez de restarse. Un miembro que no responde no tumba a los demás: «7 de 9» es una lectura normal, y los que faltan se nombran. Sólo lee — nunca opera sobre el grupo. El diagrama lleva una tabla como alternativa accesible, y ningún estado se distingue sólo por color.
Visor de binlog con filtros y PURGE
“Tu binlog, filtrable y purgable — desde la app.”
Audita qué eventos produjeron tus statements sin bajar a mysqlbinlog.
SHOW BINLOG EVENTS con categorización en DDL / DML / Sistema, búsqueda por texto y un límite de filas configurable (por defecto 300). Soporta binlogs encriptados (MySQL 8.0.14+). PURGE BINARY LOGS TO con confirmación explícita.
Dashboard, Server Info y Health
“El pulso de tu MySQL, en una sola vista.”
Consolida la salud del servidor sin abrir cinco clientes.
Server Info multipestaña (variables globales y de sesión, status global y de sesión, uso de HDD), Server Dashboard con gráficos en vivo y un Server Health Monitor.
Benchmark en vivo
“Dos consultas en la balanza; una gana.”
Elige entre dos consultas con evidencia, no con intuición.
Compara tiempos de ejecución de variantes de consulta lado a lado.
Alertas y notificaciones locales
“Tu Mac te avisa cuando la réplica se atrasa.”
El sistema te avisa — no tienes que quedarte mirando la app.
Alertas por umbral en CPU, memoria, conexiones y lag de replicación. Notificaciones nativas de macOS/iOS.
Todo lo que corre, en un solo sitio
“Lo que está corriendo ya no desaparece al cambiar de pestaña.”
Consultas, respaldos, migraciones y trabajos programados se registran en un único sitio, con tiempo transcurrido, destino y un Detener que detiene de verdad. Se ve desde el pie de la barra lateral, desde la pestaña que trabaja y desde el conmutador de servidores.
Las operaciones se inscriben solas — nada sondea banderas ajenas, porque un registro que adivina acaba mintiendo en los dos sentidos. Las tareas (que empiezan y terminan) y los modos (que están encendidos hasta que alguien los apaga) son tipos distintos, así que un modo no lleva barra de progreso ni cronómetro. Un lote sobrevive a que se destruya su vista: el controlador vive en un store indexado por pestaña, no en el estado de la vista. Umbral de 0,8 s antes de que aparezca nada — una consulta de 40 ms no es un proceso.
Errores que se explican — y que tu teléfono puede leer
“Un fallo con su causa, su sugerencia y su registro.”
Cuando algo falla, Calíope dice qué pasó, sugiere qué comprobar y enlaza al tema de ayuda que corresponde. Todo queda en un registro con su fecha y su dispositivo, que la app para iPhone puede leer desde donde estés.
Ningún código de error nombra un motor: la tabla de códigos nativos vive con su provider, así que sumar uno es implementar un protocolo. El número nativo se lee del paquete tipado, no se saca del mensaje — MySQLNIO no lo escribe, así que un fallo de credenciales se clasificaba como fallo de conexión y te mandaba a comprobar el puerto. El teléfono es de sólo lectura: podar y borrar se quedan en el escritorio. Y «no hay errores» es una afirmación — se distinguen seis motivos distintos de pantalla vacía, porque dar la buena noticia cuando lo que pasa es que el canal está cerrado es su propia clase de mentira.