Agentloze databasebewaking met ClusterControl

Met de groeiende complexiteit van database-instellingen, wenden veel SysAdmins en DBA's zich tot een agentloze benadering om de last van databasemonitoring-uitdagingen te verlichten. Met de agentless monitoring van ClusterControl kunt u databases bewaken zonder agentsoftware op elk bewaakt systeem te installeren. ClusterControl implementeert monitoring met behulp van een externe gegevensverzamelaar die het SSH-protocol gebruikt.

Laten we, voordat we direct ingaan op de details van agentless monitoring, eerst de reikwijdte en betekenis van monitoring binnen onze context hier verduidelijken. Monitoring komt na het trenden van gegevens - het proces voor het verzamelen en opslaan van statistieken - waarmee het monitoringsysteem de verzamelde gegevens kan verwerken om een ​​rechtvaardiging te produceren voor afstemming, waarschuwingen en weergave van trendgegevens voor rapportage.

Vanaf versie 1.7.0 (uitgebracht in december 2018) ondersteunt ClusterControl twee controlemethoden:

• Bewaking zonder agent (standaard)
• Op agenten gebaseerde monitoring met Prometheus

In dit bericht wordt uitgelegd hoe u uw databaseservers en clusters kunt bewaken met ClusterControl's agentless monitoring. Als u op zoek bent naar meer informatie over de op agenten gebaseerde monitoring van ClusterControl, kunt u deze documentatie raadplegen.

Over het algemeen voert ClusterControl controle-, waarschuwings- en trendingtaken zonder agent uit met behulp van de volgende drie methoden:

• SSH – verzameling van hoststatistieken (proces, load balancers-statistieken, resourcegebruik, verbruik, enz.) met behulp van SSH-bibliotheek
• Databaseclient – ​​verzameling van databasestatistieken (status, query's, variabelen, gebruik, enz.) met behulp van de respectieve databaseclientbibliotheek
• Advisor – Mini-programma's geschreven met ClusterControl DSL en uitgevoerd binnen ClusterControl zelf voor monitoring-, afstemmings- en waarschuwingsdoeleinden

SSH staat voor Secure Shell, een beveiligd netwerkprotocol dat door de meeste op Linux gebaseerde servers wordt gebruikt voor extern beheer. ClusterControl Controller, of CMON, is de backend-service die automatiserings-, beheer-, bewakings- en planningstaken uitvoert, gebouwd bovenop C++.

ClusterControl DSL (Domain Specific Language) stelt u in staat de functionaliteit van uw ClusterControl-platform uit te breiden door adviseurs, automatische tuners of "miniprogramma's" te maken. De DSL-syntaxis is gebaseerd op JavaScript, met extensies om toegang te bieden tot interne datastructuren en functies van ClusterControl. Met de DSL kunt u SQL-instructies uitvoeren, shell-opdrachten/programma's uitvoeren op al uw clusterhosts en resultaten ophalen die moeten worden verwerkt voor adviseurs/waarschuwingen of andere acties.

Bewakingstools

Aan alle vereiste tools wordt voldaan door het installatiescript of wordt automatisch geïnstalleerd door ClusterControl tijdens de implementatiefase van de database of als het vereiste bestand/binair/pakket niet op de doelserver bestaat voordat een taak wordt uitgevoerd. Over het algemeen vereist ClusterControl-bewakingstaak alleen het OpenSSH-serverpakket op de bewaakte hosts. ClusterControl gebruikt de libssh-clientbibliotheek om hoststatistieken te verzamelen voor de bewaakte hosts - CPU, geheugen, schijf, netwerk, IO, proces, enz. OpenSSH-clientpakket is alleen vereist op de ClusterControl-host om wachtwoordloze SSH en foutopsporing in te stellen. Andere SSH-implementaties zoals Dropbear en TinySSH worden niet ondersteund.

Bij het verzamelen van de databasestatistieken en -statistieken maakt ClusterControl Controller (CMON) rechtstreeks verbinding met de databaseserver via databaseclientbibliotheken - libmysqlclient (MySQL/MariaDB en ProxySQL), libpq (PostgreSQL) en libmongocxx (MongoDB ). Daarom is het cruciaal om de juiste bevoegdheden voor een ClusterControl-server in te stellen vanuit het perspectief van een databaseserver. Voor op MySQL gebaseerde clusters vereist ClusterControl databasegebruiker "cmon", terwijl voor andere databases elke gebruikersnaam kan worden gebruikt voor monitoring, zolang deze supergebruikersrechten heeft. Meestal stelt ClusterControl de vereiste privileges (of gebruikt de opgegeven databasegebruiker) automatisch in tijdens de clusterimport of clusterimplementatiefase.

ClusterControl vereist de volgende tools voor load balancers:

• Maxctrl op de MariaDB MaxScale-server
• netcat en/of socat op de HAProxy-server om verbinding te maken met het HAProxy-socketbestand en de monitoringgegevens op te halen
• ProxySQL vereist een mysql-client op de ProxySQL-server

Het volgende diagram illustreert zowel host- als databasebewakingsprocessen die worden uitgevoerd door ClusterControl met behulp van libssh en databaseclientbibliotheken:

Hoewel voor monitoringthreads geen databaseclientpakketten op de bewaakte host hoeven te worden geïnstalleerd, het wordt ten zeerste aanbevolen om ze te hebben voor managementdoeleinden. Het MySQL-clientpakket wordt bijvoorbeeld geleverd met mysql-, mysqldump-, mysqlbinlog- en mysqladmin-programma's, die door ClusterControl zullen worden gebruikt bij het uitvoeren van back-ups en herstel op een bepaald tijdstip.

Bewakingsmethoden

Voor het verzamelen van host- en load balancer-statistieken voert ClusterControl deze taak uit via SSH met supergebruikersrechten. Daarom is SSH zonder wachtwoord met supergebruikersrechten essentieel om ClusterControl in staat te stellen de benodigde opdrachten op afstand uit te voeren met de juiste escalatie. Met deze pull-aanpak zijn er een aantal voordelen in vergelijking met andere mechanismen:

• Agentloos:er hoeft geen agent te worden geïnstalleerd, geconfigureerd en onderhouden.
• De beheer- en bewakingsconfiguratie verenigen - SSH kan worden gebruikt om bewakingsstatistieken op te halen of beheertaken op de doelknooppunten te pushen.
• Vereenvoudig de implementatie – De enige vereiste is een correcte SSH-configuratie zonder wachtwoord, en dat is alles. SSH is ook erg veilig en versleuteld.
• Gecentraliseerde installatie – Eén ClusterControl-server kan meerdere servers en clusters beheren, mits deze over voldoende middelen beschikt.

Het trekmechanisme heeft echter ook de volgende nadelen:

• De monitoringgegevens zijn alleen nauwkeurig vanuit het perspectief van ClusterControl. Als er bijvoorbeeld een netwerkstoring is en ClusterControl de communicatie met de bewaakte host verliest, wordt de bemonstering overgeslagen tot de volgende beschikbare cyclus.
• Er zal netwerkoverhead zijn voor monitoring met hoge granulariteit vanwege de verhoogde bemonsteringsfrequentie waarbij ClusterControl meer verbindingen tot stand moet brengen met elke doelhost.
• ClusterControl zal blijven proberen de verbinding met het doelknooppunt opnieuw tot stand te brengen omdat het geen agent heeft om dit namens hem te doen.
• Redundante gegevensbemonstering als u meer dan één ClusterControl-server hebt die een cluster bewaakt, aangezien elke ClusterControl-server de bewakingsgegevens voor zichzelf moet ophalen.

Voor MySQL-querycontrole, vanaf ClusterControl 1.9.0 (uitgebracht in juli 2021), ondersteunt ClusterControl twee typen:

• Bewaking van zoekopdrachten zonder agent (standaard)
• Op agents gebaseerde querycontrole met behulp van CMON-queryagent, waarvoor extra stappen nodig zijn om deze in te schakelen. Alleen voor MySQL-gebaseerde en PostgreSQL-gebaseerde databases.

Agentless query monitoring controleert de queries op twee verschillende manieren:

• Query's worden opgehaald uit PERFORMANCE_SCHEMA door via SSH het schema op het databaseknooppunt op te vragen.
• Als PERFORMANCE_SCHEMA is uitgeschakeld of niet beschikbaar is, parseert ClusterControl de inhoud van het trage querylogboek via SSH.

Als Prestatieschema is ingeschakeld, zal ClusterControl het gebruiken om te zoeken naar de langzame query's. Anders parseert ClusterControl de inhoud van het MySQL-log met trage query's (via slow_query_log=ON dynamische variabele) op basis van de volgende stroom:

1. Start langzaam logboek (tijdens MySQL-runtime).
2. Doe het voor een korte periode (een seconde of een paar seconden).
3. Logboek stoppen.
4. Logboek ontleden.
5. Log afbreken (nieuw logbestand).
6. Ga naar 1.

De verzamelde zoekopdrachten worden gehasht, berekend en verwerkt (normaliseren, gemiddeld, tellen, sorteren) en vervolgens opgeslagen in de ClusterControl CMON-database. Houd er rekening mee dat voor deze steekproefmethode er een kleine kans is dat sommige zoekopdrachten niet worden vastgelegd, vooral tijdens de delen "stop log, parse log, truncate log". U kunt Prestatieschema inschakelen als dit geen optie is.

Alleen query's die de lange querytijd overschrijden, worden hier weergegeven met behulp van het logbestand voor trage query's. Stel dat de gegevens niet correct zijn ingevuld en u denkt dat er iets in zou moeten staan, dan kan het zijn dat:

• ClusterControl heeft niet genoeg zoekopdrachten verzameld om gegevens samen te vatten en te vullen. Probeer de lange zoektijd te verlagen.
• U hebt de configuratie-opties voor het logbestand voor trage query's geconfigureerd in de my.cnf van de MySQL-server en Lokale query negeren is uitgeschakeld. Als u de waarde die u in my.cnf hebt gedefinieerd echt wilt gebruiken, moet u waarschijnlijk de waarde long_query_time verlagen zodat ClusterControl een nauwkeuriger resultaat kan berekenen.
• Je hebt een ander ClusterControl-knooppunt dat ook het Slow Query-logboek haalt (voor het geval je een standby-ClusterControl-server hebt). Sta slechts één ClusterControl-server toe om dit werk te doen.

U kunt ook de ClusterControl Query Monitor gebruiken voor MySQL, MariaDB en Percona Server.

Voor PostgreSQL-querycontrole vereist ClusterControl de module pg_stat_statements om uitvoeringsstatistieken van alle SQL-instructies bij te houden. Het vult de weergaven en functies van pg_stat_statements bij het weergeven van de query's in de gebruikersinterface (onder het tabblad Query Monitor).

Intervallen en time-outs

ClusterControl-controller (cmon) is een proces met meerdere threads. Standaard maakt de ClusterControl Controller-samplingthread eenmaal verbinding met elke bewaakte host en handhaaft een permanente verbinding totdat de host wegvalt of de verbinding verbreekt wanneer de hoststatistieken worden bemonsterd. Het kan meer verbindingen tot stand brengen, afhankelijk van de taken die aan de host zijn toegewezen, aangezien de meeste beheertaken in hun eigen thread worden uitgevoerd. Clusterherstel wordt bijvoorbeeld uitgevoerd op de herstelthread, Advisor-uitvoering wordt uitgevoerd op een cron-thread en procesbewaking wordt uitgevoerd op de procescollectorthread.

ClusterControl-bewakingsthread voert de volgende bemonsteringsbewerkingen uit in het volgende interval:

• MySQL-query/status-statistieken:elke seconde
• Verzameling verwerken (/proc):elke 10 seconden
• Serverdetectie:elke 10 seconden
• Hoststatistieken (/proc, /sys):elke 30 seconden (configureerbaar via host_stats_collection_interval)
• Databasestatistieken (alleen PostgreSQL en MongoDB):elke 30 seconden (configureerbaar via db_stats_collection_interval)
• Statistieken databaseschema:elke 3 uur (configureerbaar via db_schema_stats_collection_interval)
• Load balancer-statistieken:elke 15 seconden (configureerbaar via lb_stats_collection_interval)

De imperatieve scripts (Advisors) kunnen gebruikmaken van SSH en databaseclientbibliotheken die bij CMON worden geleverd met de volgende beperkingen:

• 5 seconden harde limiet voor SSH-uitvoering.
• 10 seconden standaardlimiet voor databaseverbinding, configureerbaar via net_read_timeout, net_write_timeout, connect_timeout in CMON-configuratiebestand.
• 60 seconden totale tijdslimiet voor het uitvoeren van scripts voordat CMON het op onfatsoenlijke wijze afbreekt.

Advisors kunnen rechtstreeks vanuit de gebruikersinterface van ClusterControl worden gemaakt, gecompileerd, getest en gepland onder Beheren → Developer Studio . De volgende schermafbeelding toont een voorbeeld van een adviseur om top 10 zoekopdrachten uit PERFORMANCE_SCHEMA te extraheren:

De uitvoering van adviseurs is afhankelijk van of het is geactiveerd en de planningstijd in cron-formaat:

De resultaten van de uitvoering worden weergegeven onder Prestaties → Adviseurs , zoals weergegeven in de volgende schermafbeelding:

Raadpleeg onze Developer Studio-productpagina.

Gegevens worden rechtstreeks in de CMON-database opgeslagen voor bewakingsgegevens met korte intervallen, zoals MySQL-query's en status. Bewakingsgegevens met lange intervallen, zoals wekelijkse/maandelijkse/jaarlijkse datapunten, worden elke 60 seconden geaggregeerd en gedurende 10 minuten in het geheugen opgeslagen. Deze gedragingen zijn niet configureerbaar vanwege het architectuurontwerp.

Parameters

ClusterControl heeft veel parameters die passen bij uw monitoring- en waarschuwingsbeleid. De meeste zijn configureerbaar via ClusterControl UI → kies een cluster → Instellingen . Het tabblad "Instellingen" biedt veel opties om waarschuwingen, drempels, meldingen, grafieklay-out, databasetellers, querybewaking, enzovoort te configureren. Waarschuwings- en kritieke drempels kunnen bijvoorbeeld als volgt worden geconfigureerd:

De pagina "Runtime Configuration" toont een samengevatte lijst van de actieve ClusterControl-controller (CMON) runtime-configuratieparameters:

Er zijn in totaal meer dan 170 ClusterControl Controller-configuratie-opties, en enkele van de geavanceerde instellingen kunnen worden geconfigureerd voor fijnafstemming van het monitoring- en waarschuwingsbeleid. Enkele hiervan zijn:

• monitor_cpu_temperature
• swap_warning
• swap_critical
• redobuffer_warning
• redobuffer_critical
• indexmemory_warning
• indexmemory_critical
• datamemory_warning
• datamemory_critical
• tablespace_warning
• tablespace_critical
• redolog_warning
• redolog_critical
• max_replication_lag
• long_query_time
• log_queries_not_using_indexes
• query_monitor_use_local_settings
• enable_query_monitor
• enable_query_monitor_auto_purge_ps

Je kunt de parameters op de pagina "Runtimeconfiguratie" wijzigen met behulp van de gebruikersinterface of het CMON-configuratiebestand op /etc/cmon.d/cmon_X.cnf, waarbij X de cluster-ID is. U kunt alle ondersteunde configuratie-opties voor CMON weergeven door de volgende opdracht te gebruiken:

$ cmon --help-config

Laatste gedachten

Agentless monitoring is een van de meest effectieve methoden geworden voor het beheren van steeds complexere database-infrastructuren. Het vermindert de last van de vele uitdagingen die gepaard gaan met databasemonitoring en is eenvoudig te beheren.

Er zijn tegenwoordig tal van agentless monitoringtools beschikbaar. Niet veel van hen bieden echter ook een compleet platform vol functies om u te helpen bij het beheren van elk ander aspect van uw databaseclusters. Download uw eigen gratis proefversie van 30 dagen om te zien wat ClusterControl nog meer kan doen.

Bent u op zoek naar een agentgebaseerd alternatief voor databasemonitoring? Bekijk de op agenten gebaseerde infrastructuur voor databasebewaking van ClusterControl - SCUMM.