Monitorar uma implantação autogerenciada do MongoDB

Estratégias de monitoramento

O MongoDB fornece vários métodos para coletar dados sobre o estado de uma instância MongoDB em execução:

• O MongoDB distribui um conjunto de utilitários que fornece relatórios em tempo real de atividades do banco de dados.

• O MongoDB fornece vários comandos do banco de dados que retornam estatísticas sobre o estado atual do banco de dados com maior fidelidade.

• MongoDB Atlas é um banco de dados como serviço hospedado na cloud para executar, monitorar e manter as implantações do MongoDB.

• O MongoDB Cloud Manager é um serviço hospedado que monitora a execução de implantações MongoDB para coletar dados e fornecer visualização e alertas com base nesses dados.

• O MongoDB Ops Manager é uma solução local disponível no MongoDB Enterprise Advanced que monitora a execução de implantações do MongoDB para coletar dados e fornecer visualização e alertas com base nesses dados.

Cada estratégia pode ajudar a responder a diferentes questões e é útil em diferentes contextos. Esses métodos são complementares.

Ferramentas de relatório do MongoDB

Esta seção fornece uma visão geral dos métodos de relatório distribuídos com MongoDB. Ela também oferece exemplos dos tipos de perguntas que cada método é mais adequado para ajudar você a responder.

Registro de processos

Durante a operação normal, as instâncias do mongod e mongos relatam uma conta ativa de todas as atividades e operações do servidor para saída padrão ou um arquivo de log. As seguintes configurações de tempo de execução controlam estas opções.

• quiet. Limita a quantidade de informações gravadas no registro ou saída.

• verbosity. Aumenta a quantidade de informações gravadas no registro ou saída. Você também pode modificar a verbosidade do registro durante o tempo de execução com o parâmetro logLevel ou o método db.setLogLevel() no shell.

• path. Permite o registro em um arquivo, em vez de na saída padrão. Você deve especificar o caminho completo para o arquivo de registro ao ajustar esta configuração.

• logAppend. Adiciona informações a um arquivo de registro em vez de sobrescrevê-lo.

mongod -v --logpath /var/log/mongodb/server1.log --logappend

Os seguintes comandos do banco de dados também afetam o registro:

• getLog. Exibe as mensagens recentes do registro do processo mongod.

• logRotate. Gira os arquivos de log somente para processos do mongod. Consulte Girar arquivos de log.

db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } )

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "clients",
         "documents": [
            {
               "name": "Joe",
               "PII": "Sensitive Information",
               "_id": { "$oid": "669aea8792c7fd822d3e1d8c" }
            }
         ],
         "ordered": true,
         ...
      }
      ...
   }
}

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "###",
         "documents": [
            {
               "name": "###",
               "PII": "###",
               "_id": "###"
            }
         ],
         "ordered": "###",
         ...
      }
      ...
   }
}

Diagnosticando problemas de desempenho

Conforme você vai desenvolvendo e operando aplicativos com o MongoDB, talvez precise analisar o desempenho do banco de dados como o aplicativo. O artigo desempenho do MongoDB menciona alguns dos fatores operacionais que podem influenciar o desempenho.

Replicação e monitoramento

Além dos requisitos básicos de monitoramento para qualquer instância do MongoDB, para conjuntos de réplicas, os administradores devem monitorar o atraso de replicação. "Atraso de replicação" refere-se à quantidade de tempo que leva para copiar (ou seja, replicar) uma operação de gravação do primário para o secundário. Um pequeno período de atraso pode ser aceitável, mas problemas significativos surgem à medida que o atraso de replicação aumenta, incluindo:

• Pressão crescente do cache no primário.

• As operações que ocorreram durante o período de atraso não são replicadas para um ou mais secundários. Se você estiver usando a replicação para garantir a persistência dos dados, atrasos excepcionalmente longos podem afetar a integridade do seu conjunto de dados.

• Se o atraso de replicação exceder o comprimento do registro de operação (oplog), o MongoDB terá que executar uma sincronização inicial no secundário, copiando todos os dados do primário e reconstruindo todos os índices. [1] Isso é incomum em circunstâncias normais, mas se você configurar o oplog para ser menor que o padrão, o problema pode surgir.

  Observação

  O tamanho do oplog só pode ser configurado durante a primeira execução usando o argumento --oplogSize do comando mongod ou, de preferência, a configuração oplogSizeMB no arquivo de configuração do MongoDB. Se você não especificar isto na linha de comando antes de executar com a opção --replSet, o mongod criará um oplog de tamanho padrão.

  Por padrão, o oplog é de 5 por cento do espaço total em disco disponível em sistemas de 64bits. Para obter mais informações sobre como alterar o tamanho do oplog, consulte Alterar o tamanho do oplog de membros do conjunto de réplicas autogerenciado.

rs.status()

Fragmentação e monitoramento

Na maioria dos casos, os componentes dos clusters sharded se beneficiam do mesmo monitoramento e análise que todas as outras instâncias do MongoDB. Além disso, os clusters exigem monitoramento adicional para garantir que os dados sejam efetivamente distribuídos entre os nós e que as operações de fragmentação estejam funcionando adequadamente.

use config
db.locks.find()

db.locks.find( { _id : "balancer" } )

Watchdog do nó de armazenamento

O Storage Node Watchdog monitora os seguintes diretórios MongoDB para detectar a falta de resposta do sistema de arquivos:

• O diretório --dbpath

• O diretório journal dentro do diretório --dbpath se journaling estiver habilitado

• O diretório do arquivo --logpath

• O diretório do arquivo --auditPath

Por padrão, o Storage Node Watchdog está desabilitado. Só é possível ativar o Watchdog do nó de armazenamento em um mongod no momento da inicialização definindo o parâmetro watchdogPeriodSeconds como um número inteiro maior ou igual a 60. No entanto, uma vez ativado, você pode pausar o Node Watchdog de armazenamento e reiniciar durante o tempo de execução. Consulte o parâmetro watchdogPeriodSeconds para obter os detalhes.

Se algum dos sistemas de arquivos contendo os diretórios monitorados deixar de responder, o Storage Node Watchdog encerrará o mongod e sairá com um código de status 61. Se o mongod for o principal de um conjunto de réplicas, o encerramento iniciará um failover, permitindo que outro membro se torne primário.

Após o término de um mongod, talvez não seja possível reiniciá-lo de forma limpa na mesma máquina.

O tempo máximo que o Watchdog do nó de armazenamento pode levar para detectar um sistema de arquivos sem resposta e encerrar é quase duas vezes o valor de watchdogPeriodSeconds.