ClusterControl 1.7.0 introducerer en fed ny funktion - integration med Prometheus til agentbaseret overvågning. Vi kaldte dette SCUMM (Severalnines ClusterControl Unified Management and Monitoring). I de tidligere versioner blev overvågningsopgaverne udelukkende udført agentløst. Hvis du undrer dig over, hvordan ClusterControl udfører sine overvågningsfunktioner, så tjek denne dokumentationsside.
ProxySQL, en højtydende omvendt proxy, som forstår MySQL-protokoller, sidder almindeligvis oven på MySQL Replication og Galera Cluster for at fungere som en gateway til backend MySQL-tjenesten. Den kan konfigureres som en forespørgselsrouter, forespørgselsfirewall, forespørgselscache, trafikafsender og mange flere. ProxySQL indsamler og eksponerer også nøglemålinger via sit STATS-skema, som er meget nyttigt til at analysere ydeevne og forstå, hvad der faktisk sker bag kulisserne. Besøg vores omfattende selvstudie til ProxySQL for at lære mere om det.
I dette blogindlæg skal vi se nærmere på at overvåge ProxySQL-forekomsterne i dybden med denne nye tilgang. I dette eksempel har vi en ProxySQL-instans oven på vores to-node MySQL-replikering (1 master, 1 slave), implementeret via ClusterControl. Vores højniveauarkitektur ser nogenlunde sådan ud:
Vi har også følgende forespørgselsregler defineret i ProxySQL-forekomsten (bare til reference, for at give mening i de indsamlede overvågningsmetrikker længere nede):
Aktivering af Prometheus
ClusterControls agentbaserede overvågning er aktiveret pr. klynge. ClusterControl kan implementere en ny Prometheus-server for dig eller bruge en eksisterende Prometheus-server (implementeret af ClusterControl til andre klynge). Aktivering af Prometheus er ret ligetil. Bare gå til ClusterControl -> vælg klyngen -> Dashboards -> Aktiver agentbaseret overvågning:
Angiv derefter IP-adressen eller værtsnavnet på den nye Prometheus-server, eller vælg blot en eksisterende Prometheus-vært fra rullemenuen:
ClusterControl vil installere og konfigurere de nødvendige pakker (Prometheus på Prometheus-serveren, eksportører på databasen og ProxySQL-noder), oprette forbindelse til Prometheus som datakilde og begynde at visualisere overvågningsdataene i brugergrænsefladen.
Når implementeringsjobbet er afsluttet, bør du være i stand til at få adgang til fanen Dashboards som vist i næste afsnit.
ProxySQL Dashboard
Du kan få adgang til ProxySQL Dashboards ved at gå til den respektive klynge under Dashboards fanen. Ved at klikke på Dashboard-rullemenuen vises dashboards relateret til vores klynge (MySQL-replikering). Du kan finde ProxySQL Overview-dashboardet under afsnittet "Load Balancers":
Der er en række paneler til ProxySQL, nogle af dem er selvforklarende. Ikke desto mindre, lad os besøge dem én efter én.
Værtsgruppestørrelse
Værtsgruppestørrelse er simpelthen det samlede antal værter på alle værtsgrupper:
I dette tilfælde har vi to værtsgrupper - 10 (skribent) og 20 (læser). Værtsgruppe 10 består af én vært (master), mens værtsgruppe 20 har to værter (master og slave), hvilket summerer op til i alt tre værter.
Medmindre du ændrer værtsgruppekonfigurationen (introducerer ny vært, fjerner eksisterende vært) fra ProxySQL, skal du forvente, at intet vil ændre sig i denne graf.
Klientforbindelser
Antallet af klientforbindelser, der behandles af ProxySQL for alle værtsgrupper:
Ovenstående graf fortæller os blot, at der konsekvent er 8 MySQL-klienter forbundet til vores ProxySQL-instans på port 6033 i de sidste 45 minutter (du kan ændre dette under "Range Selection"-indstillingen). Hvis du holder op med at forbinde din applikation til ProxySQL (eller omgå den), skulle værdien til sidst falde til 0.
Kundespørgsmål
Grafen visualiserer antallet af spørgsmål, der behandles af ProxySQL for alle værtsgrupper:
Ifølge MySQL-dokumentationen er spørgsmål blot antallet af udsagn, der udføres af serveren. Dette inkluderer kun sætninger sendt til serveren af klienter og ikke sætninger udført i lagrede programmer, i modsætning til variablen Queries. Denne variabel tæller ikke kommandoerne COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE eller COM_STMT_RESET. Igen, hvis du stopper med at forbinde din applikation til ProxySQL (eller omgå den), bør værdien falde til 0.
Aktive backend-forbindelser
Antallet af forbindelser, som ProxySQL vedligeholder til backend MySQL-serverne pr. vært:
Det fortæller os blot, hvor mange forbindelser, der i øjeblikket bruges af ProxySQL til at sende forespørgsler til backend-serveren. Så længe max-værdien ikke er tæt på forbindelsesgrænsen for den bestemte server (indstillet via max_connections når serveren tilføjes til ProxySQL værtsgruppe), er vi i god form.
Mislykkede backend-forbindelser
Antallet af forbindelser, der ikke blev etableret af ProxySQL:
Ovenstående eksempel viser blot, at der ikke er sket en backend-forbindelsesfejl i de sidste 45 minutter.
Forespørgsler dirigeret
Denne graf giver indsigt i fordelingen af indgående erklæringer til backend-serverne:
Som du kan se, går de fleste læsninger til læseværtsgruppen (HG20). Herfra kan vi forstå det balanceringsmønster, der udføres af ProxySQL, som matcher vores forespørgselsregler i denne læsetunge arbejdsbyrde.
Forbindelsesfri
Grafen viser, hvor mange forbindelser der i øjeblikket er ledige:
Forbindelserne holdes åbne for at minimere tidsomkostningerne ved at sende en forespørgsel til backend-serveren.
Latens
Den aktuelle ping-tid i mikrosekunder, som rapporteret fra ProxySQL-overvågningstråd:
Dette fortæller os blot, hvor stabil forbindelsen er fra ProxySQL til backend MySQL-serverne. Høj værdi for en lang konsekvent tid indikerer for det meste netværksproblem mellem dem.
Forespørgselscachehukommelse
Denne graf visualiserer hukommelsesforbrug af forespørgsler, der cachelagres af ProxySQL:
Fra grafen ovenfor kan vi se, at ProxySQL bruger en samlet mængde på 8 MB hukommelse af forespørgselscachen. Når den når grænsen på 8 MB (kan konfigureres via mysql-query_cache_size_MB variabel), vil hukommelsen blive renset af ProxySQL's rensetråd. Denne graf vil ikke blive udfyldt, hvis du ikke har defineret en forespørgselscache-regel.
I øvrigt kan cachelagring af en forespørgsel i ProxySQL gøres med kun to klik med ClusterControl. Gå til ProxySQL's Top Queries-side, rollover på en forespørgsel, klik Query Cache og klik på "Add Rule":
Forespørgselscacheeffektivitet
Denne graf visualiserer effektiviteten af cachelagrede forespørgsler:
Den blå linje fortæller os det vellykkede forhold mellem GET-anmodninger, der er udført mod Query Cache, hvor resultatsættet var til stede og ikke udløb. Den lyserøde linje viser forholdet mellem data skrevet (indsat) i eller læst fra Query Cache. I dette tilfælde er vores data læst fra Query Cache højere fra data skrevet, hvilket indikerer en effektiv cache-konfiguration.
Denne graf vil ikke blive udfyldt, hvis du ikke har defineret en forespørgselscache-regel.
Netværkstrafik
Denne graf visualiserer netværkstrafikken (datamodtagelse + data sendt) fra/til backend MySQL-serverne pr. vært:
Ovenstående skærmbillede fortæller os, at en betydelig mængde trafik videresendes/modtages fra/til læseværtsgruppen (HG20). I denne læseintensive arbejdsbyrde forbruger læseoperationer almindeligvis meget mere trafik, primært på grund af størrelsen på resultatsættet af SELECT-sætningerne.
Kun et mindre forhold af trafikken videresendes/modtages fra/til skriveværtsgruppen (HG10), hvilket forventes, da skriveoperationerne normalt forbruger mindre netværkstrafik med et betydeligt lille resultatsæt, der returneres til klienterne.
Spejlingseffektivitet
Grafen viser blot den trafikspejlingsrelaterede status som Mirror_concurrency vs Mirror_queue_length:
Grafen udfyldes kun, hvis du har konfigureret trafikspejling (mirror_hostgroup inde forespørgselsregel). Hvis spejlingskøen er ved at tage sig op, vil en reduktion af grænsen for spejling samtidighed øge spejlingseffektiviteten, som kan styres via mysql-mirror_max_concurrency variabel. Med enkle ord er nul køposter, hvad den mest effektive spejling handler om.
Hukommelsesudnyttelse
Grafen illustrerer hukommelsesudnyttelsen af hovedkomponenter i ProxySQL - forbindelsespulje, forespørgselscache og vedvarende lagring (SQLite):
Ovenstående skærmbillede fortæller os, at ProxySQL-hukommelsesfodaftrykket er ret lille, hvilket er mindre end 12 MB i alt. Forbindelsespuljen bruger kun 1,3 MB toppe for at imødekomme vores 8-tråds (klienter) arbejdsbyrde. Med mere ledig RAM tilgængelig på værten burde vi være i stand til at øge antallet af klientforbindelser til ProxySQL med tre til fire gange eller cache meget flere hot-forespørgsler inde i ProxySQL for at aflaste vores MySQL-backend-servere.
Bonusfunktion - Nodeydelse
ClusterControl 1.7.0 inkluderer nu værtens ydeevnemålinger for ProxySQL-forekomsterne. I den tidligere version overvågede ClusterControl kun de ProxySQL-relaterede målinger, som de blev afsløret af ProxySQL-statistikskemaet. Denne nye funktion kan tilgås under nodens fane -> ProxySQL-instans -> Nodeydelse:
Histogrammerne giver indsigt i de vigtigste værtsmetrikker, svarende til det, der samples for databasenoder under Noder -> Oversigtssektion. Hvis din ProxySQL-instans er placeret på samme server som applikationen, bruger du bogstaveligt talt ClusterControl til også at overvåge applikationsserveren. Hvor fedt er det?!
Sidste tanker
ClusterControl-integration med Prometheus tilbyder en alternativ måde at overvåge og analysere din databasestak på, indtil det omvendte proxy-niveau. Du har nu et valg om at overføre overvågningsopgaverne til Prometheus eller fortsætte med at bruge standard ClusterControl agentfri overvågningstilgang til din databaseinfrastruktur.