In onze nieuwste release van ClusterControl 1.7.0 hebben we een aantal nieuwe dashboards voor MySQL toegevoegd. - en in onze vorige blog hebben we u laten zien hoe u uw ProxySQL kunt controleren met Prometheus en ClusterControl.
In deze blog kijken we naar het MySQL-overzichtsdashboard.
Daarom hebben we Agent Based Monitoring op het tabblad Dashboard ingeschakeld om metrieken naar de nodes te verzamelen. Houd er rekening mee dat wanneer u Agent Based Monitoring inschakelt, u de opties hebt om het "Scrape-interval (seconden) in te stellen ” en “Bewaren van gegevens (dagen) ”. Scraping Interval is waar u wilt instellen hoe agressief Prometheus gegevens van het doel zal verzamelen en gegevensretentie is hoe lang u uw door Prometheus verzamelde gegevens wilt bewaren voordat deze worden verwijderd.
Indien ingeschakeld, kunt u identificeren welk cluster agents heeft en welke agentless monitoring heeft.
Vergeleken met de agentless-aanpak, zal de granulariteit van uw gegevens in grafieken hoger zijn bij agents.
De MySQL-grafieken
De nieuwste versie van ClusterControl 1.7.0 (die u gratis kunt downloaden - ClusterControl Community) heeft de volgende MySQL-dashboards waarvoor u informatie voor uw MySQL-servers kunt verzamelen. Dit zijn MySQL-overzicht, MySQL InnoDB-statistieken, MySQL-prestatieschema en MySQL-replicatie.
We bespreken in detail de grafieken die beschikbaar zijn in het MySQL-overzichtsdashboard.
MySQL-overzichtsdashboard
Dit dashboard bevat de gebruikelijke belangrijke variabelen of informatie over de gezondheid van uw MySQL-knooppunt. De grafieken op dit dashboard zijn specifiek voor het knooppunt dat is geselecteerd bij het bekijken van de dashboards zoals hieronder te zien is:
Het bestaat uit 26 grafieken, maar u hebt deze misschien niet allemaal nodig bij het diagnosticeren van problemen. Deze grafieken bieden echter een essentiële weergave van de algemene statistieken voor uw MySQL-servers. Laten we de basiszaken doornemen, aangezien dit waarschijnlijk de meest voorkomende dingen zijn waar een DBA routinematig naar zal kijken.
De eerste vier grafieken die hierboven worden weergegeven, samen met de uptime van MySQL, het aantal zoekopdrachten per seconde en de bufferpoolinformatie, zijn de meest elementaire aanwijzingen die we mogelijk nodig hebben. Van de grafieken die hierboven worden weergegeven, zijn dit hun weergaven:
- MySQL-verbindingen
Hier wilt u het totale aantal klantverbindingen controleren dat tot nu toe in een bepaalde periode is toegewezen. - Activiteit MySQL-clientthread
Er zijn tijden dat uw MySQL-server erg druk kan zijn. Er kan bijvoorbeeld worden verwacht dat er op een bepaald tijdstip een toename van het verkeer wordt ontvangen en u wilt uw actieve threads-activiteit controleren. Deze grafiek is erg belangrijk om naar te kijken. Er kunnen tijden zijn dat uw queryprestaties achteruit gaan als, bijvoorbeeld, een grote update ervoor zorgt dat andere threads wachten om vergrendeling te verkrijgen. Dit zou leiden tot een groter aantal van uw actieve threads. Het aantal gemiste caches wordt berekend als Threads_created/Connections. - MySQL-vragen
Dit zijn de query's die in een bepaalde periode worden uitgevoerd. Een thread kan een transactie zijn die bestaat uit meerdere zoekopdrachten en dit kan een goede grafiek zijn om naar te kijken. - MySQL-threadcache
Deze grafiek toont de waarde thread_cache_size, threads die in de cache zijn opgeslagen (threads die opnieuw worden gebruikt) en threads die zijn gemaakt (nieuwe threads). U kunt deze grafiek raadplegen voor gevallen zoals u uw leesquery's moet afstemmen wanneer u een groot aantal inkomende verbindingen opmerkt en uw gecreëerde threads snel toenemen. Als bijvoorbeeld uw Threads_running / thread_cache_size> 2 dan kan het verhogen van uw thread_cache_size een prestatieverbetering geven aan uw server. Houd er rekening mee dat het maken en vernietigen van threads duur is. In de recente versies van MySQL (>=5.6.8) heeft deze variabele echter standaard automatische grootte, wat u als onaangeroerd zou kunnen beschouwen.
De volgende vier grafieken zijn MySQL Temporary Objects, MySQL Select Types, MySQL Sorts en MySQL Slow Queries. Deze grafieken zijn aan elkaar gerelateerd, vooral als u langlopende zoekopdrachten en grote zoekopdrachten die moeten worden geoptimaliseerd, diagnosticeert.
- MySQL tijdelijke objecten
Deze grafiek zou een goede bron zijn om op te vertrouwen als u langlopende query's wilt controleren die uiteindelijk de schijf zouden gebruiken in plaats van tijdelijke tabellen of bestanden die in het geheugen worden opgeslagen. Het is een goede plek om te beginnen met zoeken naar het periodiek voorkomen van query's die kunnen leiden tot schijfruimteproblemen, vooral in vreemde tijden. - MySQL-types selecteren
Een bron van slechte prestaties zijn query's die gebruikmaken van volledige joins, tabelscans, selectiebereik dat geen indexen gebruikt. Deze grafiek laat zien hoe uw zoekopdracht presteert en welke van de lijst van volledige joins tot full range joins, select range en tabelscans de hoogste trends heeft. - MySQL-sorteringen
Diagnose stellen van die zoekopdrachten waarbij sortering wordt gebruikt en die veel tijd kosten om te voltooien. - MySQL trage zoekopdrachten
Trends van uw langzame zoekopdrachten worden hier in deze grafiek verzameld. Dit is erg handig, vooral om vast te stellen hoe vaak uw zoekopdrachten traag zijn. Wat zijn dingen die moeten worden afgesteld? Het kan een te kleine bufferpool zijn, tabellen die geen indexen hebben en een volledige tabelscan uitvoeren, logische back-ups die volgens een onverwacht schema worden uitgevoerd, enz. Het is nuttig om onze Query Monitor in ClusterControl samen met deze grafiek te gebruiken, omdat het helpt bij het bepalen van langzame query's.
De volgende grafieken die we behandelen, zijn meer van de netwerkactiviteit, tabelvergrendelingen en het onderliggende interne geheugen dat MySQL verbruikt tijdens de MySQL-activiteit.
- MySQL afgebroken verbindingen
Het aantal afgebroken verbindingen wordt in deze grafiek weergegeven. Dit dekt de afgebroken clients, zoals waar het netwerk abrupt werd gesloten of waar de internetverbinding was verbroken of onderbroken. Het registreert ook de afgebroken verbindingen of pogingen zoals verkeerde wachtwoorden of slechte pakketten bij het tot stand brengen van een verbinding vanaf de client. - MySQL-tabelvergrendelingen
Trends voor tafels die vragen om een tafelslot dat onmiddellijk is toegekend en voor tafels die vragen om een slot dat niet onmiddellijk wordt verkregen. Als u bijvoorbeeld vergrendelingen op tafelniveau hebt op MyISAM-tafels en inkomende verzoeken van dezelfde tafel, kunnen deze niet onmiddellijk worden verleend. - MySQL-netwerkverkeer
Deze grafiek toont de trends van de inkomende en uitgaande netwerkactiviteit in de MySQL-server. "Inkomend" zijn de gegevens die worden ontvangen door de MySQL-server, terwijl "Uitgaand" de gegevens zijn die door de server worden verzonden of overgedragen vanaf de MySQL-server. Deze grafiek is het beste om te controleren of u uw netwerkverkeer wilt controleren, vooral bij het diagnosticeren van uw verkeer is matig, maar je vraagt je af waarom het een zeer hoge uitgaande overgedragen gegevens heeft, zoals bijvoorbeeld BLOB-gegevens. - Gebruik van MySQL-netwerk per uur
Hetzelfde als het netwerkverkeer dat de ontvangen en verzonden gegevens toont. Houd er rekening mee dat het is gebaseerd op 'per uur' en is gelabeld met 'laatste dag', wat niet de periode volgt die je hebt geselecteerd in de datumkiezer. - Overzicht van MySQL intern geheugen
Deze grafiek is bekend voor een doorgewinterde MySQL DBA. Elk van deze legenda's in het staafdiagram is erg belangrijk, vooral als u uw geheugengebruik, uw bufferpoolgebruik of uw adaptieve hashindexgrootte wilt controleren.
De volgende grafieken tonen de tellers waarop een DBA kan vertrouwen, zoals het controleren van de statistieken, bijvoorbeeld de statistieken voor selecties, invoegingen, updates, het aantal masterstatus dat is uitgevoerd, het aantal TOON VARIABELEN dat is uitgevoerd, controleer als u slechte query's hebt tijdens het scannen van tabellen of tabellen die geen indexen gebruiken door over de read_*-tellers te kijken, enz.
- Top opdrachttellers (per uur)
Dit zijn de grafieken die u waarschijnlijk zou moeten controleren wanneer u de statistieken voor uw invoegingen, verwijderingen, updates, uitgevoerde opdrachten zoals het verzamelen van de proceslijst, slavestatus, showstatus wilt zien (gezondheidsstatistieken van de MySQL-server ), en nog veel meer. Dit is een goede plek als u wilt controleren wat voor soort MySQL-opdrachttellers bovenaan staan en of prestatieafstemming of query-optimalisatie nodig is. Het kan je ook in staat stellen om te identificeren welke commando's agressief worden uitgevoerd terwijl je het niet nodig hebt. - MySQL-handlers
Vaak zou een DBA deze handlers doornemen en controleren hoe de query's presteren op uw MySQL-server. Kortom, deze grafiek dekt de tellers van de Handler API van MySQL. De meest voorkomende handler-tellers voor een DBA voor de opslag-API in MySQL zijn Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd en Handler_read_rnd_next. Er zijn veel MySQL-handlers om te controleren. Je kunt erover lezen in de documentatie hier. - MySQL-transactiehandlers
Als uw MySQL-server XA-transacties gebruikt, SAVEPOINT, ROLLBACK TO SAVEPOINT-instructies. Dan is deze grafiek een goede referentie om naar te kijken. Je kunt deze grafiek ook gebruiken om alle interne commits van je server te controleren. Houd er rekening mee dat de teller voor Handler_commit zelfs voor SELECT-statements wordt verhoogd, maar verschilt van insert/update/delete-statements die naar het binaire logboek gaan tijdens een aanroep van COMMIT-statement.
De volgende grafiek toont trends over processtatussen en hun gebruik per uur. Er zijn veel belangrijke punten hier in de legenda van het staafdiagram die een DBA zou controleren. Problemen met schijfruimte, verbindingsproblemen en kijk of uw verbindingspool werkt zoals verwacht, hoge schijf-I/O, netwerkproblemen, enz.
- Processtaten/Topprocesstaten per uur
In deze grafiek kunt u de topthread-statussen van uw query's in de proceslijst volgen. Dit is zeer informatief en nuttig voor dergelijke DBA-taken waarbij u hier eventuele openstaande statussen die moeten worden opgelost, kunt bekijken. Bijvoorbeeld, tafels openen staat is erg hoog en de minimale waarde ligt bijna in de buurt van de maximale waarde. Dit kan erop wijzen dat u de table_open_cache moet aanpassen. Als de statistieken hoog is en u merkt dat uw server langzamer gaat werken, kan dit erop wijzen dat uw server schijfgebonden is en moet u mogelijk overwegen om uw bufferpool te vergroten. Als u een groot aantal tmp-tabel maakt dan moet u mogelijk uw trage logbestand controleren en de aanstootgevende zoekopdrachten optimaliseren. U kunt hier de handleiding bekijken voor de volledige lijst met MySQL-threadstatussen.
De volgende grafiek die we zullen controleren, gaat over querycache, MySQL-tabeldefinitiecache, hoe vaak MySQL systeembestanden opent.
- MySQL-querycachegeheugen/activiteit
Deze grafieken zijn aan elkaar gerelateerd. Als je query_cache_size <> 0 en query_cache_type <> 0 hebt, kan deze grafiek je helpen. In de nieuwere versies van MySQL is de querycache echter gemarkeerd als verouderd omdat bekend is dat de MySQL-querycache prestatieproblemen veroorzaakt. Mogelijk heeft u dit in de toekomst niet meer nodig. De meest recente versie van MySQL 8.0 heeft drastische verbeteringen; het heeft de neiging om de prestaties te verbeteren omdat het wordt geleverd met verschillende strategieën om cache-informatie in de geheugenbuffers te verwerken. - MySQL-bestandsopeningen
Deze grafiek toont de trend voor de geopende bestanden sinds de uptime van de MySQL-server, maar sluit bestanden zoals sockets of pipes uit. Het bevat ook geen bestanden die worden geopend door de opslagengine, omdat ze hun eigen teller hebben, namelijk Innodb_num_open_files. - MySQL-bestanden openen
In deze grafiek wilt u uw InnoDB-bestanden controleren die momenteel open worden gehouden, de huidige geopende MySQL-bestanden en uw open_files_limit-variabele. - MySQL-tabel Cache-status openen
Als je hier een zeer lage table_open_cache hebt ingesteld, zal deze grafiek je vertellen over de tabellen die de cache niet halen (nieuw geopende tabellen) of missen vanwege overflow. Als u een hoog aantal of te veel status "Tafels openen" in uw proceslijst tegenkomt, zal deze grafiek als uw referentie dienen om dit te bepalen. Dit zal je vertellen of het nodig is om je table_open_cache variabele te vergroten. - MySQL open tafels
Ten opzichte van MySQL Table Open Cache Status, is deze grafiek handig in bepaalde gevallen, zoals u wilt identificeren of het nodig is om uw table_open_cache te vergroten of te verlagen als u een grote toename van open tabellen of Open_tables statusvariabele opmerkt . Merk op dat table_open_cache een grote hoeveelheid geheugenruimte in beslag kan nemen, dus u moet dit met zorg instellen, vooral in productiesystemen. - MySQL-tabeldefinitiecache
Als je het aantal van je Open_table_definitions en Opened_table_definitions statusvariabelen wilt controleren, dan is deze grafiek wat je nodig hebt. Voor nieuwere versies van MySQL (>=5.6.8) hoeft u de waarde van deze variabele mogelijk niet te wijzigen en de standaardwaarde te gebruiken omdat deze de functie voor automatisch aanpassen heeft.
Conclusie
De SCUMM-toevoeging in de nieuwste versie van ClusterControl 1.7.0 biedt belangrijke nieuwe voordelen voor een aantal belangrijke DBA-taken. De nieuwe grafieken kunnen helpen om de oorzaak van problemen waar DBA's of systeembeheerders normaal gesproken mee te maken hebben, gemakkelijk vast te stellen en om sneller passende oplossingen te vinden.
We horen graag uw ervaringen en gedachten over het gebruik van ClusterControl 1.7.0 met SCUMM (die u gratis kunt downloaden - ClusterControl Community).
In deel 2 van deze blog ga ik in op effectieve monitoring van MySQL-replicatie met SCUMM-dashboards.