Bezagentowe monitorowanie bazy danych za pomocą ClusterControl

Wraz z rosnącą złożonością konfiguracji baz danych, wielu administratorów systemu i administratorów baz danych zwraca się w stronę podejścia bezagentowego, aby zmniejszyć obciążenie związane z wyzwaniami związanymi z monitorowaniem baz danych. Bezagentowe monitorowanie ClusterControl umożliwia monitorowanie baz danych bez instalowania oprogramowania agenta w każdym monitorowanym systemie. ClusterControl wdraża monitorowanie za pomocą zdalnego modułu gromadzącego dane, który korzysta z protokołu SSH.

Zanim zagłębimy się w szczegóły monitorowania bezagentowego, wyjaśnijmy najpierw zakres i znaczenie monitorowania w naszym kontekście. Monitorowanie następuje po trendach danych — procesie gromadzenia i przechowywania metryk — który umożliwia systemowi monitorowania przetwarzanie zebranych danych w celu uzyskania uzasadnienia dostrajania, ostrzegania i wyświetlania danych trendów do raportowania.

Począwszy od wersji 1.7.0 (wydanej w grudniu 2018 r.), ClusterControl obsługuje dwie metody monitorowania:

• Monitorowanie bez agentów (domyślne)
• Monitorowanie agentowe za pomocą Prometheusa

W tym poście dowiesz się, jak monitorować serwery bazy danych i klastry za pomocą monitorowania bezagentowego ClusterControl. Jeśli szukasz więcej informacji na temat monitorowania opartego na agentach ClusterControl, możesz zapoznać się z tą dokumentacją.

Ogólnie rzecz biorąc, ClusterControl wykonuje bezagentowe monitorowanie, ostrzeganie i wyznaczanie trendów przy użyciu następujących trzech metod:

• SSH – Zbieranie metryk hosta (proces, statystyki systemów równoważenia obciążenia, wykorzystanie zasobów, zużycie itp.) przy użyciu biblioteki SSH
• Klient bazy danych — Zbieranie metryk bazy danych (status, zapytania, zmienne, użycie itp.) przy użyciu odpowiedniej biblioteki klienta bazy danych
• Advisor – Mini programy napisane przy użyciu ClusterControl DSL i działające w samym ClusterControl w celu monitorowania, dostrajania i ostrzegania

SSH oznacza Secure Shell, bezpieczny protokół sieciowy używany przez większość serwerów opartych na systemie Linux do zdalnej administracji. ClusterControl Controller lub CMON to usługa backendu wykonująca zadania automatyzacji, zarządzania, monitorowania i planowania, zbudowana na bazie C++.

ClusterControl DSL (Język specyficzny dla domeny) umożliwia rozszerzenie funkcjonalności platformy ClusterControl poprzez tworzenie Doradców, Auto Tunerów lub „Mini Programów”. Składnia DSL jest oparta na JavaScript, z rozszerzeniami zapewniającymi dostęp do wewnętrznych struktur danych i funkcji ClusterControl. DSL umożliwia wykonywanie instrukcji SQL, uruchamianie poleceń/programów powłoki na wszystkich hostach klastra i pobieranie wyników do przetworzenia dla doradców/alertów lub innych działań.

Narzędzia monitorowania

Wszystkie wstępnie wymagane narzędzia są spełniane przez skrypt instalatora lub automatycznie instalowane przez ClusterControl podczas etapu wdrażania bazy danych lub jeśli wymagany plik/binarny/pakiet nie istnieje na serwerze docelowym przed wykonaniem zadania. Ogólnie rzecz biorąc, obowiązek monitorowania ClusterControl wymaga tylko pakietu serwera OpenSSH na monitorowanych hostach. ClusterControl używa biblioteki klienta libssh do zbierania metryk hosta dla monitorowanych hostów – procesora, pamięci, dysku, sieci, IO, procesu itp. Pakiet klienta OpenSSH jest wymagany na hoście ClusterControl tylko do skonfigurowania bezhasłowego SSH i celów debugowania. Inne implementacje SSH, takie jak Dropbear i TinySSH, nie są obsługiwane.

Podczas zbierania statystyk i metryk bazy danych, ClusterControl Controller (CMON) łączy się z serwerem bazy danych bezpośrednio przez biblioteki klienckie bazy danych – libmysqlclient (MySQL/MariaDB i ProxySQL), libpq (PostgreSQL) i libmongocxx (MongoDB) ). Dlatego tak ważne jest ustawienie odpowiednich uprawnień dla serwera ClusterControl z perspektywy serwera bazy danych. W przypadku klastrów opartych na MySQL, ClusterControl wymaga użytkownika bazy danych „cmon”, podczas gdy w przypadku innych baz danych do monitorowania można użyć dowolnej nazwy użytkownika, o ile ma przyznane uprawnienia superużytkownika. W większości przypadków ClusterControl skonfiguruje wymagane uprawnienia (lub użyje określonego użytkownika bazy danych) automatycznie podczas etapu importu lub wdrażania klastra.

ClusterControl wymaga następujących narzędzi do równoważenia obciążenia:

• Maxctrl na serwerze MariaDB MaxScale
• netcat i/lub socat na serwerze HAProxy, aby połączyć się z plikiem gniazda HAProxy i pobrać dane monitorowania
• ProxySQL wymaga klienta mysql na serwerze ProxySQL

Poniższy diagram ilustruje procesy monitorowania hosta i bazy danych wykonywane przez ClusterControl przy użyciu libssh i bibliotek klienckich bazy danych:

Chociaż wątki monitorowania nie wymagają instalowania pakietów klienckich bazy danych na monitorowanym hoście, zdecydowanie zaleca się ich posiadanie do celów zarządzania. Na przykład pakiet klienta MySQL zawiera programy mysql, mysqldump, mysqlbinlog i mysqladmin, które będą używane przez ClusterControl podczas wykonywania kopii zapasowych i odzyskiwania do określonego momentu.

Metody monitorowania

W przypadku zbierania statystyk hosta i systemu równoważenia obciążenia, ClusterControl wykonuje to zadanie przez SSH z uprawnieniami superużytkownika. Dlatego też bezhasłowe SSH z uprawnieniami superużytkownika jest niezbędne, aby umożliwić ClusterControl zdalne uruchamianie niezbędnych poleceń z odpowiednią eskalacją. Takie podejście ma kilka zalet w porównaniu z innymi mechanizmami:

• Bez agenta — nie ma potrzeby instalowania, konfigurowania i utrzymywania agenta.
• Ujednolicenie konfiguracji zarządzania i monitorowania – SSH może być używany do pobierania metryk monitorowania lub zadań zarządzania push w węzłach docelowych.
• Uprość wdrożenie — jedynym wymaganiem jest prawidłowa konfiguracja SSH bez hasła i to wszystko. SSH jest również bardzo bezpieczny i szyfrowany.
• Scentralizowana konfiguracja – jeden serwer ClusterControl może zarządzać wieloma serwerami i klastrami, pod warunkiem, że ma wystarczające zasoby.

Jednak mechanizm ściągający ma również następujące wady:

• Dane monitorowania są dokładne tylko z punktu widzenia ClusterControl. Na przykład, jeśli wystąpi usterka sieci i ClusterControl utraci komunikację z monitorowanym hostem, próbkowanie zostanie pominięte do następnego dostępnego cyklu.
• Wystąpi obciążenie sieci dla monitorowania o wysokiej szczegółowości ze względu na zwiększoną częstotliwość próbkowania, w której ClusterControl musi ustanowić więcej połączeń z każdym hostem docelowym.
• ClusterControl będzie nadal próbował ponownie nawiązać połączenie z węzłem docelowym, ponieważ nie ma agenta, który mógłby to zrobić w jego imieniu.
• Nadmiarowe próbkowanie danych, jeśli masz więcej niż jeden serwer ClusterControl monitorujący klaster, ponieważ każdy serwer ClusterControl musi pobierać dane monitorowania dla siebie.

W przypadku monitorowania zapytań MySQL, począwszy od ClusterControl 1.9.0 (wydanego w lipcu 2021 r.), ClusterControl obsługuje dwa typy:

• Monitorowanie zapytań bez agentów (domyślnie)
• Monitorowanie zapytań oparte na agentach przy użyciu agenta zapytań CMON, co wymaga dodatkowych kroków, aby je włączyć. Tylko dla baz danych opartych na MySQL i PostgreSQL.

Bez agentowe monitorowanie zapytań monitoruje zapytania na dwa różne sposoby:

• Zapytania są pobierane z PERFORMANCE_SCHEMA przez odpytywanie schematu w węźle bazy danych przez SSH.
• Jeśli PERFORMANCE_SCHEMA jest wyłączona lub niedostępna, ClusterControl przeanalizuje zawartość dziennika powolnych zapytań przez SSH.

Jeśli schemat wydajności jest włączony, ClusterControl użyje go do wyszukiwania powolnych zapytań. W przeciwnym razie ClusterControl przeanalizuje zawartość dziennika powolnych zapytań MySQL (poprzez zmienną dynamiczną slow_query_log=ON) w oparciu o następujący przepływ:

1. Uruchom powolny log (podczas działania MySQL).
2. Uruchom go na krótki okres czasu (sekundę lub kilka sekund).
3. Zatrzymaj dziennik.
4. Przetwarzanie dziennika.
5. Obetnij dziennik (nowy plik dziennika).
6. Przejdź do 1.

Zebrane zapytania są haszowane, obliczane i analizowane (normalizacja, średnia, liczba, sortowanie), a następnie przechowywane w bazie danych ClusterControl CMON. Zwróć uwagę, że w przypadku tej metody próbkowania istnieje niewielka szansa, że ​​niektóre zapytania nie zostaną przechwycone, szczególnie podczas części „stop log, parse log, truncate log”. Możesz włączyć schemat wydajności, jeśli nie jest to możliwe.

Tylko zapytania, które przekraczają długi czas zapytań, zostaną tutaj wymienione przy użyciu dziennika powolnych zapytań. Załóżmy, że dane nie są prawidłowo wypełnione i uważasz, że coś tam powinno być, może to być:

• ClusterControl nie zebrał wystarczającej liczby zapytań do podsumowania i wypełnienia danych. Spróbuj obniżyć długi czas zapytań.
• Skonfigurowałeś opcje konfiguracji dziennika powolnych zapytań w my.cnf serwera MySQL, a opcja Override Local Query jest wyłączona. Jeśli naprawdę chcesz użyć wartości zdefiniowanej w my.cnf, prawdopodobnie będziesz musiał obniżyć wartość long_query_time, aby ClusterControl mógł obliczyć dokładniejszy wynik.
• Masz inny węzeł ClusterControl, który również pobiera dziennik powolnego zapytania (w przypadku, gdy masz serwer ClusterControl w stanie gotowości). Zezwól na wykonanie tego zadania tylko jednemu serwerowi ClusterControl.

Możesz także użyć monitora zapytań ClusterControl dla MySQL, MariaDB i Percona Server.

W przypadku monitorowania zapytań PostgreSQL, ClusterControl wymaga modułu pg_stat_statements do śledzenia statystyk wykonania wszystkich instrukcji SQL. Zapełnia widoki i funkcje pg_stat_statements podczas wyświetlania zapytań w interfejsie użytkownika (w zakładce Monitor zapytań).

Interwały i limity czasu

ClusterControl Controller (cmon) to proces wielowątkowy. Domyślnie wątek próbkowania ClusterControl Controller łączy się raz z każdym monitorowanym hostem i utrzymuje stałe połączenie, dopóki host nie zostanie przerwany lub rozłączony podczas próbkowania statystyk hosta. Może nawiązać więcej połączeń w zależności od zadań przypisanych do hosta, ponieważ większość zadań zarządzania działa we własnym wątku. Na przykład odzyskiwanie klastra działa w wątku odzyskiwania, wykonanie programu Advisor działa w wątku cron, a monitorowanie procesu działa w wątku kolektora procesów.

Wątek monitorujący ClusterControl wykonuje następujące operacje próbkowania w następującym przedziale czasu:

• Wskaźniki zapytań/stanu MySQL:co sekundę
• Zbieranie procesów (/proc):co 10 sekund
• Wykrywanie serwera:co 10 sekund
• Wskaźniki hosta (/proc, /sys):co 30 sekund (konfigurowalne przez host_stats_collection_interval)
• Dane bazy danych (tylko PostgreSQL i MongoDB):co 30 sekund (konfigurowalne przez db_stats_collection_interval)
• Dane schematu bazy danych:co 3 godziny (konfigurowalne przez db_schema_stats_collection_interval)
• Wskaźniki równoważenia obciążenia:co 15 sekund (konfigurowalne przez lb_stats_collection_interval)

Skrypty imperatywne (Advisors) mogą korzystać z bibliotek klienckich SSH i baz danych, które są dostarczane z CMON, z następującymi ograniczeniami:

• 5 sekund twardego limitu na wykonanie SSH.
• 10 sekund domyślnego limitu połączenia z bazą danych, konfigurowalne przez net_read_timeout, net_write_timeout, connect_timeout w pliku konfiguracyjnym CMON.
• 60 sekund całkowitego limitu czasu wykonania skryptu, zanim CMON niewdzięcznie go przerwie.

Doradców można tworzyć, kompilować, testować i planować bezpośrednio z interfejsu użytkownika ClusterControl w Zarządzaj → Developer Studio . Poniższy zrzut ekranu przedstawia przykład Doradcy, który wyodrębnia 10 najpopularniejszych zapytań z PERFORMANCE_SCHEMA:

Wykonywanie doradców zależy od tego, czy jest aktywowany, a czas planowania w formacie crona:

Wyniki wykonania są wyświetlane w sekcji Wydajność → Doradcy , jak pokazano na poniższym zrzucie ekranu:

Aby uzyskać więcej informacji na temat domyślnie udostępnianych doradców, zapoznaj się z naszym Programistą Strona produktu Studio.

Dane są przechowywane bezpośrednio w bazie danych CMON w celu monitorowania danych w krótkich odstępach czasu, takich jak zapytania MySQL i stan. Dane z monitorowania w długim okresie, takie jak tygodniowe/miesięczne/roczne punkty danych, są agregowane co 60 sekund i przechowywane w pamięci przez 10 minut. Te zachowania nie są konfigurowalne ze względu na projekt architektury.

Parametry

ClusterControl ma wiele parametrów, które pasują do Twojej polityki monitorowania i ostrzegania. Większość z nich można skonfigurować za pomocą interfejsu ClusterControl → wybierz klaster → Ustawienia . Zakładka „Ustawienia” udostępnia wiele opcji konfiguracji alertów, progów, powiadomień, układu wykresów, liczników baz danych, monitorowania zapytań i tak dalej. Na przykład progi ostrzegawcze i krytyczne można skonfigurować w następujący sposób:

Strona „Runtime Configuration” zawiera podsumowaną listę aktywnych kontrolerów ClusterControl (CMON) parametry konfiguracyjne środowiska wykonawczego:

Istnieje łącznie ponad 170 opcji konfiguracyjnych ClusterControl Controller, a niektóre zaawansowane ustawienia mogą być konfigurowane dostrajanie polityki monitorowania i alertów. Niektóre z nich to:

• monitor_cpu_temperature
• swap_warning
• swap_critical
• redobuffer_warning
• redobuffer_critical
• indexmemory_warning
• indexmemory_critical
• datamemory_warning
• datamemory_critical
• tablespace_warning
• tablespace_critical
• redolog_warning
• redolog_critical
• max_replication_lag
• long_query_time
• log_queries_not_using_indexes
• query_monitor_use_local_settings
• enable_query_monitor
• enable_query_monitor_auto_purge_ps

Możesz zmienić parametry wymienione na stronie „Konfiguracja środowiska wykonawczego” za pomocą pliku konfiguracyjnego interfejsu użytkownika lub CMON znajdującego się w /etc/cmon.d/cmon_X.cnf, gdzie X jest identyfikatorem klastra. Możesz wyświetlić listę wszystkich obsługiwanych opcji konfiguracyjnych dla CMON, używając następującego polecenia:

$ cmon --help-config

Ostateczne myśli

Monitorowanie bez agentów stało się jedną z najskuteczniejszych metod zarządzania coraz bardziej złożonymi infrastrukturami baz danych. Zmniejsza obciążenie wielu wyzwań związanych z monitorowaniem baz danych i jest łatwe w zarządzaniu.

Obecnie dostępnych jest wiele narzędzi do monitorowania bez agentów. Jednak niewiele z nich oferuje również kompletną platformę pełną funkcji ułatwiających zarządzanie każdym innym aspektem klastrów baz danych. Aby zobaczyć, co jeszcze może zrobić ClusterControl, pobierz własną bezpłatną 30-dniową wersję próbną.

Szukasz opartej na agentach alternatywy dla monitorowania baz danych? Sprawdź infrastrukturę monitorowania baz danych opartą na agentach ClusterControl — SCUMM.