sql >> Base de Datos >  >> NoSQL >> MongoDB

Supervisión de bases de datos sin agente con ClusterControl

Con la creciente complejidad de las configuraciones de bases de datos, muchos administradores de sistemas y administradores de bases de datos están recurriendo a un enfoque sin agentes para ayudar a aliviar la carga de los desafíos de monitoreo de bases de datos. El monitoreo sin agente de ClusterControl le permite monitorear bases de datos sin instalar software de agente en cada sistema monitoreado. ClusterControl implementa el monitoreo mediante un recopilador de datos remoto que utiliza el protocolo SSH.

Antes de profundizar directamente en los detalles del monitoreo sin agentes, primero aclaremos el alcance y el significado del monitoreo dentro de nuestro contexto aquí. El monitoreo viene después de la tendencia de los datos, el proceso de recopilación y almacenamiento de métricas, que permite que el sistema de monitoreo procese los datos recopilados para generar una justificación para ajustar, alertar y mostrar datos de tendencias para la generación de informes.

A partir de la versión 1.7.0 (lanzada en diciembre de 2018), ClusterControl admite dos métodos de supervisión:

  • Supervisión sin agentes (predeterminado)
  • Supervisión basada en agentes con Prometheus

Esta publicación explicará cómo monitorear sus servidores de bases de datos y clústeres con el monitoreo sin agente de ClusterControl. Si está buscando más información sobre el monitoreo basado en agentes de ClusterControl, puede consultar esta documentación.

Por lo general, ClusterControl realiza tareas de monitoreo, alerta y tendencias sin agentes utilizando los tres métodos siguientes:

  • SSH:recopilación de métricas del host (proceso, estadísticas de equilibradores de carga, uso de recursos, consumo, etc.) mediante la biblioteca SSH
  • Cliente de base de datos:recopilación de métricas de base de datos (estado, consultas, variables, uso, etc.) utilizando la biblioteca de cliente de base de datos respectiva
  • Asesor:miniprogramas escritos con ClusterControl DSL y que se ejecutan dentro de ClusterControl con fines de supervisión, ajuste y alerta

SSH significa Secure Shell, un protocolo de red seguro utilizado por la mayoría de los servidores basados ​​en Linux para la administración remota. ClusterControl Controller, o CMON, es el servicio de back-end que realiza tareas de automatización, administración, supervisión y programación, construido sobre C++.

ClusterControl DSL (lenguaje específico del dominio) le permite ampliar la funcionalidad de su plataforma ClusterControl mediante la creación de asesores, sintonizadores automáticos o "miniprogramas". La sintaxis de DSL se basa en JavaScript, con extensiones para proporcionar acceso a las funciones y estructuras de datos internas de ClusterControl. El DSL le permite ejecutar declaraciones SQL, ejecutar comandos/programas de shell en todos los hosts de su clúster y recuperar resultados para procesarlos para asesores/alertas o cualquier otra acción.

Herramientas de seguimiento

Todas las herramientas de requisitos previos se cumplen mediante el script del instalador o ClusterControl las instala automáticamente durante la etapa de implementación de la base de datos o si el archivo/binario/paquete requerido no existe en el servidor de destino antes de ejecutar un trabajo. En términos generales, el deber de monitoreo de ClusterControl solo requiere el paquete del servidor OpenSSH en los hosts monitoreados. ClusterControl utiliza la biblioteca de cliente libssh para recopilar métricas de host para los hosts monitoreados:CPU, memoria, disco, red, E/S, proceso, etc. El paquete de cliente OpenSSH es necesario en el host de ClusterControl solo para configurar SSH sin contraseña y fines de depuración. No se admiten otras implementaciones de SSH como Dropbear y TinySSH.

Al recopilar las estadísticas y métricas de la base de datos, ClusterControl Controller (CMON) se conecta al servidor de la base de datos directamente a través de las bibliotecas de cliente de la base de datos:libmysqlclient (MySQL/MariaDB y ProxySQL), libpq (PostgreSQL) y libmongocxx (MongoDB). ). Por eso es crucial configurar los privilegios adecuados para un servidor ClusterControl desde la perspectiva de un servidor de base de datos. Para los clústeres basados ​​en MySQL, ClusterControl requiere que el usuario de la base de datos sea "cmon", mientras que para otras bases de datos, se puede usar cualquier nombre de usuario para monitorear, siempre que se le otorguen privilegios de superusuario. La mayoría de las veces, ClusterControl configurará los privilegios necesarios (o usará el usuario de la base de datos especificado) automáticamente durante la etapa de importación o implementación del clúster.

ClusterControl requiere las siguientes herramientas para balanceadores de carga:

  • Maxctrl en el servidor MariaDB MaxScale
  • netcat y/o socat en el servidor HAProxy para conectarse al archivo de socket HAProxy y recuperar los datos de monitoreo
  • ProxySQL requiere un cliente mysql en el servidor ProxySQL

El siguiente diagrama ilustra los procesos de monitoreo del host y de la base de datos ejecutados por ClusterControl usando libssh y bibliotecas de cliente de base de datos:

Aunque los subprocesos de supervisión no necesitan paquetes de cliente de base de datos instalados en el host supervisado, es muy recomendable tenerlos con fines de gestión. Por ejemplo, el paquete de cliente MySQL viene con los programas mysql, mysqldump, mysqlbinlog y mysqladmin, que serán utilizados por ClusterControl al realizar copias de seguridad y recuperación de un punto en el tiempo.

Métodos de seguimiento

Para la recopilación de estadísticas del equilibrador de carga y host, ClusterControl ejecuta esta tarea a través de SSH con privilegios de superusuario. Por lo tanto, SSH sin contraseña con privilegios de superusuario es vital para permitir que ClusterControl ejecute los comandos necesarios de forma remota con la escalada adecuada. Con este enfoque de extracción, hay un par de ventajas en comparación con otros mecanismos:

  • Sin agentes:no es necesario instalar, configurar ni mantener un agente.
  • Unificación de la configuración de administración y monitoreo:SSH se puede usar para obtener métricas de monitoreo o enviar trabajos de administración a los nodos de destino.
  • Simplifique la implementación:el único requisito es una configuración SSH sin contraseña adecuada, y eso es todo. SSH también es muy seguro y está encriptado.
  • Configuración centralizada:un servidor ClusterControl puede administrar varios servidores y clústeres, siempre que tenga recursos suficientes.

Sin embargo, el mecanismo de tracción también tiene los siguientes inconvenientes:

  • Los datos de monitoreo son precisos solo desde la perspectiva de ClusterControl. Por ejemplo, si hay una falla en la red y ClusterControl pierde la comunicación con el host monitoreado, el muestreo se omitirá hasta el próximo ciclo disponible.
  • Habrá una sobrecarga de red para el monitoreo de alta granularidad debido a una mayor tasa de muestreo donde ClusterControl necesita establecer más conexiones con cada host de destino.
  • ClusterControl seguirá intentando restablecer la conexión con el nodo de destino porque no tiene un agente que lo haga en su nombre.
  • Muestreo de datos redundantes si tiene más de un servidor ClusterControl monitoreando un clúster, ya que cada servidor ClusterControl tiene que extraer los datos de monitoreo por sí mismo.

Para el monitoreo de consultas MySQL, a partir de ClusterControl 1.9.0 (lanzado en julio de 2021), ClusterControl admite dos tipos:

  • Supervisión de consultas sin agentes (predeterminado)
  • Monitoreo de consultas basado en agentes mediante el agente de consultas CMON, que requiere pasos adicionales para habilitarlo. Solo para bases de datos basadas en MySQL y PostgreSQL.

El monitoreo de consultas sin agente monitorea las consultas de dos maneras diferentes:

  • Las consultas se recuperan de PERFORMANCE_SCHEMA consultando el esquema en el nodo de la base de datos a través de SSH.
  • Si PERFORMANCE_SCHEMA está deshabilitado o no está disponible, ClusterControl analizará el contenido del registro de consultas lentas a través de SSH.

Si el esquema de rendimiento está habilitado, ClusterControl lo usará para buscar las consultas lentas. De lo contrario, ClusterControl analizará el contenido del registro de consultas lentas de MySQL (a través de la variable dinámica slow_query_log=ON) según el siguiente flujo:

  1. Iniciar registro lento (durante el tiempo de ejecución de MySQL).
  2. Ejecutarlo durante un breve período de tiempo (un segundo o un par de segundos).
  3. Detener registro.
  4. Analizar registro.
  5. Truncar registro (nuevo archivo de registro).
  6. Ir a 1.

Las consultas recopiladas se procesan, calculan y digieren (normalizan, promedian, cuentan, ordenan) y luego se almacenan en la base de datos CMON de ClusterControl. Tenga en cuenta que para este método de muestreo, existe una pequeña posibilidad de que algunas consultas no se capturen, especialmente durante las partes "detener registro, analizar registro, truncar registro". Puede habilitar el esquema de rendimiento si esta no es una opción.

Solo las consultas que excedan el tiempo de consulta largo se enumerarán aquí mediante el registro de consultas lentas. Suponga que los datos no se completan correctamente y cree que debería haber algo allí, podría ser que:

  • ClusterControl no recopiló suficientes consultas para resumir y completar los datos. Intente reducir el tiempo de consulta largo.
  • Configuró las opciones de configuración del Registro de consultas lentas en my.cnf del servidor MySQL y Anular consultas locales está desactivado. Si realmente desea utilizar el valor que definió dentro de my.cnf, probablemente tendrá que reducir el valor de long_query_time para que ClusterControl pueda calcular un resultado más preciso.
  • Tiene otro nodo de ClusterControl que extrae el registro de consulta lenta también (en caso de que tenga un servidor de ClusterControl en espera). Solo permita que un servidor ClusterControl haga este trabajo.

También puede usar el monitor de consultas ClusterControl para MySQL, MariaDB y Percona Server.

Para el monitoreo de consultas PostgreSQL, ClusterControl requiere el módulo pg_stat_statements para rastrear las estadísticas de ejecución de todas las declaraciones SQL. Rellena las vistas y funciones de pg_stat_statements al mostrar las consultas en la interfaz de usuario (en la pestaña Monitor de consultas).

Intervalos y tiempos de espera

ClusterControl Controller (cmon) es un proceso de subprocesos múltiples. De forma predeterminada, el subproceso de muestreo del controlador ClusterControl se conecta a cada host monitoreado una vez y mantiene una conexión persistente hasta que el host cae o se desconecta cuando se muestrean las estadísticas del host. Puede establecer más conexiones según los trabajos asignados al host, ya que la mayoría de los trabajos de administración se ejecutan en su propio subproceso. Por ejemplo, la recuperación del clúster se ejecuta en el subproceso de recuperación, la ejecución de Advisor se ejecuta en un subproceso cron y la supervisión de procesos se ejecuta en el subproceso del recopilador de procesos.

El subproceso de supervisión de ClusterControl realiza las siguientes operaciones de muestreo en el siguiente intervalo:

  • Métricas de consulta/estado de MySQL:cada segundo
  • Colección de procesos (/proc):cada 10 segundos
  • Detección de servidor:cada 10 segundos
  • Métricas de host (/proc, /sys):cada 30 segundos (configurable a través de host_stats_collection_interval)
  • Métricas de la base de datos (solo PostgreSQL y MongoDB):cada 30 segundos (configurable a través de db_stats_collection_interval)
  • Métricas del esquema de la base de datos:cada 3 horas (configurable a través de db_schema_stats_collection_interval)
  • Métricas del equilibrador de carga:cada 15 segundos (configurable a través de lb_stats_collection_interval)

Los scripts imperativos (Asesores) pueden hacer uso de SSH y bibliotecas de clientes de bases de datos que vienen con CMON con las siguientes restricciones:

  • 5 segundos de límite estricto para la ejecución de SSH.
  • 10 segundos de límite predeterminado para la conexión a la base de datos, configurable a través de net_read_timeout, net_write_timeout, connect_timeout en el archivo de configuración de CMON.
  • 60 segundos del límite de tiempo total de ejecución del script antes de que CMON lo cancele sin gracia.

Los asesores se pueden crear, compilar, probar y programar directamente desde la interfaz de usuario de ClusterControl en Administrar → Developer Studio . La siguiente captura de pantalla muestra un ejemplo de un asesor para extraer las 10 consultas principales de PERFORMANCE_SCHEMA:

La ejecución de los asesores depende de si está activado y del tiempo de programación en formato cron:

Los resultados de la ejecución se muestran en Rendimiento → Asesores , como se muestra en la siguiente captura de pantalla:

Para obtener más información sobre los asesores que se proporcionan de forma predeterminada, consulte nuestro Desarrollador Página de producto de Studio.

Los datos se almacenan directamente en la base de datos CMON para monitorear datos de intervalos cortos como consultas y estado de MySQL. Los datos de monitoreo de intervalos largos, como puntos de datos semanales, mensuales o anuales, se agregan cada 60 segundos y se almacenan en la memoria durante 10 minutos. Estos comportamientos no son configurables debido al diseño de la arquitectura.

Parámetros

ClusterControl tiene muchos parámetros para adaptarse a su política de monitoreo y alertas. La mayoría de ellos se pueden configurar a través de la interfaz de usuario de ClusterControl → elija un clúster → Configuración . La pestaña "Configuración" brinda muchas opciones para configurar alertas, umbrales, notificaciones, diseño de gráficos, contadores de bases de datos, monitoreo de consultas, etc. Por ejemplo, los umbrales de advertencia y críticos se pueden configurar de la siguiente manera:

La página “Runtime Configuration” muestra una lista resumida del controlador ClusterControl activo (CMON) parámetros de configuración de tiempo de ejecución:

Hay más de 170 opciones de configuración del controlador ClusterControl en total, y algunas de las configuraciones avanzadas se pueden configurar para monitorear y alertar el ajuste fino de la política. Algunos de estos incluyen:

  • monitor_cpu_temperature
  • swap_warning
  • intercambio_crítico
  • redobuffer_warning
  • redobuffer_crítico
  • indexmemory_warning
  • indexmemory_critical
  • advertencia_de_memoria_de_datos
  • datamemory_critical
  • tablespace_warning
  • tablespace_critical
  • redolog_warning
  • redolog_critical
  • max_replication_lag
  • long_query_time
  • log_queries_not_using_indexes
  • query_monitor_use_local_settings
  • habilitar_query_monitor
  • habilitar_query_monitor_auto_purge_ps

Puede cambiar los parámetros enumerados en la página "Configuración de tiempo de ejecución" utilizando el archivo de configuración de UI o CMON ubicado en /etc/cmon.d/cmon_X.cnf, donde X es la ID del clúster. Puede enumerar todas las opciones de configuración admitidas para CMON mediante el siguiente comando:

$ cmon --help-config

Reflexiones finales

El monitoreo sin agentes se ha convertido en uno de los métodos más efectivos para administrar infraestructuras de bases de datos cada vez más complejas. Reduce la carga de muchos desafíos asociados con el monitoreo de bases de datos y es fácil de administrar.

Hay muchas herramientas de monitoreo sin agente disponibles en la actualidad. Sin embargo, no muchos de ellos también ofrecen una plataforma completa llena de funciones para ayudarlo a administrar todos los demás aspectos de sus clústeres de bases de datos. Para ver qué más puede hacer ClusterControl, asegúrese de descargar su propia prueba gratuita de 30 días.

¿Está buscando una alternativa basada en agentes para el monitoreo de bases de datos? Consulte la infraestructura de monitoreo de bases de datos basada en agentes de ClusterControl:SCUMM.