ClusterControl 1.7.0 introducerar en djärv ny funktion - integration med Prometheus för agentbaserad övervakning. Vi kallade detta SCUMM (Severalnines ClusterControl Unified Management and Monitoring). I de tidigare versionerna utfördes övervakningsuppgifterna enbart agentlöst. Om du undrar hur ClusterControl utför sina övervakningsfunktioner, kolla in den här dokumentationssidan.
ProxySQL, en högpresterande omvänd proxy som förstår MySQL-protokoll, sitter vanligtvis ovanpå MySQL Replication och Galera Cluster för att fungera som en gateway till backend MySQL-tjänsten. Den kan konfigureras som en frågerouter, frågebrandvägg, frågecache, trafikledare och många fler. ProxySQL samlar också in och exponerar nyckelmått via sitt STATS-schema vilket är mycket användbart för att analysera prestanda och förstå vad som faktiskt händer bakom kulisserna. Besök vår omfattande handledning för ProxySQL för att lära dig mer om det.
I det här blogginlägget kommer vi att undersöka djupgående övervakning av ProxySQL-instanserna med detta nya tillvägagångssätt. I det här exemplet har vi en ProxySQL-instans ovanpå vår MySQL-replikering med två noder (1 master, 1 slav), distribuerad via ClusterControl. Vår högnivåarkitektur ser ut ungefär så här:
Vi har också följande frågeregler definierade i ProxySQL-instansen (bara för referens, för att förstå de insamlade övervakningsmåtten längre ner):
Aktivera Prometheus
ClusterControls agentbaserade övervakning är aktiverad per kluster. ClusterControl kan distribuera en ny Prometheus-server åt dig eller använda en befintlig Prometheus-server (distribueras av ClusterControl för andra kluster). Att aktivera Prometheus är ganska enkelt. Gå bara till ClusterControl -> välj klustret -> Dashboards -> Aktivera agentbaserad övervakning:
Ange sedan IP-adressen eller värdnamnet för den nya Prometheus-servern, eller välj bara en befintlig Prometheus-värd från rullgardinsmenyn:
ClusterControl kommer att installera och konfigurera nödvändiga paket (Prometheus på Prometheus-servern, exportörer på databasen och ProxySQL-noder), ansluta till Prometheus som datakälla och börja visualisera övervakningsdata i användargränssnittet.
När distributionsjobbet är klart bör du kunna komma åt fliken Dashboards som visas i nästa avsnitt.
ProxySQL Dashboard
Du kan komma åt ProxySQL Dashboards genom att gå till respektive kluster under Dashboards-fliken. Genom att klicka på rullgardinsmenyn Dashboard visas instrumentpaneler relaterade till vårt kluster (MySQL-replikering). Du hittar ProxySQL Overview-instrumentpanelen under avsnittet "Load Balancers":
Det finns ett antal paneler för ProxySQL, några av dem är självförklarande. Men låt oss besöka dem en efter en.
Värdgruppsstorlek
Värdgruppsstorlek är helt enkelt det totala antalet värdar på alla värdgrupper:
I det här fallet har vi två värdgrupper - 10 (författare) och 20 (läsare). Värdgrupp 10 består av en värd (master) medan värdgrupp 20 har två värdar (master och slav), vilket summerar till totalt tre värdar.
Om du inte ändrar värdgruppskonfigurationen (introducerar ny värd, tar bort befintlig värd) från ProxySQL, bör du förvänta dig att ingenting kommer att förändras i denna graf.
Klientanslutningar
Antalet klientanslutningar som bearbetas av ProxySQL för alla värdgrupper:
Grafen ovan berättar helt enkelt för oss att det konsekvent finns 8 MySQL-klienter anslutna till vår ProxySQL-instans på port 6033 under de senaste 45 minuterna (du kan ändra detta under alternativet "Range Selection"). Om du slutar ansluta din applikation till ProxySQL (eller kringgår den), bör värdet så småningom sjunka till 0.
Kundfrågor
Grafen visualiserar antalet frågor som behandlas av ProxySQL för alla värdgrupper:
Enligt MySQL-dokumentationen är frågor helt enkelt antalet satser som körs av servern. Detta inkluderar endast satser som skickas till servern av klienter och inte satser som körs i lagrade program, till skillnad från variabeln Queries. Denna variabel räknar inte kommandon COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE eller COM_STMT_RESET. Återigen, om du slutar ansluta din applikation till ProxySQL (eller kringgår den), bör värdet sjunka till 0.
Aktiva backend-anslutningar
Antalet anslutningar som ProxySQL upprätthåller till backend-MySQL-servrarna per värd:
Det berättar helt enkelt för oss hur många anslutningar som för närvarande används av ProxySQL för att skicka frågor till backend-servern. Så länge maxvärdet inte är nära anslutningsgränsen för den specifika servern (inställt via max_connections när servern läggs till i ProxySQL-värdgruppen), är vi i bra form.
Misslyckade backend-anslutningar
Antalet anslutningar som inte upprättades framgångsrikt av ProxySQL:
Exemplet ovan visar helt enkelt att inget backend-anslutningsfel inträffade under de senaste 45 minuterna.
Frågor dirigerades
Det här diagrammet ger insikt i distributionen av inkommande uttalanden till backend-servrarna:
Som du kan se går de flesta läsningarna till läsarvärdgruppen (HG20). Härifrån kan vi förstå balanseringsmönstret som utförs av ProxySQL som matchar våra frågeregler i denna läsintensiva arbetsbelastning.
Anslutningsfri
Grafen visar hur många anslutningar som för närvarande är lediga:
Anslutningarna hålls öppna för att minimera tidskostnaden för att skicka en fråga till backend-servern.
Latens
Den aktuella pingtiden i mikrosekunder, som rapporterats från ProxySQL-övervakningstråden:
Detta berättar helt enkelt för oss hur stabil anslutningen är från ProxySQL till backend MySQL-servrarna. Högt värde under en lång konsekvent tid indikerar oftast nätverksproblem mellan dem.
Fråga cacheminne
Det här diagrammet visualiserar minnesförbrukningen för frågor som cachelagras av ProxySQL:
Från grafen ovan kan vi säga att ProxySQL förbrukar en total mängd av 8 MB minne av frågecachen. När den når 8MB-gränsen (konfigurerbar via mysql-query_cache_size_MB variabel), kommer minnet att renas av ProxySQL:s rensningstråd. Det här diagrammet kommer inte att fyllas i om du inte har definierat någon regel för frågecache.
Förresten, cachning av en fråga i ProxySQL kan göras med bara två klick med ClusterControl. Gå till ProxySQL:s Top Queries-sida, rulla över en fråga, klicka på Query Cache och klicka på "Lägg till regel":
Frågecacheeffektivitet
Det här diagrammet visualiserar effektiviteten hos cachade frågor:
Den blå linjen talar om för oss det framgångsrika förhållandet mellan GET-förfrågningar som körs mot frågecachen där resultatuppsättningen fanns och inte löpte ut. Den rosa linjen visar förhållandet mellan data som skrivits (infogats) i eller lästs från frågecachen. I det här fallet är vår data som läses från Query Cache högre från data som skrivs vilket indikerar en effektiv cachekonfiguration.
Det här diagrammet kommer inte att fyllas i om du inte har definierat någon regel för frågecache.
Nätverkstrafik
Den här grafen visualiserar nätverkstrafiken (datamottagning + data skickas) från/till backend MySQL-servrarna, per värd:
Ovanstående skärmdump berättar att en betydande mängd trafik vidarebefordras/mottas från/till läsarvärdgruppen (HG20). I denna läsintensiva arbetsbelastning förbrukar läsoperationer vanligtvis mycket mer trafik, främst på grund av storleken på resultatuppsättningen på SELECT-satserna.
Endast en mindre andel av trafiken vidarebefordras/mottas från/till skrivvärdgruppen (HG10), vilket förväntas eftersom skrivoperationerna vanligtvis förbrukar mindre nätverkstrafik med en betydligt liten resultatuppsättning som returneras till klienterna.
Speglingseffektivitet
Grafen visar helt enkelt trafikspeglingsrelaterade status som Mirror_concurrency vs Mirror_queue_length:
Grafen fylls bara i om du har konfigurerat trafikspegling (mirror_hostgroup inuti frågeregeln). Om speglingskön plockar upp, kommer en minskning av speglingssamtidsgränsen att öka speglingseffektiviteten, som kan styras via mysql-mirror_max_concurrency variabel. Med enkla ord, noll köposter är vad den mest effektiva speglingen handlar om.
Minnesanvändning
Grafen illustrerar minnesanvändningen av huvudkomponenterna i ProxySQL - anslutningspool, frågecache och beständig lagring (SQLite):
Ovanstående skärmdump berättar att ProxySQL-minnets fotavtryck är ganska litet, vilket är mindre än 12 MB totalt. Anslutningspoolen förbrukar bara 1,3 MB toppar för att klara vår 8-tråds (klienter) arbetsbelastning. Med mer ledigt RAM tillgängligt på värden borde vi kunna öka antalet klientanslutningar till ProxySQL med tre till fyra gånger eller cache mycket fler heta frågor inuti ProxySQL för att avlasta våra MySQL-backend-servrar.
Bonusfunktion - Nodprestanda
ClusterControl 1.7.0 innehåller nu mätvärden för värdprestanda för ProxySQL-instanserna. I den tidigare versionen övervakade ClusterControl endast de ProxySQL-relaterade mätvärdena som exponerades av ProxySQL-statistikschemat. Den här nya funktionen kan nås under Nodens flik -> ProxySQL-instans -> Nodprestanda:
Histogrammen ger insikt i nyckelvärdens mätvärden, liknande det som samplas för databasnoder under avsnittet Noder -> Översikt. Om din ProxySQL-instans är samlokaliserad på samma server som applikationen använder du bokstavligen ClusterControl för att också övervaka applikationsservern. Hur coolt är det?!
Sluta tankar
ClusterControl-integrering med Prometheus erbjuder ett alternativt sätt att övervaka och analysera din databasstack, fram till den omvända proxynivån. Du kan nu välja att överföra övervakningsjobben till Prometheus, eller fortsätta att använda den förinställda ClusterControl agentlösa övervakningsmetoden för din databasinfrastruktur.