Интегриране на ClusterControl със SNMP - Доказателство за концепция:Част първа

ClusterControl идва с редица отличителни сигнали (или аларми), които няма да намерите в други системи за наблюдение. ClusterControl разбира топологията на клъстера на база данни като цяло - всички възли на базата данни и връзката между тях, включително зависимите възли или клъстери като подчинен клъстер, обратен прокси и арбитър възли. Например, ClusterControl е в състояние да открие и отчита разделен клъстер, отклонение във времето между всички възли в клъстера, неуспех при възстановяване на клъстер, неуспех при репликация от клъстер към клъстер и много други специфични аларми за целия клъстер. Следователно би било чудесно, ако можем да интегрираме алармите на ClusterControl с всяка съществуваща SNMP-базирана система за наблюдение или пейджинг.

В тази серия от блогове ще представим доказателство за концепцията за това как да интегрирате ClusterControl с SNMP протокол. В края на поредицата от блогове в крайна сметка ще можем да изпратим SNMP капан до SNMP мениджър (Nagios, Zabbix и т.н.). В тази част ще покрием следните части:

MIB (дефиниция на SNMP обект)
SNMP агент (отчитане)

Архитектура

В този пример имаме сървър Nagios като SNMP мениджър, със сървър ClusterControl (SNMP агент), който наблюдава клъстер Galera с 3 възела, както е илюстрирано на следната диаграма:

Всички инструкции в тази публикация са базирани на CentOS 7.

Инсталиране на SNMP на сървъра на ClusterControl

1) Инсталирайте свързани с SNMP пакети:

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

2) Уверете се, че съдържанието на /etc/snmp/snmpd.conf съдържа следното:

$ 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

Малко обяснение:

MIB на Severalnines е частен компонент, следователно трябва да разрешим само нашата мрежа, 192.168.10.0/16 и localhost за запитване на SNMP данните. Дефинираме това в секцията "com2sec".
След това създаваме група за сигурност, наречена "myGroup", която позволява връзки само от мрежата "mynet" и приема протокол SNMP версия 2c.
След това дефинираме изгледа (това, което може да се види от заявителя). "всички" означава, че SNMP рикуестърът може да види всичко (започвайки от OID .1). „systemview“ е ограничен само до безопасна за обществеността информация като име на хост, дата и час и т.н., която е по подразбиране за публични потребители на SNMP.
След това позволяваме на "myGroup" да има изглед "всички".

3) Рестартирайте SNMP услугата, за да заредите промените:

$ systemctl restart snmpd

4) Сега трябва да можете да видите някои MIB, ако извършим 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

Инсталиране на ClusterControl MIB на сървъра на ClusterControl

MIB означава База за информация за управление. Това е форматиран текстов файл, който изброява обектите с данни, използвани от определена част от SNMP оборудване. Без MIB, OID, използван от SNMP, не може да бъде преведен в "нещо". SNMP MIB дефинициите са написани в сбит MIB формат в съответствие с RFC 1212. Severalnines има свой собствен номер на частно предприятие (PEN), 57397. Можете да проверите базата данни с регистрирани корпоративни номера тук.

1) Копирайте SEVERALNINES-CLUSTERCONTROL-MIB.txt и го поставете под /usr/share/snmp/mibs. За да проверите кой MIB път ще търси SNMP, използвайте тази команда:

$ net-snmp-config --default-mibdirs

2) За да заредим нашия персонализиран MIB, трябва да създадем нов конфигурационен файл в /etc/snmp/snmp.conf (забележете без "d") и да добавим следния ред:

mibs +SEVERALNINES-CLUSTERCONTROL-MIB

3) Добавете следния ред в /etc/sysconfig/snmpd, за да разрешите отдалечен достъп до услугата SNMP:

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

4) Рестартирайте SNMP демона, за да заредите промяната:

$ systemctl restart snmpd

5) За да видите дали MIB е зареден правилно, използвайте командата 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)

Горният изход показва, че сме заредили MIB на нашия ClusterControl. За това доказателство на концепцията имаме само един основен компонент, наречен "аларми", а под него имаме 3 подкомпонента заедно с техния тип данни:

alarmSummary – Резюме на алармите. Само показва критичен, предупреждение и съответния идентификатор на клъстера.
alarmSummaryGroup – Групиране на нашите SNMP обекти.
alarmNotification - Това е за дефиниране на SNMP капан. Без това нашият SNMP капан няма да бъде разбираем от SNMP мениджъра.

Номерацията до него указва идентификатора на обекта (OID). Например, totalWarning OID е .1.3.6.1.4.1.57397.1.1.1.3, а идентификаторът на CriticalAlarmNotification е .1.3.6.1.4.1.57397.1.1.3.1. За частни организации OID винаги започва с „.1.3.6.1.4.1“, последвано от номера на предприятието (57397 е PEN на Severalnines) и след това MIB обектите.

Инсталиране на SNMP агента на сървъра ClusterControl

За да "обслужваме" изхода на SNMP обекта (броя на критичните аларми, идентификатора на клъстера и т.н.), трябва да разширим SNMP демона със SNMP агент. В SNMP те наричат този протокол като AgentX, който сме дефинирали в snmpd.conf в този раздел:

master agentx

За това доказателство на концепцията съм подготвил скрипт, написан на Perl, за извличане и докладване на обобщението на алармата в SNMP/OID форматиране.

1) Инсталирайте Perl SNMP компонент:

$ yum install perl-Net-SNMP

2) Поставете clustercontrol-snmp-agent.pl навсякъде, достъпно от SNMP процеса. Препоръчително е да го поставите в директорията /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) Конфигурирайте следните редове вътре в скрипта (ред 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) Задайте скрипта с разрешение за изпълнение:

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

5) Изпълнете скрипта:

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

Уверете се, че виждате реда „свързан субагент“. В този момент алармата на ClusterControl трябва да бъде докладвана правилно чрез SNMP протокол. За да проверите, просто използвайте командата snmpwalk и я изпълнете от отдалечен сървър, например от сървъра Nagios (snmpwalk се предоставя от 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

Алтернативно, можете също да използвате името на MIB обект вместо това, което води до същия резултат:

$ 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

Последни мисли

Това е просто много просто доказателство на концепцията (PoC) за това как ClusterControl може да бъде интегриран с SNMP протокола. В следващия епизод ще разгледаме изпращането на SNMP капани от сървъра на ClusterControl към SNMP мениджъра като Nagios, Zabbix или Sensu.