ClusterControl 1.7.0 introduceert een gedurfde nieuwe functie:integratie met Prometheus voor op agenten gebaseerde monitoring. We noemden dit SCUMM (Severalnines ClusterControl Unified Management and Monitoring). In de vorige versies werden de monitoringtaken uitsluitend agentless uitgevoerd. Als je je afvraagt hoe ClusterControl zijn monitoringfuncties uitvoert, bekijk dan deze documentatiepagina.
ProxySQL, een high-performance reverse-proxy die MySQL-protocollen begrijpt, zit gewoonlijk bovenop MySQL Replication en Galera Cluster om te fungeren als een toegangspoort tot de backend MySQL-service. Het kan worden geconfigureerd als een query-router, query-firewall, query-caching, verkeersdispatcher en nog veel meer. ProxySQL verzamelt en onthult ook belangrijke statistieken via het STATS-schema, wat erg handig is om de prestaties te analyseren en te begrijpen wat er werkelijk achter de schermen gebeurt. Bezoek onze uitgebreide tutorial voor ProxySQL om er meer over te leren.
In deze blogpost gaan we dieper in op het monitoren van de ProxySQL-instanties met deze nieuwe aanpak. In dit voorbeeld hebben we een ProxySQL-instantie bovenop onze MySQL-replicatie met twee knooppunten (1 master, 1 slave), geïmplementeerd via ClusterControl. Onze architectuur op hoog niveau ziet er ongeveer zo uit:
We hebben ook de volgende queryregels gedefinieerd in de ProxySQL-instantie (alleen ter referentie, om de verzamelde monitoringstatistieken verderop te begrijpen):
Prometheus inschakelen
De agent-based monitoring van ClusterControl wordt per cluster ingeschakeld. ClusterControl kan een nieuwe Prometheus-server voor u implementeren of een bestaande Prometheus-server gebruiken (geïmplementeerd door ClusterControl voor een ander cluster). Het inschakelen van Prometheus is vrij eenvoudig. Ga gewoon naar ClusterControl -> kies het cluster -> Dashboards -> Agent Based Monitoring inschakelen:
Geef vervolgens het IP-adres of de hostnaam van de nieuwe Prometheus-server op, of kies gewoon een bestaande Prometheus-host uit de vervolgkeuzelijst:
ClusterControl zal de benodigde pakketten installeren en configureren (Prometheus op de Prometheus-server, exporteurs op de database en ProxySQL-knooppunten), verbinding maken met de Prometheus als gegevensbron en beginnen met het visualiseren van de monitoringgegevens in de gebruikersinterface.
Zodra de implementatietaak is voltooid, zou u toegang moeten hebben tot het tabblad Dashboards, zoals weergegeven in de volgende sectie.
ProxySQL-dashboard
U kunt toegang krijgen tot de ProxySQL-dashboards door naar het betreffende cluster te gaan onder het tabblad Dashboards. Als u op de vervolgkeuzelijst Dashboard klikt, worden dashboards weergegeven die verband houden met ons cluster (MySQL-replicatie). U kunt het ProxySQL-overzichtsdashboard vinden onder de sectie "Load Balancers":
Er zijn een aantal panelen voor ProxySQL, sommige spreken voor zich. Laten we ze echter een voor een bezoeken.
Grootte hostgroep
De grootte van de hostgroep is gewoon het totale aantal host op alle hostgroepen:
In dit geval hebben we twee hostgroepen - 10 (schrijver) en 20 (lezer). Hostgroep 10 bestaat uit één host (master) terwijl hostgroep 20 twee hosts heeft (master en slave), wat neerkomt op in totaal drie hosts.
Tenzij u de configuratie van de hostgroep wijzigt (nieuwe host introduceren, bestaande host verwijderen) van ProxySQL, mag u verwachten dat er niets zal veranderen in deze grafiek.
Klantverbindingen
Het aantal clientverbindingen dat wordt verwerkt door ProxySQL voor alle hostgroepen:
De bovenstaande grafiek vertelt ons eenvoudig dat er de afgelopen 45 minuten consistent 8 MySQL-clients zijn verbonden met onze ProxySQL-instantie op poort 6033 (u kunt dit wijzigen onder de optie "Bereikselectie"). Als u stopt met het verbinden van uw applicatie met ProxySQL (of deze omzeilt), zou de waarde uiteindelijk naar 0 moeten dalen.
Vragen van klanten
De grafiek visualiseert het aantal vragen dat door ProxySQL wordt verwerkt voor alle hostgroepen:
Volgens MySQL-documentatie zijn vragen gewoon het aantal instructies dat door de server wordt uitgevoerd. Dit omvat alleen instructies die door clients naar de server worden verzonden en geen instructies die worden uitgevoerd in opgeslagen programma's, in tegenstelling tot de variabele Queries. Deze variabele telt geen COM_PING-, COM_STATISTICS-, COM_STMT_PREPARE-, COM_STMT_CLOSE- of COM_STMT_RESET-opdrachten. Nogmaals, als u stopt met het verbinden van uw applicatie met ProxySQL (of deze omzeilt), zou de waarde naar 0 moeten dalen.
Actieve backend-verbindingen
Het aantal verbindingen dat ProxySQL onderhoudt met de backend MySQL-servers per host:
Het vertelt ons eenvoudig hoeveel verbindingen momenteel door ProxySQL worden gebruikt voor het verzenden van query's naar de backend-server. Zolang de max-waarde niet in de buurt komt van de verbindingslimiet voor de specifieke server (ingesteld via max_connections wanneer de server wordt toegevoegd aan de ProxySQL-hostgroep), zijn we in een goede vorm.
Mislukte backend-verbindingen
Het aantal verbindingen dat niet succesvol tot stand is gebracht door ProxySQL:
Het bovenstaande voorbeeld laat eenvoudig zien dat er in de afgelopen 45 minuten geen backend-verbindingsfout is opgetreden.
Query's doorgestuurd
Deze grafiek geeft inzicht in de distributie van inkomende verklaringen naar de backend-servers:
Zoals je kunt zien, gaan de meeste reads naar de reader-hostgroep (HG20). Van hieruit kunnen we het evenwichtspatroon begrijpen dat wordt uitgevoerd door ProxySQL en dat overeenkomt met onze queryregels in deze leesintensieve werklast.
Verbindingsvrij
De grafiek laat zien hoeveel verbindingen momenteel vrij zijn:
De verbindingen worden open gehouden om de tijdskosten van het verzenden van een query naar de backend-server te minimaliseren.
Latentie
De huidige ping-tijd in microseconden, zoals gerapporteerd door ProxySQL-monitoringthread:
Dit vertelt ons eenvoudig hoe stabiel de verbinding is van de ProxySQL naar de backend MySQL-servers. Hoge waarde voor een lange, consistente tijd duidt meestal op een netwerkprobleem tussen hen.
Query cachegeheugen
Deze grafiek visualiseert het geheugenverbruik van query's die door ProxySQL in de cache worden opgeslagen:
Uit de bovenstaande grafiek kunnen we afleiden dat ProxySQL in totaal 8 MB geheugen verbruikt door de querycache. Nadat de limiet van 8 MB is bereikt (configureerbaar via mysql-query_cache_size_MB variabele), wordt het geheugen opgeschoond door ProxySQL's purge-thread. Deze grafiek wordt niet ingevuld als u geen querycacheregel heeft gedefinieerd.
Het cachen van een query in ProxySQL kan trouwens in slechts twee klikken met ClusterControl. Ga naar de ProxySQL's Top Queries-pagina, rollover op een query, klik op Query Cache en klik op "Regel toevoegen":
Efficiëntie van querycache
Deze grafiek visualiseert de efficiëntie van zoekopdrachten in de cache:
De blauwe lijn vertelt ons de succesvolle verhouding van GET-verzoeken die zijn uitgevoerd tegen de Query Cache waar de resultatenset aanwezig was en niet was verlopen. De roze lijn geeft de verhouding weer van gegevens die zijn geschreven (ingevoegd) in of gelezen uit de Query Cache. In dit geval zijn onze gegevens die uit de Query Cache worden gelezen hoger dan de gegevens die zijn geschreven, wat wijst op een efficiënte cacheconfiguratie.
Deze grafiek wordt niet ingevuld als u geen querycacheregel heeft gedefinieerd.
Netwerkverkeer
Deze grafiek visualiseert het netwerkverkeer (data ontvangen + data verzonden) van/naar de backend MySQL-servers, per host:
De bovenstaande screenshot vertelt ons dat een aanzienlijke hoeveelheid verkeer wordt doorgestuurd/ontvangen van/naar de reader-hostgroep (HG20). In deze leesintensieve werkbelasting verbruiken leesbewerkingen gewoonlijk veel meer verkeer, voornamelijk vanwege de grootte van de resultatenset van de SELECT-instructies.
Slechts een kleinere verhouding van het verkeer wordt doorgestuurd/ontvangen van/naar de schrijf-hostgroep (HG10), wat wordt verwacht omdat de schrijfbewerkingen gewoonlijk minder netwerkverkeer verbruiken, met een aanzienlijk kleine resultatenset die wordt teruggestuurd naar de clients.
Efficiëntie spiegelen
De grafiek toont eenvoudig de verkeer-mirroring-gerelateerde status, zoals Mirror_concurrency vs Mirror_queue_length:
De grafiek wordt alleen ingevuld als u mirroring van verkeer heeft geconfigureerd (mirror_hostgroup binnen vraagregel). Als de mirror-wachtrij aan het oppakken is, zal het verlagen van de gelijktijdigheidslimiet voor mirroring de mirroring-efficiëntie verhogen, die kan worden beheerd via mysql-mirror_max_concurrency variabel. In eenvoudige bewoordingen, de nul-wachtrij-invoer is waar het bij de meest efficiënte spiegeling om draait.
Geheugengebruik
De grafiek illustreert het geheugengebruik door de belangrijkste componenten binnen ProxySQL - verbindingspool, querycache en permanente opslag (SQLite):
De bovenstaande schermafbeelding vertelt ons dat de voetafdruk van ProxySQL-geheugen vrij klein is, namelijk minder dan 12 MB in totaal. De verbindingspool verbruikt slechts 1,3 MB tops om onze 8-thread (clients) werklast op te vangen. Met meer vrije RAM beschikbaar op de host, zouden we in staat moeten zijn om het aantal clientverbindingen met ProxySQL te verdrievoudigen tot viervoudig of veel meer hot queries in ProxySQL te cachen om onze MySQL-backendservers te ontlasten.
Bonusfunctie - Knooppuntprestaties
ClusterControl 1.7.0 bevat nu hostprestatiestatistieken voor de ProxySQL-instanties. In de vorige versie bewaakte ClusterControl alleen de ProxySQL-gerelateerde statistieken zoals weergegeven door het ProxySQL-statistiekenschema. Deze nieuwe functie is toegankelijk via het tabblad Node -> ProxySQL-instantie -> Node-prestaties:
De histogrammen bieden inzicht in de belangrijkste hoststatistieken, vergelijkbaar met wat wordt gesampled voor databaseknooppunten in de sectie Knooppunten -> Overzicht. Als uw ProxySQL-instantie zich samen met de toepassing op dezelfde server bevindt, gebruikt u letterlijk ClusterControl om ook de toepassingsserver te bewaken. Hoe cool is dat?!
Laatste gedachten
ClusterControl-integratie met Prometheus biedt een alternatieve manier om uw databasestack te bewaken en te analyseren, tot aan de reverse-proxy-laag. U hebt nu de keuze om de monitoringtaken over te dragen aan Prometheus, of om de standaard ClusterControl agentless monitoring-aanpak voor uw database-infrastructuur te blijven gebruiken.