sql >> Base de Datos >  >> RDS >> Mysql

Monitoreo efectivo de MySQL con SCUMM Dashboards:primera parte

Agregamos varios paneles nuevos para MySQL en nuestra última versión de ClusterControl 1.7.0. - y en nuestro blog anterior, le mostramos cómo monitorear su ProxySQL con Prometheus y ClusterControl.

En este blog, veremos el panel de información general de MySQL.

Por lo tanto, hemos habilitado el Monitoreo basado en agentes en la pestaña Panel para comenzar a recopilar métricas para los nodos. Tenga en cuenta que al habilitar el Monitoreo basado en agentes, tiene las opciones para configurar el “Intervalo de raspado (segundos) ” y “Retención de datos (días) ”. Scraping Interval es donde desea establecer la agresividad con la que Prometheus recolectará datos del objetivo y Data Retention es cuánto tiempo desea mantener sus datos recopilados por Prometheus antes de que se eliminen.

Cuando está habilitado, puede identificar qué clúster tiene agentes y cuál tiene monitoreo sin agente.

En comparación con el enfoque sin agentes, la granularidad de sus datos en los gráficos será mayor con los agentes.

Los gráficos de MySQL

La última versión de ClusterControl 1.7.0 (que puede descargar de forma gratuita - ClusterControl Community) tiene los siguientes paneles MySQL para los que puede recopilar información para sus servidores MySQL. Estos son MySQL Overview, MySQL InnoDB Metrics, MySQL Performance Schema y MySQL Replication.

Cubriremos en detalle los gráficos disponibles en el panel de información general de MySQL.

Panel de información general de MySQL

Este tablero contiene las variables importantes habituales o información sobre el estado de su nodo MySQL. Los gráficos contenidos en este tablero son específicos para el nodo seleccionado al ver los tableros como se ve a continuación:

Consta de 26 gráficos, pero es posible que no los necesite todos al diagnosticar problemas. Sin embargo, estos gráficos proporcionan una representación vital de las métricas generales de sus servidores MySQL. Repasemos las básicas, ya que estas son probablemente las cosas más comunes que un DBA revisará de forma rutinaria.

Los primeros cuatro gráficos que se muestran arriba junto con el tiempo de actividad de MySQL, las consultas por segundo y la información del grupo de búfer son los indicadores más básicos que podríamos necesitar. De los gráficos que se muestran arriba, aquí están sus representaciones:

  • Conexiones MySQL
    Aquí es donde desea verificar el total de conexiones de clientes asignadas hasta el momento en un período de tiempo específico.
  • Actividad del subproceso del cliente MySQL
    Hay momentos en que su servidor MySQL podría estar muy ocupado. Por ejemplo, se puede esperar que reciba un aumento en el tráfico en un momento específico y desea monitorear la actividad de sus subprocesos en ejecución. Este gráfico es realmente importante para mirar. Puede haber ocasiones en las que el rendimiento de su consulta pueda empeorar si, por ejemplo, una actualización grande hace que otros subprocesos esperen para adquirir el bloqueo. Esto conduciría a un mayor número de subprocesos en ejecución. La tasa de errores de caché se calcula como Threads_created/Connections.
  • Preguntas de MySQL
    Estas son las consultas que se ejecutan en un período de tiempo específico. Un hilo puede ser una transacción compuesta por múltiples consultas y este puede ser un buen gráfico para observar.
  • Caché de subprocesos de MySQL
    Este gráfico muestra el valor thread_cache_size, los subprocesos que se almacenan en caché (subprocesos que se reutilizan) y los subprocesos que se crean (subprocesos nuevos). Puede verificar en este gráfico para instancias tales como si necesita ajustar sus consultas de lectura cuando nota una gran cantidad de conexiones entrantes y sus hilos creados aumentan rápidamente. Por ejemplo, si Threads_running / thread_cache_size> 2, aumentar su thread_cache_size puede aumentar el rendimiento de su servidor. Tenga en cuenta que la creación y destrucción de subprocesos son costosas. Sin embargo, en las versiones recientes de MySQL (>=5.6.8), esta variable tiene un tamaño automático predeterminado, por lo que podría considerarla intacta.

Los cuatro gráficos siguientes son Objetos temporales de MySQL, Tipos de selección de MySQL, Ordenaciones de MySQL y Consultas lentas de MySQL. Estos gráficos están relacionados entre sí, especialmente si está diagnosticando consultas de ejecución prolongada y consultas grandes que necesitan optimización.

  • Objetos temporales de MySQL
    Este gráfico sería una buena fuente en la que confiar si desea monitorear consultas de ejecución prolongada que terminarían usando el disco en lugar de tablas temporales o archivos en la memoria. Es un buen lugar para comenzar a buscar la aparición periódica de consultas que podrían sumarse para crear problemas de espacio en disco, especialmente en momentos extraños.
  • Selección de tipos de MySQL
    Una fuente de mal rendimiento son las consultas que usan uniones completas, exploraciones de tablas, rango seleccionado que no usa ningún índice. Este gráfico mostraría el rendimiento de su consulta y qué elementos de la lista, desde uniones completas hasta uniones de rango completo, rango seleccionado, exploraciones de tablas, tienen las tendencias más altas.
  • Ordenaciones de MySQL
    Diagnosticar las consultas que utilizan la ordenación y las que tardan mucho tiempo en finalizar.
  • Consultas lentas de MySQL
    Las tendencias de sus consultas lentas se recopilan aquí en este gráfico. Esto es muy útil, especialmente para diagnosticar con qué frecuencia sus consultas son lentas. ¿Cuáles son las cosas que necesitan ser afinadas? Podría ser un grupo de búfer demasiado pequeño, tablas que carecen de índices y realizan un escaneo de tabla completa, copias de seguridad lógicas que se ejecutan en un horario inesperado, etc. El uso de nuestro Query Monitor en ClusterControl junto con este gráfico es beneficioso, ya que ayuda a determinar las consultas lentas.

Los siguientes gráficos que cubrimos son más sobre la actividad de la red, los bloqueos de tablas y la memoria interna subyacente que consume MySQL durante la actividad de MySQL.

  • Conexiones anuladas de MySQL
    El número de conexiones anuladas aparecerá en este gráfico. Esto cubre los clientes abortados, como cuando la red se cerró abruptamente o donde la conexión a Internet se cayó o se interrumpió. También registra las conexiones abortadas o los intentos, como contraseñas incorrectas o paquetes defectuosos al establecer una conexión desde el cliente.
  • Bloqueos de tabla MySQL
    Tendencias para tablas que solicitan un bloqueo de mesa que se ha otorgado de inmediato y para tablas que solicitan un bloqueo que no se ha adquirido de inmediato. Por ejemplo, si tiene bloqueos a nivel de tabla en tablas MyISAM y solicitudes entrantes de la misma tabla, estos no se pueden otorgar de inmediato.
  • Tráfico de red MySQL
    Este gráfico muestra las tendencias de la actividad de red entrante y saliente en el servidor MySQL. "Entrante" son los datos recibidos por el servidor MySQL, mientras que "Salientes" son los datos enviados o transferidos por el servidor desde el servidor MySQL. Este gráfico es el mejor para verificar si desea monitorear el tráfico de su red, especialmente al diagnosticar si su tráfico es moderado, pero se pregunta por qué tiene una transferencia de datos salientes muy alta, como por ejemplo, datos BLOB.
  • Uso de la red MySQL por hora
    Igual que el tráfico de red que muestra los datos recibidos y enviados. Tenga en cuenta que se basa en "por hora" y está etiquetado como "último día", que no seguirá el período de tiempo que seleccionó en el selector de fechas.
  • Descripción general de la memoria interna de MySQL
    Este gráfico es familiar para un administrador de bases de datos MySQL experimentado. Cada una de estas leyendas en el gráfico de barras es muy importante, especialmente si desea controlar el uso de la memoria, el uso del grupo de búfer o el tamaño del índice hash adaptativo.

Los siguientes gráficos muestran los contadores en los que puede confiar un DBA, como comprobar las estadísticas, por ejemplo, las estadísticas de selecciones, inserciones, actualizaciones, el número de estado maestro que se ha ejecutado, el número de MOSTRAR VARIABLES que se ha ejecutado, comprobar si tiene consultas incorrectas al hacer escaneos de tablas o tablas que no usan índices al revisar los contadores read_*, etc.


  • Contadores de comandos superiores (por hora)
    Estos son los gráficos que probablemente tendría que revisar cada vez que desee ver las estadísticas de sus inserciones, eliminaciones, actualizaciones, comandos ejecutados como la recopilación de la lista de procesos, el estado del esclavo, mostrar el estado (estadísticas de salud del servidor MySQL ), y muchos más. Este es un buen lugar si desea verificar qué tipo de contadores de comandos de MySQL son los más importantes y si se necesita algún ajuste de rendimiento u optimización de consultas. También podría permitirle identificar qué comandos se ejecutan agresivamente sin necesitarlos.
  • Manejadores MySQL
    A menudo, un DBA revisaría estos controladores y comprobaría el rendimiento de las consultas en su servidor MySQL. Básicamente, este gráfico cubre los contadores de la API Handler de MySQL. Los contadores de controlador más comunes para un DBA para la API de almacenamiento en MySQL son Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd y Handler_read_rnd_next. Hay muchos controladores de MySQL para verificar. Puede leer sobre ellos en la documentación aquí.
  • Controladores de transacciones MySQL
    Si su servidor MySQL utiliza transacciones XA, declaraciones SAVEPOINT, ROLLBACK TO SAVEPOINT. Entonces este gráfico es una buena referencia para mirar. También puede usar este gráfico para monitorear todas las confirmaciones internas de su servidor. Tenga en cuenta que el contador de Handler_commit se incrementa incluso para las sentencias SELECT pero difiere de las sentencias de inserción/actualización/eliminación que van al registro binario durante una llamada a la sentencia COMMIT.

El siguiente gráfico mostrará las tendencias sobre los estados del proceso y su uso por hora. Hay muchos puntos clave aquí en la leyenda del gráfico de barras que un DBA verificaría. Encontrar problemas de espacio en disco, problemas de conexión y ver si su conjunto de conexiones funciona como se esperaba, alta E/S de disco, problemas de red, etc.

  • Estados del proceso/Estados principales del proceso por hora
    Este gráfico es donde puede monitorear los estados de subprocesos principales de sus consultas que se ejecutan en la lista de procesos. Esto es muy informativo y útil para tales tareas de DBA donde puede examinar aquí cualquier estado pendiente que necesite resolución. Por ejemplo, mesas de apertura estado es muy alto y su valor mínimo está casi cerca del valor máximo. Esto podría indicar que necesita ajustar table_open_cache. Si las estadísticas es alto y está notando una ralentización de su servidor, esto podría indicar que su servidor está vinculado al disco y es posible que deba considerar aumentar su grupo de búfer. Si tiene una gran cantidad de creación de la tabla tmp entonces es posible que deba verificar su registro lento y optimizar las consultas ofensivas. Puede consultar el manual para ver la lista completa de estados de subprocesos de MySQL aquí.

El siguiente gráfico que revisaremos es sobre el caché de consultas, el caché de definición de tabla de MySQL, la frecuencia con la que MySQL abre archivos del sistema.


  • Actividad/memoria caché de consulta de MySQL
    Estos gráficos están relacionados entre sí. Si tiene query_cache_size <> 0 y query_cache_type <> 0, entonces este gráfico puede ser de ayuda. Sin embargo, en las versiones más recientes de MySQL, la caché de consultas se ha marcado como obsoleta, ya que se sabe que la caché de consultas de MySQL causa problemas de rendimiento. Es posible que no necesite esto en el futuro. La versión más reciente de MySQL 8.0 tiene mejoras drásticas; tiende a aumentar el rendimiento ya que viene con varias estrategias para manejar la información de caché en los búferes de memoria.
  • Aperturas de archivos MySQL
    Este gráfico muestra la tendencia de los archivos abiertos desde el tiempo de actividad del servidor MySQL, pero excluye archivos como sockets o tuberías. Tampoco incluye los archivos que abre el motor de almacenamiento, ya que tienen su propio contador, que es Innodb_num_open_files.
  • Archivos abiertos de MySQL
    Este gráfico es donde desea verificar sus archivos InnoDB actualmente abiertos, los archivos abiertos actuales de MySQL y su variable open_files_limit.
  • Estado de caché abierto de tabla MySQL
    Si tiene una configuración table_open_cache muy baja aquí, este gráfico le informará acerca de las tablas que fallan en el caché (tablas recién abiertas) o no se encuentran debido a un desbordamiento. Si encuentra un número alto o demasiado estado de "Tablas abiertas" en su lista de procesos, este gráfico le servirá como referencia para determinarlo. Esto le dirá si es necesario aumentar su variable table_open_cache.
  • Tablas abiertas de MySQL
    En relación con el estado de caché abierto de la tabla MySQL, este gráfico es útil en ciertas ocasiones, como cuando desea identificar si es necesario aumentar su table_open_cache o reducirlo si nota un gran aumento de tablas abiertas o la variable de estado de Open_tables. . Tenga en cuenta que table_open_cache podría ocupar una gran cantidad de espacio de memoria, por lo que debe configurar esto con cuidado, especialmente en los sistemas de producción.
  • Caché de definición de tablas de MySQL
    Si desea verificar el número de sus variables de estado Open_table_definitions y Opened_table_definitions, entonces este gráfico es lo que necesita. Para las versiones más nuevas de MySQL (>=5.6.8), es posible que no necesite cambiar el valor de esta variable y usar el valor predeterminado ya que tiene la función de tamaño automático.

Conclusión

La adición de SCUMM en la última versión de ClusterControl 1.7.0 proporciona nuevos beneficios significativos para varias tareas clave de DBA. Los nuevos gráficos pueden ayudar a identificar fácilmente la causa de los problemas que los DBA o los administradores de sistemas normalmente tendrían que tratar y ayudar a encontrar las soluciones adecuadas más rápido.

Nos encantaría escuchar su experiencia y opiniones sobre el uso de ClusterControl 1.7.0 con SCUMM (que puede descargar de forma gratuita - ClusterControl Community).

En la parte 2 de este blog, hablaré sobre el monitoreo efectivo de la replicación de MySQL con paneles SCUMM.