Monitoring Serwerów - Forum o monitoringu infrastruktury IT
Skalowalność op5 - monitoring rozproszony - Printable Version

+- Monitoring Serwerów - Forum o monitoringu infrastruktury IT (https://monitoringserwerow.pl)
+-- Forum: MONITORING INFRASTRUKTURY IT (https://monitoringserwerow.pl/forumdisplay.php?fid=1)
+--- Forum: op5 Monitor i Nagios (https://monitoringserwerow.pl/forumdisplay.php?fid=12)
+--- Thread: Skalowalność op5 - monitoring rozproszony (/showthread.php?tid=71)

Skalowalność op5 - monitoring rozproszony - ArturB - 07-31-2019

Jedną z największych zalet aplikacji op5 Monitor jest szeroko rozumiana skalowalność.
Ten aspekt jest często nie do pominięcia w przypadku średnich i dużych wdrożeń. Zespół op5 udostępnił sporo narzędzi które pozwalają nam iść w tym kierunku.
  • Cała konfiguracja znajduje się na węźle "Master"

  • Ta konfiguracja jest dzielona na "Pollery", wg ich odpowiedzialności za "hostgroupy" - grupy maszyn

  • Statusy poszczególnych metod monitoringu spływają do węzła "Master"
Kiedy taka konfiguracja okaże się pomocna? M.in. w przypadku dużych wdrożeń, gdzie niejednokrotnie stykamy się z połączeniem między wieloma lokalizacjami, które posiadają odrębną infrastrukturę, często oddzieloną firewallem. W końcu nie chcemy ani otwierania licznych połączeń między lokalizacjami, ani sytuacji gdy musimy zapewnić ruch sieciowy między maszyną spoza subnetu a wszystkimi (monitorowanymi) maszynami wewnątrz niego.

Co jest nam potrzebne żeby wdrożyć takie rozwiązanie:
  • Przynajmniej dwa serwery op5 Monitor tej samej architektury (ważne)

  • Najlepiej tą samą wersję op5 Monitor, a przynajmniej >=5.2

  • Otwarty ruch pomiędzy serwerami na portach 15551 (port backendowy op5) i 22 (służący do synchronizowania konfiguracji)

  • Dodatkowo chcielibyśmy korzystać z nazw domenowych, ale odpowiednie wpisy w /etc/host.conf wystarczą
Nazwijmy naszą maszyny jako master i poller1. Załóżmy, że chcemy aby poller1 był związany grupą hostów silesia, związaną geograficznie z częścią naszej infrastruktury, a master zajął się resztą monitoringu, sam znajdzie się fizycznie w drugiej dużej lokalizacji, ale zajmie się również dostępem do pojedynczych urządzeń spoza niej.
op5 dostarcza nam narzędzie

KOD: ZAZNACZ CAŁY
Code:
mon // mon --help


krótka instrukcja stworzenia konfiguracji takiego środowiska będzie wyglądała tak

1. Zaloguj się na master jako root
2. Dodajemy nowy poller

KOD: ZAZNACZ CAŁY
Code:
mon node add poller1 type=poller hostgroup=silesia


3.Tworzymy i wymieniamy klucze ssh

KOD: ZAZNACZ CAŁY
Code:
mon sshkey push --all && mon sshkey fetch --all


4. Korzystając z narzędzia ustawiamy poller1 (wszystkie pollery jeśli w tym momencie będzie ich więcej)

KOD: ZAZNACZ CAŁY
Code:
mon node ctrl --type=poller -- mon node add master type=master


5.Ustawiamy synchronizację na przykładzie nagios.cfg

KOD: ZAZNACZ CAŁY
Code:
conf=/opt/monitor/etc/nagios.cfg
mon node ctrl -- sed -i /^cfg_file=/d $conf


6. upewniamy się że mamy pustą konfigurację na polerze

KOD: ZAZNACZ CAŁY
Code:
if [  `mon node ctrl -- mon oconf hash` -eq "d55d3fa04bdd060bbe821b57c320fe807a096727" ]; then echo "OK"; else echo "NOK"; fi;


7. Uzupełniamy konfigurację i restartujemy wszystkie węzły

KOD: ZAZNACZ CAŁY
Code:
mon oconf push
mon node ctrl --self -- mon restart; sleep 3; mon log push


Dodanie nowego dodatkowego pollera również będzie stosunkowo łatwe. Skorzystamy już z wykorzystanych komend i uzyskujemy następującą konfigurację:

KOD: ZAZNACZ CAŁY
Code:
mon node add poller2 type=poller hostgroup=warsaw 
#nic nie stoi na przeszkodzie aby drugi poller również zajmował się grupą silesia
mon sshkey push poller2
mon sshkey fetch poller2
mon node ctrl poller2 -- mon node add master type=master
conf=/opt/monitor/etc/nagios.cfg
mon node ctrl poller2 -- sed -i /^cfg_file=/d $conf
if [  `mon node ctrl poller2 -- mon oconf hash` -eq "d55d3fa04bdd060bbe821b57c320fe807a096727" ]; then echo "OK"; else echo "NOK"; fi;
mon oconf push
mon node ctrl --self -- mon restart; sleep 3; mon log push


Aby dodać lub usunąć grupę hostów z polera wystarczy wyedytować plik /opt/monitor/op5/merlin/merlin.conf
separatorem hostgroup jest ","
następnie należy pamiętać aby zrestartować węzeł master i wysłać konfigurację

KOD: ZAZNACZ CAŁY
Code:
mon restart &&mon oconf push


Usuwanie pollera.

KOD: ZAZNACZ CAŁY
Code:
mon node ctrl poller2 -- mon node remove master
mon node cttrl poller2 -- mon restart
mon node remove poller2
mon restart


Możemy również ustalić czy jeśli poller przestaje odpowiadać, to jego zadaniami ma zająć się master.
W pliku /opt/monitor/op5/merlin/merlin.conf wystarczy ustawić zmienną

KOD: ZAZNACZ CAŁY
Code:
takeover = yes


albo

KOD: ZAZNACZ CAŁY
Code:
takeover  = no


W tym samym pliku możemy dodawać pliki (pamiętając że w systemach unix folder również jest plikiem)
które mają się automatycznie synchronizować np:

KOD: ZAZNACZ CAŁY
Code:
poller poller1 {
address = <ip>
port = <port>
contact_group = <contactgroup>
sync {
/opt/plugins/custom/
/opt/monitor/etc/resource.cfg
 
/etc/op5/
}
}


W /etc/op5/ znajdują się pliki odpowiedzialne za lokalną autoryzację, w tym loginy i hash'e kont klientów

warto również na pollerach z racji niepełnej konfiguracji którą posiadają ustawić
connect = no:

KOD: ZAZNACZ CAŁY
Code:
poller poller1 {
address = <ip>
port = <port>
contact_group = <contactgroup>
connect = no
}


Aby uniemożliwić wykonanie

KOD: ZAZNACZ CAŁY
Code:
mon oconf push


z pollera które mogłoby usunąć z monitoringu wszystkie hostgroupy poza tymi którymi opiekuje się poller.