Servicio ▸ Base de datos — Manual de InfraGuard

Resumen — qué hace

Servicio ▸ Base de datos (/service/database) es una pantalla de monitorización en vivo que se conecta directamente a los recolectores de base de datos registrados (access=database) para muestrear métricas de carga y analizar la estructura del esquema. Cada base de datos se representa como una tarjeta, y cada tarjeta muestra de un vistazo dos ejes de carga.

La monitorización de bases de datos se construye alrededor de dos ejes de carga:

Eje	Pregunta	Métricas clave
① Carga de concurrencia	¿Cuánto se está acumulando ahora mismo?	`threads_running`, saturación de conexiones (`conn_pct`), consultas en espera (`waiting`)
② Rendimiento e ineficiencia	¿Cuánto trabajo se hace y cuánto se desperdicia?	QPS (`Δquestions/Δt`), tasa de consultas lentas (`Δslow_queries/Δt`)

Además de eso ofrece análisis del esquema (tamaño total · bases de datos más grandes · tablas más grandes · mezcla de motores), puntuaciones de eficiencia (tasa de aciertos de caché del buffer pool · uso de índices) y un bloque de gestión de memoria de InnoDB (vaciado de páginas sucias · checkpoint).

Esta pantalla no instala ningún agente en la base de datos de destino. La aplicación InfraGuard simplemente se conecta al MySQL/MariaDB remoto con las credenciales registradas y lanza consultas SHOW GLOBAL STATUS / information_schema.

Cuándo usarla

Una base de datos se ha vuelto lenta de repente: saber al instante si se saturaron las conexiones, se disparó la concurrencia o aumentaron las consultas lentas.
Antes y después de ajustar el pool de conexiones: observar la saturación de threads_connected / max_connections a lo largo del tiempo.
Planificación de capacidad: ver qué esquemas o tablas consumen más disco y cuál es la mezcla de motores.
Diagnóstico de la presión de vaciado de InnoDB: si las páginas sucias circulan de forma sana por debajo del umbral y hasta dónde ha avanzado la edad del checkpoint respecto a la capacidad de redo.
Revisión de eficiencia de caché e índices: leer la tasa de aciertos del buffer pool y el uso de índices como evidencia para el ajuste.

Disposición

KPI superiores

KPI	Significado
Número de BD	Total de recolectores `access=database` registrados
Up / Degraded / Down	Agregado del estado de las tarjetas (`up`/`degraded`/`down`)
QPS total	Suma de QPS de todas las tarjetas
Conexiones	Suma de `threads_connected` de todas las tarjetas

Cabecera de la tarjeta

Etiqueta del host (host_alias del recolector → config.host → host env de cred_ref, en ese orden).
Controlador (mysql/mariadb), nombre de la base de datos, tiempo activo, distintivo de estado.

① Carga de concurrencia

Indicador de anillo de saturación de conexiones = threads_connected / max_connections.
Running (threads_running): hilos que realmente consumen CPU.
Waiting (acumulación) (waiting): consultas cuyo tiempo de procesamiento supera el umbral (2 s por defecto). Según el privilegio PROCESS, esto cuenta todo el servidor o solo la propia conexión (el alcance se muestra en la tarjeta).

② Rendimiento e ineficiencia

Minigráfico de QPS = Δquestions / Δt (últimas 60 muestras correctas).
Tasa de consultas lentas = Δslow_queries / Δt, y total de consultas lentas (slow_queries).

Pie de la tarjeta — eficiencia · bloqueos

Métrica	Fórmula	Grados
Tasa de aciertos de caché	`1 − Δinnodb_buffer_pool_reads / Δinnodb_buffer_pool_read_requests`	Excelente ≥99,5 % · Buena ≥98 % · Aceptable ≥90 %
Uso de índices	`Δhandler_read_key / (Δhandler_read_key + Δhandler_read_rnd_next)`	Excelente ≥90 % · Bueno ≥70 % · Aceptable ≥40 %
lock	`innodb_row_lock_time_avg` (espera media de bloqueo de fila, ms)	Cuanto más bajo, mejor

Cada etiqueta de métrica (cache · index · lock · checkpoint) lleva un popover educativo que explica causas y remedios (por ejemplo, aumentar innodb_buffer_pool_size, usar índices de cobertura, evitar bloqueos de hueco).

Análisis del esquema (plegable)

Está plegado por defecto; se abre con [Expandir]. Agregado a partir de information_schema.tables, muestra tamaño total · número de tablas · número de esquemas · los 8 esquemas mayores por tamaño · las 14 tablas mayores por tamaño · mezcla de motores.

El análisis del esquema es de por sí una consulta lenta en el servidor (medida en ~3,5 s), así que se evita con una caché larga de 30 minutos. El planificador (infr:collect-db) calienta la caché, de modo que las peticiones web siempre aciertan. Cuando la caché está vacía la sección se oculta brevemente y aparece en el siguiente sondeo.

Gestión de memoria de InnoDB (vaciado de páginas sucias)

Serie temporal de páginas sucias más una superposición de "valor adecuado" (umbral): MAX (innodb_max_dirty_pages_pct) y LWM (innodb_max_dirty_pages_pct_lwm) convertidos a recuentos absolutos de páginas (no constantes arbitrarias, sino el punto en el que InnoDB empieza realmente a vaciar de forma agresiva).
Edad del checkpoint (Log sequence number − Last checkpoint at) como porcentaje de la capacidad de redo.
Tamaño del buffer pool y su proporción respecto a la RAM del servidor (el mem_mb de la instancia de SO unida por alias).

Disposición de las tarjetas

La cuadrícula de tarjetas admite reordenación por arrastre (SortableJS · orden guardado en localStorage) con mampostería por row-span. La pantalla se refresca con un sondeo de 30 segundos.

Cómo usarla

Registre primero un recolector access=database en Administración ▸ Recolectores. Introduzca host/port/database/username más la contraseña (almacenada cifrada con Crypt en el recolector), o defina cred_ref = env:PREFIX para reutilizar un conjunto de credenciales existente de .env.
Abra /service/database; las bases de datos registradas se listan como tarjetas. Al entrar, si la última muestra tiene más de 60 segundos, se toma una muestra inmediata única (ensureFresh).
Identifique la BD problemática por el distintivo de estado de la cabecera y luego acote la causa con los dos ejes de carga (concurrencia / rendimiento).
Expanda el análisis del esquema para inspeccionar los esquemas y tablas mayores (la mampostería se recoloca automáticamente al cambiar la altura).
Arrastre las tarjetas para llevar arriba las bases de datos que le interesen (el orden se guarda en el navegador).

Reutilizar credenciales mediante cred_ref

Con cred_ref = env:PREFIX, las siguientes claves se leen de .env, de modo que no se almacena ningún secreto en la base de datos:

Por ejemplo: env:STATS_DB → servidor blue, env:STATS_GLORY_DB → servidor glory.

Para ver las consultas en espera de todo el servidor

Para agregar waiting en todo el servidor, la cuenta de monitorización necesita el privilegio PROCESS; de lo contrario solo se cuentan sus propias conexiones. Una cuenta de monitorización con privilegios mínimos:

CREATE USER 'infra_monitor'@'%' IDENTIFIED BY 'YOUR_DB_PASSWORD';
GRANT PROCESS, SELECT ON *.* TO 'infra_monitor'@'%';
FLUSH PRIVILEGES;

La decisión de alcance (si se tiene PROCESS) es fija por cuenta, así que se cachea durante 1 hora. Si concede el privilegio más tarde, surtirá efecto en un plazo de una hora (limpie la caché para que sea inmediato).

Fuentes de datos

Consultas de origen (ejecutadas en la BD remota)

Consulta	Propósito
`SHOW GLOBAL STATUS`	Todos los contadores de threads · questions · slow_queries · bytes · buffer pool · handler · InnoDB
`SELECT @@GLOBAL.max_connections` y similares	max_connections, ajustes de vaciado de InnoDB (caché de 1 h)
`information_schema.processlist`	Recuento de consultas en espera y decisión de alcance
`information_schema.tables`	Análisis del esquema (caché de 30 minutos)
`SHOW ENGINE INNODB STATUS`	Edad del checkpoint (LSN − último checkpoint · requiere `PROCESS`)
`SHOW GRANTS FOR CURRENT_USER()`	Detección del privilegio `PROCESS` (alcance)

Tabla de almacenamiento

Los datos muestreados se escriben en la serie temporal infr_db_metric (migración 000681). Los contadores acumulados (questions/slow_queries/bytes_*) también se almacenan para que la siguiente muestra pueda calcular QPS · tasa de consultas lentas · puntuaciones de eficiencia por delta.

infr_db_metric
  collector_id  host  sampled_at  uptime_sec
  threads_connected/running/cached  max_connections  conn_pct
  waiting  waiting_scope
  questions  slow_queries  qps  slow_qps
  bytes_received/sent  recv_bps/sent_bps  innodb_row_lock_waits
  ok  message  raw(json: efficiency + InnoDB memory-management derivations)

Sin fugas de conexiones (la lección del [1040]). Cada muestra crea una conexión en tiempo de ejecución y la libera de inmediato con DB::purge en finally. Un tiempo de espera de PDO (5 s por defecto) evita que las peticiones web y el planificador se queden colgados con un remoto lento. Si esta disciplina se rompe, se agota el max_connections del MySQL compartido y hasta producción se ve afectada.

Planificación de la recolección · condiciones

La serie temporal la rellena el comando de artisan infr:collect-db. Se ejecuta una vez y termina (no es un demonio); el planificador lo invoca cada minuto.

# Toma una muestra inmediata para un solo recolector (salta la condición)
php artisan infr:collect-db --key=db@blue --force

La política de operaciones (Administración ▸ Política de operaciones · OpsPolicy) condiciona las ejecuciones planificadas:

Ajuste	Valor por defecto	Significado
`db_collect_mode`	`economy`	economy = recolectar solo cuando hay un usuario de consola (presencia) · always = recolectar continuamente
`db_collect_interval_sec`	`60`	Intervalo de recolección (s). El tic es cada minuto, pero el periodo efectivo es este valor

Umbrales de degraded/down

DbCollectorService::statusOf decide el estado mediante OpsPolicy::dbThresholds().

Motivo	Condición	Umbral por defecto
`conn_saturation`	`conn_pct ≥`	80 %
`high_concurrency`	`threads_running ≥`	40
`query_backlog`	`waiting ≥`	5
`slow_query_rate`	`slow_qps ≥`	1/s
`down`	Sin muestra / `ok=false`, o última muestra de hace más de 5 minutos (`stale`)	—

Si hay cualquier motivo presente → degraded; si no hay ninguno → up.

Acceso

Esta pantalla es una consola de solo lectura dentro del grupo infr.auth: nivel mínimo de lectura demo=1.
Esta página no tiene endpoints de escritura. Registre o edite las credenciales de las BD de destino en Administración ▸ Recolectores (admin=10, control level≥5).
Cambie los umbrales y el modo de recolección en Administración ▸ Política de operaciones (admin).

Resolución de problemas y preguntas frecuentes

Una tarjeta muestra "down"

no_credentials: el host o el username de config están vacíos, o faltan las claves env de cred_ref=env:PREFIX.
stale: la última muestra tiene más de 5 minutos. Compruebe que el planificador (infr:collect-db) está en marcha y, en modo economy, que hay un usuario de consola presente.
Otro mensaje: se muestra literalmente la causa del fallo de conexión (autenticación denegada, host inalcanzable, tiempo de espera agotado). Diagnostique con php artisan infr:collect-db --key=<key> --force.

QPS, tasa de consultas lentas o puntuaciones de eficiencia muestran "—"

Los valores derivados se calculan como un delta respecto a la muestra correcta anterior. En la primera muestra, tras reiniciar la BD (uptime disminuyó → contador reiniciado) o cuando un contador retrocede, el valor no es fiable y se deja en null (—). Aparece con normalidad a partir de la segunda muestra.

Las consultas en espera muestran "solo la propia conexión"

La cuenta de monitorización carece del privilegio global PROCESS, así que en information_schema.processlist solo son visibles sus propias conexiones. Conceda PROCESS con el SQL de Para ver las consultas en espera de todo el servidor (efecto en una hora, cuando caduque la caché de alcance).

La sección de gestión de memoria o de checkpoint está vacía

La gestión de memoria requiere innodb_buffer_pool_pages_total (oculta en muestras antiguas).
La edad del checkpoint se analiza a partir de SHOW ENGINE INNODB STATUS (→ necesita PROCESS). Sin el privilegio, la línea de checkpoint y su anotación se omiten con elegancia.

El análisis del esquema parpadea vacío y luego aparece

analysisCached es una búsqueda solo en caché. En la primera entrada la caché está vacía y la sección se oculta; una vez que el planificador la calienta, aparece en el siguiente sondeo de 30 segundos. Los fallos se cachean solo 30 s (los aciertos, 30 minutos), de modo que un error transitorio no queda fijado mucho tiempo.

Relacionado

Formación sobre carga y ajuste de BD: trasfondo de los popovers de lock · cache · index · checkpoint.
Recolectores: registro de recolectores access=database, secretos, cred_ref.
Política de operaciones: modo de recolección · intervalo · umbrales de degradación.
Sesiones (Redis): la pantalla hermana que aplica la misma metodología a Redis.
Resumen de servicio: donde se resumen las tarjetas de BD en el panel de servicios en vivo.
Canalización del recolector de BD: comando de recolección y disciplina contra fugas de conexiones.