ClusterControl 1.7.0 představuje novou odvážnou funkci – integraci s Prometheus pro monitorování založené na agentech. Nazvali jsme to SCUMM (Severalnines ClusterControl Unified Management and Monitoring). V předchozích verzích byly úkoly monitorování prováděny pouze bez agenta. Pokud vás zajímá, jak ClusterControl provádí své monitorovací funkce, podívejte se na tuto stránku dokumentace.
ProxySQL, vysoce výkonný reverzní proxy server, který rozumí protokolům MySQL, je běžně umístěn na vrcholu replikace MySQL a Galera Cluster, aby fungoval jako brána k backendové službě MySQL. Lze jej nakonfigurovat jako směrovač dotazů, firewall dotazů, ukládání do mezipaměti dotazů, dispečer provozu a mnoho dalších. ProxySQL také shromažďuje a odhaluje klíčové metriky prostřednictvím svého schématu STATS, které je velmi užitečné pro analýzu výkonu a pochopení toho, co se skutečně děje v zákulisí. Navštivte náš komplexní výukový program pro ProxySQL, kde se o něm dozvíte více.
V tomto příspěvku na blogu se podíváme na podrobné monitorování instancí ProxySQL pomocí tohoto nového přístupu. V tomto příkladu máme instanci ProxySQL nad naší dvouuzlovou replikací MySQL (1 hlavní, 1 podřízená) nasazenou prostřednictvím ClusterControl. Naše architektura na vysoké úrovni vypadá asi takto:
V instanci ProxySQL máme také definovaná následující pravidla dotazů (jen pro informaci, abychom dali smysl shromážděným metrikám monitorování níže):
Aktivace Promethea
Monitorování založené na agentech ClusterControl je povoleno pro každý cluster. ClusterControl pro vás může nasadit nový server Prometheus nebo použít stávající server Prometheus (nasazený společností ClusterControl pro jiný cluster). Povolit Prometheus je docela jednoduché. Stačí přejít na ClusterControl -> vybrat cluster -> Řídicí panely -> Povolit monitorování založené na agentech:
Poté zadejte IP adresu nebo název hostitele nového serveru Prometheus nebo jednoduše vyberte existujícího hostitele Prometheus z rozevírací nabídky:
ClusterControl nainstaluje a nakonfiguruje potřebné balíčky (Prometheus na serveru Prometheus, exportéry na databázi a uzly ProxySQL), připojí se k Prometheus jako zdroji dat a začne vizualizovat data monitorování v uživatelském rozhraní.
Po dokončení úlohy nasazení byste měli mít přístup ke kartě Řídicí panely, jak je znázorněno v další části.
ProxySQL Dashboard
K řídicím panelům ProxySQL můžete přistupovat tak, že přejdete do příslušného clusteru na kartě Řídicí panely. Kliknutím na rozbalovací nabídku Dashboard zobrazíte seznam dashboardů souvisejících s naším clusterem (MySQL Replication). Řídicí panel ProxySQL Overview můžete najít v sekci "Load Balancers":
Pro ProxySQL existuje řada panelů, některé z nich jsou samozřejmé. Nicméně pojďme je jednoho po druhém navštívit.
Velikost hostitelské skupiny
Velikost hostitelské skupiny je jednoduše celkový počet hostitelů ve všech hostitelských skupinách:
V tomto případě máme dvě hostitelské skupiny – 10 (zapisovatel) a 20 (čtenář). Hostgroup 10 se skládá z jednoho hostitele (master), zatímco hostitelská skupina 20 má dva hostitele (master a slave), což dohromady tvoří tři hostitele.
Pokud nezměníte konfiguraci hostitelské skupiny (zavedete nového hostitele, odeberete stávajícího) z ProxySQL, měli byste očekávat, že se v tomto grafu nic nezmění.
Připojení klientů
Počet klientských připojení zpracovávaných ProxySQL pro všechny hostitelské skupiny:
Výše uvedený graf nám jednoduše říká, že k naší instanci ProxySQL na portu 6033 je za posledních 45 minut trvale připojeno 8 klientů MySQL (můžete to změnit pod volbou „Výběr rozsahu“). Pokud přestanete připojovat svou aplikaci k ProxySQL (nebo ji obejdete), hodnota by nakonec měla klesnout na 0.
Dotazy klientů
Graf zobrazuje počet otázek zpracovávaných ProxySQL pro všechny hostitelské skupiny:
Podle dokumentace MySQL jsou otázky jednoduše počet příkazů provedených serverem. To zahrnuje pouze příkazy zaslané na server klienty a nikoli příkazy prováděné v rámci uložených programů, na rozdíl od proměnné Queries. Tato proměnná nepočítá příkazy COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE nebo COM_STMT_RESET. Znovu, pokud přestanete připojovat svou aplikaci k ProxySQL (nebo ji obejdete), hodnota by měla klesnout na 0.
Aktivní připojení backend
Počet připojení, která ProxySQL udržuje k backendovým serverům MySQL na hostitele:
Jednoduše nám říká, kolik připojení aktuálně používá ProxySQL pro odesílání dotazů na backend server. Pokud se maximální hodnota neblíží limitu připojení pro konkrétní server (nastaveno pomocí max_connections když je server přidán do hostitelské skupiny ProxySQL), jsme v dobrém stavu.
Selhala připojení backendu
Počet připojení, která nebyla úspěšně navázána pomocí ProxySQL:
Výše uvedený příklad jednoduše ukazuje, že za posledních 45 minut nedošlo k žádné chybě back-endového připojení.
Směrované dotazy
Tento graf poskytuje přehled o distribuci příchozích příkazů na backend servery:
Jak můžete vidět, většina čtení jde do hostitelské skupiny čtenářů (HG20). Odtud můžeme porozumět vzoru vyvažování, který provádí ProxySQL a který odpovídá našim pravidlům dotazů v této zátěži náročné na čtení.
Připojení zdarma
Graf ukazuje, kolik připojení je aktuálně volných:
Spojení jsou udržována otevřená, aby se minimalizovaly časové náklady na odesílání dotazu na backend server.
Latence
Aktuální čas pingu v mikrosekundách, jak je hlášeno z vlákna monitorování ProxySQL:
To nám jednoduše říká, jak stabilní je připojení z ProxySQL k backendovým serverům MySQL. Vysoká hodnota po dlouhou konzistentní dobu většinou indikuje problém se sítí mezi nimi.
Dotaz na mezipaměť
Tento graf zobrazuje spotřebu paměti u dotazů, které jsou ukládány do mezipaměti ProxySQL:
Z výše uvedeného grafu můžeme říci, že ProxySQL spotřebovává celkem 8 MB paměti cache dotazů. Jakmile dosáhne limitu 8 MB (lze konfigurovat pomocí mysql-query_cache_size_MB proměnná), paměť bude vyčištěna podprocesem čištění ProxySQL. Pokud nemáte definováno žádné pravidlo mezipaměti dotazů, tento graf se nevyplní.
Mimochodem, ukládání dotazu do mezipaměti v ProxySQL lze provést pomocí ClusterControl pouhými dvěma kliknutími. Přejděte na stránku Nejčastější dotazy ProxySQL, přejděte na dotaz, klikněte na Mezipaměť dotazů a klikněte na „Přidat pravidlo“:
Efektivita mezipaměti dotazů
Tento graf znázorňuje efektivitu dotazů uložených v mezipaměti:
Modrá čára nám říká úspěšný poměr požadavků GET provedených proti mezipaměti dotazů, kde byla sada výsledků přítomna a nevypršela její platnost. Růžová čára ukazuje poměr dat zapsaných (vložení) do nebo přečtených z mezipaměti dotazů. V tomto případě jsou naše data načtená z Query Cache vyšší než data zapsaná, což naznačuje efektivní konfiguraci cache.
Pokud nemáte definováno žádné pravidlo mezipaměti dotazů, tento graf se nevyplní.
Provoz v síti
Tento graf vizualizuje síťový provoz (přijímaná data + odeslaná data) z/na backendové servery MySQL podle hostitele:
Výše uvedený snímek obrazovky nám říká, že značné množství provozu je předáváno/přijímáno z/do hostitelské skupiny čtenářů (HG20). Při této zátěži náročné na čtení spotřebovávají operace čtení běžně mnohem vyšší provoz, hlavně kvůli velikosti sady výsledků příkazů SELECT.
Pouze menší poměr provozu je předáván/přijímán z/do skupiny hostitelů pro zápis (HG10), což se očekává, protože operace zápisu obvykle spotřebují méně síťového provozu a klientům se vrací výrazně malá sada výsledků.
Účinnost zrcadlení
Graf jednoduše ukazuje stav související se zrcadlením provozu, jako je Mirror_concurrency vs Mirror_queue_length:
Graf se vyplní pouze v případě, že jste nakonfigurovali zrcadlení provozu (mirror_hostgroup uvnitř pravidla dotazu). Pokud se fronta zrcadlení sbírá, snížení limitu souběžnosti zrcadlení zvýší efektivitu zrcadlení, kterou lze ovládat pomocí mysql-mirror_max_concurrency variabilní. Jednoduše řečeno, nulové položky fronty jsou tím nejúčinnějším zrcadlením.
Využití paměti
Graf ukazuje využití paměti hlavními komponentami uvnitř ProxySQL – fond připojení, mezipaměť dotazů a trvalé úložiště (SQLite):
Výše uvedený snímek obrazovky nám říká, že paměťová stopa ProxySQL je poměrně malá, což je celkem méně než 12 MB. Fond připojení spotřebovává pouze 1,3 MB horní části, aby se přizpůsobil naší 8vláknové (klientské) zátěži. S více volnou RAM dostupnou na hostiteli bychom měli být schopni trojnásobně až čtyřnásobně zvýšit počet klientských připojení k ProxySQL nebo ukládat do ProxySQL mnohem více horkých dotazů, abychom vytížili naše backendové servery MySQL.
Bonusová funkce – výkon uzlu
ClusterControl 1.7.0 nyní obsahuje metriky výkonu hostitele pro instance ProxySQL. V předchozí verzi ClusterControl monitoroval pouze metriky související s ProxySQL, jak byly odhaleny ve statistickém schématu ProxySQL. Tato nová funkce je přístupná na kartě Node -> Instance ProxySQL -> Výkon uzlu:
Histogramy poskytují náhled na klíčové metriky hostitele, podobné těm, které jsou vzorkovány pro databázové uzly v části Nodes -> Overview. Pokud je vaše instance ProxySQL umístěna na stejném serveru s aplikací, doslova používáte ClusterControl také k monitorování aplikačního serveru. Jak skvělé to je?!
Poslední myšlenky
Integrace ClusterControl s Prometheus nabízí alternativní způsob monitorování a analýzy vašeho databázového zásobníku až do úrovně reverzního proxy. Nyní máte možnost přesunout úlohy monitorování na Prometheus, nebo pokračovat v používání výchozího přístupu k monitorování bez agentů ClusterControl pro vaši databázovou infrastrukturu.