ClusterControl 1.7.0 въвежда смела нова функция - интеграция с Prometheus за мониторинг, базиран на агенти. Нарекохме това SCUMM (Обединено управление и наблюдение на няколко клъстера). В предишните версии задачите за наблюдение се изпълняваха единствено без агент. Ако се чудите как ClusterControl изпълнява функциите си за наблюдение, вижте тази страница с документация.
ProxySQL, високопроизводителен обратен прокси, който разбира MySQL протоколи, обикновено се намира на върха на MySQL репликация и Galera Cluster, за да действа като портал към бекенд услугата MySQL. Може да бъде конфигуриран като рутер за заявки, защитна стена на заявки, кеширане на заявки, диспечер на трафик и много други. ProxySQL също събира и излага ключови показатели чрез своята схема STATS, която е много полезна за анализиране на производителността и разбиране какво всъщност се случва зад кулисите. Посетете нашия изчерпателен урок за ProxySQL, за да научите повече за него.
В тази публикация в блога ще разгледаме задълбочено наблюдението на екземплярите на ProxySQL с този нов подход. В този пример имаме ProxySQL екземпляр върху нашата MySQL репликация с два възела (1 главен, 1 подчинен), разгърнат чрез ClusterControl. Нашата архитектура на високо ниво изглежда така:
Също така имаме следните правила за заявка, дефинирани в екземпляра на ProxySQL (само за справка, за да осмислим събраните показатели за наблюдение по-надолу):
Активиране на Prometheus
Базираният на агент мониторинг на ClusterControl е разрешен за всеки клъстер. ClusterControl може да разположи нов сървър на Prometheus вместо вас или да използва съществуващ сървър Prometheus (разгърнат от ClusterControl за друг клъстер). Активирането на Prometheus е доста лесно. Просто отидете на ClusterControl -> изберете клъстера -> Табла за управление -> Активиране на мониторинг, базиран на агенти:
След това посочете IP адреса или името на хоста на новия сървър на Prometheus или просто изберете съществуващ хост на Prometheus от падащото меню:
ClusterControl ще инсталира и конфигурира необходимите пакети (Prometheus на сървъра Prometheus, експортери на базата данни и ProxySQL възли), ще се свърже с Prometheus като източник на данни и ще започне да визуализира данните за наблюдение в потребителския интерфейс.
След като задачата за внедряване приключи, трябва да имате достъп до раздела Табла за управление, както е показано в следващия раздел.
Табло за управление на ProxySQL
Можете да получите достъп до таблата за управление на ProxySQL, като отидете до съответния клъстер в раздела Табла за управление. Щракването върху падащото табло за управление ще изброи таблата, свързани с нашия клъстер (MySQL репликация). Можете да намерите таблото за управление с преглед на ProxySQL в секцията „Балансиране на натоварването“:
Има редица панели за ProxySQL, някои от тях се разбират сами. Независимо от това, нека ги посетим един по един.
Размер на хост групата
Размерът на хостгрупата е просто общият брой хостове във всички хост групи:
В този случай имаме две хостгрупи - 10 (писател) и 20 (четец). Хостгрупа 10 се състои от един хост (главен), докато хост група 20 има два хоста (главен и подчинен), което обобщава до общо три хоста.
Освен ако не промените конфигурацията на хостгрупата (въведете нов хост, премахнете съществуващ хост) от ProxySQL, трябва да очаквате, че нищо няма да се промени в тази графика.
Клиентски връзки
Броят на клиентската връзка, която се обработва от ProxySQL за всички хост групи:
Горната графика просто ни казва, че има постоянно 8 MySQL клиента, свързани към нашия ProxySQL екземпляр на порт 6033 за последните 45 минути (можете да промените това под опцията „Избор на диапазон“). Ако спрете да свързвате приложението си с ProxySQL (или го заобиколите), стойността в крайна сметка трябва да падне до 0.
Въпроси на клиенти
Графиката визуализира броя на Въпросите, обработвани от ProxySQL за всички хост групи:
Според документацията на MySQL, въпросите са просто броят на операторите, изпълнявани от сървъра. Това включва само изрази, изпратени до сървъра от клиенти, а не изрази, изпълнявани в съхранени програми, за разлика от променливата Queries. Тази променлива не отчита командите COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE или COM_STMT_RESET. Отново, ако спрете да свързвате приложението си с ProxySQL (или го заобиколите), стойността трябва да падне до 0.
Активни бекенд връзки
Броят на връзките, които ProxySQL поддържа към задните MySQL сървъри на хост:
Той просто ни казва колко връзки в момента се използват от ProxySQL за изпращане на заявки към задния сървър. Докато максималната стойност не е близка до лимита за връзка за конкретния сървър (зададена чрез max_connections когато сървърът е добавен към ProxySQL хостгрупа), ние сме в добра форма.
Неуспешни бекенд връзки
Броят на връзките, които не са били установени успешно от ProxySQL:
Горният пример просто показва, че през последните 45 минути не се е случила грешка в бекенд връзката.
Насочени заявки
Тази графика дава представа за разпределението на входящите оператори към бекенд сървърите:
Както можете да видите, повечето от четенията отиват в групата на четеца (HG20). От тук можем да разберем модела на балансиране, изпълняван от ProxySQL, който съответства на нашите правила за заявка в това натоварване с интензивно четене.
Безплатна връзка
Графиката показва колко връзки в момента са безплатни:
Връзките се поддържат отворени, за да се сведат до минимум разходите за време за изпращане на заявка до задния сървър.
Закъснение
Текущото време за пинг в микросекунди, както се съобщава от нишката за наблюдение на ProxySQL:
Това просто ни казва колко стабилна е връзката от ProxySQL към задните MySQL сървъри. Високата стойност за дълъг период от време показва най-вече проблем с мрежата между тях.
Кеш памет на заявки
Тази графика визуализира консумацията на памет от заявки, които се кешират от ProxySQL:
От графиката по-горе можем да кажем, че ProxySQL консумира общо 8MB памет от кеша на заявките. След като достигне ограничението от 8MB (конфигурира се чрез mysql-query_cache_size_MB променлива), паметта ще бъде прочистена от нишката за почистване на ProxySQL. Тази графика няма да бъде попълнена, ако нямате дефинирано правило за кеширане на заявки.
Между другото, кеширането на заявка в ProxySQL може да се извърши само с две щраквания с ClusterControl. Отидете на страницата с най-добрите заявки на ProxySQL, превъртете върху заявка, щракнете върху Кеш на заявки и щракнете върху „Добавяне на правило“:
Ефективност на кеша на заявки
Тази графика визуализира ефективността на кешираните заявки:
Синята линия ни показва успешното съотношение на GET заявките, изпълнени спрямо кеша на заявките, където наборът от резултати е присъствал и не е изтекъл. Розовата линия показва съотношението на данните, записани (вмъкнати) в или прочетени от кеша на заявките. В този случай нашите данни, прочетени от Query Cache, са по-високи от данните, записани, което показва ефективна конфигурация на кеша.
Тази графика няма да бъде попълнена, ако нямате дефинирано правило за кеширане на заявки.
Мрежов трафик
Тази графика визуализира мрежовия трафик (получаване на данни + изпратени данни) от/към задните MySQL сървъри, на хост:
Горната екранна снимка ни казва, че значително количество трафик се препраща/получава от/към групата на четеца (HG20). При това натоварване с интензивно четене операциите за четене обикновено консумират много по-висок трафик, главно поради размера на набора от резултати на операторите SELECT.
Само по-малко съотношение на трафика се препраща/получава от/към групата хост за запис (HG10), което се очаква, тъй като операциите по запис обикновено консумират по-малко мрежов трафик със значително малък набор от резултати, който се връща на клиентите.
Ефективност на отразяване
Графиката просто показва състоянието, свързано с огледално отразяване на трафика, като Mirror_concurrency срещу Mirror_queue_length:
Графиката се попълва само ако сте конфигурирали огледално отразяване на трафика (mirror_hostgroup вътрешно правило за заявка). Ако опашката за огледало се набира, намаляването на ограничението за едновременност на дублиране ще увеличи ефективността на огледалното отразяване, което може да се контролира чрез mysql-mirror_max_concurrency променлива. С прости думи, нулевите записи в опашката са най-ефективното огледално отразяване.
Използване на паметта
Графиката илюстрира използването на паметта от основните компоненти в ProxySQL - пул за връзки, кеш на заявки и постоянно съхранение (SQLite):
Горната екранна снимка ни казва, че обемът на паметта на ProxySQL е доста малък, което е по-малко от 12 MB общо. Пулът за връзки консумира само 1,3 MB върхове, за да побере нашето 8-нишково (клиенти) работно натоварване. С повече свободна RAM, налична на хоста, би трябвало да можем да увеличим броя на клиентските връзки към ProxySQL от три до четири пъти или да кешираме много повече горещи заявки в ProxySQL, за да разтоварим нашите сървъри на MySQL backend.
Бонус функция – производителност на възела
ClusterControl 1.7.0 вече включва показатели за производителност на хоста за екземплярите на ProxySQL. В предишната версия ClusterControl наблюдаваше само свързаните с ProxySQL показатели, изложени от схемата за статистика на ProxySQL. Тази нова функция може да бъде достъпна в раздела Node -> ProxySQL екземпляр -> Производителност на възел:
Хистограмите предоставят представа за ключовите показатели на хоста, подобно на това, което се взема за извадка за възлите на базата данни в секцията Възли -> Преглед. Ако вашият ProxySQL екземпляр се намира в същия сървър с приложението, вие буквално използвате ClusterControl, за да наблюдавате и сървъра на приложения. Колко готино е това?!
Последни мисли
Интеграцията на ClusterControl с Prometheus предлага алтернативен начин за наблюдение и анализиране на стека на вашата база данни, до нивото на обратно прокси. Вече имате избор да разтоварите заданията за наблюдение на Prometheus или да продължите да използвате подхода за наблюдение без агенти ClusterControl по подразбиране за вашата инфраструктура на базата данни.
