ClusterControl 1.7.0 presenta una característica nueva y audaz:la integración con Prometheus para el monitoreo basado en agentes. Llamamos a esto SCUMM (Severalnines ClusterControl Unified Management and Monitoring). En las versiones anteriores, las tareas de monitoreo se realizaban únicamente sin agentes. Si se pregunta cómo realiza ClusterControl sus funciones de supervisión, consulte esta página de documentación.
ProxySQL, un proxy inverso de alto rendimiento que comprende los protocolos de MySQL, normalmente se ubica sobre MySQL Replication y Galera Cluster para actuar como una puerta de enlace al servicio back-end de MySQL. Se puede configurar como enrutador de consultas, firewall de consultas, almacenamiento en caché de consultas, despachador de tráfico y muchos más. ProxySQL también recopila y expone métricas clave a través de su esquema STATS, que es muy útil para analizar el rendimiento y comprender lo que realmente sucede detrás de escena. Visite nuestro completo tutorial de ProxySQL para obtener más información al respecto.
En esta publicación de blog, analizaremos en profundidad las instancias de ProxySQL con este nuevo enfoque. En este ejemplo, tenemos una instancia de ProxySQL encima de nuestra replicación de MySQL de dos nodos (1 maestro, 1 esclavo), implementada a través de ClusterControl. Nuestra arquitectura de alto nivel se parece a esto:
También tenemos las siguientes reglas de consulta definidas en la instancia de ProxySQL (solo como referencia, para dar sentido a las métricas de monitoreo recopiladas más adelante):
Habilitación de Prometeo
El monitoreo basado en agentes de ClusterControl está habilitado por clúster. ClusterControl puede implementar un nuevo servidor Prometheus para usted o usar un servidor Prometheus existente (implementado por ClusterControl para otro clúster). Habilitar Prometheus es bastante sencillo. Simplemente vaya a ClusterControl -> elija el clúster -> Tableros -> Habilitar monitoreo basado en agentes:
Luego, especifique la dirección IP o el nombre de host del nuevo servidor Prometheus, o simplemente elija un host Prometheus existente del menú desplegable:
ClusterControl instalará y configurará los paquetes necesarios (Prometheus en el servidor Prometheus, exportadores en la base de datos y nodos ProxySQL), se conectará a Prometheus como fuente de datos y comenzará a visualizar los datos de monitoreo en la interfaz de usuario.
Una vez que finalice el trabajo de implementación, debería poder acceder a la pestaña Paneles como se muestra en la siguiente sección.
Panel de control de ProxySQL
Puede acceder a los paneles de ProxySQL yendo al clúster respectivo en la pestaña Paneles. Al hacer clic en el menú desplegable Tablero, aparecerá una lista de tableros relacionados con nuestro clúster (Replicación de MySQL). Puede encontrar el panel de información general de ProxySQL en la sección "Equilibradores de carga":
Hay una serie de paneles para ProxySQL, algunos de ellos se explican por sí mismos. Sin embargo, vamos a visitarlos uno por uno.
Tamaño del grupo de host
El tamaño del grupo de hosts es simplemente el número total de hosts en todos los grupos de hosts:
En este caso, tenemos dos grupos de host:10 (escritor) y 20 (lector). El grupo de host 10 consta de un host (maestro) mientras que el grupo de host 20 tiene dos hosts (maestro y esclavo), lo que suma un total de tres hosts.
A menos que cambie la configuración del grupo de host (introducir un nuevo host, eliminar el host existente) de ProxySQL, debe esperar que nada cambie en este gráfico.
Conexiones de clientes
El número de conexiones de clientes procesadas por ProxySQL para todos los grupos de host:
El gráfico anterior simplemente nos dice que constantemente hay 8 clientes MySQL conectados a nuestra instancia de ProxySQL en el puerto 6033 durante los últimos 45 minutos (puede cambiar esto en la opción "Selección de rango"). Si deja de conectar su aplicación a ProxySQL (o lo omite), el valor eventualmente debería caer a 0.
Preguntas de clientes
El gráfico visualiza la cantidad de preguntas procesadas por ProxySQL para todos los grupos de host:
De acuerdo con la documentación de MySQL, las Preguntas son simplemente la cantidad de declaraciones ejecutadas por el servidor. Esto incluye solo declaraciones enviadas al servidor por clientes y no declaraciones ejecutadas dentro de programas almacenados, a diferencia de la variable Consultas. Esta variable no cuenta los comandos COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE o COM_STMT_RESET. Nuevamente, si deja de conectar su aplicación a ProxySQL (o lo omite), el valor debería caer a 0.
Conexiones back-end activas
La cantidad de conexiones que ProxySQL mantiene con los servidores backend MySQL por host:
Simplemente nos dice cuántas conexiones utiliza actualmente ProxySQL para enviar consultas al servidor backend. Siempre que el valor máximo no esté cerca del límite de conexión para el servidor en particular (establecido a través de max_connections cuando el servidor se agrega al grupo de host ProxySQL), estamos en buena forma.
Conexiones de servidor fallidas
El número de conexiones que ProxySQL no estableció correctamente:
El ejemplo anterior simplemente muestra que no ocurrió ninguna falla de conexión de back-end en los últimos 45 minutos.
Consultas enrutadas
Este gráfico proporciona información sobre la distribución de las declaraciones entrantes a los servidores backend:
Como puede ver, la mayoría de las lecturas van al grupo host de lectores (HG20). Desde aquí podemos comprender el patrón de equilibrio que realiza ProxySQL, que coincide con nuestras reglas de consulta en esta carga de trabajo de lectura intensiva.
Conexión gratuita
El gráfico muestra cuántas conexiones están libres actualmente:
Las conexiones se mantienen abiertas para minimizar el costo de tiempo de enviar una consulta al servidor backend.
Latencia
El tiempo de ping actual en microsegundos, según lo informado por el hilo de monitoreo de ProxySQL:
Esto simplemente nos dice qué tan estable es la conexión desde ProxySQL a los servidores backend MySQL. Un valor alto durante un tiempo prolongado indica principalmente un problema de red entre ellos.
Memoria caché de consulta
Este gráfico visualiza el consumo de memoria de las consultas que ProxySQL almacena en caché:
Del gráfico anterior, podemos decir que ProxySQL consume una cantidad total de 8 MB de memoria por el caché de consultas. Después de alcanzar el límite de 8 MB (configurable a través de mysql-query_cache_size_MB variable), la memoria será purgada por el subproceso de purga de ProxySQL. Este gráfico no se completará si no tiene definida una regla de caché de consultas.
Por cierto, el almacenamiento en caché de una consulta en ProxySQL se puede hacer con solo dos clics con ClusterControl. Vaya a la página de Consultas principales de ProxySQL, desplácese por una consulta, haga clic en Caché de consultas y haga clic en "Agregar regla":
Eficiencia de la caché de consultas
Este gráfico visualiza la eficiencia de las consultas en caché:
La línea azul nos dice la proporción exitosa de solicitudes GET ejecutadas contra Query Cache donde el conjunto de resultados estaba presente y no caducó. La línea rosa muestra la proporción de datos escritos (insertados) en o leídos desde Query Cache. En este caso, nuestros datos leídos de Query Cache son más altos que los datos escritos, lo que indica una configuración de caché eficiente.
Este gráfico no se completará si no tiene definida una regla de caché de consultas.
Tráfico de red
Este gráfico visualiza el tráfico de red (datos recibidos + datos enviados) desde/hacia los servidores backend MySQL, por host:
La captura de pantalla anterior nos dice que una cantidad significativa de tráfico se está reenviando/recibiendo desde/hacia el grupo host del lector (HG20). En esta carga de trabajo de lectura intensiva, las operaciones de lectura suelen consumir un tráfico mucho mayor, principalmente debido al tamaño del conjunto de resultados de las instrucciones SELECT.
Solo una proporción más pequeña del tráfico se reenvía/recibe desde/hacia el grupo de host de escritura (HG10), lo que se espera ya que las operaciones de escritura generalmente consumen menos tráfico de red con un conjunto de resultados significativamente pequeño que se devuelve a los clientes.
Eficiencia de duplicación
El gráfico simplemente muestra el estado relacionado con la duplicación del tráfico, como Mirror_concurrency frente a Mirror_queue_length:
El gráfico solo se completa si ha configurado la duplicación de tráfico (mirror_hostgroup dentro de la regla de consulta). Si la cola de replicación se recupera, la reducción del límite de simultaneidad de la replicación aumentará la eficiencia de la replicación, que se puede controlar a través de mysql-mirror_max_concurrency variable. En palabras simples, las entradas de cola cero es de lo que se trata la duplicación más eficiente.
Uso de memoria
El gráfico ilustra la utilización de la memoria por parte de los componentes principales dentro de ProxySQL:grupo de conexiones, caché de consultas y almacenamiento persistente (SQLite):
La captura de pantalla anterior nos dice que la huella de memoria ProxySQL es bastante pequeña, menos de 12 MB en total. El grupo de conexiones solo consume 1,3 MB como máximo para acomodar nuestra carga de trabajo de 8 subprocesos (clientes). Con más RAM libre disponible en el host, deberíamos poder aumentar la cantidad de conexiones de clientes a ProxySQL entre tres y cuatro veces o almacenar en caché muchas más consultas activas dentro de ProxySQL para descargar nuestros servidores back-end de MySQL.
Característica adicional:rendimiento del nodo
ClusterControl 1.7.0 ahora incluye métricas de rendimiento del host para las instancias de ProxySQL. En la versión anterior, ClusterControl solo monitoreaba las métricas relacionadas con ProxySQL según lo expuesto por el esquema de estadísticas de ProxySQL. Se puede acceder a esta nueva función en la pestaña Nodo -> Instancia de ProxySQL -> Rendimiento del nodo:
Los histogramas brindan información sobre las métricas clave del host, de manera similar a lo que se está muestreando para los nodos de la base de datos en la sección Nodos -> Descripción general. Si su instancia de ProxySQL está ubicada en el mismo servidor que la aplicación, literalmente también está utilizando ClusterControl para monitorear el servidor de la aplicación. ¡¿Qué tan genial es eso?!
Reflexiones finales
La integración de ClusterControl con Prometheus ofrece una forma alternativa de monitorear y analizar su pila de base de datos, hasta el nivel de proxy inverso. Ahora tiene la opción de descargar los trabajos de monitoreo a Prometheus, o seguir usando el enfoque de monitoreo sin agente predeterminado de ClusterControl para su infraestructura de base de datos.
