MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Integrieren von ClusterControl mit SNMP – ein Machbarkeitsnachweis:Teil Eins

ClusterControl enthält eine Reihe von charakteristischen Warnungen (oder Alarmen), die Sie in anderen Überwachungssystemen nicht finden werden. ClusterControl versteht eine Datenbank-Cluster-Topologie als Ganzes - alle Datenbankknoten und die Beziehung zwischen ihnen, einschließlich der abhängigen Knoten oder Cluster wie Slave-Cluster, Reverse-Proxy und Arbitrator-Knoten. Beispielsweise ist ClusterControl in der Lage, einen partitionierten Cluster, Zeitabweichungen zwischen allen Knoten im Cluster, Cluster-Wiederherstellungsfehler, Cluster-zu-Cluster-Replikationsfehler und viele weitere clusterweite spezifische Alarme zu erkennen und zu melden. Daher wäre es großartig, wenn wir ClusterControl-Alarme in jedes vorhandene SNMP-basierte Überwachungs- oder Paging-System integrieren könnten.

In dieser Blogserie werden wir einen Machbarkeitsnachweis darüber zeigen, wie ClusterControl mit dem SNMP-Protokoll integriert werden kann. Am Ende der Blogserie wären wir schließlich in der Lage, einen SNMP-Trap an einen SNMP-Manager (Nagios, Zabbix, etc) zu senden. In diesem Teil behandeln wir die folgenden Teile:

  • MIB (SNMP-Objektdefinition)
  • SNMP-Agent (Berichterstellung)

Architektur

In diesem Beispiel haben wir einen Nagios-Server als SNMP-Manager, wobei ein ClusterControl-Server (SNMP-Agent) einen 3-Knoten-Galera-Cluster überwacht, wie im folgenden Diagramm dargestellt:

Alle Anleitungen in diesem Beitrag basieren auf CentOS 7.

SNMP auf dem ClusterControl-Server installieren

1) Installieren Sie SNMP-bezogene Pakete:

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

2) Stellen Sie sicher, dass der Inhalt von /etc/snmp/snmpd.conf Folgendes enthält:

$ 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

Eine kleine Erklärung:

  • Die MIB von Severalnines ist eine private Komponente, daher müssen wir nur unser Netzwerk 192.168.10.0/16 zulassen und localhost, um die SNMP-Daten abzufragen. Wir definieren dies im Abschnitt "com2sec".

  • Dann erstellen wir eine Sicherheitsgruppe namens "myGroup", die nur Verbindungen vom "mynet"-Netzwerk zulässt, und akzeptiert Protokoll SNMP Version 2c.

  • Dann definieren wir die Ansicht (was vom Anfragenden zu sehen ist). „all“ bedeutet, dass der SNMP-Requester alles sehen kann (ab OID .1). „systemview“ ist nur auf sichere Informationen wie Hostname, Datum, Uhrzeit usw. beschränkt, was die Standardeinstellung für öffentliche SNMP-Benutzer ist.

  • Dann erlauben wir "myGroup" eine "alle" Ansicht zu haben.

3) Starten Sie den SNMP-Dienst neu, um die Änderungen zu laden:

$ systemctl restart snmpd

4) Jetzt sollten Sie einige MIBs sehen können, wenn wir snmpwalk ausführen:

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

ClusterControl-MIBs auf dem ClusterControl-Server installieren

MIB steht für Management Information Base. Es ist eine formatierte Textdatei, die die Datenobjekte auflistet, die von einem bestimmten Teil der SNMP-Ausrüstung verwendet werden. Ohne MIB kann die von SNMP verwendete OID nicht in ein "Ding" übersetzt werden. Die SNMP-MIB-Definitionen sind im präzisen MIB-Format gemäß RFC 1212 geschrieben. Multiplenines hat seine eigene Private Enterprise Number (PEN), 57397. Sie können die Datenbank mit registrierten Unternehmensnummern hier einsehen.

1) Kopieren Sie die SEVERALNINES-CLUSTERCONTROL-MIB.txt und legen Sie sie unter /usr/share/snmp/mibs ab. Verwenden Sie diesen Befehl, um zu prüfen, nach welchem ​​MIB-Pfad SNMP suchen würde:

$ net-snmp-config --default-mibdirs

2) Um unsere benutzerdefinierte MIB zu laden, müssen wir eine neue Konfigurationsdatei unter /etc/snmp/snmp.conf (Hinweis ohne das „d“) erstellen und die folgende Zeile hinzufügen:

mibs +SEVERALNINES-CLUSTERCONTROL-MIB

3) Fügen Sie die folgende Zeile in /etc/sysconfig/snmpd hinzu, um den Fernzugriff auf den SNMP-Dienst zu ermöglichen:

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

4) Starten Sie den SNMP-Daemon neu, um die Änderung zu laden:

$ systemctl restart snmpd

5) Um zu sehen, ob die MIB richtig geladen ist, verwenden Sie den snmptranslate-Befehl:

$ 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)

Die obige Ausgabe zeigt, dass wir die MIB unseres ClusterControl geladen haben. Für diesen Proof-of-Concept haben wir nur eine Hauptkomponente namens „Alarme“ und darunter haben wir neben ihrem Datentyp 3 Unterkomponenten:

  • alarmSummary - Zusammenfassung der Alarme. Zeigt nur kritisch, Warnung und die entsprechende Cluster-ID an.

  • alarmSummaryGroup - Gruppierung unserer SNMP-Objekte.

  • alarmNotification – Dies ist für die SNMP-Trap-Definition. Ohne dies ist unser SNMP-Trap für den SNMP-Manager nicht verständlich.

Die Nummerierung daneben gibt die Objektkennung (OID) an. Die totalWarning-OID ist beispielsweise .1.3.6.1.4.1.57397.1.1.1.3 und die kritischeAlarmNotification-OID ist .1.3.6.1.4.1.57397.1.1.3.1. Für private Organisationen beginnt die OID immer mit ".1.3.6.1.4.1", gefolgt von der Unternehmensnummer (57397 ist der PEN von Multiplenines) und dann den MIB-Objekten.

Installation des SNMP-Agenten auf dem ClusterControl-Server

Um die SNMP-Objektausgabe (die Anzahl der kritischen Alarme, die Cluster-ID usw.) zu "bedienen", müssen wir den SNMP-Daemon mit einem SNMP-Agenten erweitern. In SNMP nennen sie dieses Protokoll AgentX, das wir in der snmpd.conf unter diesem Abschnitt definiert haben:

master agentx

Für diesen Proof-of-Concept habe ich ein in Perl geschriebenes Skript vorbereitet, um die Zusammenfassung des Alarms abzurufen und im SNMP/OID-Format zu melden.

1) Perl-SNMP-Komponente installieren:

$ yum install perl-Net-SNMP

2) Platzieren Sie clustercontrol-snmp-agent.pl an einer beliebigen Stelle, auf die der SNMP-Prozess zugreifen kann. Es wird empfohlen, es im Verzeichnis /usr/share/snmp abzulegen.

$ 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) Konfigurieren Sie die folgenden Zeilen innerhalb des Skripts (Zeile 14 bis 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) Setzen Sie das Skript auf Ausführungsberechtigung:

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

5) Führen Sie das Skript aus:

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

Stellen Sie sicher, dass die Zeile „subagent connected“ angezeigt wird. An dieser Stelle sollte der ClusterControl-Alarm korrekt über das SNMP-Protokoll gemeldet werden. Verwenden Sie zur Überprüfung einfach den Befehl snmpwalk und führen Sie ihn von einem Remote-Server aus, beispielsweise vom Nagios-Server (snmpwalk wird vom Paket net-snmp-utils bereitgestellt):

$ 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

Alternativ können Sie stattdessen auch den MIB-Objektnamen verwenden, was zum gleichen Ergebnis führt:

$ 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

Abschließende Gedanken

Dies ist nur ein sehr einfacher Proof-of-Concept (PoC) darüber, wie ClusterControl in das SNMP-Protokoll integriert werden kann. In der nächsten Folge werden wir uns mit dem Senden von SNMP-Traps vom ClusterControl-Server an SNMP-Manager wie Nagios, Zabbix oder Sensu befassen.