MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Monitoramento de banco de dados sem agente com ClusterControl

Com a crescente complexidade das configurações de banco de dados, muitos SysAdmins e DBAs estão adotando uma abordagem sem agente para ajudar a aliviar a carga dos desafios de monitoramento de banco de dados. O monitoramento sem agente do ClusterControl permite monitorar bancos de dados sem instalar software de agente em cada sistema monitorado. O ClusterControl implementa o monitoramento usando um coletor de dados remoto que usa o protocolo SSH.

Antes de mergulhar direto nas especificidades do monitoramento sem agente, vamos primeiro esclarecer o escopo e o significado do monitoramento em nosso contexto aqui. O monitoramento vem após a tendência de dados – o processo de coleta e armazenamento de métricas – que permite que o sistema de monitoramento processe os dados coletados para produzir justificativa para ajuste, alerta e exibição de dados de tendência para relatórios.

A partir da versão 1.7.0 (lançada em dezembro de 2018), o ClusterControl oferece suporte a dois métodos de monitoramento:

  • Monitoramento sem agente (padrão)
  • Monitoramento baseado em agente com o Prometheus

Esta postagem mostrará como monitorar seus servidores de banco de dados e clusters com o monitoramento sem agente do ClusterControl. Se você estiver procurando mais informações sobre o monitoramento baseado em agente do ClusterControl, consulte esta documentação.

Geralmente, o ClusterControl executa tarefas de monitoramento, alerta e tendência sem agente usando os três métodos a seguir:

  • SSH – Coleta de métricas do host (processo, estatísticas de balanceadores de carga, uso de recursos, consumo etc.) usando a biblioteca SSH
  • Cliente de banco de dados – Coleta de métricas de banco de dados (status, consultas, variáveis, uso, etc.) usando a respectiva biblioteca de cliente de banco de dados
  • Advisor – Miniprogramas escritos usando ClusterControl DSL e executados no próprio ClusterControl para fins de monitoramento, ajuste e alerta

SSH significa Secure Shell, um protocolo de rede seguro usado pela maioria dos servidores baseados em Linux para administração remota. O ClusterControl Controller, ou CMON, é o serviço de back-end que executa tarefas de automação, gerenciamento, monitoramento e agendamento, construído sobre C++.

ClusterControl DSL (Domain Specific Language) permite estender a funcionalidade de sua plataforma ClusterControl criando Advisors, Auto Tuners ou "Mini Programs". A sintaxe DSL é baseada em JavaScript, com extensões para fornecer acesso às estruturas e funções de dados internos do ClusterControl. O DSL permite que você execute instruções SQL, execute comandos/programas de shell em todos os seus hosts de cluster e recupere resultados a serem processados ​​para orientadores/alertas ou quaisquer outras ações.

Ferramentas de monitoramento

Todas as ferramentas de pré-requisito são atendidas pelo script do instalador ou instaladas automaticamente pelo ClusterControl durante o estágio de implantação do banco de dados ou se o arquivo/binário/pacote necessário não existir no servidor de destino antes de executar um trabalho. De um modo geral, o dever de monitoramento do ClusterControl requer apenas o pacote do servidor OpenSSH nos hosts monitorados. O ClusterControl usa a biblioteca cliente libssh para coletar métricas de host para os hosts monitorados – CPU, memória, disco, rede, IO, processo, etc. O pacote cliente OpenSSH é necessário no host ClusterControl apenas para configurar SSH sem senha e fins de depuração. Outras implementações SSH como Dropbear e TinySSH não são suportadas.

Ao reunir as estatísticas e métricas do banco de dados, o ClusterControl Controller (CMON) se conecta ao servidor de banco de dados diretamente por meio de bibliotecas de cliente de banco de dados – libmysqlclient (MySQL/MariaDB e ProxySQL), libpq (PostgreSQL) e libmongocxx (MongoDB ). É por isso que é crucial configurar privilégios adequados para um servidor ClusterControl da perspectiva de um servidor de banco de dados. Para clusters baseados em MySQL, o ClusterControl requer o usuário do banco de dados "cmon", enquanto para outros bancos de dados, qualquer nome de usuário pode ser usado para monitoramento, desde que tenha privilégios de superusuário. Na maioria das vezes, o ClusterControl configurará os privilégios necessários (ou usará o usuário do banco de dados especificado) automaticamente durante a importação do cluster ou o estágio de implantação do cluster.

ClusterControl requer as seguintes ferramentas para balanceadores de carga:

  • Maxctrl no servidor MariaDB MaxScale
  • netcat e/ou socat no servidor HAProxy para se conectar ao arquivo de soquete HAProxy e recuperar os dados de monitoramento
  • ProxySQL requer um cliente mysql no servidor ProxySQL

O diagrama a seguir ilustra os processos de monitoramento de host e banco de dados executados pelo ClusterControl usando libssh e bibliotecas de cliente de banco de dados:

Embora os threads de monitoramento não precisem de pacotes de cliente de banco de dados instalados no host monitorado, é altamente recomendável tê-los para fins de gerenciamento. Por exemplo, o pacote do cliente MySQL vem com os programas mysql, mysqldump, mysqlbinlog e mysqladmin, que serão usados ​​pelo ClusterControl ao realizar backups e recuperação pontual.

Métodos de monitoramento

Para coleta de estatísticas de host e balanceador de carga, o ClusterControl executa essa tarefa via SSH com privilégio de superusuário. Portanto, o SSH sem senha com privilégio de superusuário é vital para permitir que o ClusterControl execute os comandos necessários remotamente com escalonamento adequado. Com essa abordagem pull, há algumas vantagens em comparação com outros mecanismos:

  • Sem agente – Não é necessário instalar, configurar e manter um agente.
  • Unificação da configuração de gerenciamento e monitoramento – o SSH pode ser usado para extrair métricas de monitoramento ou enviar tarefas de gerenciamento nos nós de destino.
  • Simplifique a implantação – O único requisito é a configuração SSH sem senha adequada, e é isso. O SSH também é muito seguro e criptografado.
  • Configuração centralizada – Um servidor ClusterControl pode gerenciar vários servidores e clusters, desde que tenha recursos suficientes.

No entanto, o mecanismo de puxar também tem as seguintes desvantagens:

  • Os dados de monitoramento são precisos apenas da perspectiva do ClusterControl. Por exemplo, se houver uma falha na rede e o ClusterControl perder a comunicação com o host monitorado, a amostragem será ignorada até o próximo ciclo disponível.
  • Haverá sobrecarga de rede para monitoramento de alta granularidade devido ao aumento da taxa de amostragem em que o ClusterControl precisa estabelecer mais conexões com cada host de destino.
  • O ClusterControl continuará tentando restabelecer a conexão com o nó de destino porque não tem um agente para fazer isso em seu nome.
  • Amostragem de dados redundante se você tiver mais de um servidor ClusterControl monitorando um cluster, pois cada servidor ClusterControl precisa extrair os dados de monitoramento para si mesmo.

Para monitoramento de consultas MySQL, a partir do ClusterControl 1.9.0 (lançado em julho de 2021), o ClusterControl oferece suporte a dois tipos:

  • Monitoramento de consultas sem agente (padrão)
  • Monitoramento de consulta baseado em agente usando o agente de consulta CMON, que requer etapas adicionais para habilitá-lo. Apenas para bancos de dados baseados em MySQL e PostgreSQL.

O monitoramento de consultas sem agente monitora as consultas de duas maneiras diferentes:

  • As consultas são recuperadas de PERFORMANCE_SCHEMA consultando o esquema no nó do banco de dados via SSH.
  • Se PERFORMANCE_SCHEMA estiver desabilitado ou indisponível, o ClusterControl analisará o conteúdo do log de consulta lenta via SSH.

Se o Esquema de Desempenho estiver habilitado, o ClusterControl o usará para procurar as consultas lentas. Caso contrário, o ClusterControl analisará o conteúdo do log de consultas lentas do MySQL (por meio da variável dinâmica slow_query_log=ON) com base no seguinte fluxo:

  1. Iniciar log lento (durante o tempo de execução do MySQL).
  2. Execute-o por um curto período de tempo (um segundo ou alguns segundos).
  3. Parar registro.
  4. Registro de análise.
  5. Truncar log (novo arquivo de log).
  6. Vá para 1.

As consultas coletadas são submetidas a hash, calculadas e digeridas (normalizar, média, contagem, classificação) e, em seguida, armazenadas no banco de dados CMON do ClusterControl. Observe que, para este método de amostragem, há uma pequena chance de algumas consultas não serem capturadas, especialmente durante as partes “stop log, parse log, truncate log”. Você pode habilitar o Esquema de Desempenho se isso não for uma opção.

Somente as consultas que excederem o Longo Tempo de Consulta serão listadas aqui usando o log de Consulta Lenta. Suponha que os dados não sejam preenchidos corretamente e você acredita que deve haver algo lá, pode ser que:

  • O ClusterControl não coletou consultas suficientes para resumir e preencher dados. Tente diminuir o tempo de consulta longo.
  • Você configurou as opções de configuração do Log de consulta lenta no my.cnf do servidor MySQL e a opção Substituir consulta local está desativada. Se você realmente quiser usar o valor definido em my.cnf, provavelmente terá que diminuir o valor long_query_time para que o ClusterControl possa calcular um resultado mais preciso.
  • Você também tem outro nó ClusterControl puxando o log de Consulta Lenta (caso você tenha um servidor ClusterControl em espera). Permita que apenas um servidor ClusterControl faça este trabalho.

Você também pode usar o ClusterControl Query Monitor para MySQL, MariaDB e Percona Server.

Para monitoramento de consultas PostgreSQL, o ClusterControl requer o módulo pg_stat_statements para rastrear estatísticas de execução de todas as instruções SQL. Ele preenche as visualizações e funções pg_stat_statements ao exibir as consultas na interface do usuário (na guia Query Monitor).

Intervalos e tempos limite

ClusterControl Controller (cmon) é um processo multithread. Por padrão, o thread de amostragem do ClusterControl Controller se conecta a cada host monitorado uma vez e mantém uma conexão persistente até que o host caia ou se desconecte durante a amostragem das estatísticas do host. Ele pode estabelecer mais conexões dependendo dos trabalhos atribuídos ao host, pois a maioria dos trabalhos de gerenciamento é executada em seu próprio thread. Por exemplo, a recuperação de cluster é executada no encadeamento de recuperação, a execução do Advisor é executada em um cron-thread e o monitoramento do processo é executado no encadeamento do coletor de processos.
O encadeamento de monitoramento

ClusterControl executa as seguintes operações de amostragem no seguinte intervalo:

  • Métricas de consulta/status do MySQL:a cada segundo
  • Coleta de processos (/proc):a cada 10 segundos
  • Detecção do servidor:a cada 10 segundos
  • Métricas do host (/proc, /sys):a cada 30 segundos (configurável via host_stats_collection_interval)
  • Métricas de banco de dados (somente PostgreSQL e MongoDB):a cada 30 segundos (configurável via db_stats_collection_interval)
  • Métricas de esquema de banco de dados:a cada 3 horas (configurável via db_schema_stats_collection_interval)
  • Métricas do balanceador de carga:a cada 15 segundos (configurável por meio de lb_stats_collection_interval)

Os scripts imperativos (Advisors) podem usar SSH e bibliotecas de cliente de banco de dados que acompanham o CMON com as seguintes restrições:

  • 5 segundos de limite rígido para execução SSH.
  • 10 segundos de limite padrão para conexão de banco de dados, configurável via net_read_timeout, net_write_timeout, connect_timeout no arquivo de configuração CMON.
  • 60 segundos do limite de tempo total de execução do script antes que o CMON o aborte de forma desajeitada.

Os conselheiros podem ser criados, compilados, testados e agendados diretamente da interface do ClusterControl em Gerenciar → Developer Studio . A captura de tela a seguir mostra um exemplo de um Advisor para extrair as 10 principais consultas de PERFORMANCE_SCHEMA:

A execução dos orientadores depende se está ativado e do tempo de agendamento em formato cron:

Os resultados da execução são exibidos em Desempenho → Consultores , conforme mostrado na captura de tela a seguir:

Para obter mais informações sobre quais Advisors são fornecidos por padrão, consulte nosso desenvolvedor Página do produto Studio.

Os dados são armazenados diretamente no banco de dados CMON para dados de monitoramento de curto intervalo, como consultas e status do MySQL. Dados de monitoramento de longo intervalo, como pontos de dados semanais/mensais/anuais, são agregados a cada 60 segundos e armazenados na memória por 10 minutos. Esses comportamentos não são configuráveis ​​devido ao design da arquitetura.

Parâmetros

O ClusterControl tem muitos parâmetros para se adequar à sua política de monitoramento e alerta. A maioria deles é configurável através da ClusterControl UI → escolha um cluster → Configurações . A guia "Configurações" oferece muitas opções para configurar alertas, limites, notificações, layout de gráfico, contadores de banco de dados, monitoramento de consultas e assim por diante. Por exemplo, os limites de aviso e crítico são configuráveis ​​da seguinte forma:

A página “Runtime Configuration” mostra uma lista resumida do ClusterControl Controller ativo (CMON) parâmetros de configuração de tempo de execução:

Existem mais de 170 opções de configuração do ClusterControl Controller no total, e algumas delas as configurações avançadas podem ser configuradas monitorando e alertando o ajuste fino da política. Alguns deles incluem:

  • 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

Você pode alterar os parâmetros listados na página “Configuração de tempo de execução” usando a interface do usuário ou o arquivo de configuração CMON localizado em /etc/cmon.d/cmon_X.cnf, onde X é o ID do cluster. Você pode listar todas as opções de configuração suportadas para CMON usando o seguinte comando:

$ cmon --help-config

Considerações finais

O monitoramento sem agente tornou-se um dos métodos mais eficazes para gerenciar infraestruturas de banco de dados cada vez mais complexas. Ele reduz a carga de muitos desafios associados ao monitoramento de banco de dados e é fácil de gerenciar.

Existem muitas ferramentas de monitoramento sem agente disponíveis hoje. No entanto, poucos deles também oferecem uma plataforma completa cheia de recursos para ajudá-lo a gerenciar todos os outros aspectos de seus clusters de banco de dados. Para ver o que mais o ClusterControl pode fazer, certifique-se de baixar sua própria avaliação gratuita de 30 dias.

Você está procurando uma alternativa baseada em agente para monitoramento de banco de dados? Confira a infraestrutura de monitoramento de banco de dados baseada em agente do ClusterControl — SCUMM.