Мониторинг на база данни без агент с ClusterControl

С нарастващата сложност на настройките на базата данни много системни администратори и администратори на база данни се обръщат към подход без агент, за да помогнат за облекчаване на тежестта на предизвикателствата при наблюдение на базата данни. Мониторингът без агенти на ClusterControl ви позволява да наблюдавате бази данни, без да инсталирате агент софтуер на всяка наблюдавана система. ClusterControl реализира наблюдение с помощта на отдалечен колектор на данни, който използва SSH протокола.

Преди да се потопим направо в спецификата на наблюдението без агенти, нека първо изясним обхвата и значението на наблюдението в нашия контекст тук. Мониторингът идва след тенденцията на данните — процесът на събиране и съхранение на показатели — който позволява на системата за наблюдение да обработва събраните данни, за да произведе обосновка за настройка, предупреждение и показване на актуални данни за отчитане.

Започвайки от версия 1.7.0 (издадена декември 2018 г.), ClusterControl поддържа два метода за наблюдение:

• Наблюдение без агент (по подразбиране)
• Наблюдение, базирано на агенти с Prometheus

Тази публикация ще ви покаже как да наблюдавате сървърите и клъстерите на вашите бази данни с мониторинг без агенти на ClusterControl. Ако търсите повече информация относно мониторинга, базиран на агенти на ClusterControl, можете да се обърнете към тази документация.

Като цяло ClusterControl изпълнява безагентни задачи за наблюдение, сигнали и тенденции, като използва следните три метода:

• SSH – Събиране на показатели за хост (процес, статистика за балансиране на натоварването, използване на ресурси, потребление и т.н.) с помощта на библиотека SSH
• Клиент на база данни – Колекция от показатели на базата данни (състояние, заявки, променливи, използване и т.н.), използвайки съответната клиентска библиотека на базата данни
• Съветник – Мини програми, написани с помощта на ClusterControl DSL и работещи в самия ClusterControl с цел наблюдение, настройка и предупреждение

SSH означава Secure Shell, защитен мрежов протокол, използван от повечето базирани на Linux сървъри за отдалечено администриране. ClusterControl Controller или CMON е бекенд услугата, изпълняваща задачи за автоматизация, управление, наблюдение и планиране, изградена върху C++.

ClusterControl DSL (специфичен за домейн език) ви позволява да разширите функционалността на вашата платформа ClusterControl чрез създаване на съветници, автоматични тунери или „мини програми“. Синтаксисът на DSL се основава на JavaScript, с разширения за осигуряване на достъп до вътрешни структури и функции на ClusterControl. DSL ви позволява да изпълнявате SQL оператори, да изпълнявате команди/програми на обвивката във всичките си хостове на клъстери и да извличате резултати, които да бъдат обработени за съветници/известия или всякакви други действия.

Инструменти за наблюдение

Всички необходими инструменти се изпълняват от скрипта на инсталатора или се инсталират автоматично от ClusterControl по време на етапа на разполагане на базата данни или ако необходимият файл/двоичен файл/пакет не съществува на целевия сървър, преди да се изпълни задание. Най-общо казано, задължението за наблюдение на ClusterControl изисква само OpenSSH сървърен пакет на наблюдаваните хостове. ClusterControl използва клиентска библиотека libssh за събиране на метрики на хоста за наблюдаваните хостове – процесор, памет, диск, мрежа, IO, процес и т.н. OpenSSH клиентски пакет е необходим на хоста на ClusterControl само за настройване на SSH без парола и целите за отстраняване на грешки. Други SSH реализации като Dropbear и TinySSH не се поддържат.

Когато събира статистиката и показателите на базата данни, ClusterControl Controller (CMON) се свързва със сървъра на база данни директно чрез клиентски библиотеки на база данни – libmysqlclient (MySQL/MariaDB и ProxySQL), libpq (PostgreSQL) и libmongocxx (Mongocxx ). Ето защо е изключително важно да настроите подходящи привилегии за сървър ClusterControl от гледна точка на сървъра на база данни. За клъстери, базирани на MySQL, ClusterControl изисква потребител на база данни „cmon“, докато за други бази данни всяко потребителско име може да се използва за наблюдение, стига да му се предоставят привилегии на суперпотребител. През повечето време ClusterControl ще настрои необходимите привилегии (или ще използва посочения потребител на базата данни) автоматично по време на етапа на импортиране на клъстер или разгръщане на клъстер.

ClusterControl изисква следните инструменти за балансиране на натоварването:

• Maxctrl на сървъра MariaDB MaxScale
• netcat и/или socat на HAProxy сървъра за свързване към HAProxy сокет файла и извличане на данните за наблюдение
• ProxySQL изисква mysql клиент на ProxySQL сървъра

Следната диаграма илюстрира процесите за наблюдение на хоста и базата данни, изпълнявани от ClusterControl с помощта на libssh и клиентски библиотеки на база данни:

Въпреки че нишките за наблюдение не се нуждаят от клиентски пакети на база данни, инсталирани на наблюдавания хост, силно препоръчително е да ги имате за целите на управлението. Например, клиентският пакет MySQL идва с програми mysql, mysqldump, mysqlbinlog и mysqladmin, които ще се използват от ClusterControl при извършване на архивиране и възстановяване в момента.

Методи за наблюдение

За събиране на статистики за хост и балансиране на натоварване, ClusterControl изпълнява тази задача чрез SSH с привилегия на суперпотребител. Следователно, SSH без парола с привилегия на суперпотребител е жизненоважен, за да позволи на ClusterControl да изпълнява необходимите команди отдалечено с подходящо ескалиране. С този подход на изтегляне има няколко предимства в сравнение с други механизми:

• Без агенти – Няма нужда агент да бъде инсталиран, конфигуриран и поддържан.
• Обединяване на конфигурацията за управление и наблюдение – SSH може да се използва за изтегляне на метрики за наблюдение или изпращане на задачи за управление на целевите възли.
• Опростете внедряването – Единственото изискване е правилна настройка на SSH без парола и това е всичко. SSH също е много сигурен и криптиран.
• Централизирана настройка – Един сървър на ClusterControl може да управлява множество сървъри и клъстери, при условие че разполага с достатъчно ресурси.

Въпреки това, механизмът за изтегляне има и следните недостатъци:

• Данните за наблюдение са точни само от гледна точка на ClusterControl. Например, ако има проблем в мрежата и ClusterControl загуби комуникация с наблюдавания хост, вземането на проби ще бъде пропуснато до следващия наличен цикъл.
• Ще има мрежови разходи за мониторинг с висока детайлност поради повишената честота на дискретизация, при която ClusterControl трябва да установи повече връзки към всеки целеви хост.
• ClusterControl ще продължи да се опитва да възстанови връзката с целевия възел, защото няма агент, който да направи това от негово име.
• Излишно вземане на проби от данни, ако имате повече от един сървър на ClusterControl, наблюдаващ клъстер, тъй като всеки сървър на ClusterControl трябва да извлича данните за наблюдение за себе си.

За мониторинг на MySQL заявки, започвайки от ClusterControl 1.9.0 (издадена юли 2021 г.), ClusterControl поддържа два типа:

• Наблюдение на заявки без агент (по подразбиране)
• Наблюдение на заявки, базирано на агент, с помощта на агент за заявки CMON, което изисква допълнителни стъпки, за да го активирате. Само за базирани на MySQL и PostgreSQL бази данни.

Мониторингът на заявки без агент следи заявките по два различни начина:

• Заявките се извличат от PERFORMANCE_SCHEMA чрез запитване на схемата на възела на базата данни чрез SSH.
• Ако PERFORMANCE_SCHEMA е деактивирана или недостъпна, ClusterControl ще анализира съдържанието на дневника за бавни заявки чрез SSH.

Ако схемата за ефективност е активирана, ClusterControl ще я използва, за да търси бавните заявки. В противен случай ClusterControl ще анализира съдържанието на дневника на бавните заявки на MySQL (чрез динамична променлива slow_query_log=ON) въз основа на следния поток:

1. Стартирайте бавен журнал (по време на изпълнение на MySQL).
2. Изпълнете го за кратък период от време (секунда или няколко секунди).
3. Спиране на журнала.
4. Разбиране на дневника.
5. Отрязване на регистрационния файл (нов регистрационен файл).
6. Отидете на 1.

Събраните заявки се хешират, изчисляват и усвояват (нормализират, усредняват, преброяват, сортират) и след това се съхраняват в базата данни ClusterControl CMON. Обърнете внимание, че за този метод за вземане на проби има малка вероятност някои заявки да не бъдат уловени, особено по време на частите „стоп дневник, синтактичен дневник, съкратен дневник“. Можете да активирате схемата на производителност, ако това не е опция.

Само заявки, които надвишават дългото време на заявка, ще бъдат изброени тук с помощта на дневника за бавни заявки. Да предположим, че данните не са попълнени правилно и смятате, че трябва да има нещо вътре, може да бъде или следното:

• ClusterControl не събра достатъчно заявки за обобщаване и попълване на данни. Опитайте се да намалите дългото време за заявка.
• Конфигурирали сте опциите за конфигурация на бавен дневник на заявките в my.cnf на MySQL сървъра и Override Local Query е изключено. Ако наистина искате да използвате стойността, която сте дефинирали в my.cnf, вероятно ще трябва да намалите стойността long_query_time, за да може ClusterControl да изчисли по-точен резултат.
• Имате и друг възел на ClusterControl, който изтегля и дневника на Slow Query (в случай че имате резервен сървър на ClusterControl). Разрешете само на един сървър на ClusterControl да върши тази работа.

Можете също да използвате ClusterControl Query Monitor за MySQL, MariaDB и Percona Server.

За наблюдение на заявки на PostgreSQL ClusterControl изисква модула pg_stat_statements за проследяване на статистически данни за изпълнението на всички SQL изрази. Той попълва изгледите и функциите pg_stat_statements, когато показва заявките в потребителския интерфейс (в раздела Монитор на заявки).

Интервали и изчаквания

ClusterControl Controller (cmon) е многонишков процес. По подразбиране нишката за вземане на проби на ClusterControl Controller се свързва с всеки наблюдаван хост веднъж и поддържа постоянна връзка, докато хостът не се свърже или прекъсне, когато взема извадка от статистиката на хоста. Може да установи повече връзки в зависимост от заданията, присвоени на хоста, тъй като повечето от задачите за управление се изпълняват в собствена нишка. Например възстановяването на клъстер се изпълнява в нишката за възстановяване, изпълнението на Advisor се изпълнява в cron-нишката, а мониторингът на процеса се изпълнява в нишката на колектора на процесите.

Нишката за наблюдение на ClusterControl изпълнява следните операции за вземане на проби в следния интервал:

• Показатели за MySQL заявка/състояние:всяка секунда
• Събиране на процеса (/proc):на всеки 10 секунди
• Откриване на сървър:на всеки 10 секунди
• Показатели за хост (/proc, /sys):на всеки 30 секунди (конфигурира се чрез host_stats_collection_interval)
• Показатели на базата данни (само за PostgreSQL и MongoDB):на всеки 30 секунди (конфигурира се чрез db_stats_collection_interval)
• Показатели на схемата на базата данни:на всеки 3 часа (конфигурира се чрез db_schema_stats_collection_interval)
• Показатели за балансиране на зареждане:на всеки 15 секунди (конфигурира се чрез lb_stats_collection_interval)

Императивните скриптове (Advisors) могат да използват SSH и клиентски библиотеки на база данни, които идват с CMON със следните ограничения:

• 5 секунди твърдо ограничение за SSH изпълнение.
• 10 секунди ограничение по подразбиране за връзка с база данни, конфигурируемо чрез net_read_timeout, net_write_timeout, connect_timeout в конфигурационен файл CMON.
• 60 секунди от общото време за изпълнение на скрипта, преди CMON неудобно да го прекрати.

Съветниците могат да се създават, компилират, тестват и планират директно от потребителския интерфейс на ClusterControl под Управление → Студио за разработчици . Следната екранна снимка показва пример за съветник за извличане на топ 10 заявки от PERFORMANCE_SCHEMA:

Изпълнението на съветниците зависи от това дали е активирано и времето за планиране във формат cron:

Резултатите от изпълнението се показват под Ефективност → Съветници , както е показано на следната екранна снимка:

За повече информация относно това какви съветници се предоставят по подразбиране, вижте нашия разработчик Продуктова страница на Studio.

Данните се съхраняват директно в базата данни CMON за данни за наблюдение на кратък интервал, като MySQL заявки и състояние. Данните за мониторинг на дълги интервали като седмични/месечни/годишни данни се обобщават на всеки 60 секунди и се съхраняват в паметта за 10 минути. Тези поведения не могат да се конфигурират поради архитектурния дизайн.

Параметри

ClusterControl има много параметри, които да отговарят на вашата политика за наблюдение и предупреждение. Повечето от тях се конфигурират чрез Потребителски интерфейс на ClusterControl → изберете клъстер → Настройки . Разделът „Настройки“ предоставя много опции за конфигуриране на сигнали, прагове, известия, оформление на графиката, броячи на базата данни, наблюдение на заявки и т.н. Например, предупредителните и критичните прагове се конфигурират, както следва:

Страницата „Конфигурация по време на изпълнение“ показва обобщен списък на активния контролер ClusterControl (CMON) конфигурационни параметри по време на изпълнение:

Има общо повече от 170 опции за конфигурация на ClusterControl Controller и някои от Разширените настройки могат да бъдат конфигурирани за наблюдение и фина настройка на политиката за предупреждение. Някои от тях включват:

• monitor_cpu_temperature
• swap_warning
• swap_critical
• redobuffer_warning
• redobuffer_critical
• indexmemory_warning
• indexmemory_critical
• datamemory_warning
• datamemory_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

Можете да промените параметрите, изброени на страницата „Конфигурация по време на изпълнение“, като използвате UI или CMON конфигурационния файл, намиращ се в /etc/cmon.d/cmon_X.cnf, където X е идентификаторът на клъстера. Можете да изброите всички поддържани опции за конфигурация за CMON, като използвате следната команда:

$ cmon --help-config

Последни мисли

Мониторингът без агенти се превърна в един от най-ефективните методи за управление на все по-сложни инфраструктури на бази данни. Той намалява тежестта на много предизвикателства, свързани с мониторинга на базата данни и е лесен за управление.

Днес има много инструменти за наблюдение без агенти. Въпреки това, не много от тях предлагат и пълна платформа, пълна с функции, които да ви помогнат да управлявате всеки друг аспект на клъстерите на вашите бази данни. За да видите какво още може да направи ClusterControl, не забравяйте да изтеглите своя собствена безплатна 30-дневна пробна версия.

Търсите ли алтернатива на базата на агенти за наблюдение на база данни? Вижте базираната на агенти инфраструктура за мониторинг на база данни на ClusterControl – SCUMM.