Mensagens de registro

Formato de saída de registro JSON

Toda a saída de log está no formato JSON, incluindo a saída enviada para:

• Arquivo de log

• Syslog

• Stdout (padrão de saída) destinos de log

A saída do comando getLog também está no formato JSON.

Cada entrada de registro é gerada como um objeto JSON independente que segue a especificação Relaxed Extended JSON v2.0 e tem o seguinte layout e ordem de campo:

{
  "t": <Datetime>, // timestamp
  "s": <String>, // severity
  "c": <String>, // component
  "id": <Integer>, // unique identifier
  "ctx": <String>, // context
  "svc": <String>, // service
  "msg": <String>, // message body
  "attr": <Object>, // additional attributes (optional)
  "tags": <Array of strings>, // tags (optional)
  "truncated": <Object>, // truncation info (if truncated)
  "size": <Object> // original size of entry (if truncated)
}

Descrições do Campo:

{
  "command": {
    "find": "mycoll",
    "filter": {
      "value1": {
        "$in": [0, 1, 2, 3, ... 4999]
      },
      "value2": "foo"
              },
              "sort": { "value1": 1 },
              "lsid":{"id":{"$uuid":"80a99e49-a850-467b-a26d-aeb2d8b9f42b"}},
              "$db": "testdb"
        }
}

{
  "t": { "$date": "2021-03-17T20:30:07.212+01:00" },
  "s": "I",
  "c": "COMMAND",
  "id": 51803,
  "ctx": "conn9",
  "msg": "Slow query",
  "attr": {
    "command": {
      "find": "mycoll",
      "filter": {
        "value1": {
          "$in": [ 0, 1, ..., 376 ] // Values in array omitted for brevity
        }
      }
    },
    ... // Other attr fields omitted for brevity
  },
  "truncated": {
    "command": {
      "truncated": {
        "filter": {
          "truncated": {
            "value1": {
              "truncated": {
                "$in": {
                  "truncated": {
                    "377": {
                      "type": "double",
                      "size": 8
                    }
                  },
                  "omitted": 4623
                }
              }
            }
          },
          "omitted": 1
        }
      },
      "omitted": 3
    }
  },
  "size": {
    "command": 21692
  }
}

{"t":{"$date":"2020-05-18T20:18:12.724+00:00"},"s":"I", "c":"CONTROL", "id":23285, "ctx":"main", "svc": "R", "msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
{"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"W", "c":"ASIO", "id":22601, "ctx":"main", "svc": "R", "msg":"No TransportLayer configured during NetworkInterface startup"}
{"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"I", "c":"NETWORK", "id":4648601, "ctx":"main", "svc": "R", "msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"STORAGE", "id":4615611, "ctx":"initandlisten", "svc": "R", "msg":"MongoDB starting", "attr":{"pid":10111,"port":27001,"dbPath":"/var/lib/mongo","architecture":"64-bit","host":"centos8"}}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":23403, "ctx":"initandlisten", "svc": "R", "msg":"Build Info", "attr":{"buildInfo":{"version":"4.4.0","gitVersion":"328c35e4b883540675fb4b626c53a08f74e43cf0","openSSLVersion":"OpenSSL 1.1.1c FIPS  28 May 2019","modules":[],"allocator":"tcmalloc","environment":{"distmod":"rhel80","distarch":"x86_64","target_arch":"x86_64"}}}}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":51765, "ctx":"initandlisten", "svc": "R", "msg":"Operating System", "attr":{"os":{"name":"CentOS Linux release 8.0.1905 (Core) ","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}

Configurar destinos de mensagens de registro

As mensagens de registro do MongoDB podem ser enviadas para arquivo, syslog ou stdout (saída padrão).

Para configurar o destino de saída do registro, use uma das seguintes configurações, no arquivo de configuração ou na linha de comando:

Arquivo de Configuração:

• A opção systemLog.destination para arquivo ou syslog

Linha de comando:

• a opção --logpath para mongod para arquivo

• a opção --syslog para mongod para syslog

• a opção --logpath para mongos para arquivo

• a opção --syslog para mongos para syslog

Não especificar arquivo ou syslog envia todos os resultados de registro para stdout.

Para obter a lista completa de configurações e opções de registro, consulte:

Arquivo de Configuração:

• lista de opções do systemLog

Linha de comando:

• Lista de opções de registro para mongod

• Lista de opções de registro para mongos

Timestamp

O tipo de campo de carimbo de data/hora indica a data e hora precisas em que o evento registrado ocorreu.

{
  "t": {
    "$date": "2020-05-01T15:16:17.180+00:00"
  },
  "s": "I",
  "c": "NETWORK",
  "id": 12345,
  "ctx": "listener",
  "svc": "R",
  "msg": "Listening on",
  "attr": {
    "address": "127.0.0.1"
  }
}

Ao fazer login no arquivo ou no syslog [1], o formato padrão para o carimbo de data/hora é iso8601-local. Para modificar o formato do carimbo de data/hora, use a opção de tempo de execução --timeStampFormat ou a configuração systemLog.timeStampFormat .

Consulte Filtragem por faixa de datas para ver exemplos de análise de logs que filtram o campo de carimbo de data/hora.

Gravidade

O tipo de campo de gravidade indica o nível de gravidade associado ao evento registrado.

{
  "t": {
    "$date": "2020-05-01T15:16:17.180+00:00"
  },
  "s": "I",
  "c": "NETWORK",
  "id": 12345,
  "ctx": "listener",
  "svc": "R",
  "msg": "Listening on",
  "attr": {
    "address": "127.0.0.1"
  }
}

Os níveis de gravidade variam de "Fatal" (mais grave) a "Depuração" (menos grave):

Você pode especificar o nível de detalhamento de vários componentes para determinar a quantidade de mensagens informativas e de depuração emitidas pelo MongoDB. As categorias de gravidade acima desses níveis são sempre exibidas. [2] Para definir níveis de detalhamento, consulte Configurar níveis de detalhamento de log.

Componentes

O tipo de campo do componente indica a categoria da qual um evento registrado é membro, como NETWORK ou COMMAND.

{
  "t": {
    "$date": "2020-05-01T15:16:17.180+00:00"
  },
  "s": "I",
  "c": "NETWORK",
  "id": 12345,
  "ctx": "listener",
  "svc": "R",
  "msg": "Listening on",
  "attr": {
    "address": "127.0.0.1"
  }
}

Cada componente pode ser configurado individualmente por meio de seu próprio filtro de detalhamento. Os componentes disponíveis são os seguintes:

ACCESS

Mensagens relacionadas ao controle de acesso, como autenticação. Para especificar o nível de log dos componentes ACCESS, use a configuração systemLog.component.accessControl.verbosity.

COMMAND

Mensagens relacionadas aos comandos do banco de dados, como count. Para especificar o nível de log para componentes COMMAND, use a configuração systemLog.component.command.verbosity.

CONTROL

Mensagens relacionadas a atividades de controle, como inicialização. Para especificar o nível de log dos componentes CONTROL, use a configuração systemLog.component.control.verbosity.

ELECTION

Mensagens relacionadas especificamente às eleições do conjunto de réplicas. Para especificar o nível de log para componentes ELECTION, defina o parâmetro systemLog.component.replication.election.verbosity.

REPL é o componente principal de ELECTION. Se systemLog.component.replication.election.verbosity não estiver definido, o MongoDB usará o nível de detalhamento REPL para componentes ELECTION .

FTDC

Mensagens relacionadas ao mecanismo de coleção de dados para diagnóstico, incluindo estatísticas do servidor e atualizações de status. Para especificar o nível de log dos componentes FTDC, use a configuração systemLog.component.ftdc.verbosity.

GEO

Mensagens relacionadas à análise de formas geoespaciais, como verificar as formas GeoJSON. Para especificar o nível de log para componentes GEO, defina o parâmetro systemLog.component.geo.verbosity.

INDEX

Mensagens relacionadas a operações de indexação, como criar índices. Para especificar o nível de log para componentes INDEX, defina o parâmetro systemLog.component.index.verbosity.

INITSYNC

Mensagens relacionadas à operação de sincronização inicial. Para especificar o nível de log para componentes INITSYNC, defina o parâmetro systemLog.component.replication.initialSync.verbosity.

REPL é o componente principal de INITSYNC. Se systemLog.component.replication.initialSync.verbosity não estiver definido, o MongoDB usará o nível de detalhamento REPL para componentes INITSYNC .

JOURNAL

Mensagens relacionadas especificamente às atividades de registro no diário de armazenamento. Para especificar o nível de log dos componentes JOURNAL, use a configuração systemLog.component.storage.journal.verbosity.

STORAGE é o componente principal de JOURNAL. Se systemLog.component.storage.journal.verbosity não estiver definido, o MongoDB usará o nível de detalhamento STORAGE para componentes JOURNAL .

NETWORK

Mensagens relacionadas às atividades da rede, como aceitar conexões. Para especificar o nível de log para componentes NETWORK, defina o parâmetro systemLog.component.network.verbosity.

QUERY

Mensagens relacionadas a queries, incluindo atividades do planejador de query. Para especificar o nível de log para componentes QUERY, defina o parâmetro systemLog.component.query.verbosity.

QUERYSTATS

Mensagens relacionadas às operações $queryStats . Para especificar o nível de registro para QUERYSTATS componentes, defina o parâmetro systemLog.component.queryStats.verbosity .

RECOVERY

Mensagens relacionadas às atividades de recuperação de armazenamento. Para especificar o nível de log dos componentes RECOVERY, use a configuração systemLog.component.storage.recovery.verbosity.

STORAGE é o componente principal de RECOVERY. Se systemLog.component.storage.recovery.verbosity não estiver definido, o MongoDB usará o nível de detalhamento STORAGE para componentes RECOVERY .

REPL

Mensagens relacionadas a conjuntos de réplicas, como sincronização inicial, pulsações, replicação de estado estável e rollback. [2] Para especificar o nível de log para componentes REPL, defina o parâmetro systemLog.component.replication.verbosity.

REPL é o componente principal dos componentes ELECTION, INITSYNC, REPL_HB e ROLLBACK.

REPL_HB

Mensagens relacionadas especificamente a pulsações do conjunto de réplicas. Para especificar o nível de log para componentes REPL_HB, definir o parâmetro systemLog.component.replication.heartbeats.verbosity.

REPL é o componente principal de REPL_HB. Se systemLog.component.replication.heartbeats.verbosity não estiver definido, o MongoDB usará o nível de detalhamento REPL para componentes REPL_HB .

ROLLBACK

Mensagens relacionadas às operações de rollback. Para especificar o nível de log dos componentes ROLLBACK, defina o parâmetro systemLog.component.replication.rollback.verbosity.

REPL é o componente principal de ROLLBACK. Se systemLog.component.replication.rollback.verbosity não estiver definido, o MongoDB usará o nível de detalhamento REPL para componentes ROLLBACK .

SHARDING

Mensagens relacionadas a atividades de compartilhamento, como a inicialização do mongos. Para especificar o nível de log dos componentes SHARDING, use a configuração systemLog.component.sharding.verbosity.

STORAGE

Mensagens relacionadas a atividades de armazenamento, como processos envolvidos no comando fsync. Para especificar o nível de log dos componentes STORAGE, use a configuração systemLog.component.storage.verbosity.

STORAGE é o componente principal de JOURNAL e RECOVERY.

TXN

Mensagens relacionadas a transações multidocumento. Para especificar o nível de log dos componentes TXN, use a configuração systemLog.component.transaction.verbosity.

WRITE

Mensagens relacionadas a operações de gravação, como comandos update. Para especificar o nível de log dos componentes WRITE, use a configuração systemLog.component.write.verbosity.

WT

Novidades na versão 5.3.

Mensagens relacionadas ao storage engine WiredTiger. Para especificar o nível de log dos componentes WT, use a configuração systemLog.component.storage.wt.verbosity.

WTBACKUP

Novidades na versão 5.3.

Mensagens relacionadas às operações de backup executadas pelo storage engine WiredTiger. Para especificar o nível de log dos componentes WTBACKUP, use a configuração systemLog.component.storage.wt.wtBackup.verbosity.

WTCHKPT

Novidades na versão 5.3.

Mensagens relacionadas às operações de checkpoint realizadas pelo storage engine WiredTiger. Para especificar o nível de log dos componentes WTCHKPT, usar a configuração systemLog.component.storage.wt.wtCheckpoint.verbosity.

WTCMPCT

Novidades na versão 5.3.

Mensagens relacionadas às operações de compactação realizadas pelo storage engine WiredTiger . Para especificar o nível de log dos componentes WTCMPCT, usar a configuração systemLog.component.storage.wt.wtCompact.verbosity.

WTEVICT

Novidades na versão 5.3.

Mensagens relacionadas a operações de despejo realizadas pelo mecanismo de armazenamento WiredTiger. Para especificar o nível de log dos componentes WTEVICT, use a configuração systemLog.component.storage.wt.wtEviction.verbosity.

WTHS

Novidades na versão 5.3.

Mensagens relacionadas ao histórico de armazenamento do mecanismo de armazenamento WiredTiger. Para especificar o nível de log dos componentes WTHS, use a configuração systemLog.component.storage.wt.wtHS.verbosity.

WTRECOV

Novidades na versão 5.3.

Mensagens relacionadas a operações de recuperação realizadas pelo storage engine WiredTiger. Para especificar o nível de log dos componentes WTRECOV, usar a configuração systemLog.component.storage.wt.wtRecovery.verbosity.

WTRTS

Novidades na versão 5.3.

Mensagens relacionadas a operações de rollback to stable (RTS) realizadas pelo mecanismo de armazenamento WiredTiger. Para especificar o nível de log dos componentes WTRTS, use a configuração systemLog.component.storage.wt.wtRTS.verbosity.

WTSLVG

Novidades na versão 5.3.

Mensagens relacionadas a operações de recuperação realizadas pelo mecanismo de armazenamento WiredTiger. Para especificar o nível de log dos componentes WTSLVG, use a configuração systemLog.component.storage.wt.wtSalvage.verbosity.

WTTS

Novidades na versão 5.3.

Mensagens relacionadas a logs de data e hora usados pelo mecanismo de armazenamento do WiredTiger. Para especificar o nível de log dos componentes WTTS, use a configuração systemLog.component.storage.wt.wtTimestamp.verbosity.

WTTXN

Novidades na versão 5.3.

Mensagens relacionadas a transações realizadas pelo mecanismo de armazenamento WiredTiger. Para especificar o nível de log dos componentes WTTXN, use a configuração systemLog.component.storage.wt.wtTransaction.verbosity.

WTVRFY

Novidades na versão 5.3.

Mensagens relacionadas a operações de verificação realizadas pelo mecanismo de armazenamento WiredTiger. Para especificar o nível de log dos componentes WTVRFY, use a configuração systemLog.component.storage.wt.wtVerify.verbosity.

WTWRTLOG

Novidades na versão 5.3.

Mensagens relacionadas a operações de gravação de log realizadas pelo storage engine WiredTiger. Para especificar o nível de log dos componentes WTWRTLOG, use a configuração systemLog.component.storage.wt.wtWriteLog.verbosity.

-

Mensagens não associadas a um componente nomeado. Os componentes sem nome têm o nível de log padrão especificado na configuração systemLog.verbosity . A configuração systemLog.verbosity é a configuração padrão para componentes nomeados e não nomeados.

Consulte Filtrando por componente para ver exemplos de análise de logs que filtram no campo de componente.

Dados do cliente

Os drivers do MongoDB e aplicativos de clientes (incluindo mongosh) podem enviar informações de identificação no momento da conexão com o servidor. Depois que a conexão é estabelecida, o cliente não envia as informações de identificação novamente, a menos que a conexão seja interrompida e restabelecida.

Esta informação de identificação está contida no campo atributos da entrada de registro. A informação exata incluída varia de acordo com o cliente.

Abaixo está uma mensagem de log de exemplo contendo o documento de dados do cliente como transmitido de uma conexão mongosh. Os dados do cliente estão contidos no objeto doc no campo atributos:

{"t":{"$date":"2020-05-20T16:21:31.561+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn202", "svc": "R", "msg":"client metadata", "attr":{"remote":"127.0.0.1:37106","client":"conn202","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}

Quando os membros secundários de um conjunto de réplicas iniciam uma conexão com um primary, eles enviam dados semelhantes. Um exemplo de mensagem de registro contendo essa conexão de iniciação pode aparecer da seguinte forma. Os dados do cliente estão contidos no objeto doc no campo atributos:

{"t":{"$date":"2020-05-20T16:33:40.595+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn214", "svc": "R", "msg":"client metadata", "attr":{"remote":"127.0.0.1:37176","client":"conn214","doc":{"driver":{"name":"NetworkInterfaceTL","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}

Consulte a seção de exemplos para ver um exemplo em pretty-print que mostra os dados do cliente.

Para obter uma descrição completa das informações do cliente e dos campos obrigatórios, consulte a especificação do Handshake do MongoDB.

Visualizar nível de verbosidade do registro atual

Para visualizar os níveis de verbosidade atuais, utilize o método db.getLogComponents():

db.getLogComponents()

Seu resultado pode se assemelhar ao seguinte:

{
 "verbosity" : 0,
 "accessControl" : {
    "verbosity" : -1
 },
 "command" : {
    "verbosity" : -1
 },
 ...
 "storage" : {
    "verbosity" : -1,
    "recovery" : {
       "verbosity" : -1
    },
    "journal" : {
        "verbosity" : -1
    }
 },
 ...

A entrada verbosity inicial é o nível de detalhamento principal para todos os componentes, enquanto os componentes individuais nomeados a seguir, como accessControl, indicam o nível de detalhamento específico para esse componente, substituindo o nível de detalhamento global para esse componente específico, se definido.

Um valor de -1, indica que o componente herda o nível de detalhamento de seu pai, se eles tiverem um (como recovery acima, herdando de storage), ou o nível de detalhamento global se eles não tiverem (como com command). Os relacionamentos de herança para níveis de detalhamento são indicados na seção de componentes.

Configurar níveis de verbosidade de registro

Você pode configurar o nível de verbosidade utilizando: as configurações do systemLog.verbosity e systemLog.component.<name>.verbosity, o parâmetro logComponentVerbosity ou o método db.setLogLevel(). [2]

systemLog:
   verbosity: 1
   component:
      query:
         verbosity: 2
      storage:
         verbosity: 2
         journal:
            verbosity: 1

db.adminCommand( {
   setParameter: 1,
   logComponentVerbosity: {
      verbosity: 1,
      query: {
         verbosity: 2
      },
      storage: {
         verbosity: 2,
         journal: {
            verbosity: 1
         }
      }
   }
} )

db.setLogLevel(-1, "query")

Registro de operações lentas

As operações do cliente (como queries) aparecem no log se a duração exceder o limite de operação lenta ou quando o nível de verbosidade do log for 1 ou superior. [2] Essas entradas de log incluem o objeto de comando completo associado à operação.

As entradas do criador de perfil e as mensagens de log de diagnóstico (ou seja, mensagens de log mongod/mongos) para operações de leitura/gravação incluem:

• planCacheShapeHash para ajudar a identificar queries lentas com a mesma forma de query de cache de plano.

  A partir do MongoDB 8.0, o campo queryHash pré-existente é renomeado para planCacheShapeHash. Se você estiver usando uma versão anterior do MongoDB , verá queryHash em vez de planCacheShapeHash.

• planCacheKey para fornecer mais informações sobre o cache do plano de consulta para queries lentas.

A partir do MongoDB 5.0, as mensagens de registro de operações lentas incluem um campo remote que especifica o endereço IP do cliente.

A partir do MongoDB 6.2, as mensagens de registro de operação lenta incluem um campo queryFramework que indica qual mecanismo de consulta executou a consulta:

• queryFramework: "classic" indica que o mecanismo clássico executou a consulta.

• queryFramework: "sbe" indica que o mecanismo de execução de consulta baseado em slot executou a consulta.

A partir do MongoDB 6.1, as mensagens de log de operação lenta incluem campos de tempo de atualização do cache.

A partir do MongoDB 6.3, as mensagens de registro de operação lenta e as entradas do analisador de banco de dados incluem um campo cpuNanos que especifica o tempo total de CPU gasto por uma operação de query em nanossegundos. O campo cpuNanos está disponível somente em sistemas Linux.

A partir do MongoDB 7.0 (e 6.0.13, 5.0.24), o totalOplogSlotDurationMicros na mensagem de registro de query lenta mostra o tempo entre uma operação de gravação que obtém um carimbo de data/hora de confirmação para confirmar as gravações do mecanismo de armazenamento e a confirmação efetiva. mongod suporta gravações paralelas. No entanto, ele confirma operações de gravação com registros de data e hora de confirmação em qualquer ordem.

Para obter um exemplo em pretty-print de uma entrada de registro de operação lenta, consulte Exemplos de mensagens de registro.

A partir do MongoDB 8.0, o campo queryShapeHash para um formato de consulta também é incluído no log de consulta lenta, quando disponível.

Também a partir do MongoDB 8.0, a saída da query lenta inclui um documento queues que contém informações sobre as filas da operação. Cada fila no campo queues contém um campo totalTimeQueuedMicros que contém o tempo cumulativo total, em microssegundos, que a operação passou na fila correspondente.

Tempo de remoteOpWaitMillis espera por shards registrados no campo

A partir do MongoDB 5.0, você pode usar o campo de registro remoteOpWaitMillis para obter o tempo de espera (em milissegundos) para resultados de shards.

remoteOpWaitMillis só está registrado:

• Se você configurar registro de operações lento.

• No shard ou mongos que mescla os resultados.

Para determinar se uma operação de mesclagem ou um problema de shard está causando uma consulta lenta, compare os campos de tempo workingMillis e remoteOpWaitMillis no registro. workingMillis é o tempo total que a query levou para ser concluída. Especificamente:

• Se workingMillis for um pouco mais longo que remoteOpWaitMillis, então a maior parte do tempo foi gasta aguardando uma resposta do shard. Por exemplo, workingMillis de 17 e remoteOpWaitMillis de 15.

• Se workingMillis for significativamente maior que remoteOpWaitMillis, a maior parte do tempo foi gasta realizando a mesclagem. Por exemplo, workingMillis de 100 e remoteOpWaitMillis de 15.

Redação de registro de Queryable Encryption

Ao utilizar o Queryable Encryption, as operações CRUD para collections criptografadas são omitidas do registro de query lenta. Para obter detalhes, consulte Redação de Queryable Encryption.

Redação de registros corporativos

Disponível apenas no MongoDB Enterprise

Um mongod ou mongos em execução com redactClientLogData elimina qualquer mensagem que acompanhe um determinado evento de registro antes do registro, deixando apenas metadados, arquivos de origem ou números de linha relacionados ao evento. redactClientLogData impede a entrada de informações sensíveis no registro do sistema, mas reduz a quantidade de detalhes disponíveis para diagnóstico.

Por exemplo, a operação a seguir insere um documento em um mongod em execução sem supressão de log. O mongod tem o nível de detalhamento do log definido como 1:

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

Esta operação produz o seguinte evento de registro:

{
   "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,
         ...
      }
      ...
   }
}

Quando mongod é executado com redactClientLogData e executa a mesma operação de inserção, ele produz o seguinte evento de registro:

{
   "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": "###",
         ...
      }
      ...
   }
}

Use redactClientLogData em conjunto com Encryption at Rest e TLS/SSL (criptografia de transporte) para auxiliar a conformidade com os requisitos normativos.

Exemplos de análise de registro

Ao trabalhar com o registro estruturado do MongoDB, o utilitário de linha de comando jq de terceiros é uma ferramenta útil que permite o pretty-printing de entradas de registro, além de correspondência e filtragem avançadas com base em chaves.

jq é um analisador JSON de código aberto, e está disponível para Linux, Windows e macOS.

Esses exemplos usam jq para simplificar a análise de registros.

jq -r ".msg" /var/log/mongodb/mongod.log | sort | uniq -c | sort -rn | head -10

jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | sort | uniq -c | sort -r

jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | awk -F':' '{print $1}' | sort | uniq -c | sort -r

jq -cr '.attr.doc.driver' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn

jq -r '.attr.doc.os.type' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn

jq 'select(.attr.workingMillis>=2000)' /var/log/mongodb/mongod.log

jq 'select(.c=="REPL")' /var/log/mongodb/mongod.log

jq 'select(.c!="REPL")' /var/log/mongodb/mongod.log

jq 'select( .c as $c | ["REPL", "STORAGE"] | index($c) )' /var/log/mongodb/mongod.log

{"t":{"$date":"2020-06-01T13:06:59.027-0500"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener", "svc": "R", "msg":"connection accepted from {session_remote} #{session_id} ({connectionCount}{word} now open)", "attr":{"session_remote":"127.0.0.1:61298", "session_id":164,"connectionCount":11,"word":" connections"}}
{"t":{"$date":"2020-06-01T13:07:03.490-0500"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn157", "svc": "R", "msg":"end connection {remote} ({connectionCount}{word} now open)", "attr":{"remote":"127.0.0.1:61298","connectionCount":10,"word":" connections"}}

jq 'select( .id as $id | [22943, 22944] | index($id) )' /var/log/mongodb/mongod.log

jq 'select(.t["$date"] >= "2020-04-15T00:00:00.000" and .t["$date"] <= "2020-04-15T23:59:59.999")' /var/log/mongodb/mongod.log

jq 'select(.t["$date"] >= "2020-05-01T00:00:00.000" and .t["$date"] <= "2020-05-31T23:59:59.999" and .attr.remote)' /var/log/mongodb/mongod.log

Registrar serviços de ingestão

Os serviços de ingestão de registros são produtos de terceiros que contêm e agregam arquivos de log, geralmente de um cluster distribuído de sistemas, e fornecem análise contínua desses dados em um local central.

O formato de log JSON permite mais flexibilidade ao se usar serviços de análise e ingestão de log. Enquanto os logs de texto sem formatação geralmente exigem algum tipo de transformação antes de serem qualificados para uso com esses produtos, os arquivos JSON geralmente podem ser consumidos prontamente, dependendo do serviço. Além disso, os logs formatados em JSON oferecem mais controle ao executar a filtragem para esses serviços, pois a estrutura de chave-valor oferece a capacidade de importar especificamente somente os campos de interesse, enquanto omite o restante.

Consulte a documentação do serviço de ingestão de registros de terceiros escolhido para obter mais informações.

Aviso de inicialização

Este exemplo mostra um aviso de inicialização:

{
  "t": {
    "$date": "2020-05-20T19:17:06.188+00:00"
  },
  "s": "W",
  "c": "CONTROL",
  "id": 22120,
  "ctx": "initandlisten",
  "svc": "R",
  "msg": "Access control is not enabled for the database. Read and write access to data and configuration is unrestricted",
  "tags": [
    "startupWarnings"
  ]
}

Conexão do cliente

Este exemplo mostra uma conexão de cliente que inclui dados do cliente:

{
  "t": {
    "$date": "2020-05-20T19:18:40.604+00:00"
  },
  "s": "I",
  "c": "NETWORK",
  "id": 51800,
  "ctx": "conn281",
  "svc": "R",
  "msg": "client metadata",
  "attr": {
    "remote": "192.168.14.15:37666",
    "client": "conn281",
    "doc": {
      "application": {
        "name": "MongoDB Shell"
      },
      "driver": {
        "name": "MongoDB Internal Client",
        "version": "4.4.0"
      },
      "os": {
        "type": "Linux",
        "name": "CentOS Linux release 8.0.1905 (Core) ",
        "architecture": "x86_64",
        "version": "Kernel 4.18.0-80.11.2.el8_0.x86_64"
      }
    }
  }
}

Operação lenta

A partir do MongoDB 8.0, as operações lentas são registradas com base no tempo que o MongoDB gasta trabalhando nessa operação, em vez da latência total da operação.

É possível usar as métricas no operation log para identificar onde uma operação passa o tempo em seu ciclo de vida, o que ajuda a identificar possíveis melhorias de desempenho.

Na seguinte mensagem de log de exemplo:

• A quantidade de tempo gasto aguardando recursos durante a execução da consulta é mostrada nestas métricas:

  • queues.execution.totalTimeQueuedMicros

  • timeAcquiringMicros

• workingMillis é o tempo que o MongoDB passa trabalhando na operação.

• durationMillis é a latência total da operação.

{
   "t":{
      "$date":"2024-06-01T13:24:10.034+00:00"
   },
   "s":"I",
   "c":"COMMAND",
   "id":51803,
   "ctx":"conn3",
   "msg":"Slow query",
   "attr":{
      "type":"command",
      "isFromUserConnection":true,
      "ns":"db.coll",
      "collectionType":"normal",
      "appName":"MongoDB Shell",
      "command":{
         "find":"coll",
         "filter":{
            "b":-1
         },
         "sort":{
            "splitPoint":1
         },
         "readConcern":{ },
         "$db":"db"
      },
      "planSummary":"COLLSCAN",
      "planningTimeMicros":87,
      "keysExamined":0,
      "docsExamined":20889,
      "hasSortStage":true,
      "nBatches":1,
      "cursorExhausted":true,
      "numYields":164,
      "nreturned":99,
      "planCacheShapeHash":"9C05019A",
      "planCacheKey":"C41063D6",
      "queryFramework":"classic",
      "reslen":96,
      "locks":{
         "ReplicationStateTransition":{
            "acquireCount":{
               "w":3
            }
         },
         "Global":{
            "acquireCount":{
               "r":327,
               "w":1
            }
         },
         "Database":{
            "acquireCount":{
               "r":1
            },
            "acquireWaitCount":{
               "r":1
            },
            "timeAcquiringMicros":{
               "r":2814
            }
         },
         "Collection":{
            "acquireCount":{
               "w":1
            }
         }
      },
      "flowControl":{
         "acquireCount":1,
         "acquireWaitCount":1,
         "timeAcquiringMicros":8387
      },
      "readConcern":{
         "level":"local",
         "provenance":"implicitDefault"
      },
      "storage":{ },
      "cpuNanos":20987385,
      "remote":"127.0.0.1:47150",
      "protocol":"op_msg",
      "queues":{
         "ingress":{
            "admissions":7,
            "totalTimeQueuedMicros":0
         },
         "execution":{
            "admissions":328,
            "totalTimeQueuedMicros":2109
         }
      },
      "workingMillis":89,
      "durationMillis":101
   }
}

A partir do MongoDB 8.0, o campo queryHash pré-existente é renomeado para planCacheShapeHash. Se você estiver usando uma versão anterior do MongoDB , verá queryHash em vez de planCacheShapeHash.

Fuga

Este exemplo demonstra fuga de caracteres, como mostrado no campo setName do objeto de atributo:

{
  "t": {
    "$date": "2020-05-20T19:11:09.268+00:00"
  },
  "s": "I",
  "c": "REPL",
  "id": 21752,
  "ctx": "ReplCoord-0",
  "svc": "R",
  "msg": "Scheduling remote command request",
  "attr": {
    "context": "vote request",
    "request": "RemoteCommand 229 -- target:localhost:27003 db:admin cmd:{ replSetRequestVotes: 1, setName: \"my-replica-name\", dryRun: true, term: 3, candidateIndex: 0, configVersion: 2, configTerm: 3, lastAppliedOpTime: { ts: Timestamp(1589915409, 1), t: 3 } }"
  }
}

Vista

A partir do MongoDB 5.0, as mensagens de registro para query lentas em exibições incluem um campo resolvedViews que contém os detalhes da exibição:

"resolvedViews": [ {
   "viewNamespace": <String>,  // namespace and view name
   "dependencyChain": <Array of strings>,  // view name and collection
   "resolvedPipeline": <Array of documents>  // aggregation pipeline for view
} ]

O exemplo a seguir utiliza o banco de dados do test e cria uma visualização denominada myView que classifica os documentos no myCollection pelo campo firstName:

use test
db.createView( "myView", "myCollection", [ { $sort: { "firstName" : 1 } } ] )

Suponha que uma query lenta seja executada em myView. A mensagem de log de exemplo a seguir contém um campo resolvedViews para myView:

{
   "t": {
      "$date": "2021-09-30T17:53:54.646+00:00"
   },
   "s": "I",
   "c": "COMMAND",
   "id": 51803,
   "ctx": "conn249",
   "svc": "R",
   "msg": "Slow query",
   "attr": {
      "type": "command",
      "ns": "test.myView",
      "appName": "MongoDB Shell",
      "command": {
         "find": "myView",
         "filter": {},
         "lsid": {
            "id": { "$uuid": "ad176471-60e5-4e82-b977-156a9970d30f" }
         },
         "$db": "test"
      },
      "planSummary":"COLLSCAN",
         "resolvedViews": [ {
            "viewNamespace": "test.myView",
            "dependencyChain": [ "myView", "myCollection" ],
            "resolvedPipeline": [ { "$sort": { "firstName": 1 } } ]
         } ],
         "keysExamined": 0,
         "docsExamined": 1,
         "hasSortStage": true,
         "cursorExhausted": true,
         "numYields": 0,
         "nreturned": 1,
         "planCacheShapeHash": "3344645B",
         "planCacheKey": "1D3DE690",
         "queryFramework": "classic"
         "reslen": 134,
         "locks": { "ParallelBatchWriterMode": { "acquireCount": { "r": 1 } },
         "ReplicationStateTransition": { "acquireCount": { "w": 1 } },
         "Global": { "acquireCount": { "r": 4 } },
         "Database": { "acquireCount": {"r": 1 } },
         "Collection": { "acquireCount": { "r": 1 } },
         "Mutex": { "acquireCount": { "r": 4 } } },
         "storage": {},
         "remote": "127.0.0.1:34868",
         "protocol": "op_msg",
         "workingMillis": 0,
         "durationMillis": 0
      }
   }
}

A partir do MongoDB 8.0, o campo queryHash pré-existente é renomeado para planCacheShapeHash. Se você estiver usando uma versão anterior do MongoDB , verá queryHash em vez de planCacheShapeHash.

Autorização

A partir do MongoDB 5.0, mensagens de log para queries lentas incluem uma seção system.profile.authorization. Essas métricas ajudam a determinar se uma solicitação está atrasada devido à contenção do cache de autorização do usuário.

"authorization": {
   "startedUserCacheAcquisitionAttempts": 1,
   "completedUserCacheAcquisitionAttempts": 1,
   "userCacheWaitTimeMicros": 508
 },

Mensagem de registro do fluxo de trabalho da sessão

A partir do MongoDB 6.3, uma mensagem é adicionada ao registro se o tempo para enviar uma resposta de operação exceder a opção de limite slowms.

A mensagem é conhecida como mensagem de registro do fluxo de trabalho da sessão e contém vários horários para executar uma operação em uma sessão de banco de dados.

Exemplo de mensagem de registro do fluxo de trabalho da sessão:

{
   "t": {
     "$date": "2022-12-14T17:22:44.233+00:00"
   },
   "s": "I",
   "c": "EXECUTOR",
   "id": 6983000,
   "ctx": "conn1",
   "svc": "R",
   "msg": "Slow network response send time",
   "attr": {
      "elapsed": {
         "totalMillis": 109,
         "activeMillis": 30,
         "receiveWorkMillis": 2,
         "processWorkMillis": 10,
         "sendResponseMillis": 22,
         "yieldMillis": 15,
         "finalizeMillis": 30
      }
   }
}

Os tempos estão em milissegundos.

Uma mensagem de fluxo de trabalho de sessão será adicionada ao registro se sendResponseMillis exceder a opção de limite de lentidão.

Mensagem de registro de aquisição de conexão com fio

A partir do MongoDB 6.3, uma mensagem será adicionada ao registro se o tempo que uma operação esperou entre a aquisição de uma conexão de servidor e a gravação dos bytes a serem enviados ao servidor pela rede exceder 1 milissegundo.

Por padrão, a mensagem é registrada no nível de informação "I" e no máximo uma vez por segundo para evitar muitas mensagens de registro. Se você precisar obter todas as mensagens de registro, altere o nível de registro para depurar.

Se o tempo de espera da operação exceder 1 milissegundo e a mensagem for registrada no nível de informações no último segundo, a próxima mensagem será registrada no nível de depuração. Caso contrário, a próxima mensagem será registrada no nível de informação.

Exemplo de mensagem de registro:

{
   "t": {
      "$date":"2023-01-31T15:22:29.473+00:00"
   },
   "s": "I",
   "c": "NETWORK",
   "id": 6496702,
   "ctx": "ReplicaSetMonitor-TaskExecutor",
   "svc": "R",
   "msg": "Acquired connection for remote operation and completed writing to wire",
   "attr": {
      "durationMicros": 1683
   }
}

A tabela a seguir descreve o campo durationMicros em attr.

Tempos de atualização do cache

A partir do MongoDB 6.1, as mensagens de log para queries lentas incluem os seguintes campos de tempo de atualização do cache:

• catalogCacheDatabaseLookupDurationMillis

• catalogCacheCollectionLookupDurationMillis

• databaseVersionRefreshDurationMillis

• shardVersionRefreshMillis

A partir do MongoDB 7.0, as mensagens de log para queries lentas também incluem o campo catalogCacheIndexLookupDurationMillis, que indica o tempo que a operação gastou buscando informações do cache do índice. Esta versão também renomeia o campo shardVersionRefreshMillis para placementVersionRefreshMillis.

O exemplo a seguir inclui:

• catalogCacheDatabaseLookupDurationMillis

• catalogCacheCollectionLookupDurationMillis

• catalogCacheIndexLookupDurationMillis

{
  "t": {
    "$date": "2023-03-17T09:47:55.929+00:00"
  },
  "s": "I",
  "c": "COMMAND",
  "id": 51803,
  "ctx": "conn14",
  "svc": "R",
  "msg": "Slow query",
  "attr": {
    "type": "command",
    "ns": "db.coll",
    "appName": "MongoDB Shell",
    "command": {
      "insert": "coll",
      "ordered": true,
      "lsid": {
        "id": {
          "$uuid": "5d50b19c-8559-420a-a122-8834e012274a"
        }
      },
      "$clusterTime": {
        "clusterTime": {
          "$timestamp": {
            "t": 1679046398,
            "i": 8
          }
        },
        "signature": {
          "hash": {
            "$binary": {
              "base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
              "subType": "0"
            }
          },
          "keyId": 0
        }
      },
      "$db": "db"
    },
    "catalogCacheDatabaseLookupDurationMillis": 19,
    "catalogCacheCollectionLookupDurationMillis": 68,
    "catalogCacheIndexLookupDurationMillis": 16026,
    "nShards": 1,
    "ninserted": 1,
    "numYields": 232,
    "reslen": 96,
    "readConcern": {
      "level": "local",
      "provenance": "implicitDefault",
    },
    "cpuNanos": 29640339,
    "remote": "127.0.0.1:48510",
    "protocol": "op_msg",
    "remoteOpWaitMillis": 4078,
    "workingMillis": 20334,
    "durationMillis": 20334
  }
}