MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Surveillance de base de données sans agent avec ClusterControl

Avec la complexité croissante des configurations de bases de données, de nombreux administrateurs système et DBA se tournent vers une approche sans agent pour aider à alléger le fardeau des défis de surveillance des bases de données. La surveillance sans agent de ClusterControl vous permet de surveiller les bases de données sans installer de logiciel agent sur chaque système surveillé. ClusterControl implémente la surveillance à l'aide d'un collecteur de données distant qui utilise le protocole SSH.

Avant de plonger directement dans les spécificités de la surveillance sans agent, clarifions d'abord la portée et la signification de la surveillance dans notre contexte ici. La surveillance vient après la tendance des données - le processus de collecte et de stockage des métriques - qui permet au système de surveillance de traiter les données collectées pour produire une justification pour le réglage, l'alerte et l'affichage des données de tendance pour les rapports.

Depuis la version 1.7.0 (publiée en décembre 2018), ClusterControl prend en charge deux méthodes de surveillance :

  • Surveillance sans agent (par défaut)
  • Surveillance basée sur les agents avec Prometheus

Cet article explique comment surveiller vos serveurs de base de données et vos clusters avec la surveillance sans agent de ClusterControl. Si vous recherchez plus d'informations sur la surveillance basée sur les agents de ClusterControl, vous pouvez vous référer à cette documentation.

Généralement, ClusterControl effectue des tâches de surveillance, d'alerte et de tendance sans agent en utilisant les trois méthodes suivantes :

  • SSH – Collecte des métriques de l'hôte (processus, statistiques des équilibreurs de charge, utilisation des ressources, consommation, etc.) à l'aide de la bibliothèque SSH
  • Client de base de données :collecte des métriques de la base de données (état, requêtes, variables, utilisation, etc.) à l'aide de la bibliothèque cliente de la base de données respective
  • Conseiller – Mini-programmes écrits à l'aide de ClusterControl DSL et exécutés dans ClusterControl lui-même à des fins de surveillance, de réglage et d'alerte

SSH signifie Secure Shell, un protocole réseau sécurisé utilisé par la plupart des serveurs basés sur Linux pour l'administration à distance. ClusterControl Controller, ou CMON, est le service backend effectuant des tâches d'automatisation, de gestion, de surveillance et de planification, construit sur C++.

ClusterControl DSL (Domain Specific Language) vous permet d'étendre les fonctionnalités de votre plate-forme ClusterControl en créant des conseillers, des syntoniseurs automatiques ou des "mini programmes". La syntaxe DSL est basée sur JavaScript, avec des extensions permettant d'accéder aux structures et fonctions de données internes de ClusterControl. Le DSL vous permet d'exécuter des instructions SQL, d'exécuter des commandes/programmes shell sur tous vos hôtes de cluster et de récupérer les résultats à traiter pour les conseillers/alertes ou toute autre action.

Outils de surveillance

Tous les outils prérequis sont remplis par le script d'installation ou installés automatiquement par ClusterControl lors de l'étape de déploiement de la base de données ou si le fichier/binaire/package requis n'existe pas sur le serveur cible avant l'exécution d'une tâche. De manière générale, le devoir de surveillance de ClusterControl ne nécessite que le package de serveur OpenSSH sur les hôtes surveillés. ClusterControl utilise la bibliothèque client libssh pour collecter les métriques d'hôte pour les hôtes surveillés - CPU, mémoire, disque, réseau, IO, processus, etc. Le package client OpenSSH est requis sur l'hôte ClusterControl uniquement pour configurer SSH sans mot de passe et à des fins de débogage. Les autres implémentations SSH telles que Dropbear et TinySSH ne sont pas prises en charge.

Lors de la collecte des statistiques et des métriques de la base de données, ClusterControl Controller (CMON) se connecte directement au serveur de base de données via les bibliothèques clientes de base de données - libmysqlclient (MySQL/MariaDB et ProxySQL), libpq (PostgreSQL) et libmongocxx (MongoDB ). C'est pourquoi il est crucial de configurer des privilèges appropriés pour un serveur ClusterControl du point de vue d'un serveur de base de données. Pour les clusters basés sur MySQL, ClusterControl nécessite l'utilisateur de base de données "cmon", tandis que pour les autres bases de données, n'importe quel nom d'utilisateur peut être utilisé pour la surveillance, tant qu'il dispose des privilèges de super-utilisateur. La plupart du temps, ClusterControl configurera automatiquement les privilèges requis (ou utilisera l'utilisateur de base de données spécifié) lors de l'importation du cluster ou de l'étape de déploiement du cluster.

ClusterControl nécessite les outils suivants pour les équilibreurs de charge :

  • Maxctrl sur le serveur MariaDB MaxScale
  • netcat et/ou socat sur le serveur HAProxy pour se connecter au fichier socket HAProxy et récupérer les données de monitoring
  • ProxySQL nécessite un client mysql sur le serveur ProxySQL

Le schéma suivant illustre à la fois les processus de surveillance de l'hôte et de la base de données exécutés par ClusterControl à l'aide de libssh et des bibliothèques client de base de données :

Bien que les threads de surveillance n'aient pas besoin de packages client de base de données installés sur l'hôte surveillé, il est fortement recommandé de les avoir à des fins de gestion. Par exemple, le package client MySQL est fourni avec les programmes mysql, mysqldump, mysqlbinlog et mysqladmin, qui seront utilisés par ClusterControl lors de l'exécution de sauvegardes et de restaurations ponctuelles.

Méthodes de surveillance

Pour la collecte des statistiques de l'hôte et de l'équilibreur de charge, ClusterControl exécute cette tâche via SSH avec le privilège de super-utilisateur. Par conséquent, SSH sans mot de passe avec privilège de super-utilisateur est essentiel pour permettre à ClusterControl d'exécuter les commandes nécessaires à distance avec une escalade appropriée. Avec cette approche pull, il y a quelques avantages par rapport à d'autres mécanismes :

  • Sans agent :il n'est pas nécessaire d'installer, de configurer et de gérer un agent.
  • Unification de la configuration de gestion et de surveillance :SSH peut être utilisé pour extraire des métriques de surveillance ou envoyer des tâches de gestion sur les nœuds cibles.
  • Simplifier le déploiement :la seule exigence est une configuration SSH correcte sans mot de passe, et c'est tout. SSH est également très sécurisé et crypté.
  • Configuration centralisée :un serveur ClusterControl peut gérer plusieurs serveurs et clusters, à condition qu'il dispose de ressources suffisantes.

Cependant, le mécanisme de traction présente également les inconvénients suivants :

  • Les données de surveillance ne sont exactes que du point de vue de ClusterControl. Par exemple, s'il y a un problème de réseau et que ClusterControl perd la communication avec l'hôte surveillé, l'échantillonnage sera ignoré jusqu'au prochain cycle disponible.
  • Il y aura une surcharge du réseau pour une surveillance à haute granularité en raison de l'augmentation du taux d'échantillonnage où ClusterControl doit établir plus de connexions à chaque hôte cible.
  • ClusterControl continuera de tenter de rétablir la connexion au nœud cible car il n'a pas d'agent pour le faire en son nom.
  • Échantillonnage de données redondant si vous avez plusieurs serveurs ClusterControl surveillant un cluster puisque chaque serveur ClusterControl doit extraire les données de surveillance pour lui-même.

Pour la surveillance des requêtes MySQL, à partir de ClusterControl 1.9.0 (publié en juillet 2021), ClusterControl prend en charge deux types :

  • Surveillance des requêtes sans agent (par défaut)
  • Surveillance des requêtes basée sur l'agent à l'aide de l'agent de requête CMON, qui nécessite des étapes supplémentaires pour l'activer. Uniquement pour les bases de données basées sur MySQL et PostgreSQL.

La surveillance des requêtes sans agent surveille les requêtes de deux manières différentes :

  • Les requêtes sont extraites de PERFORMANCE_SCHEMA en interrogeant le schéma sur le nœud de la base de données via SSH.
  • Si PERFORMANCE_SCHEMA est désactivé ou indisponible, ClusterControl analysera le contenu du journal des requêtes lentes via SSH.

Si le schéma de performance est activé, ClusterControl l'utilisera pour rechercher les requêtes lentes. Sinon, ClusterControl analysera le contenu du journal des requêtes lentes MySQL (via la variable dynamique slow_query_log=ON) en fonction du flux suivant :

  1. Démarrer un journal lent (pendant l'exécution de MySQL).
  2. Exécutez-le pendant une courte période (une seconde ou quelques secondes).
  3. Arrêter le journal.
  4. Journal d'analyse.
  5. Tronquer le journal (nouveau fichier journal).
  6. Aller à 1.

Les requêtes collectées sont hachées, calculées et digérées (normalisation, moyenne, comptage, tri), puis stockées dans la base de données ClusterControl CMON. Notez que pour cette méthode d'échantillonnage, il y a une légère chance que certaines requêtes ne soient pas capturées, en particulier pendant les parties "stop log, parse log, truncate log". Vous pouvez activer le schéma de performances si ce n'est pas une option.

Seules les requêtes qui dépassent le temps de requête long seront répertoriées ici à l'aide du journal des requêtes lentes. Supposons que les données ne soient pas remplies correctement et que vous pensez qu'il devrait y avoir quelque chose dedans, il se peut que :

  • ClusterControl n'a pas collecté suffisamment de requêtes pour résumer et remplir les données. Essayez de réduire le temps de requête long.
  • Vous avez configuré les options de configuration du journal des requêtes lentes dans le fichier my.cnf du serveur MySQL, et l'option Remplacer la requête locale est désactivée. Si vous voulez vraiment utiliser la valeur que vous avez définie dans my.cnf, vous devrez probablement réduire la valeur long_query_time pour que ClusterControl puisse calculer un résultat plus précis.
  • Vous avez un autre nœud ClusterControl qui extrait également le journal des requêtes lentes (au cas où vous auriez un serveur ClusterControl de secours). N'autorisez qu'un seul serveur ClusterControl à effectuer cette tâche.

Vous pouvez également utiliser le moniteur de requêtes ClusterControl pour MySQL, MariaDB et Percona Server.

Pour la surveillance des requêtes PostgreSQL, ClusterControl nécessite le module pg_stat_statements pour suivre les statistiques d'exécution de toutes les instructions SQL. Il remplit les vues et fonctions pg_stat_statements lors de l'affichage des requêtes dans l'interface utilisateur (sous l'onglet Query Monitor).

Intervalles et délais

ClusterControl Controller (cmon) est un processus multithread. Par défaut, le thread d'échantillonnage du contrôleur ClusterControl se connecte une fois à chaque hôte surveillé et maintient une connexion persistante jusqu'à ce que l'hôte abandonne ou se déconnecte lors de l'échantillonnage des statistiques de l'hôte. Il peut établir plus de connexions en fonction des tâches affectées à l'hôte puisque la plupart des tâches de gestion s'exécutent dans leur propre thread. Par exemple, la récupération du cluster s'exécute sur le thread de récupération, l'exécution du conseiller s'exécute sur un thread cron et la surveillance des processus s'exécute sur le thread du collecteur de processus.

Le thread de surveillance de ClusterControl effectue les opérations d'échantillonnage suivantes dans l'intervalle suivant :

  • Métriques d'état/requête MySQL :toutes les secondes
  • Traiter la collecte (/proc) :toutes les 10 secondes
  • Détection du serveur :toutes les 10 secondes
  • Métriques de l'hôte (/proc, /sys) :toutes les 30 secondes (configurables via host_stats_collection_interval)
  • Métriques de la base de données (PostgreSQL et MongoDB uniquement) :toutes les 30 secondes (configurables via db_stats_collection_interval)
  • Métriques du schéma de base de données :toutes les 3 heures (configurable via db_schema_stats_collection_interval)
  • Métriques de l'équilibreur de charge :toutes les 15 secondes (configurables via lb_stats_collection_interval)

Les scripts impératifs (Advisors) peuvent utiliser les bibliothèques clientes SSH et de base de données fournies avec CMON avec les restrictions suivantes :

  • 5 secondes de limite stricte pour l'exécution SSH.
  • 10 secondes de limite par défaut pour la connexion à la base de données, configurable via net_read_timeout, net_write_timeout, connect_timeout dans le fichier de configuration CMON.
  • 60 secondes de délai total d'exécution du script avant que CMON ne l'interrompe sans grâce.

Les conseillers peuvent être créés, compilés, testés et programmés directement à partir de l'interface utilisateur de ClusterControl sous Gérer → Developer Studio . La capture d'écran suivante montre un exemple d'un conseiller pour extraire les 10 requêtes principales de PERFORMANCE_SCHEMA :

L'exécution des conseillers dépend de son activation et de l'heure de planification au format cron :

Les résultats de l'exécution sont affichés sous Performance → Advisors , comme illustré dans la capture d'écran suivante :

Pour plus d'informations sur les conseillers fournis par défaut, consultez notre développeur Page produit Studio.

Les données sont stockées directement dans la base de données CMON pour les données de surveillance à court intervalle telles que les requêtes MySQL et l'état. Les données de surveillance à long intervalle telles que les points de données hebdomadaires/mensuels/annuels sont agrégées toutes les 60 secondes et stockées en mémoire pendant 10 minutes. Ces comportements ne sont pas configurables en raison de la conception de l'architecture.

Paramètres

ClusterControl dispose de nombreux paramètres adaptés à votre politique de surveillance et d'alerte. La plupart d'entre eux sont configurables via ClusterControl UI → choisissez un cluster → Paramètres . L'onglet "Paramètres" fournit de nombreuses options pour configurer les alertes, les seuils, les notifications, la disposition des graphiques, les compteurs de base de données, la surveillance des requêtes, etc. Par exemple, les seuils d'avertissement et critique sont configurables comme suit :

La page « Configuration d'exécution » affiche une liste résumée du contrôleur ClusterControl actif Paramètres de configuration d'exécution (CMON) :

Il existe plus de 170 options de configuration de ClusterControl Controller au total, et certaines les paramètres avancés peuvent être configurés en surveillant et en ajustant la politique d'alerte. Certains d'entre eux incluent :

  • monitor_cpu_temperature
  • swap_warning
  • swap_critical
  • redobuffer_warning
  • redobuffer_critical
  • indexmemory_warning
  • indexmemory_critical
  • datamemory_warning
  • 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
  • enable_query_monitor
  • enable_query_monitor_auto_purge_ps

Vous pouvez modifier les paramètres répertoriés dans la page « Configuration d'exécution » en utilisant l'interface utilisateur ou le fichier de configuration CMON situé dans /etc/cmon.d/cmon_X.cnf, où X est l'ID de cluster. Vous pouvez répertorier toutes les options de configuration prises en charge pour CMON à l'aide de la commande suivante :

$ cmon --help-config

Réflexions finales

La surveillance sans agent est devenue l'une des méthodes les plus efficaces pour gérer des infrastructures de bases de données de plus en plus complexes. Il réduit le fardeau de nombreux défis associés à la surveillance de la base de données et est facile à gérer.

De nombreux outils de surveillance sans agent sont disponibles aujourd'hui. Cependant, peu d'entre eux offrent également une plate-forme complète pleine de fonctionnalités pour vous aider à gérer tous les autres aspects de vos clusters de bases de données. Pour voir ce que ClusterControl peut faire d'autre, assurez-vous de télécharger votre propre essai gratuit de 30 jours.

Êtes-vous à la recherche d'une alternative basée sur un agent à la surveillance de la base de données ? Découvrez l'infrastructure de surveillance de base de données basée sur des agents de ClusterControl - SCUMM.