O ClusterControl 1.7.0 apresenta um novo recurso ousado - integração com o Prometheus para monitoramento baseado em agente. Chamamos isso de SCUMM (Severalnines ClusterControl Unified Management and Monitoring). Nas versões anteriores, as tarefas de monitoramento eram executadas apenas sem agente. Se você quer saber como o ClusterControl executa suas funções de monitoramento, confira esta página de documentação.
ProxySQL, um proxy reverso de alto desempenho que entende os protocolos MySQL, geralmente fica no topo da Replicação MySQL e do Galera Cluster para atuar como um gateway para o serviço MySQL de back-end. Ele pode ser configurado como um roteador de consulta, firewall de consulta, cache de consulta, despachante de tráfego e muito mais. O ProxySQL também coleta e expõe as principais métricas por meio de seu esquema STATS, que é muito útil para analisar o desempenho e entender o que realmente acontece nos bastidores. Visite nosso tutorial abrangente para ProxySQL para saber mais sobre ele.
Nesta postagem do blog, analisaremos detalhadamente o monitoramento das instâncias do ProxySQL com essa nova abordagem. Neste exemplo, temos uma instância ProxySQL em cima de nossa Replicação MySQL de dois nós (1 mestre, 1 escravo), implantada via ClusterControl. Nossa arquitetura de alto nível se parece com isto:
Também temos as seguintes regras de consulta definidas na instância ProxySQL (apenas para referência, para entender as métricas de monitoramento coletadas mais abaixo):
Ativando o Prometheus
O monitoramento baseado em agente do ClusterControl é habilitado por cluster. O ClusterControl pode implantar um novo servidor Prometheus para você ou usar um servidor Prometheus existente (implantado pelo ClusterControl para outro cluster). Ativar o Prometheus é bastante simples. Basta ir para ClusterControl -> escolher o cluster -> Dashboards -> Enable Agent Based Monitoring:
Em seguida, especifique o endereço IP ou o nome do host do novo servidor Prometheus ou apenas escolha um host Prometheus existente no menu suspenso:
O ClusterControl irá instalar e configurar os pacotes necessários (Prometheus no servidor Prometheus, exportadores no banco de dados e nós ProxySQL), conectar-se ao Prometheus como fonte de dados e começar a visualizar os dados de monitoramento na interface do usuário.
Depois que o trabalho de implantação for concluído, você poderá acessar a guia Painéis, conforme mostrado na próxima seção.
Painel do ProxySQL
Você pode acessar os ProxySQL Dashboards acessando o respectivo cluster na guia Dashboards. Clicar no menu suspenso Painel listará os painéis relacionados ao nosso cluster (Replicação MySQL). Você pode encontrar o painel de visão geral do ProxySQL na seção "Load Balancers":
Existem vários painéis para ProxySQL, alguns deles são autoexplicativos. No entanto, vamos visitá-los um por um.
Tamanho do grupo de hosts
O tamanho do grupo de hosts é simplesmente o número total de hosts em todos os grupos de hosts:
Neste caso, temos dois grupos de hosts - 10 (gravador) e 20 (leitor). O grupo de host 10 consiste em um host (mestre) enquanto o grupo de host 20 possui dois hosts (mestre e escravo), o que soma um total de três hosts.
A menos que você altere a configuração do grupo de hosts (introduza um novo host, removendo o host existente) do ProxySQL, você deve esperar que nada mude neste gráfico.
Conexões do cliente
O número de conexão do cliente sendo processada pelo ProxySQL para todos os grupos de hosts:
O gráfico acima simplesmente nos diz que há consistentemente 8 clientes MySQL conectados à nossa instância ProxySQL na porta 6033 nos últimos 45 minutos (você pode alterar isso na opção "Range Selection"). Se você parar de conectar seu aplicativo ao ProxySQL (ou ignorá-lo), o valor deverá cair para 0.
Perguntas do cliente
O gráfico visualiza o número de perguntas sendo processadas pelo ProxySQL para todos os grupos de hosts:
De acordo com a documentação do MySQL, Questions são simplesmente o número de instruções executadas pelo servidor. Isso inclui apenas instruções enviadas ao servidor por clientes e não instruções executadas em programas armazenados, ao contrário da variável Queries. Esta variável não conta os comandos COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE ou COM_STMT_RESET. Novamente, se você parar de conectar seu aplicativo ao ProxySQL (ou ignorá-lo), o valor deve cair para 0.
Conexões de back-end ativas
O número de conexões que o ProxySQL mantém com os servidores MySQL de back-end por host:
Ele simplesmente nos diz quantas conexões estão sendo usadas atualmente pelo ProxySQL para enviar consultas ao servidor de back-end. Desde que o valor máximo não esteja próximo do limite de conexão para o servidor em particular (definido via max_connections quando o servidor é adicionado ao hostgroup ProxySQL), estamos em boa forma.
Falha nas conexões de back-end
O número de conexões que não foram estabelecidas com sucesso pelo ProxySQL:
O exemplo acima simplesmente mostra que nenhuma falha de conexão de back-end ocorreu nos últimos 45 minutos.
Consultas roteadas
Este gráfico fornece informações sobre a distribuição de instruções de entrada para os servidores de back-end:
Como você pode ver, a maioria das leituras vai para o hostgroup do leitor (HG20). A partir daqui, podemos entender o padrão de balanceamento executado pelo ProxySQL que corresponde às nossas regras de consulta nesta carga de trabalho de leitura intensiva.
Conexão gratuita
O gráfico mostra quantas conexões estão atualmente livres:
As conexões são mantidas abertas para minimizar o custo de tempo de envio de uma consulta ao servidor backend.
Latência
O tempo de ping atual em microssegundos, conforme relatado no thread de monitoramento do ProxySQL:
Isso simplesmente nos diz o quão estável é a conexão do ProxySQL aos servidores MySQL de back-end. Alto valor por um longo tempo consistente indica principalmente problema de rede entre eles.
Consultar memória cache
Este gráfico visualiza o consumo de memória de consultas que estão sendo armazenadas em cache pelo ProxySQL:
A partir do gráfico acima, podemos dizer que o ProxySQL consome uma quantidade total de 8 MB de memória pelo cache de consulta. Após atingir o limite de 8 MB (configurável via mysql-query_cache_size_MB variável), a memória será limpa pelo thread de limpeza do ProxySQL. Este gráfico não será preenchido se você não tiver uma regra de cache de consulta definida.
A propósito, armazenar em cache uma consulta no ProxySQL pode ser feito em apenas dois cliques com o ClusterControl. Vá para a página Principais consultas do ProxySQL, role sobre uma consulta, clique em Cache de consulta e clique em "Adicionar regra":
Eficiência do cache de consulta
Este gráfico visualiza a eficiência das consultas em cache:
A linha azul nos informa a proporção bem-sucedida de solicitações GET executadas no Query Cache em que o conjunto de resultados estava presente e não expirou. A linha rosa mostra a proporção de dados gravados (inserir) ou lidos no Cache de Consulta. Nesse caso, nossos dados lidos do Query Cache são superiores aos dados gravados, indicando uma configuração de cache eficiente.
Este gráfico não será preenchido se você não tiver uma regra de cache de consulta definida.
Tráfego de rede
Este gráfico visualiza o tráfego de rede (recebimento de dados + dados enviados) de/para os servidores MySQL de back-end, por host:
A captura de tela acima nos diz que uma quantidade significativa de tráfego está sendo encaminhada/recebida de/para o grupo de hosts do leitor (HG20). Nessa carga de trabalho de leitura intensa, as operações de leitura geralmente consomem um tráfego muito maior, principalmente devido ao tamanho do conjunto de resultados das instruções SELECT.
Apenas uma proporção menor do tráfego é encaminhada/recebida de/para o grupo de hosts de gravação (HG10), o que é esperado, pois as operações de gravação geralmente consomem menos tráfego de rede com um conjunto de resultados significativamente pequeno sendo retornado aos clientes.
Espelhando eficiência
O gráfico simplesmente mostra o status relacionado ao espelhamento de tráfego, como Mirror_concurrency vs Mirror_queue_length:
O gráfico só é preenchido se você tiver configurado o espelhamento de tráfego (mirror_hostgroup dentro da regra de consulta). Se a fila de espelhamento estiver aumentando, reduzir o limite de simultaneidade do espelhamento aumentará a eficiência do espelhamento, que pode ser controlado via mysql-mirror_max_concurrency variável. Em palavras simples, as entradas de fila zero são o que é o espelhamento mais eficiente.
Utilização de memória
O gráfico ilustra a utilização de memória pelos principais componentes dentro do ProxySQL - pool de conexões, cache de consulta e armazenamento persistente (SQLite):
A captura de tela acima nos diz que a pegada de memória do ProxySQL é bastante pequena, com menos de 12 MB no total. O pool de conexões consome apenas 1,3 MB tops para acomodar nossa carga de trabalho de 8 threads (clientes). Com mais RAM livre disponível no host, devemos ser capazes de aumentar o número de conexões de clientes com o ProxySQL em três a quatro vezes ou armazenar em cache muito mais consultas quentes dentro do ProxySQL para descarregar nossos servidores de back-end MySQL.
Recurso de bônus - Desempenho do nó
O ClusterControl 1.7.0 agora inclui métricas de desempenho do host para as instâncias do ProxySQL. Na versão anterior, o ClusterControl monitorava apenas as métricas relacionadas ao ProxySQL conforme exposto pelo esquema de estatísticas do ProxySQL. Esse novo recurso pode ser acessado na guia Node's -> ProxySQL instance -> Node Performance:
Os histogramas fornecem informações sobre as principais métricas do host, semelhantes ao que está sendo amostrado para nós de banco de dados na seção Nós -> Visão geral. Se sua instância ProxySQL estiver localizada no mesmo servidor com o aplicativo, você estará literalmente usando o ClusterControl para monitorar também o servidor de aplicativos. Quão legal é isso?!
Considerações finais
A integração do ClusterControl com o Prometheus oferece uma maneira alternativa de monitorar e analisar sua pilha de banco de dados, até a camada de proxy reverso. Agora você tem a opção de descarregar os trabalhos de monitoramento para o Prometheus ou continuar usando a abordagem de monitoramento sem agente ClusterControl padrão para sua infraestrutura de banco de dados.
