Agentløs databaseovervågning med ClusterControl

Med den voksende kompleksitet af databaseopsætninger, vender mange SysAdmins og DBA'er til en agentløs tilgang for at hjælpe med at lette byrden af ​​databaseovervågningsudfordringer. ClusterControls agentfri overvågning giver dig mulighed for at overvåge databaser uden at installere agentsoftware på hvert overvåget system. ClusterControl implementerer overvågning ved hjælp af en ekstern dataindsamler, der bruger SSH-protokollen.

Før vi dykker direkte ned i de specifikke forhold ved agentfri overvågning, lad os først afklare omfanget og betydningen af ​​overvågning i vores kontekst her. Overvågning kommer efter datatrend - processen med indsamling og lagring af metrics - som gør det muligt for overvågningssystemet at behandle de indsamlede data for at skabe begrundelse for tuning, advarsel og visning af trenddata til rapportering.

Begyndende i version 1.7.0 (udgivet december 2018) understøtter ClusterControl to overvågningsmetoder:

• Agentfri overvågning (standard)
• Agent-baseret overvågning med Prometheus

Dette indlæg vil gennemgå, hvordan du overvåger dine databaseservere og klynger med ClusterControls agentfri overvågning. Hvis du leder efter mere information om ClusterControls agentbaserede overvågning, kan du henvise til denne dokumentation.

Generelt udfører ClusterControl agentfri overvågning, alarmering og trendopgaver ved hjælp af følgende tre metoder:

• SSH – Indsamling af værtsmetrikker (proces, belastningsbalanceringsstatistik, ressourceforbrug, forbrug osv.) ved hjælp af SSH-bibliotek
• Databaseklient – ​​Indsamling af databasemetrics (status, forespørgsler, variabler, brug osv.) ved hjælp af det respektive databaseklientbibliotek
• Rådgiver – Miniprogrammer skrevet ved hjælp af ClusterControl DSL og kører i selve ClusterControl til overvågning, tuning og advarselsformål

SSH står for Secure Shell, en sikker netværksprotokol, der bruges af de fleste Linux-baserede servere til fjernadministration. ClusterControl Controller, eller CMON, er backend-tjenesten, der udfører automatiserings-, administrations-, overvågnings- og planlægningsopgaver, bygget oven på C++.

ClusterControl DSL (Domain Specific Language) giver dig mulighed for at udvide funktionaliteten af ​​din ClusterControl-platform ved at oprette rådgivere, autotunere eller "miniprogrammer". DSL-syntaksen er baseret på JavaScript, med udvidelser for at give adgang til ClusterControls interne datastrukturer og funktioner. DSL giver dig mulighed for at udføre SQL-sætninger, køre shell-kommandoer/-programmer på tværs af alle dine klyngeværter og hente resultater, der skal behandles til rådgivere/advarsler eller andre handlinger.

Overvågningsværktøjer

Alle forudsætningsværktøjer opfyldes af installationsscriptet eller installeres automatisk af ClusterControl under databaseimplementeringsstadiet, eller hvis den nødvendige fil/binære/pakke ikke findes på målserveren, før et job udføres. Generelt kræver ClusterControl-overvågningspligt kun OpenSSH-serverpakken på de overvågede værter. ClusterControl bruger libssh-klientbibliotek til at indsamle værtsmetrikker for de overvågede værter – CPU, hukommelse, disk, netværk, IO, proces osv. OpenSSH-klientpakke er kun påkrævet på ClusterControl-værten for at opsætte adgangskodefri SSH og fejlfindingsformål. Andre SSH-implementeringer som Dropbear og TinySSH understøttes ikke.

Når der indsamles databasestatistik og metrics, forbinder ClusterControl Controller (CMON) til databaseserveren direkte via databaseklientbiblioteker – libmysqlclient (MySQL/MariaDB og ProxySQL), libpq (PostgreSQL) og libmongocxx (MongoDB) ). Det er derfor, det er afgørende at konfigurere de rigtige privilegier for en ClusterControl-server fra en databaseservers perspektiv. For MySQL-baserede klynger kræver ClusterControl databasebruger "cmon", mens for andre databaser kan ethvert brugernavn bruges til overvågning, så længe det er tildelt superbrugerrettigheder. Det meste af tiden vil ClusterControl konfigurere de nødvendige privilegier (eller bruge den angivne databasebruger) automatisk under klyngeimport- eller klyngeimplementeringsstadiet.

ClusterControl kræver følgende værktøjer til belastningsbalancere:

• Maxctrl på MariaDB MaxScale-serveren
• netcat og/eller socat på HAProxy-serveren for at oprette forbindelse til HAProxy-socket-filen og hente overvågningsdataene
• ProxySQL kræver en mysql-klient på ProxySQL-serveren

Følgende diagram illustrerer både værts- og databaseovervågningsprocesser, der udføres af ClusterControl ved hjælp af libssh- og databaseklientbiblioteker:

Selvom overvågningstråde ikke behøver databaseklientpakker installeret på den overvågede vært, det anbefales stærkt at have dem til administrationsformål. For eksempel kommer MySQL-klientpakken med programmerne mysql, mysqldump, mysqlbinlog og mysqladmin, som vil blive brugt af ClusterControl, når der udføres sikkerhedskopier og gendannelse på tidspunkter.

Overvågningsmetoder

Til indsamling af værts- og belastningsbalanceringsstatistik udfører ClusterControl denne opgave via SSH med superbrugerrettigheder. Derfor er adgangskodefri SSH med superbrugerrettigheder afgørende for at tillade ClusterControl at køre de nødvendige kommandoer eksternt med korrekt eskalering. Med denne pull-tilgang er der et par fordele sammenlignet med andre mekanismer:

• Agentless – Der er ikke behov for, at en agent skal installeres, konfigureres og vedligeholdes.
• Forening af administrations- og overvågningskonfigurationen – SSH kan bruges til at trække overvågningsmetrikker eller pushe administrationsjob på målknuderne.
• Forenkle implementeringen – Det eneste krav er korrekt SSH-opsætning uden adgangskode, og det er det. SSH er også meget sikkert og krypteret.
• Centraliseret opsætning – Én ClusterControl-server kan administrere flere servere og klynger, forudsat at den har tilstrækkelige ressourcer.

Trækmekanismen har dog også følgende ulemper:

• Overvågningsdataene er kun nøjagtige fra ClusterControls perspektiv. Hvis der f.eks. er en netværksfejl, og ClusterControl mister kommunikationen til den overvågede vært, vil prøvetagningen blive sprunget over indtil den næste tilgængelige cyklus.
• Der vil være netværksoverhead til overvågning med høj granularitet på grund af øget samplinghastighed, hvor ClusterControl skal etablere flere forbindelser til hver målvært.
• ClusterControl vil blive ved med at forsøge at genetablere forbindelsen til målknuden, fordi den ikke har nogen agent til at gøre dette på sine vegne.
• Redundant datasampling, hvis du har mere end én ClusterControl-server, der overvåger en klynge, da hver ClusterControl-server skal trække overvågningsdataene for sig selv.

For MySQL-forespørgselsovervågning, startende fra ClusterControl 1.9.0 (udgivet juli 2021), understøtter ClusterControl to typer:

• Agentless forespørgselsovervågning (standard)
• Agent-baseret forespørgselsovervågning ved hjælp af CMON-forespørgselsagent, som kræver yderligere trin for at aktivere det. Kun for MySQL-baserede og PostgreSQL-baserede databaser.

Agentless forespørgselsovervågning overvåger forespørgslerne på to forskellige måder:

• Forespørgsler hentes fra PERFORMANCE_SCHEMA ved at forespørge skemaet på databasenoden via SSH.
• Hvis PERFORMANCE_SCHEMA er deaktiveret eller utilgængelig, vil ClusterControl parse indholdet af Slow Query Log via SSH.

Hvis Performance Schema er aktiveret, vil ClusterControl bruge det til at lede efter de langsomme forespørgsler. Ellers vil ClusterControl parse indholdet af MySQL langsomme forespørgselslog (via slow_query_log=ON dynamisk variabel) baseret på følgende flow:

1. Start langsom log (under MySQL-kørsel).
2. Kør det i en kort periode (et sekund eller et par sekunder).
3. Stop log.
4. Parse log.
5. Trunker log (ny logfil).
6. Gå til 1.

De indsamlede forespørgsler hashes, beregnes og fordøjes (normalisere, gennemsnit, tælle, sortere) og derefter lagres i ClusterControl CMON-databasen. Bemærk, at for denne prøvetagningsmetode er der en lille chance for, at nogle forespørgsler ikke bliver fanget, især under delene "stop log, parse log, truncate log". Du kan aktivere Performance Schema, hvis dette ikke er en mulighed.

Kun forespørgsler, der overskrider den lange forespørgselstid, vil blive vist her ved hjælp af logfilen for langsom forespørgsel. Antag, at dataene ikke er udfyldt korrekt, og du mener, at der burde være noget derinde, kan det være, at enten:

• ClusterControl indsamlede ikke nok forespørgsler til at opsummere og udfylde data. Prøv at sænke den lange forespørgselstid.
• Du har konfigureret konfigurationsindstillinger for langsom forespørgselslog i my.cnf på MySQL-serveren, og Tilsidesæt lokal forespørgsel er slået fra. Hvis du virkelig vil bruge den værdi, du har defineret inde i my.cnf, bliver du sandsynligvis nødt til at sænke long_query_time-værdien, så ClusterControl kan beregne et mere præcist resultat.
• Du har en anden ClusterControl-node, der også trækker Slow Query-loggen (i tilfælde af at du har en standby ClusterControl-server). Tillad kun én ClusterControl-server at udføre dette job.

Du kan også bruge ClusterControl Query Monitor til MySQL, MariaDB og Percona Server.

For PostgreSQL-forespørgselsovervågning kræver ClusterControl modulet pg_stat_statements for at spore eksekveringsstatistikker for alle SQL-sætninger. Den udfylder pg_stat_statements-visningerne og -funktionerne, når forespørgslerne vises i brugergrænsefladen (under fanen Query Monitor).

Intervaller og timeouts

ClusterControl Controller (cmon) er en flertrådsproces. Som standard forbinder ClusterControl Controller-samplingstråden til hver overvåget vært én gang og opretholder en vedvarende forbindelse, indtil værten falder eller afbrydes, når der udtages værtsstatistik. Det kan etablere flere forbindelser afhængigt af de job, der er tildelt til værten, da de fleste af ledelsesjobene kører i deres egen tråd. For eksempel kører klyngendannelse på gendannelsestråden, Advisor-udførelse kører på en cron-tråd, og procesovervågning kører på procesopsamlertråden.

ClusterControl-overvågningstråd udfører følgende samplingsoperationer i følgende interval:

• MySQL-forespørgsel/statusmålinger:hvert sekund
• Procesindsamling (/proc):hvert 10. sekund
• Serverregistrering:hvert 10. sekund
• Host-metrics (/proc, /sys):hvert 30. sekund (kan konfigureres via host_stats_collection_interval)
• Databasemålinger (kun PostgreSQL og MongoDB):hvert 30. sekund (kan konfigureres via db_stats_collection_interval)
• Databaseskemametrics:hver 3. time (kan konfigureres via db_schema_stats_collection_interval)
• Load balancer-metrics:hvert 15. sekund (kan konfigureres via lb_stats_collection_interval)

De imperative scripts (rådgivere) kan gøre brug af SSH- og databaseklientbiblioteker, der følger med CMON med følgende begrænsninger:

• 5 sekunders hård grænse for SSH-udførelse.
• 10 sekunders standardgrænse for databaseforbindelse, konfigurerbar via net_read_timeout, net_write_timeout, connect_timeout i CMON-konfigurationsfilen.
• 60 sekunder af den samlede scriptudførelsestidsgrænse, før CMON ungerigt afbryder det.

Rådgivere kan oprettes, kompileres, testes og planlægges direkte fra ClusterControls brugergrænseflade under Administrer → Udviklerstudie . Følgende skærmbillede viser et eksempel på en rådgiver til at udtrække top 10 forespørgsler fra PERFORMANCE_SCHEMA:

Udførelsen af ​​rådgivere afhænger af, om den er aktiveret, og tidsplanlægningstiden i cron-format:

Resultaterne af udførelsen vises under Ydeevne → Rådgivere , som vist på følgende skærmbillede:

For mere information om, hvilke rådgivere der leveres som standard, tjek vores udvikler Studio produktside.

Data gemmes direkte i CMON-databasen til overvågningsdata med kort intervaller som MySQL-forespørgsler og status. Overvågningsdata med lang intervaller som ugentlige/månedlige/årlige datapunkter aggregeres hvert 60. sekund og gemmes i hukommelsen i 10 minutter. Disse adfærd kan ikke konfigureres på grund af arkitekturdesignet.

Parametre

ClusterControl har mange parametre, der passer til din overvågnings- og advarselspolitik. De fleste af dem kan konfigureres gennem ClusterControl UI → vælg en klynge → Indstillinger . Fanen "Indstillinger" giver mange muligheder for at konfigurere advarsler, tærskler, meddelelser, graflayout, databasetællere, forespørgselsovervågning og så videre. For eksempel kan advarsler og kritiske tærskler konfigureres som følger:

"Runtime Configuration"-siden viser en opsummeret liste over den aktive ClusterControl Controller (CMON) runtime konfigurationsparametre:

Der er mere end 170 ClusterControl Controller-konfigurationsmuligheder i alt, og nogle af de avancerede indstillinger kan konfigureres til finjustering af overvågning og advarselspolitik. Nogle af disse omfatter:

• 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

Du kan ændre parametrene angivet på siden "Runtime Configuration" ved enten at bruge UI- eller CMON-konfigurationsfilen, der findes på /etc/cmon.d/cmon_X.cnf, hvor X er klynge-id'et. Du kan liste alle de understøttede konfigurationsmuligheder for CMON ved at bruge følgende kommando:

$ cmon --help-config

Sidste tanker

Agentløs overvågning er blevet en af ​​de mest effektive metoder til at administrere stadig mere komplekse databaseinfrastrukturer. Det reducerer byrden af ​​mange udfordringer forbundet med databaseovervågning og er let at administrere.

Der er masser af agentløse overvågningsværktøjer tilgængelige i dag. Men ikke mange af dem tilbyder også en komplet platform fuld af funktioner, der hjælper dig med at administrere alle andre aspekter af dine databaseklynger. For at se, hvad ClusterControl ellers kan gøre, skal du sørge for at downloade din egen gratis 30-dages prøveversion.

Leder du efter et agentbaseret alternativ til databaseovervågning? Tjek ClusterControls agentbaserede databaseovervågningsinfrastruktur — SCUMM.