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

Intégration de ClusterControl avec SNMP - Une preuve de concept :première partie

ClusterControl est livré avec un certain nombre d'alertes (ou alarmes) distinctes que vous ne trouverez pas dans d'autres systèmes de surveillance. ClusterControl comprend une topologie de cluster de base de données dans son ensemble - tous les nœuds de base de données et la relation entre eux, y compris les nœuds ou clusters dépendants comme le cluster esclave, le proxy inverse et les nœuds arbitres. Par exemple, ClusterControl est capable de détecter et de signaler un cluster partitionné, une dérive temporelle entre tous les nœuds du cluster, un échec de récupération de cluster, un échec de réplication de cluster à cluster et bien d'autres alarmes spécifiques à l'échelle du cluster. Par conséquent, ce serait formidable si nous pouvions intégrer les alarmes ClusterControl à tout système de surveillance ou de pagination basé sur SNMP existant.

Dans cette série de blogs, nous allons présenter une preuve de concept sur la façon d'intégrer ClusterControl au protocole SNMP. À la fin de la série de blogs, nous serions finalement en mesure d'envoyer un trap SNMP à un gestionnaire SNMP (Nagios, Zabbix, etc.). Dans cette partie, nous allons couvrir les parties suivantes :

  • MIB (définition d'objet SNMP)
  • Agent SNMP (rapports)

Architecture

Dans cet exemple, nous avons un serveur Nagios en tant que gestionnaire SNMP, avec un serveur ClusterControl (agent SNMP) surveillant un cluster Galera à 3 nœuds comme illustré dans le schéma suivant :

Toutes les instructions de cet article sont basées sur CentOS 7.

Installer SNMP sur le serveur ClusterControl

1) Installez les packages liés à SNMP :

$ yum -y install net-snmp net-snmp-perl net-snmp-utils perl-Net-SNMP perl-CPAN

2) Assurez-vous que le contenu de /etc/snmp/snmpd.conf contient les éléments suivants :

$ grep -v '^\s*$\|^\s*\#' /etc/snmp/snmpd.conf
com2sec   notConfigUser  default              public
com2sec   mynet          192.168.10.0/16      private
com2sec   mynet          localhost            private
group   notConfigGroup v1            notConfigUser
group   notConfigGroup v2c           notConfigUser
group   myGroup        v2c           mynet
view    all           included   .1
view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1
access  notConfigGroup ""      any       noauth    exact  systemview none none
access  myGroup        ""      any       noauth    exact  all        all  none
master agentx
syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root <[email protected]> (configure /etc/snmp/snmp.local.conf)
dontLogTCPWrappersConnects yes

Un peu d'explication :

  • La MIB de Severalnines est un composant privé, par conséquent, nous devons autoriser uniquement notre réseau, 192.168.10.0/16 et localhost pour interroger les données SNMP. Nous définissons cela dans la section "com2sec".

  • Ensuite, nous créons un groupe de sécurité appelé "myGroup", qui autorise uniquement les connexions à partir du réseau "mynet", et accepte le protocole SNMP version 2c.

  • Ensuite, nous définissons la vue (ce qui peut être vu du demandeur). "tout" signifie que le demandeur SNMP peut tout voir (à partir de l'OID .1). "systemview" est uniquement limité aux informations sécurisées pour le public telles que le nom d'hôte, la date et l'heure, etc., ce qui est la valeur par défaut pour les utilisateurs SNMP publics.

  • Ensuite, nous autorisons "myGroup" à avoir une vue "tout".

3) Redémarrez le service SNMP pour charger les modifications :

$ systemctl restart snmpd

4) Maintenant, vous devriez pouvoir voir certaines MIB si nous effectuons snmpwalk :

$ snmpwalk -v2c -cpublic localhost # should return limited entries
$ snmpwalk -v2c -cprivate localhost # should return thousands of entries because the private view starts with .1

Installation des MIB ClusterControl sur le serveur ClusterControl

MIB signifie Management Information Base. Il s'agit d'un fichier texte formaté qui répertorie les objets de données utilisés par un équipement SNMP particulier. Sans MIB, l'OID utilisé par SNMP ne peut pas être traduit en une "chose". Les définitions SNMP MIB sont écrites dans un format MIB concis conformément à la RFC 1212. Plusieursnines a son propre numéro d'entreprise privée (PEN), 57397. Vous pouvez consulter la base de données des numéros d'entreprise enregistrés ici.

1) Copiez le fichier SEVERALNINES-CLUSTERCONTROL-MIB.txt et placez-le sous /usr/share/snmp/mibs. Pour vérifier quel chemin MIB SNMP rechercherait, utilisez cette commande :

$ net-snmp-config --default-mibdirs

2) Pour charger notre MIB personnalisée, nous devons créer un nouveau fichier de configuration dans /etc/snmp/snmp.conf (notez sans le "d") et ajouter la ligne suivante :

mibs +SEVERALNINES-CLUSTERCONTROL-MIB

3) Ajoutez la ligne suivante dans /etc/sysconfig/snmpd pour autoriser l'accès à distance au service SNMP :

OPTIONS="-Lsd -Lf /dev/null -p /var/run/snmpd.pid -a"

4) Redémarrez le démon SNMP pour charger le changement :

$ systemctl restart snmpd

5) Pour voir si la MIB est chargée correctement, utilisez la commande snmptranslate :

$ snmptranslate -IR -On -Tp severalnines
+--severalnines(57397)
   |
   +--clustercontrolMIB(1)
      |
      +--alarms(1)
         |
         +--alarmSummary(1)
         |  |
         |  +-- -R-- Integer32 totalAlarms(1)
         |  |        Range: 0..2147483647
         |  +-- -R-- Integer32 totalCritical(2)
         |  |        Range: 0..2147483647
         |  +-- -R-- Integer32 totalWarning(3)
         |  |        Range: 0..2147483647
         |  +-- -R-- Integer32 clusterId(4)
         |           Range: 0..2147483647
         |
         +--alarmSummaryGroup(2)
         |
         +--alarmNotification(3)
            |
            +--criticalAlarmNotification(1)
            +--criticalAlarmNotificationEnded(2)

La sortie ci-dessus montre que nous avons chargé la MIB de notre ClusterControl. Pour cette preuve de concept, nous n'avons qu'un seul composant principal appelé "alarmes", et en dessous, nous avons 3 sous-composants à côté de leur type de données :

  • alarmSummary - Résumé des alarmes. Affiche simplement critique, avertissement et l'ID de cluster correspondant.

  • alarmSummaryGroup - Regroupement de nos objets SNMP.

  • alarmNotification - Il s'agit de la définition d'interruption SNMP. Sans cela, notre trap SNMP ne sera pas compréhensible par le gestionnaire SNMP.

La numérotation à côté indique l'identifiant de l'objet (OID). Par exemple, totalWarning OID est .1.3.6.1.4.1.57397.1.1.1.3 et CriticalAlarmNotification OID est .1.3.6.1.4.1.57397.1.1.3.1. Pour les organisations privées, l'OID commence toujours par ".1.3.6.1.4.1", suivi du numéro d'entreprise (57397 est le PEN de Manynines) puis des objets MIB.

Installation de l'agent SNMP sur le serveur ClusterControl

Pour "servir" la sortie de l'objet SNMP (le nombre d'alarmes critiques, l'identifiant du cluster, etc.), nous devons étendre le démon SNMP avec un agent SNMP. Dans SNMP, ils appellent ce protocole AgentX, que nous avons défini dans le snmpd.conf sous cette section :

master agentx

Pour cette preuve de concept, j'ai préparé un script écrit en Perl pour récupérer et rapporter le résumé de l'alarme au format SNMP/OID.

1) Installez le composant SNMP Perl :

$ yum install perl-Net-SNMP

2) Mettez clustercontrol-snmp-agent.pl n'importe où accessible par le processus SNMP. Il est recommandé de le placer sous le répertoire /usr/share/snmp.

$ ls -al /usr/share/snmp/clustercontrol-snmp-agent.pl
-rwxr-xr-x 1 root root 2974 May 10 14:16 /usr/share/snmp/clustercontrol-snmp-agent.pl

3) Configurez les lignes suivantes dans le script (lignes 14 à 17) :

my $clusterId = 23; # cluster ID that you want to monitor
my $totalAlarm = `/bin/s9s alarms --list --cluster-id=$clusterId --batch | wc -l`;
my $criticalAlarm = `/bin/s9s alarms --list --cluster-id=$clusterId --batch | grep CRITICAL | wc -l`;
my $warningAlarm = `/bin/s9s alarms --list --cluster-id=$clusterId --batch | grep WARNING | wc -l`;

4) Définissez le script avec une autorisation exécutable :

$ chmod 755 /usr/share/snmp/clustercontrol-snmp-agent.pl

5) Exécutez le script :

$ perl /usr/share/snmp/clustercontrol-snmp-agent.pl
NET-SNMP version 5.7.2 AgentX subagent connected

Assurez-vous de voir la ligne "sous-agent connecté". À ce stade, l'alarme ClusterControl doit être signalée correctement via le protocole SNMP. Pour vérifier, utilisez simplement la commande snmpwalk et exécutez-la depuis un serveur distant, par exemple depuis le serveur Nagios (snmpwalk est fourni par le package net-snmp-utils) :

$ snmpwalk -v2c -c private 192.168.10.50 .1.3.6.1.4.1.57397.1.1.1
SEVERALNINES-CLUSTERCONTROL-MIB::totalAlarms = INTEGER: 3
SEVERALNINES-CLUSTERCONTROL-MIB::totalCritical = INTEGER: 2
SEVERALNINES-CLUSTERCONTROL-MIB::totalWarning = INTEGER: 1
SEVERALNINES-CLUSTERCONTROL-MIB::clusterId = INTEGER: 23

Vous pouvez également utiliser le nom de l'objet MIB à la place, ce qui produit le même résultat :

$ snmpwalk -v2c -c private 192.168.10.50 SEVERALNINES-CLUSTERCONTROL-MIB::alarmSummary
SEVERALNINES-CLUSTERCONTROL-MIB::totalAlarms = INTEGER: 3
SEVERALNINES-CLUSTERCONTROL-MIB::totalCritical = INTEGER: 2
SEVERALNINES-CLUSTERCONTROL-MIB::totalWarning = INTEGER: 1
SEVERALNINES-CLUSTERCONTROL-MIB::clusterId = INTEGER: 23

Réflexions finales

Il s'agit simplement d'une preuve de concept (PoC) très simple sur la manière dont ClusterControl peut être intégré au protocole SNMP. Dans le prochain épisode, nous allons nous pencher sur l'envoi de traps SNMP depuis le serveur ClusterControl vers le gestionnaire SNMP comme Nagios, Zabbix ou Sensu.