El monitoreo estándar ofrece una vista unificada del estado de su instancia de RDS for MySQL. Integra Performance Trend y proporciona gráficos de tendencias de rendimiento, detección automática de anomalías, análisis de causa raíz y cinco vistas de diagnóstico especializadas para los problemas más comunes de bases de datos.
Funciones del monitoreo estándar
|
Capability |
Description |
|
Métricas de rendimiento |
Amplia variedad de métricas con vistas personalizadas; seleccione las métricas que desea rastrear |
|
Vistas de diagnóstico |
Cinco vistas predefinidas para OOM de memoria, retraso en instancias de solo lectura, espacio en disco lleno, fluctuación de CPU y transacciones grandes |
|
Diagnóstico automático |
Detecta eventos en su instancia y proporciona un análisis de causa raíz con acciones recomendadas |
|
Diagnóstico manual |
Seleccione cualquier intervalo de tiempo para activar un diagnóstico bajo demanda |
Para obtener detalles sobre los parámetros de rendimiento de cada métrica, consulte Performance Parameter Table.
Consulta de datos de monitoreo estándar
Inicie sesión en la consola de ApsaraDB RDS y vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside su instancia, localice la instancia y haga clic en su ID.
En el panel de navegación izquierdo, haga clic en Monitoring and Alerts.
En la página Standard Monitoring, seleccione Standard View o Custom View.
Vista estándar
La pestaña Standard View muestra Performance Events y Performance Metrics para un intervalo de tiempo seleccionado.
El intervalo de tiempo no puede abarcar más de 7 días. Puede consultar datos de los últimos 30 días.
Consulta de eventos de rendimiento
El área de estadísticas de eventos muestra el recuento de eventos por tipo dentro del intervalo de tiempo seleccionado. Haga clic en View Details para abrir la página View Performance Events, donde podrá ver actividades anómalas y eventos de optimización (programados, en curso o completados).
Consulta de métricas de rendimiento
En la vista predeterminada Classic View:
Haga clic en More Metrics para seleccionar métricas adicionales y consultar sus tendencias de rendimiento.
Haga clic en
junto al nombre de una métrica para ver qué submétricas contiene.
Haga clic en Details en cualquier gráfico de tendencias para ampliarlo y ajustar el intervalo de tiempo.
Haga clic en Add Trend Comparison para comparar la misma métrica en diferentes periodos de tiempo.
Análisis de eventos en gráficos de métricas
En la vista Classic View, seleccione un nivel de evento para superponer los eventos correspondientes en los gráficos de tendencias de MySQL CPU/Memory Utilization y Session Connections. Haga clic en cualquier marcador de evento para consultar su resultado de diagnóstico.
Ejecución de diagnóstico en un intervalo de tiempo
En cualquier gráfico de tendencias de métricas, arrastre el cursor para seleccionar un intervalo de tiempo y luego haga clic en Diagnose para obtener un análisis detallado de la causa raíz de ese periodo.
Uso de vistas de diagnóstico
Haga clic en cualquiera de las cinco vistas de diagnóstico para investigar un tipo específico de problema:
Memory OOM Diagnosis
Read-only Instance Delay Diagnosis
Full Disk Space Diagnosis
CPU Jitter Diagnosis
Large Transaction Recognition Diagnosis
Para interpretar las métricas y conocer los siguientes pasos de cada vista, consulte Diagnostic views.
Vista personalizada
En la pestaña Custom View, haga clic en Add Monitoring Dashboard para crear un panel con las métricas que le interesan. Para obtener detalles sobre los parámetros de cada métrica, consulte Performance Parameter Table.
Haga clic en Add Node And Metric Monitoring para seleccionar nodos y métricas.
-
Elija cómo se muestran las métricas:
Merged Display: Todas las métricas seleccionadas aparecen en un solo gráfico de tendencias.
Separate Display: Cada métrica aparece en su propio gráfico. Use Chart Layout para establecer cuántos gráficos aparecen por fila. Haga clic en Details en cualquier gráfico para ampliarlo y ajustar el intervalo de tiempo.
Para volver a la versión anterior de monitoreo, haga clic en Old Version en la esquina superior derecha de la página Standard Monitoring.
Vistas de diagnóstico
Diagnóstico de OOM de memoria
La vista Memory OOM Diagnosis le ayuda a analizar problemas de falta de memoria (OOM). Métricas clave y lo que indican:
Memory Usage — interprete la tendencia en relación con el uso del InnoDB Buffer Pool:
|
Pattern |
Likely cause |
|
InnoDB Buffer Pool sin cambios; la memoria aumenta lentamente durante varios días (por ejemplo, más de 7 días) |
Fuga de memoria |
|
La memoria tiene picos repentinos; InnoDB Buffer Pool sin cambios |
Pico de tráfico |
|
Tanto la memoria como el InnoDB Buffer Pool aumentan gradualmente |
El Buffer Pool se está llenando (comportamiento normal) |
Resident Memory muestra la cantidad de memoria física en uso. Open files, Temp File Size, Temp Disk Tables y Sort Rows son indicadores comunes de presión sobre la memoria.
Dado que los eventos OOM suelen finalizar los procesos que causaron el pico, resulta difícil identificar la sentencia SQL exacta después del hecho. Para prepararse:
Revise los registros del negocio cuando ocurran picos de memoria para rastrear la causa.
Actualice las especificaciones de memoria y habilite SQL Explorer and Audit para que, al producirse un pico, pueda revisar los tiempos de ejecución de consultas e identificar la causa.
Diagnóstico de retraso en instancias de solo lectura
La vista Read-only Instance Delay Diagnosis ayuda a diagnosticar el retraso de replicación en instancias de solo lectura. Métricas clave:
Active Session: Indica bloqueo por metadata lock. Las consultas que escanean grandes volúmenes de datos impiden que las sentencias DDL adquieran bloqueos de metadatos, lo que provoca que el DDL bloquee otras sesiones y se acumulen conexiones.
DML Rows Processed, Pages Requested, DML/DDL Operations, Temp Disk Space Used: Métricas comunes de carga de trabajo del negocio.
Replication Delay: El principal indicador de latencia.
Diagnóstico de espacio en disco lleno
La vista Full Disk Space Diagnosis muestra qué tipos de archivos consumen almacenamiento y cómo cambian sus tamaños con el tiempo. Se rastrean las siguientes categorías de almacenamiento:
Archivos de datos (
user_data_size): Use Space Analysis para identificar el uso de espacio por base de datos y tabla; luego escale horizontalmente o elimine datos innecesarios. Consulte Solutions for a full instance caused by data files.Archivos temporales (
temp_file_size): Se generan durante operaciones SQL de ordenamiento, agrupación y unión, así como archivos de caché de registro binario antes de que se confirmen transacciones grandes. Consulte Resolve full instance storage caused by temporary files.Registros binarios (
binlog_size): Las transacciones grandes pueden generar registros binarios rápidamente. Si sus servicios están suscritos a los registros binarios de la instancia, es posible que estos no se limpien de inmediato. Consulte Resolve full instance storage caused by binary log files.-
Registros de deshacer (
undo_log_size): Las consultas de larga duración impiden que se purguen los registros de deshacer. Compruebe si hay consultas que llevan mucho tiempo ejecutándose sin completarse.NotaEn MySQL 5.6 y versiones anteriores, los registros de deshacer no tienen un tablespace separado.
-
Registro de consultas lentas (
slowlog_size): Ejecute el comandotruncatefuera de horas pico para limpiar el registro de consultas lentas si consume demasiado espacio.NotaLa compatibilidad con el comando
truncatese agregó en MySQL 5.7 versión 20210630 y MySQL 8.0 versión 20210930. -
Registros generales (
general_log_size): Tamaño combinado de los registros de errores, Performance Agent y recuperación de la instancia. Este valor suele ser estable y menor a 1 GB. Si supera significativamente este umbral, envíe un ticket para contactar al equipo del producto.Notageneral_log_sizerepresenta datos generados periódicamente por el kernel de MySQL, no el tamaño del archivogeneral_logde MySQL.
Diagnóstico de fluctuación de CPU
La vista CPU Jitter Diagnosis le ayuda a identificar por qué fluctúa la utilización de CPU. Rastree estas métricas:
Métricas de negocio:
Page Request: Las solicitudes al Buffer Pool suelen fluctuar en sincronía con la utilización de CPU.
Rows Processed: Compare con la utilización de CPU para determinar si los cambios en el volumen de filas se correlacionan con los picos de CPU.
Queries: Identifique los tipos de sentencias SQL ejecutados durante los cambios en la utilización de CPU.
Conexiones:
Thread Running: Una alta concurrencia eleva la utilización de CPU. La acumulación de MDL y los bloqueos de fila también pueden provocar una acumulación de conexiones, lo que incrementa la carga de CPU.
Causas comunes y siguientes pasos:
Si Page Request o Rows Processed cambiaron cuando hubo un pico de CPU, arrastre el cursor para seleccionar el intervalo de tiempo afectado y haga clic en Diagnose para obtener un análisis detallado de la causa raíz.
Si aumentaron las conexiones activas, investigue desde el lado de la aplicación para determinar qué provocó el incremento de conexiones.
Diagnóstico de transacciones grandes
La vista Large Transaction Recognition Diagnosis ayuda a identificar transacciones grandes y su impacto. Tres métricas principales señalan una transacción grande:
|
Signal |
Core metric |
|
Acumulación de sesiones activas |
Threads Connected |
|
El espacio temporal sube y luego baja |
Temp File Size |
|
Tras disminuir el espacio temporal, aumenta el espacio de registros binarios |
Binlog Space |
Rows Processed, Logical Page Write y Queries per Second indican el tipo de transacción. Por ejemplo, pocas consultas combinadas con un alto recuento de filas eliminadas apuntan a una operación DELETE grande.
Cómo afectan las transacciones grandes a la instancia:
Mientras se ejecuta la transacción grande, el tablespace temporal (caché de registro binario) aumenta gradualmente y luego se estabiliza.
Una vez que el tablespace temporal se estabiliza, aumenta el espacio de registros binarios. Dado que las escrituras de registros binarios son globales y secuenciales, otras transacciones se bloquean y se acumulan conexiones.
En instancias High-availability Edition, las sentencias de sondeo del componente HA en las instancias primaria y secundaria también se bloquean, y ocurre un failover entre primaria y secundaria.
Para evitar estos problemas, divida las transacciones grandes en otras más pequeñas. Para sentencias DELETE, agregue una cláusula WHERE que limite cuántas filas se eliminan por operación, convirtiendo una sola eliminación grande en varias eliminaciones más pequeñas.
Funciones
La función actualizada Standard Monitoring en RDS for MySQL integra Performance Trend y proporciona más funciones.
-
Vistas personalizadas: La función de monitoreo estándar ofrece una amplia gama de métricas de rendimiento y admite vistas personalizadas. Puede seleccionar las métricas que desea monitorear.
NotaPara obtener más información sobre los parámetros de rendimiento de cada métrica, consulte Performance Parameter Table.
Vistas de diagnóstico para problemas comunes: El servicio proporciona varias vistas de diagnóstico que puede usar para identificar problemas rápidamente. Estas vistas incluyen Memory OOM Diagnosis, Read-only Instance Delay Diagnosis, Full Storage Diagnosis, CPU Jitter Diagnosis y Large Transaction Recognition Diagnosis.
Diagnóstico automático: La función de monitoreo estándar detecta eventos en su instancia de base de datos, realiza diagnósticos automáticos y proporciona análisis de causa raíz y sugerencias.
Diagnóstico manual: Puede seleccionar un intervalo de tiempo para realizar un diagnóstico manual.
Consulta de datos de monitoreo estándar
Inicie sesión en la consola de ApsaraDB RDS y vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside la instancia RDS. Luego, localice la instancia RDS y haga clic en su ID.
En el panel de navegación izquierdo, haga clic en Monitoring and Alerts.
-
En la página Standard Monitoring, seleccione Standard View o Custom View.
Standard View
En la pestaña Standard View, puede seleccionar un intervalo de tiempo para consultar Performance Events y Performance Metrics del periodo seleccionado.
NotaAl seleccionar un intervalo de tiempo, el lapso entre la hora de inicio y la de fin no puede exceder los 7 días. Puede consultar datos de los últimos 30 días.
-
Consultar eventos de rendimiento
En el área de estadísticas de eventos, puede consultar información estadística de diversos tipos de eventos dentro del intervalo de tiempo seleccionado. Haga clic en View Details para abrir la página View Performance Events, donde podrá consultar información detallada sobre actividades anómalas de la instancia y eventos de optimización, incluidos eventos programados, en curso o completados.
-
Consultar métricas de rendimiento
-
Consultar métricas
En la vista predeterminada Classic View, puede consultar métricas de monitoreo para un intervalo de tiempo seleccionado.
Haga clic en More Metrics y seleccione las métricas para consultar sus tendencias de rendimiento.
Puede hacer clic en
después de cada métrica para ver las métricas que contiene.Haga clic en Details en un gráfico de tendencias de métricas para ampliarlo y ajustar el intervalo de tiempo.
Haga clic en Add Trend Comparison para comparar las tendencias de rendimiento de la misma métrica en diferentes periodos de tiempo.
-
Consultar análisis de eventos
En la vista predeterminada Classic View, al seleccionar un nivel de evento se muestran los eventos correspondientes en los gráficos de tendencias de MySQL CPU/Memory Utilization y Session Connections.
Puede hacer clic en un evento dentro de un gráfico de tendencias para consultar el resultado del diagnóstico en los detalles del evento.
-
Diagnosticar y analizar métricas
En cualquier gráfico de tendencias de métricas, puede seleccionar un intervalo de tiempo para ejecutar Diagnose arrastrando el mouse.
-
Consultar vistas de diagnóstico para problemas comunes
Puede usar las siguientes vistas de diagnóstico para identificar rápidamente la causa raíz de los problemas: Memory OOM Diagnosis, Read-only Instance Delay Diagnosis, Full Disk Space Diagnosis, CPU Jitter Diagnosis y Large Transaction Recognition Diagnosis. Para obtener más información, consulte Using Diagnostic Views.
-
Custom View
En la pestaña Custom View, haga clic en Add Monitoring Dashboard para consultar las tendencias de las métricas que desea monitorear. Para obtener más información sobre los parámetros de rendimiento de cada métrica, consulte Performance Parameter Table.
Haga clic en Add Node And Metric Monitoring para seleccionar nodos y métricas que agregar al panel.
-
Puede elegir cómo se muestran las métricas: Merged Display o Separate Display.
Merged View: Muestra múltiples métricas en un solo gráfico de tendencias.
-
Separate Display: Muestra cada métrica en un gráfico de tendencias separado.
Puede usar Chart Layout para establecer cuántos gráficos de tendencias de métricas se muestran por fila.
Haga clic en Details en un gráfico de tendencias de métricas para ampliarlo y ajustar el intervalo de tiempo.
-
En la página Standard Monitoring, haga clic en el botón Old Version en la esquina superior derecha para volver a the previous monitoring version.
Uso de vistas de diagnóstico
Diagnóstico de OOM de memoria
Utilice la vista Memory OOM Diagnosis para analizar problemas de falta de memoria (OOM).
-
Memory Usage:
Si el uso del InnoDB Buffer Pool se mantiene sin cambios mientras que el uso de memoria aumenta lenta y continuamente durante un periodo prolongado, como más de siete días, es posible que exista una fuga de memoria.
Si el uso de memoria aumenta repentinamente mientras el uso del InnoDB Buffer Pool permanece constante, el incremento podría deberse a picos de tráfico.
Si tanto el uso de memoria como el del InnoDB Buffer Pool aumentan, significa que el InnoDB Buffer Pool se está llenando gradualmente, lo cual es un comportamiento normal.
Resident Memory: Cantidad de memoria física utilizada.
Open files, Temp File Size, Temp Disk Tables y Sort Rows son métricas comunes que indican el consumo de memoria.
El crecimiento de la memoria está relacionado con las métricas de negocio. Las sentencias SQL que provocan picos repentinos de memoria suelen ser difíciles de rastrear debido al OOM. Por lo tanto, se recomienda:
Revisar los registros de negocio para determinar la causa del aumento repentino de memoria.
Actualizar las especificaciones de memoria y habilitar SQL Explorer and Audit. Si ocurre un pico repentino de memoria, consulte el tiempo de ejecución de las consultas SQL para identificar la causa.
Diagnóstico de latencia en instancias de solo lectura
Utilice la vista Read-only Instance Delay Diagnosis para diagnosticar retrasos en instancias de solo lectura.
-
Active Session: Compruebe si existen bloqueos por metadata locks.
Por lo general, las consultas sobre grandes volúmenes de datos impiden que las sentencias DDL obtengan metadata locks. En este caso, las sentencias DDL bloquean otras sesiones, lo que provoca la acumulación de conexiones.
DML Rows Processed, Pages Requested, DML/DDL Operations y Temp Disk Space Used: Muestran métricas comunes de negocio.
Replication Delay: Métrica de latencia.
Diagnóstico de espacio de almacenamiento lleno
Utilice la vista Diagnosis Of Space Full Problem para analizar problemas de espacio insuficiente.
Consulte los tipos de archivos que ocupan el espacio de almacenamiento de la instancia y sus tendencias de cambio. Las siguientes métricas suelen estar asociadas con el uso de almacenamiento:
Archivos de datos (user_data_size): Utilice Space Analysis para consultar el uso de espacio de cada base de datos y tabla; posteriormente, escale o elimine los datos innecesarios. Para obtener más información, consulte Solutions for a Full Instance Caused by Data Files.
Archivos temporales (temp_file_size): Es posible que se generen tablas temporales al ejecutar sentencias SQL para ordenar y agrupar datos o asociar tablas. Los archivos de caché de registros binarios se generan antes de confirmar transacciones grandes. Estas tablas y archivos ocupan espacio de almacenamiento. Para obtener más información, consulte Resolve full instance storage caused by temporary files.
-
Registros binarios (binlog_size): Las transacciones grandes pueden generar registros binarios rápidamente. Estos registros ocupan espacio de almacenamiento. Para obtener más información sobre cómo gestionar los registros binarios, consulte Resolve full instance storage caused by MySQL binary log files.
NotaSi sus servicios están suscritos a los registros binarios de la base de datos, es posible que los registros no se limpien oportunamente y ocupen espacio.
-
Registros de deshacer (undo_log_size): En la mayoría de los casos, las consultas de larga duración impiden que se limpien los registros de deshacer. Compruebe si existen consultas de larga duración que no se hayan completado.
NotaEn MySQL 5.6 y versiones anteriores, los registros de deshacer no tienen un tablespace separado.
-
Registro de consultas lentas (slowlog_size): Si el registro de consultas lentas utiliza demasiado espacio, utilice el comando
truncatepara limpiarlo durante las horas de menor actividad.NotaLa compatibilidad con el comando
truncatese agregó en la versión 20210630 de MySQL 5.7 y en la versión 20210930 de MySQL 8.0. Registros generales (general_log_size): Tamaño total de los registros de errores, de Performance Agent y de recuperación de una instancia, que suele ser estable y menor a 1 GB. Si el tamaño supera significativamente este valor, envíe un ticket para ponerse en contacto con el equipo del producto. Esta métrica representa datos generados periódicamente por el kernel de MySQL, no el tamaño del archivo general_log en MySQL.
Diagnóstico de fluctuación de CPU
Utilice la vista CPU Jitter Diagnostics para analizar problemas de fluctuación de CPU. Las métricas relevantes incluyen:
-
Métricas de negocio:
Page Request: Por lo general, las solicitudes al Buffer Pool fluctúan en sincronía con la utilización de la CPU.
Rows Processed: Examine la relación entre la utilización de la CPU y el número de filas procesadas para determinar si un pico en el número de filas corresponde a un cambio en la utilización de la CPU.
Queries: Consulte los principales tipos de sentencias SQL que se ejecutan cuando cambia la utilización de la CPU.
-
Conexiones:
Thread Running: Una alta concurrencia puede provocar una elevada utilización de la CPU. La acumulación de MDL o los bloqueos de fila también pueden causar una acumulación de conexiones, lo que incrementa la utilización de la CPU.
Causas comunes de la fluctuación de CPU:
Los cambios en las métricas de negocio, como Page Request o Rows Processed, pueden afectar la utilización de la CPU. Si esto ocurre, seleccione el intervalo de tiempo del cambio en la utilización de la CPU y ejecute Diagnosis para obtener un análisis detallado de la causa raíz.
Un aumento en las conexiones activas provoca consumo de CPU. En este caso, debe investigar el problema desde el lado del negocio.
Diagnóstico de transacciones grandes
Utilice la vista Large Transaction Recognition Diagnosis para analizar problemas de transacciones grandes.
-
Threads Connected, Temp File Size y Binlog Space: Son las tres métricas principales que indican una transacción grande. Existe una transacción grande en la base de datos si ocurre alguno de los siguientes eventos:
Se acumulan sesiones activas.
El espacio temporal primero aumenta y luego disminuye.
Después de que disminuye el espacio temporal, aumenta el espacio de Binlog.
-
Rows Processed, Logical Page Write y Queries per Second: Estas métricas se utilizan para determinar el tipo de transacción grande.
Por ejemplo, si hay pocas consultas pero se eliminan muchas filas, indica una transacción grande que elimina datos.
Las transacciones grandes pueden bloquear las escrituras de registros binarios:
Cuando una instancia tiene una transacción grande, el tablespace temporal (caché de binlog) primero aumenta gradualmente y luego se estabiliza.
Cuando el tablespace temporal se estabiliza, aumenta el espacio de Binlog. Dado que la escritura de registros binarios es serial a nivel global, otras transacciones se bloquean, lo que provoca la acumulación de conexiones.
Si la instancia ejecuta RDS High-availability Edition, las sentencias de sondeo del componente de alta disponibilidad (HA) en las instancias principal y secundaria también se bloquean, y se produce un failover principal/secundario.
Se recomienda dividir las transacciones grandes en transacciones pequeñas y ejecutarlas por separado. Por ejemplo, en una sentencia delete, agregue una cláusula where para limitar la cantidad de datos que se eliminan en cada operación, dividiendo así una sola operación de eliminación en varias operaciones más pequeñas.
Referencia de API
|
API |
Description |
|
Consulta los datos de rendimiento de una instancia RDS |
Pasos siguientes
Troubleshoot slow SQL statements on an ApsaraDB RDS for MySQL instance
Troubleshoot memory consumption issues on an ApsaraDB RDS for MySQL instance
Solución de problemas de almacenamiento insuficiente en una instancia de ApsaraDB RDS for MySQL
Troubleshoot high I/O issues on an ApsaraDB RDS for MySQL instance
Causes and solutions for high IOPS usage on an RDS for MySQL instance
Apéndice: Monitoreo heredado
Descripción general de métricas en el monitoreo heredado
Consulta de datos de monitoreo heredado
Inicie sesión en la consola de ApsaraDB RDS y vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside su instancia, busque la instancia y haga clic en su ID.
En el panel de navegación izquierdo, haga clic en Monitoring and Alerts.
En la pestaña Standard Monitoring, haga clic en Old Version.
Seleccione Resource Monitoring, Engine Monitoring o Deployment Monitoring, y luego establezca un intervalo de tiempo para consultar los datos. Para instancias Cluster Edition, también puede filtrar por ID de instancia o nodo. Puede consultar datos de los últimos 30 días.