Jak chciałbyś scalić „najwyższy” proces dla wszystkich 5 węzłów bazy danych i posortować według użycia procesora za pomocą tylko jednowierszowego polecenia? Tak, dobrze to przeczytałeś! A co z interaktywnymi wykresami wyświetlanymi w interfejsie terminala? Około rok temu wprowadziliśmy klienta CLI dla ClusterControl o nazwie s9s, który jest świetnym uzupełnieniem interfejsu internetowego. Jest to również open source..
W tym poście na blogu pokażemy, jak możesz monitorować swoje bazy danych za pomocą terminala i interfejsu CLI s9s.
Wprowadzenie do s9s, ClusterControl CLI
ClusterControl CLI (lub s9s lub s9s CLI) to projekt open source i opcjonalny pakiet wprowadzony z ClusterControl w wersji 1.4.1. Jest to narzędzie wiersza poleceń do interakcji, kontroli i zarządzania infrastrukturą bazy danych za pomocą ClusterControl. Projekt wiersza poleceń s9s jest open source i można go znaleźć na GitHub.
Począwszy od wersji 1.4.1, skrypt instalacyjny automatycznie zainstaluje pakiet (s9s-tools) w węźle ClusterControl.
Niektóre warunki wstępne. Aby uruchomić s9s-tools CLI, muszą być spełnione następujące warunki:
- Działający kontroler ClusterControl (cmon).
- Klient s9s, zainstaluj jako oddzielny pakiet.
- Port 9501 musi być dostępny dla klienta s9s.
Instalacja CLI s9s jest prosta, jeśli zainstalujesz go na samym hoście ClusterControl Controller:$ rm
$ rm -Rf ~/.s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ ./install-s9s-tools.shMożesz zainstalować s9s-tools poza serwerem ClusterControl (laptopem stacji roboczej lub hostem bastionu), o ile interfejs ClusterControl Controller RPC (TLS) jest dostępny w sieci publicznej (domyślnie 127.0.0.1:9501). Więcej informacji na temat konfiguracji znajdziesz na stronie dokumentacji.
Aby sprawdzić, czy możesz prawidłowo połączyć się z interfejsem ClusterControl RPC, powinieneś otrzymać odpowiedź OK po uruchomieniu następującego polecenia:
$ s9s cluster --ping
PING OK 2.000 msNa marginesie spójrz również na ograniczenia podczas korzystania z tego narzędzia.
Przykładowe wdrożenie
Nasze przykładowe wdrożenie składa się z 8 węzłów w 3 klastrach:
- Replikacja strumieniowa PostgreSQL — 1 główna, 2 podrzędna
- Replikacja MySQL — 1 główna, 1 podrzędna
- Zestaw replik MongoDB — 1 główny, 2 dodatkowe węzły
Wszystkie klastry baz danych zostały wdrożone przez ClusterControl za pomocą kreatora wdrażania „Deploy Database Cluster” i z punktu widzenia interfejsu użytkownika oto, co zobaczylibyśmy w panelu klastra:
Monitorowanie klastra
Zaczniemy od wylistowania klastrów:
$ s9s cluster --list --long
ID STATE TYPE OWNER GROUP NAME COMMENT
23 STARTED postgresql_single system admins PostgreSQL 10 All nodes are operational.
24 STARTED replication system admins Oracle 5.7 Replication All nodes are operational.
25 STARTED mongodb system admins MongoDB 3.6 All nodes are operational.Widzimy te same klastry, co interfejs użytkownika. Możemy uzyskać więcej szczegółów na temat konkretnego klastra, używając flagi --stat. W ten sposób można również monitorować wiele klastrów i węzłów, opcje wiersza poleceń mogą nawet używać symboli wieloznacznych w nazwach węzłów i klastrów:
$ s9s cluster --stat *Replication
Oracle 5.7 Replication Name: Oracle 5.7 Replication Owner: system/admins
ID: 24 State: STARTED
Type: REPLICATION Vendor: oracle 5.7
Status: All nodes are operational.
Alarms: 0 crit 1 warn
Jobs: 0 abort 0 defnd 0 dequd 0 faild 7 finsd 0 runng
Config: '/etc/cmon.d/cmon_24.cnf'
LogFile: '/var/log/cmon_24.log'
HOSTNAME CPU MEMORY SWAP DISK NICs
10.0.0.104 1 6% 992M 120M 0B 0B 19G 13G 10K/s 54K/s
10.0.0.168 1 6% 992M 116M 0B 0B 19G 13G 11K/s 66K/s
10.0.0.156 2 39% 3.6G 2.4G 0B 0B 19G 3.3G 338K/s 79K/sPowyższe dane wyjściowe zawierają podsumowanie naszej replikacji MySQL wraz ze statusem klastra, stanem, dostawcą, plikiem konfiguracyjnym i tak dalej. W dalszej części możesz zobaczyć listę węzłów, które należą do tego identyfikatora klastra, z podsumowanym widokiem zasobów systemowych dla każdego hosta, takich jak liczba procesorów, całkowita pamięć, użycie pamięci, dysk wymiany i interfejsy sieciowe. Wszystkie pokazane informacje są pobierane z bazy danych CMON, a nie bezpośrednio z rzeczywistych węzłów.
Możesz także uzyskać zbiorczy widok wszystkich baz danych we wszystkich klastrach:
$ s9s cluster --list-databases --long
SIZE #TBL #ROWS OWNER GROUP CLUSTER DATABASE
7,340,032 0 0 system admins PostgreSQL 10 postgres
7,340,032 0 0 system admins PostgreSQL 10 template1
7,340,032 0 0 system admins PostgreSQL 10 template0
765,460,480 24 2,399,611 system admins PostgreSQL 10 sbtest
0 101 - system admins Oracle 5.7 Replication sys
Total: 5 databases, 789,577,728, 125 tables.Ostatnia linia podsumowuje, że mamy w sumie 5 baz danych ze 125 tabelami, 4 z nich znajdują się w naszym klastrze PostgreSQL.
Aby uzyskać pełny przykład użycia opcji wiersza poleceń klastra s9s, zapoznaj się z dokumentacją klastra s9s.
Monitorowanie węzłów
W przypadku monitorowania węzłów s9s CLI ma podobne funkcje z opcją klastra. Aby uzyskać zbiorczy widok wszystkich węzłów, możesz po prostu wykonać:
$ s9s node --list --long
STAT VERSION CID CLUSTER HOST PORT COMMENT
coC- 1.6.2.2662 23 PostgreSQL 10 10.0.0.156 9500 Up and running
poM- 10.4 23 PostgreSQL 10 10.0.0.44 5432 Up and running
poS- 10.4 23 PostgreSQL 10 10.0.0.58 5432 Up and running
poS- 10.4 23 PostgreSQL 10 10.0.0.60 5432 Up and running
soS- 5.7.23-log 24 Oracle 5.7 Replication 10.0.0.104 3306 Up and running.
coC- 1.6.2.2662 24 Oracle 5.7 Replication 10.0.0.156 9500 Up and running
soM- 5.7.23-log 24 Oracle 5.7 Replication 10.0.0.168 3306 Up and running.
mo-- 3.2.20 25 MongoDB 3.6 10.0.0.125 27017 Up and Running
mo-- 3.2.20 25 MongoDB 3.6 10.0.0.131 27017 Up and Running
coC- 1.6.2.2662 25 MongoDB 3.6 10.0.0.156 9500 Up and running
mo-- 3.2.20 25 MongoDB 3.6 10.0.0.35 27017 Up and Running
Total: 11Kolumna najbardziej po lewej stronie określa typ węzła. W tym wdrożeniu litera „c” oznacza kontroler ClusterControl, „p” — PostgreSQL, „m” — MongoDB, „e” — Memcached, a s — ogólne węzły MySQL. Następny to stan hosta — „o” — online, „ l” dla off-line, „f” dla uszkodzonych węzłów itd. Kolejna to rola węzła w klastrze. Może to być M dla mastera, S dla slave, C dla kontrolera i – dla wszystkiego innego. Pozostałe kolumny są dość oczywiste.
Możesz uzyskać całą listę, patrząc na stronę podręcznika tego komponentu:
$ man s9s-nodeStamtąd możemy przejść do bardziej szczegółowych statystyk dla wszystkich węzłów z flagą --stats:
$ s9s node --stat --cluster-id=24
10.0.0.104:3306
Name: 10.0.0.104 Cluster: Oracle 5.7 Replication (24)
IP: 10.0.0.104 Port: 3306
Alias: - Owner: system/admins
Class: CmonMySqlHost Type: mysql
Status: CmonHostOnline Role: slave
OS: centos 7.0.1406 core Access: read-only
VM ID: -
Version: 5.7.23-log
Message: Up and running.
LastSeen: Just now SSH: 0 fail(s)
Connect: y Maintenance: n Managed: n Recovery: n Skip DNS: y SuperReadOnly: n
Pid: 16592 Uptime: 01:44:38
Config: '/etc/my.cnf'
LogFile: '/var/log/mysql/mysqld.log'
PidFile: '/var/lib/mysql/mysql.pid'
DataDir: '/var/lib/mysql/'
10.0.0.168:3306
Name: 10.0.0.168 Cluster: Oracle 5.7 Replication (24)
IP: 10.0.0.168 Port: 3306
Alias: - Owner: system/admins
Class: CmonMySqlHost Type: mysql
Status: CmonHostOnline Role: master
OS: centos 7.0.1406 core Access: read-write
VM ID: -
Version: 5.7.23-log
Message: Up and running.
Slaves: 10.0.0.104:3306
LastSeen: Just now SSH: 0 fail(s)
Connect: n Maintenance: n Managed: n Recovery: n Skip DNS: y SuperReadOnly: n
Pid: 975 Uptime: 01:52:53
Config: '/etc/my.cnf'
LogFile: '/var/log/mysql/mysqld.log'
PidFile: '/var/lib/mysql/mysql.pid'
DataDir: '/var/lib/mysql/'
10.0.0.156:9500
Name: 10.0.0.156 Cluster: Oracle 5.7 Replication (24)
IP: 10.0.0.156 Port: 9500
Alias: - Owner: system/admins
Class: CmonHost Type: controller
Status: CmonHostOnline Role: controller
OS: centos 7.0.1406 core Access: read-write
VM ID: -
Version: 1.6.2.2662
Message: Up and running
LastSeen: 28 seconds ago SSH: 0 fail(s)
Connect: n Maintenance: n Managed: n Recovery: n Skip DNS: n SuperReadOnly: n
Pid: 12746 Uptime: 01:10:05
Config: ''
LogFile: '/var/log/cmon_24.log'
PidFile: ''
DataDir: ''Bardzo pouczające może być również drukowanie wykresów z klientem s9s. Przedstawia to dane zebrane przez kontrolera na różnych wykresach. Istnieje prawie 30 wykresów obsługiwanych przez to narzędzie, jak wymieniono tutaj, a s9s-node wylicza je wszystkie. Poniżej przedstawiono histogram obciążenia serwera dla wszystkich węzłów dla klastra o identyfikatorze 1 zebrany przez CMON bezpośrednio z Twojego terminala:
Istnieje możliwość ustawienia daty i godziny rozpoczęcia i zakończenia. Można przeglądać krótkie okresy (np. ostatnia godzina) lub dłuższe okresy (np. tydzień lub miesiąc). Poniżej znajduje się przykład przeglądania wykorzystania dysku w ciągu ostatniej godziny:
Używając opcji --density, dla każdego wykresu można wydrukować inny widok. Ten wykres gęstości nie pokazuje szeregów czasowych, ale częstotliwość wyświetlania danych wartości (oś X reprezentuje wartość gęstości):
Jeśli terminal nie obsługuje znaków Unicode, opcja --only-ascii może je wyłączyć:
Wykresy mają kolory, gdzie np. niebezpiecznie wysokie wartości są pokazane na czerwono. Listę węzłów można filtrować za pomocą opcji --nodes, w której można określić nazwy węzłów lub użyć symboli wieloznacznych, jeśli jest to wygodne.
Monitorowanie procesów
Kolejną fajną rzeczą w CLI s9s jest to, że zapewnia listę procesów całego klastra - „górę” dla wszystkich węzłów, wszystkie procesy połączone w jeden. Poniższe polecenie uruchamia polecenie „top” we wszystkich węzłach bazy danych dla klastra o identyfikatorze 24, posortowane według największego zużycia procesora i stale aktualizowane:
$ s9s process --top --cluster-id=24
Oracle 5.7 Replication - 04:39:17 All nodes are operational.
3 hosts, 4 cores, 10.6 us, 4.2 sy, 84.6 id, 0.1 wa, 0.3 st,
GiB Mem : 5.5 total, 1.7 free, 2.6 used, 0.1 buffers, 1.1 cached
GiB Swap: 0 total, 0 used, 0 free,
PID USER HOST PR VIRT RES S %CPU %MEM COMMAND
12746 root 10.0.0.156 20 1359348 58976 S 25.25 1.56 cmon
1587 apache 10.0.0.156 20 462572 21632 S 1.38 0.57 httpd
390 root 10.0.0.156 20 4356 584 S 1.32 0.02 rngd
975 mysql 10.0.0.168 20 1144260 71936 S 1.11 7.08 mysqld
16592 mysql 10.0.0.104 20 1144808 75976 S 1.11 7.48 mysqld
22983 root 10.0.0.104 20 127368 5308 S 0.92 0.52 sshd
22548 root 10.0.0.168 20 127368 5304 S 0.83 0.52 sshd
1632 mysql 10.0.0.156 20 3578232 1803336 S 0.50 47.65 mysqld
470 proxysql 10.0.0.156 20 167956 35300 S 0.44 0.93 proxysql
338 root 10.0.0.104 20 4304 600 S 0.37 0.06 rngd
351 root 10.0.0.168 20 4304 600 R 0.28 0.06 rngd
24 root 10.0.0.156 20 0 0 S 0.19 0.00 rcu_sched
785 root 10.0.0.156 20 454112 11092 S 0.13 0.29 httpd
26 root 10.0.0.156 20 0 0 S 0.13 0.00 rcuos/1
25 root 10.0.0.156 20 0 0 S 0.13 0.00 rcuos/0
22498 root 10.0.0.168 20 127368 5200 S 0.09 0.51 sshd
14538 root 10.0.0.104 20 0 0 S 0.09 0.00 kworker/0:1
22933 root 10.0.0.104 20 127368 5200 S 0.09 0.51 sshd
28295 root 10.0.0.156 20 127452 5016 S 0.06 0.13 sshd
2238 root 10.0.0.156 20 197520 10444 S 0.06 0.28 vc-agent-007
419 root 10.0.0.156 20 34764 1660 S 0.06 0.04 systemd-logind
1 root 10.0.0.156 20 47628 3560 S 0.06 0.09 systemd
27992 proxysql 10.0.0.156 20 11688 872 S 0.00 0.02 proxysql_galera
28036 proxysql 10.0.0.156 20 11688 876 S 0.00 0.02 proxysql_galeraIstnieje również flaga --list, która zwraca podobny wynik bez ciągłej aktualizacji (podobnie jak polecenie „ps”):
$ s9s process --list --cluster-id=25Monitorowanie zadań
Zadania to zadania wykonywane przez kontroler w tle, dzięki czemu aplikacja kliencka nie musi czekać na zakończenie całego zadania. ClusterControl wykonuje zadania zarządzania, przypisując identyfikator każdemu zadaniu i pozwala wewnętrznemu planistowi zdecydować, czy dwa lub więcej zadań może być uruchomionych równolegle. Na przykład, więcej niż jedno wdrożenie klastra może być wykonywane jednocześnie, a także inne długotrwałe operacje, takie jak tworzenie kopii zapasowych i automatyczne przesyłanie kopii zapasowych do pamięci w chmurze.
W każdej operacji zarządzania byłoby pomocne, gdybyśmy mogli monitorować postęp i status konkretnego zadania, jak np. skalowanie nowego slave'a dla naszej replikacji MySQL. Poniższe polecenie dodaje nowe urządzenie podrzędne, 10.0.0.77, aby skalować naszą replikację MySQL:
$ s9s cluster --add-node --nodes="10.0.0.77" --cluster-id=24
Job with ID 66992 registered.Następnie możemy monitorować jobID 66992 za pomocą opcji zadania:
$ s9s job --log --job-id=66992
addNode: Verifying job parameters.
10.0.0.77:3306: Adding host to cluster.
10.0.0.77:3306: Testing SSH to host.
10.0.0.77:3306: Installing node.
10.0.0.77:3306: Setup new node (installSoftware = true).
10.0.0.77:3306: Setting SELinux in permissive mode.
10.0.0.77:3306: Disabling firewall.
10.0.0.77:3306: Setting vm.swappiness = 1
10.0.0.77:3306: Installing software.
10.0.0.77:3306: Setting up repositories.
10.0.0.77:3306: Installing helper packages.
10.0.0.77: Upgrading nss.
10.0.0.77: Upgrading ca-certificates.
10.0.0.77: Installing socat.
...
10.0.0.77: Installing pigz.
10.0.0.77: Installing bzip2.
10.0.0.77: Installing iproute2.
10.0.0.77: Installing tar.
10.0.0.77: Installing openssl.
10.0.0.77: Upgrading openssl openssl-libs.
10.0.0.77: Finished with helper packages.
10.0.0.77:3306: Verifying helper packages (checking if socat is installed successfully).
10.0.0.77:3306: Uninstalling existing MySQL packages.
10.0.0.77:3306: Installing replication software, vendor oracle, version 5.7.
10.0.0.77:3306: Installing software.
...Lub możemy użyć flagi --wait i uzyskać spinner z paskiem postępu:
$ s9s job --wait --job-id=66992
Add Node to Cluster
- Job 66992 RUNNING [ █] ---% Add New Node to ClusterTo tyle, jeśli chodzi o dzisiejszy dodatek do monitorowania. Mamy nadzieję, że spróbujesz CLI i uzyskasz z niego wartość. Miłego klastrowania
