S rostoucí složitostí nastavení databází se mnoho SysAdminů a DBA obrací na přístup bez agentů, aby jim pomohly zmírnit zátěž související s monitorováním databáze. Monitorování ClusterControl bez agentů vám umožňuje sledovat databáze bez instalace softwaru agenta na každý monitorovaný systém. ClusterControl implementuje monitorování pomocí vzdáleného sběrače dat, který používá protokol SSH.
Než se pustíme přímo do specifik monitorování bez agentů, nejprve si zde ujasněme rozsah a význam monitorování v našem kontextu. Monitorování následuje po trendování dat – procesu shromažďování a ukládání metrik – což umožňuje monitorovacímu systému zpracovat shromážděná data, aby bylo možné vyladit, upozorňovat a zobrazovat data trendů pro vytváření přehledů.
Od verze 1.7.0 (vydané v prosinci 2018) podporuje ClusterControl dvě metody monitorování:
- Monitorování bez agentů (výchozí)
- Monitorování pomocí agentů pomocí Prometheus
Tento příspěvek vás seznámí s tím, jak monitorovat databázové servery a clustery pomocí monitorování bez agentů ClusterControl. Pokud hledáte další informace o monitorování ClusterControl založeném na agentech, můžete se podívat do této dokumentace.
ClusterControl obecně provádí monitorování, upozorňování a sledování trendů bez agentů pomocí následujících tří metod:
- SSH – Sběr metrik hostitele (proces, statistiky nástroje pro vyrovnávání zatížení, využití zdrojů, spotřeba atd.) pomocí knihovny SSH
- Databázový klient – sběr metrik databáze (stav, dotazy, proměnné, využití atd.) pomocí příslušné knihovny databázového klienta
- Advisor – Mini programy napsané pomocí ClusterControl DSL a spuštěné v samotném ClusterControl pro účely monitorování, ladění a upozornění
SSH je zkratka pro Secure Shell, zabezpečený síťový protokol používaný většinou serverů založených na Linuxu pro vzdálenou správu. ClusterControl Controller, neboli CMON, je backendová služba provádějící automatizaci, správu, monitorování a plánování, postavená na C++.
ClusterControl DSL (Domain Specific Language) vám umožňuje rozšířit funkčnost vaší platformy ClusterControl vytvořením poradců, automatických tunerů nebo „mini programů“. Syntaxe DSL je založena na JavaScriptu s rozšířeními umožňujícími přístup k interním datovým strukturám a funkcím ClusterControl. DSL vám umožňuje spouštět příkazy SQL, spouštět příkazy/programy shellu na všech hostitelích clusteru a získávat výsledky ke zpracování pro poradce/výstrahy nebo jakékoli jiné akce.
Nástroje pro monitorování
Všechny nezbytné nástroje splňuje instalační skript nebo je automaticky nainstaluje ClusterControl během fáze nasazení databáze nebo pokud požadovaný soubor/binární soubor/balíček neexistuje na cílovém serveru před provedením úlohy. Obecně řečeno, povinnost monitorování ClusterControl vyžaduje pouze balík serveru OpenSSH na monitorovaných hostitelích. ClusterControl používá klientskou knihovnu libssh ke shromažďování metrik hostitelů pro monitorované hostitele – CPU, paměť, disk, síť, IO, proces atd. Klientský balíček OpenSSH je vyžadován na hostiteli ClusterControl pouze pro nastavení SSH bez hesla a účely ladění. Jiné implementace SSH jako Dropbear a TinySSH nejsou podporovány.
Při shromažďování statistik a metrik databáze se ClusterControl Controller (CMON) připojuje k databázovému serveru přímo prostřednictvím klientských knihoven databáze – libmysqlclient (MySQL/MariaDB a ProxySQL), libpq (PostgreSQL) a libmongocxx (MongoDB ). Proto je klíčové nastavit správná oprávnění pro server ClusterControl z pohledu databázového serveru. U clusterů založených na MySQL vyžaduje ClusterControl databázového uživatele „cmon“, zatímco u jiných databází lze pro monitorování použít libovolné uživatelské jméno, pokud má oprávnění superuživatele. Ve většině případů ClusterControl nastaví požadovaná oprávnění (nebo použije zadaného uživatele databáze) automaticky během fáze importu nebo nasazení clusteru.
ClusterControl vyžaduje následující nástroje pro vyrovnávání zatížení:
- Maxctrl na serveru MariaDB MaxScale
- netcat a/nebo socat na serveru HAProxy pro připojení k souboru soketu HAProxy a načtení monitorovacích dat
- ProxySQL vyžaduje klienta mysql na serveru ProxySQL
Následující diagram ilustruje procesy monitorování hostitele i databáze prováděné ClusterControl pomocí libssh a databázových klientských knihoven:
Přestože monitorovací vlákna nepotřebují na monitorovaném hostiteli nainstalované balíčky databázových klientů, důrazně se doporučuje mít je pro účely správy. Například klientský balíček MySQL je dodáván s programy mysql, mysqldump, mysqlbinlog a mysqladmin, které bude ClusterControl používat při provádění záloh a obnovy v určitém okamžiku.
Metody monitorování
Pro sběr statistik hostitele a nástroje pro vyrovnávání zatížení provádí ClusterControl tuto úlohu prostřednictvím SSH s oprávněním superuživatele. Proto je SSH bez hesla s oprávněním superuživatele životně důležité, aby ClusterControl mohl spouštět potřebné příkazy na dálku se správnou eskalací. Tento přístup tahu má ve srovnání s jinými mechanismy několik výhod:
- Bez agenta – Agenta není třeba instalovat, konfigurovat a udržovat.
- Sjednocení konfigurace správy a monitorování – SSH lze použít ke stahování monitorovacích metrik nebo úloh správy push na cílových uzlech.
- Zjednodušte nasazení – Jediným požadavkem je správné nastavení SSH bez hesla a to je vše. SSH je také velmi bezpečné a šifrované.
- Centralizované nastavení – jeden server ClusterControl může spravovat více serverů a clusterů za předpokladu, že má dostatečné zdroje.
Tažný mechanismus má však také následující nevýhody:
- Monitorovací údaje jsou přesné pouze z pohledu ClusterControl. Pokud například dojde k závadě sítě a ClusterControl ztratí komunikaci s monitorovaným hostitelem, vzorkování bude přeskočeno až do dalšího dostupného cyklu.
- Vzhledem ke zvýšené vzorkovací frekvenci, kdy ClusterControl potřebuje vytvořit více připojení ke každému cílovému hostiteli, dojde k režii sítě pro vysoce podrobné monitorování.
- ClusterControl se bude neustále pokoušet o obnovení připojení k cílovému uzlu, protože nemá žádného agenta, který by to udělal jeho jménem.
- Redundantní vzorkování dat, pokud máte více než jeden server ClusterControl, který monitoruje cluster, protože každý server ClusterControl si musí data monitorování získávat sám.
Pro monitorování dotazů MySQL, počínaje ClusterControl 1.9.0 (vydáno v červenci 2021), ClusterControl podporuje dva typy:
- Monitorování dotazů bez agenta (výchozí)
- Agentové monitorování dotazů pomocí dotazovacího agenta CMON, které vyžaduje další kroky k jeho aktivaci. Pouze pro databáze založené na MySQL a PostgreSQL.
Monitorování dotazů bez agenta monitoruje dotazy dvěma různými způsoby:
- Dotazy se získávají z PERFORMANCE_SCHEMA dotazem na schéma v uzlu databáze přes SSH.
- Pokud je PERFORMANCE_SCHEMA zakázáno nebo nedostupné, ClusterControl analyzuje obsah protokolu pomalých dotazů prostřednictvím SSH.
Pokud je povoleno schéma výkonu, ClusterControl jej použije k vyhledání pomalých dotazů. Jinak ClusterControl analyzuje obsah protokolu pomalých dotazů MySQL (prostřednictvím dynamické proměnné slow_query_log=ON) na základě následujícího postupu:
- Spustit pomalý protokol (během běhu MySQL).
- Spusťte jej na krátkou dobu (sekundu nebo několik sekund).
- Protokol zastavení.
- Protokol analýzy.
- Zkrácení protokolu (nový soubor protokolu).
- Přejděte na 1.
Shromážděné dotazy jsou hashovány, počítány a zpracovávány (normalizovány, zprůměrovány, spočítány, seřazeny) a poté uloženy do databáze ClusterControl CMON. Vezměte na vědomí, že u této metody vzorkování existuje malá šance, že některé dotazy nebudou zachyceny, zejména během částí „stop log, parse log, truncate log“. Pokud to není možnost, můžete povolit schéma výkonu.
Pouze dotazy, které přesahují Dlouhou dobu dotazování, zde budou uvedeny pomocí protokolu Slow Query. Předpokládejme, že data nejsou správně vyplněna a myslíte si, že by tam něco mělo být, mohlo by to být:
- ClusterControl neshromáždil dostatek dotazů pro shrnutí a naplnění dat. Zkuste zkrátit Dlouhou dobu dotazování.
- Nakonfigurovali jste možnosti konfigurace protokolu pomalého dotazu v my.cnf serveru MySQL a funkce Přepsat místní dotaz je vypnutá. Pokud opravdu chcete použít hodnotu, kterou jste definovali v my.cnf, budete pravděpodobně muset snížit hodnotu long_query_time, aby ClusterControl mohl vypočítat přesnější výsledek.
- Máte další uzel ClusterControl, který také stahuje protokol Slow Query (v případě, že máte záložní server ClusterControl). Tuto úlohu povolte pouze jednomu serveru ClusterControl.
Můžete také použít ClusterControl Query Monitor pro MySQL, MariaDB a Percona Server.
Pro monitorování dotazů PostgreSQL vyžaduje ClusterControl modul pg_stat_statements ke sledování statistik provádění všech příkazů SQL. Vyplní pohledy a funkce pg_stat_statements při zobrazování dotazů v uživatelském rozhraní (na kartě Monitor dotazů).
Intervaly a časové limity
ClusterControl Controller (cmon) je vícevláknový proces. Ve výchozím nastavení se vzorkovací vlákno ClusterControl Controller připojí ke každému monitorovanému hostiteli jednou a udržuje trvalé připojení, dokud hostitel neklesne nebo se neodpojí při vzorkování statistik hostitele. Může vytvořit více připojení v závislosti na úlohách přiřazených k hostiteli, protože většina úloh správy běží ve vlastním vláknu. Například obnova clusteru běží na vláknu obnovy, provádění Advisor běží na cron-vláknu a monitorování procesů běží na vláknu kolektoru procesů.
Monitorovací vlákno ClusterControl provádí následující operace vzorkování v následujícím intervalu:
- Metriky dotazů/stavů MySQL:každou sekundu
- Zpracovat sběr (/proc):každých 10 sekund
- Detekce serveru:každých 10 sekund
- Metriky hostitele (/proc, /sys):každých 30 sekund (konfigurovatelné pomocí host_stats_collection_interval)
- Metriky databáze (pouze PostgreSQL a MongoDB):každých 30 sekund (konfigurovatelné pomocí db_stats_collection_interval)
- Metriky schématu databáze:každé 3 hodiny (konfigurovatelné pomocí db_schema_stats_collection_interval)
- Metriky nástroje pro vyrovnávání zatížení:každých 15 sekund (konfigurovatelné pomocí lb_stats_collection_interval)
Imperativní skripty (Advisors) mohou využívat SSH a knihovny databázových klientů, které se dodávají s CMON, s následujícími omezeními:
- 5 sekund pevného limitu pro spuštění SSH.
- 10 sekund výchozího limitu pro připojení k databázi, konfigurovatelného pomocí net_read_timeout, net_write_timeout, connect_timeout v konfiguračním souboru CMON.
- 60 sekund z celkového časového limitu pro provádění skriptu, než jej CMON bezdůvodně přeruší.
Poradce lze vytvářet, kompilovat, testovat a plánovat přímo z uživatelského rozhraní ClusterControl pod Spravovat → Developer Studio . Následující snímek obrazovky ukazuje příklad poradce pro extrahování 10 nejčastějších dotazů z PERFORMANCE_SCHEMA:
Provádění poradců závisí na tom, zda je aktivováno, a na čase plánování ve formátu cron:
Výsledky provedení se zobrazí v části Výkon → Poradci , jak je znázorněno na následujícím snímku obrazovky:
Další informace o tom, co jsou ve výchozím nastavení poskytováni poradci, najdete v našem Vývojáři Stránka produktu Studio.
Data jsou ukládána přímo do databáze CMON pro krátkodobé monitorování dat, jako jsou dotazy a stav MySQL. Data z dlouhodobého monitorování, jako jsou týdenní/měsíční/roční datové body, se agregují každých 60 sekund a ukládají se do paměti po dobu 10 minut. Tato chování nelze konfigurovat kvůli návrhu architektury.
Parametry
ClusterControl má mnoho parametrů, které vyhovují vašim zásadám monitorování a upozornění. Většinu z nich lze konfigurovat pomocí uživatelského rozhraní ClusterControl → vybrat cluster → Nastavení . Karta „Nastavení“ poskytuje mnoho možností pro konfiguraci výstrah, prahových hodnot, upozornění, rozložení grafu, databázových čítačů, monitorování dotazů atd. Například varovné a kritické prahové hodnoty lze konfigurovat následovně:
Stránka „Runtime Configuration“ zobrazuje souhrnný seznam aktivního řadiče ClusterControl (CMON) runtime konfigurační parametry:
Celkem existuje více než 170 možností konfigurace ClusterControl Controller a některé z nich pokročilá nastavení lze konfigurovat sledováním a doladěním politiky upozornění. Některé z nich zahrnují:
- monitor_cpu_temperature
- swap_warning
- swap_critical
- redobuffer_warning
- redobuffer_critical
- indexmemory_warning
- indexmemory_critical
- datamemory_warning
- datamemory_critical
- varování_tabulkového_prostoru
- kritický_tabulkový_prostor
- 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
Parametry uvedené na stránce „Runtime Configuration“ můžete změnit pomocí uživatelského rozhraní nebo konfiguračního souboru CMON umístěného na adrese /etc/cmon.d/cmon_X.cnf, kde X je ID clusteru. Pomocí následujícího příkazu můžete vypsat všechny podporované možnosti konfigurace pro CMON:
$ cmon --help-configPoslední myšlenky
Monitorování bez agentů se stalo jednou z nejúčinnějších metod pro správu stále složitějších databázových infrastruktur. Snižuje zátěž mnoha problémů spojených s monitorováním databáze a snadno se spravuje.
V současnosti je k dispozici mnoho nástrojů pro monitorování bez agentů. Jen málo z nich však nabízí kompletní platformu plnou funkcí, které vám pomohou spravovat každý další aspekt vašich databázových clusterů. Chcete-li zjistit, co ještě ClusterControl umí, nezapomeňte si stáhnout vlastní bezplatnou 30denní zkušební verzi.
Hledáte alternativu k monitorování databáze na bázi agentů? Podívejte se na infrastrukturu monitorování databází na bázi agentů ClusterControl — SCUMM.