ClusterControl 1.7.0 wprowadza nową, odważną funkcję - integrację z Prometheus w celu monitorowania opartego na agentach. Nazwaliśmy to SCUMM (Severalnines ClusterControl Unified Management and Monitoring). W poprzednich wersjach zadania monitorowania były wykonywane wyłącznie bez agentów. Jeśli zastanawiasz się, jak ClusterControl wykonuje swoje funkcje monitorowania, sprawdź tę stronę dokumentacji.
ProxySQL, wysokowydajny reverse-proxy, który rozumie protokoły MySQL, często znajduje się na szczycie MySQL Replication i Galera Cluster, aby działać jako brama do backendowej usługi MySQL. Może być skonfigurowany jako router zapytań, firewall zapytań, buforowanie zapytań, dyspozytor ruchu i wiele innych. ProxySQL zbiera również i udostępnia kluczowe metryki za pomocą schematu STATS, który jest bardzo przydatny do analizy wydajności i zrozumienia, co faktycznie dzieje się za kulisami. Odwiedź nasz obszerny samouczek dotyczący ProxySQL, aby dowiedzieć się więcej na ten temat.
W tym poście na blogu przyjrzymy się dogłębnemu monitorowaniu instancji ProxySQL za pomocą tego nowego podejścia. W tym przykładzie mamy instancję ProxySQL nad naszą dwuwęzłową replikacją MySQL (1 master, 1 slave), wdrożoną za pośrednictwem ClusterControl. Nasza architektura wysokiego poziomu wygląda mniej więcej tak:
Mamy również następujące reguły zapytań zdefiniowane w instancji ProxySQL (tylko w celach informacyjnych, aby zrozumieć zebrane metryki monitorowania w dalszej części):
Włączanie Prometeusza
Monitorowanie oparte na agentach ClusterControl jest włączone dla każdego klastra. ClusterControl może wdrożyć dla Ciebie nowy serwer Prometheus lub użyć istniejącego serwera Prometheus (wdrożonego przez ClusterControl dla innego klastra). Włączenie Prometeusza jest dość proste. Po prostu przejdź do ClusterControl -> wybierz klaster -> Pulpity nawigacyjne -> Włącz monitorowanie oparte na agentach:
Następnie określ adres IP lub nazwę hosta nowego serwera Prometheus lub po prostu wybierz istniejącego hosta Prometheus z listy rozwijanej:
ClusterControl zainstaluje i skonfiguruje niezbędne pakiety (Prometheus na serwerze Prometheus, eksportery w bazie danych i węzły ProxySQL), połączy się z Prometheusem jako źródłem danych i rozpocznie wizualizację danych monitorowania w interfejsie użytkownika.
Po zakończeniu zadania wdrażania powinieneś być w stanie uzyskać dostęp do karty Pulpity nawigacyjne, jak pokazano w następnej sekcji.
Panel ProxySQL
Dostęp do pulpitów nawigacyjnych ProxySQL można uzyskać, przechodząc do odpowiedniego klastra w zakładce Pulpity nawigacyjne. Kliknięcie w menu rozwijane Dashboard spowoduje wyświetlenie pulpitów nawigacyjnych związanych z naszym klastrem (replikacja MySQL). Pulpit nawigacyjny Przegląd ProxySQL można znaleźć w sekcji „Systemy równoważenia obciążenia”:
Istnieje wiele paneli dla ProxySQL, niektóre z nich nie wymagają wyjaśnień. Niemniej jednak odwiedźmy je jeden po drugim.
Rozmiar grupy hostów
Rozmiar grupy hostów to po prostu całkowita liczba hostów we wszystkich grupach hostów:
W tym przypadku mamy dwie grupy hostów - 10 (writer) i 20 (reader). Grupa hostów 10 składa się z jednego hosta (master), podczas gdy grupa hostów 20 ma dwa hosty (master i slave), co w sumie daje trzy hosty.
O ile nie zmienisz konfiguracji grupy hostów (wprowadzisz nowy host, usuniesz istniejący host) z ProxySQL, powinieneś oczekiwać, że nic się nie zmieni na tym wykresie.
Połączenia klienta
Liczba połączeń klientów przetwarzanych przez ProxySQL dla wszystkich grup hostów:
Powyższy wykres mówi nam po prostu, że przez ostatnie 45 minut z naszą instancją ProxySQL na porcie 6033 stale połączonych jest 8 klientów MySQL (możesz to zmienić w opcji „Wybór zakresu”). Jeśli przestaniesz łączyć swoją aplikację z ProxySQL (lub go ominiesz), wartość powinna ostatecznie spaść do 0.
Pytania klientów
Wykres przedstawia liczbę pytań przetwarzanych przez ProxySQL dla wszystkich grup hostów:
Zgodnie z dokumentacją MySQL, pytania to po prostu liczba instrukcji wykonywanych przez serwer. Obejmuje to tylko instrukcje wysyłane do serwera przez klientów, a nie instrukcje wykonywane w programach przechowywanych, w przeciwieństwie do zmiennej Queries. Ta zmienna nie liczy poleceń COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE ani COM_STMT_RESET. Ponownie, jeśli przestaniesz łączyć swoją aplikację z ProxySQL (lub go ominiesz), wartość powinna spaść do 0.
Aktywne połączenia zaplecza
Liczba połączeń, które ProxySQL utrzymuje z serwerami zaplecza MySQL na host:
Po prostu mówi nam, ile połączeń jest obecnie używanych przez ProxySQL do wysyłania zapytań do serwera zaplecza. Dopóki maksymalna wartość nie jest zbliżona do limitu połączeń dla konkretnego serwera (ustawionego przez max_connections gdy serwer zostanie dodany do grupy hostów ProxySQL), jesteśmy w dobrej formie.
Nieudane połączenia zaplecza
Liczba połączeń, które nie zostały pomyślnie nawiązane przez ProxySQL:
Powyższy przykład pokazuje po prostu, że w ciągu ostatnich 45 minut nie wystąpiła awaria połączenia zaplecza.
Kwerendy kierowane
Ten wykres zapewnia wgląd w dystrybucję przychodzących wyciągów na serwery zaplecza:
Jak widać, większość odczytów trafia do grupy hosta czytnika (HG20). Stąd możemy zrozumieć wzorzec równoważenia wykonywany przez ProxySQL, który pasuje do naszych reguł zapytań w tym intensywnym obciążeniu.
Bezpłatne połączenie
Wykres pokazuje, ile połączeń jest obecnie wolnych:
Połączenia są utrzymywane otwarte, aby zminimalizować koszt czasu wysyłania zapytania do serwera zaplecza.
Opóźnienie
Bieżący czas pingowania w mikrosekundach, zgłoszony z wątku monitorowania ProxySQL:
To po prostu mówi nam, jak stabilne jest połączenie między ProxySQL a serwerami zaplecza MySQL. Wysoka wartość przez długi, stały czas wskazuje głównie na problem z siecią między nimi.
Pamięć pamięci podręcznej zapytań
Ten wykres wizualizuje zużycie pamięci przez zapytania, które są buforowane przez ProxySQL:
Z powyższego wykresu możemy powiedzieć, że ProxySQL zużywa łącznie 8 MB pamięci przez pamięć podręczną zapytań. Po osiągnięciu limitu 8 MB (konfigurowalne przez mysql-query_cache_size_MB zmienna), pamięć zostanie wyczyszczona przez wątek czyszczenia ProxySQL. Ten wykres nie zostanie wypełniony, jeśli nie masz zdefiniowanej reguły pamięci podręcznej zapytań.
Nawiasem mówiąc, buforowanie zapytania w ProxySQL można wykonać za pomocą zaledwie dwóch kliknięć za pomocą ClusterControl. Przejdź do strony Najczęstsze zapytania ProxySQL, najedź kursorem na zapytanie, kliknij Pamięć podręczna zapytań i kliknij „Dodaj regułę”:
Wydajność pamięci podręcznej zapytań
Ten wykres przedstawia wydajność zapytań w pamięci podręcznej:
Niebieska linia informuje nas o pomyślnym stosunku żądań GET wykonanych względem pamięci podręcznej zapytań, w której zestaw wyników był obecny i nie wygasł. Różowa linia pokazuje stosunek danych zapisanych (wstawionych) do lub odczytanych z pamięci podręcznej zapytań. W tym przypadku nasze dane odczytane z pamięci podręcznej zapytań są wyższe od danych zapisanych, co wskazuje na wydajną konfigurację pamięci podręcznej.
Ten wykres nie zostanie wypełniony, jeśli nie masz zdefiniowanej reguły pamięci podręcznej zapytań.
Ruch sieciowy
Ten wykres wizualizuje ruch sieciowy (odbieranie danych + wysyłanie danych) z/do serwerów zaplecza MySQL, na host:
Powyższy zrzut ekranu mówi nam, że znaczna ilość ruchu jest przekazywana/odbierana z/do grupy hostów czytnika (HG20). W tym obciążeniu intensywnym odczyty operacje odczytu zwykle pochłaniają znacznie większy ruch, głównie ze względu na rozmiar zestawu wyników instrukcji SELECT.
Tylko mniejszy stosunek ruchu jest przekazywany/odbierany z/do grupy hostów zapisu (HG10), czego można się spodziewać, ponieważ operacje zapisu zwykle zużywają mniej ruchu sieciowego, a do klientów zwracany jest znacznie mniejszy zestaw wyników.
Wydajność odbicia lustrzanego
Wykres po prostu pokazuje stan związany z dublowaniem ruchu, np. Mirror_concurrency vs Mirror_queue_length:
Wykres jest wypełniany tylko wtedy, gdy skonfigurowano dublowanie ruchu (mirror_hostgroup wewnątrz reguły zapytania). Jeśli kolejka kopii lustrzanych się podnosi, zmniejszenie limitu współbieżności tworzenia kopii lustrzanych zwiększy wydajność tworzenia kopii lustrzanych, którą można kontrolować za pomocą mysql-mirror_max_concurrency zmienny. Mówiąc prościej, wpisy z zerową kolejką są tym, o co chodzi w najbardziej wydajnym dublowaniu.
Wykorzystanie pamięci
Wykres ilustruje wykorzystanie pamięci przez główne komponenty w ProxySQL - pulę połączeń, pamięć podręczną zapytań i pamięć trwałą (SQLite):
Powyższy zrzut ekranu mówi nam, że rozmiar pamięci ProxySQL jest raczej niewielki, czyli łącznie mniej niż 12 MB. Pula połączeń zajmuje tylko 1,3 MB, aby obsłużyć nasze 8-wątkowe (klienci) obciążenie. Mając więcej wolnej pamięci RAM dostępnej na hoście, powinniśmy być w stanie zwiększyć liczbę połączeń klientów z ProxySQL od trzykrotnego do czterokrotnego lub buforować znacznie więcej gorących zapytań w ProxySQL, aby odciążyć nasze serwery zaplecza MySQL.
Funkcja dodatkowa — wydajność węzła
ClusterControl 1.7.0 zawiera teraz metryki wydajności hosta dla instancji ProxySQL. W poprzedniej wersji program ClusterControl monitorował tylko metryki związane z ProxySQL, które zostały ujawnione przez schemat statystyk ProxySQL. Dostęp do tej nowej funkcji można uzyskać w zakładce Node -> Instancja ProxySQL -> Wydajność węzła:
Histogramy zapewniają wgląd w kluczowe metryki hosta, podobnie jak w przypadku węzłów bazy danych w sekcji Węzły -> Przegląd. Jeśli instancja ProxySQL znajduje się w tym samym serwerze co aplikacja, dosłownie używasz ClusterControl do monitorowania serwera aplikacji. Jakie to fajne?!
Ostateczne myśli
Integracja ClusterControl z Prometheusem oferuje alternatywny sposób monitorowania i analizowania stosu bazy danych, aż do warstwy odwrotnego proxy. Masz teraz możliwość przeniesienia zadań monitorowania do Prometheusa lub dalszego korzystania z domyślnego podejścia do monitorowania bezagentowego ClusterControl dla infrastruktury bazy danych.
