Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Referência

Mensagens de registro

Nesta página

  • Visão geral
  • Registro estruturado
  • Tipos de campos de mensagem de registro
  • Níveis de verbosidade
  • Supressão de registros
  • Analisar mensagens de registro estruturadas
  • Exemplos de mensagens de registro
  • Baixe seus registros

Visão geral

Como parte da operação normal, o MongoDB mantém um registro de eventos em execução, incluindo entradas como conexões de entrada, comandos executados e problemas encontrados. Geralmente, as mensagens de registro são úteis para diagnosticar problemas, monitorar o sistema e ajustar o desempenho.

Para receber suas mensagens de registro, você pode usar qualquer um dos seguintes métodos:

Registro estruturado

As instâncias mongod / mongos geram todas as mensagens de log no formato JSON estruturado. As entradas de log são escritas como uma série de pares de chave-valor, em que cada chave indica um tipo de campo de mensagem de log, como "gravidade", e cada valor correspondente registra as respectivas informações de log para esse tipo de campo, como "informational". Antes, as entradas de log eram geradas como texto simples.

Exemplo

Veja a seguir um exemplo de mensagem de registro no formato JSON, conforme apareceria no arquivo de log do MongoDB:

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

As entradas de registro JSON podem ser formatadas em pretty-print para facilitar a leitura. Esta é a mesma entrada de registro em pretty-print:

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

Nessa entrada de log, por exemplo, a chave s, que representa a gravidade, tem um valor correspondente de I, que representa "Informational", e a chave c, que representa o componente, tem um valor correspondente de NETWORK, indicando que o componente da "rede" foi responsável por essa mensagem específica. Os vários tipos de campo são apresentados em detalhes na seção Tipos de campo de mensagem de log.

O log estruturado com pares chave-valor permite a análise eficiente por ferramentas automatizadas ou serviços de ingestão de log e facilita a pesquisa programática e a análise de mensagens de log. Exemplos de análise de mensagens de log estruturadas podem ser encontrados na seção Analisando mensagens de log estruturadas .

Formato de saída de registro JSON

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

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
  "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:

Nome do campo
Tipo
Descrição
t
Data hora
Carimbo de data/hora da mensagem de log no formato ISO-8601. Para ver um exemplo, consulte Carimbo de data/hora.
s
String
Código de gravidade curto da mensagem de log. Para ver um exemplo, consulte Gravidade.
c
String
String completa do componente para a mensagem de log. Para um exemplo, consulte Componentes.
id
Inteiro
Identificador exclusivo para a declaração de log. Para obter um exemplo, consulte Filtragem por ID de log conhecido.
ctx
String
Nome do tópico que causou a declaração de registro.
msg
String
Mensagem de saída de log passada do servidor ou do driver. Se necessário, a mensagem é evitada de acordo com a especificação JSON.
attr
Objeto

Um ou mais pares de valores-chave para atributos de registro adicionais. Se uma mensagem de log não incluir atributos adicionais, o objeto attr será omitido.

Os valores de atributos podem ser referenciados pelo nome da chave no corpo da mensagem msg, dependendo da mensagem. Se necessário, os atributos são escapados de acordo com a especificação JSON.

tags
Array de strings
Strings que representam quaisquer tags aplicáveis à declaração de registro. Por exemplo, ["startupWarnings"].
truncated
Objeto
Informações sobre o truncamento da mensagem de log, se aplicável. Somente incluído se a entrada de log contiver pelo menos um atributo attr truncado.
size
Objeto
Tamanho original de uma entrada de log se tiver sido truncada. Somente incluído se a entrada de log contiver pelo menos um atributo attr truncado.

Fuga

Os campos de mensagem e atributos escaparão dos caracteres de controle conforme necessário de acordo com a especificação JSON Estendido Relaxado v2.0 :

Caractere representado
Sequência de fuga
Aspas (")
\"
Backslash (\)
\\
Backspace (0x08)
\b
Formfeed (0x0C)
\f
Newline (0x0A)
\n
Quebra de linha (0x0D)
\r
Horizontal tab (0x09)
\t

Os caracteres de controle não mencionados são representados como \uXXXX, sendo "XXXX" o ponto de código Unicode em formato hexadecimal. Bytes com codificação UTF-8 inválida são substituídos pelo caractere de substituição unicode representado por \ufffd.

Um exemplo de escape de mensagem é fornecido na seção de exemplos.

Truncamento

Quaisquer atributos que excedam o tamanho máximo definido com maxLogSizeKB (padrão: 10 KB) são truncados. Os atributos truncados omitem os dados de registro além do limite configurado, mas mantêm a formatação JSON da entrada para garantir que a entrada permaneça analisável.

Aqui está um exemplo de uma entrada de registro com um atributo truncado:

{"t":{"$date":"2020-05-19T18:12:05.702+00:00"},"s":"I",  "c":"SHARDING", "id":22104,   "ctx":"conn33",
"msg":"Received splitChunk request","attr":{"request":{"splitChunk":"config.system.sessions",
"from":"production-shard1","keyPattern":{"_id":1},"epoch":{"$oid":"5ec42172996456771753a59e"},
"shardVersion":[{"$timestamp":{"t":1,"i":0}},{"$oid":"5ec42172996456771753a59e"}],"min":{"_id":{"$minKey":1}},
"max":{"_id":{"$maxKey":1}},"splitKeys":[{"_id":{"id":{"$uuid":"00400000-0000-0000-0000-000000000000"}}},
{"_id":{"id":{"$uuid":"00800000-0000-0000-0000-000000000000"}}},
...
{"_id":{"id":{"$uuid":"26c00000-0000-0000-0000-000000000000"}}},{"_id":{}}]}},
"truncated":{"request":{"splitKeys":{"155":{"_id":{"id":{"type":"binData","size":21}}}}}},
"size":{"request":46328}}

Nesse caso, o atributo request foi truncado e a instância específica de seu subcampo _id que provocou a truncamento (ou seja, fez com que o atributo ultrapassasse maxLogSizeKB) é apresentado sem dados como {"_id":{}}. O restante do atributo request é então omitido.

As entradas de registro que contêm um ou mais atributos truncados incluem um objeto truncated que fornece as seguintes informações para cada atributo truncado na entrada de registro:

  • o atributo que foi truncado

  • o subobjeto específico daquele atributo que acionou a truncamento, se aplicável.

  • o type de dados do campo truncado

  • o size do campo truncado

As entradas de registro com atributos truncados também podem incluir um campo size adicional no final da entrada, que indica o tamanho original do atributo antes do truncamento, neste caso 46328 ou cerca de 46 KB. Esse campo size final só é exibido se for diferente do campo size no objeto truncated, ou seja, se o tamanho total do objeto do atributo for diferente do tamanho do subobjeto truncado, como é o caso no exemplo acima.

Preenchimento

No arquivo de saída ou nos registros do syslog, espaços são inseridos após os campos de severity, context e id para aumentar a legibilidade com fontes de largura fixa.

O seguinte trecho do arquivo de log do MongoDB demonstra este preenchimento:

{"t":{"$date":"2020-05-18T20:18:12.724+00:00"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"main","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","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","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","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","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","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"}}}

Pretty printing

Ao trabalhar com o log estruturado do MongoDB, o utilitário de linha de comando jq de terceiros é uma ferramenta útil que possibilita a impressão bonita e fácil de entradas de log, além de correspondência e filtragem avançadas baseada em chaves.

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

Você pode usar jq para formatar em pretty-print as entradas de registro da seguinte maneira:

  • Formatar o arquivo de registro inteiro em pretty-print:

    cat mongod.log | jq

  • Formatar a entrada de registro mais recente em pretty-print:

    cat mongod.log | tail -1 | jq

Mais exemplos de como trabalhar com logs estruturados do MongoDB estão disponíveis na seção Analisar mensagens de log estruturadas.

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:
Linha de comando:

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:
Linha de comando:

Observação

As mensagens de erro enviadas para stderr (erro padrão), como erros fatais durante a inicialização quando não estiver usando o arquivo ou os destinos de registro do syslog, ou mensagens relacionadas a definições de registro mal configuradas, não são afetadas pela definição do destino de saída de registro e são impressas em stderr em formato de texto simples.

Tipos de campos de mensagem de registro

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

Observação

O formato de carimbo de data/hora ctime não é mais aceito.

[1] Ao fazer login no syslog, o daemon syslog gera carimbos de data/hora quando registra uma mensagem, não quando o MongoDB emite a mensagem. Isso pode levar a registros de data/hora enganosos para entradas de registro, especialmente quando o sistema está sob volume pesado.

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",
  "msg": "Listening on",
  "attr": {
    "address": "127.0.0.1"
  }
}

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

Nível
Descrição
F
Fatal
E
Erro
W
Aviso
I
Informativo, para nível de verbosidade 0
D1 - D5

Depuração, para níveis de detalhamento > 0

A partir da versão 4.2, O MongoDB indica o nível de verbosidade de depuração específico . Por exemplo, se o nível de verbosidade for 2, o MongoDB indica D2.

Em versões anteriores, as mensagens de registro do MongoDB especificaram D para todos os níveis de verbosidade de depuração.

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

Níveis de verbosidade

Você pode especificar o nível de detalhamento do log para aumentar ou diminuir a quantidade de mensagens de log geradas pelo MongoDB. Os níveis de detalhamento podem ser ajustados para todos os componentes em conjunto ou para componentes nomeados específicos individualmente.

O detalhamento afeta as entradas de log apenas nas categorias de gravidade Informational e Debug. As categorias de gravidade acima desses níveis são sempre exibidas.

Você pode definir níveis de verbosidade para um valor alto para mostrar o registro detalhado para depuração ou desenvolvimento, ou para um valor baixo para minimizar as gravações no registro em um sistema de produção verificado. [2]

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 Configurações de verbosidade

Para configurar o nível de log padrão para todos os componentes, utilize a configuração do systemLog.verbosity. Para configurar o nível de componentes específicos, utilize as configurações do systemLog.component.<name>.verbosity.

Por exemplo, a seguinte configuração define o systemLog.verbosity para 1, o systemLog.component.query.verbosity para 2, o systemLog.component.storage.verbosity para 2 e o systemLog.component.storage.journal.verbosity para 1:

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

Você define estes valores no arquivo de configuração ou na linha de comando para sua instância do mongod ou mongos.

Todos os componentes não especificados explicitamente na configuração têm um nível de detalhamento de -1, indicando que eles herdam o nível de seu pai, se tiverem um, ou o nível de detalhamento global (systemLog.verbosity), se não tiverem.

logComponentVerbosity Parâmetro

Para definir o parâmetrologComponentVerbosity, passe um documento com as configurações de detalhamento a serem alteradas.

Por exemplo, o seguinte define o default verbosity level como 1, o query como 2, o storage para 2e o storage.journal para 1.

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

Você definiria esses valores de mongosh.

db.setLogLevel()

Use o método db.setLogLevel() para atualizar um único nível de registro de componente. Para um componente, você pode especificar o nível de verbosidade de 0 a 5 ou pode especificar -1 para herdar a verbosidade do componente principal. Por exemplo, o seguinte define o systemLog.component.query.verbosity para sua verbosidade pai (ou seja, verosidade padrão):

db.setLogLevel(-1, "query")

Você definiria este valor em mongosh.

[2](1, 2, 3, 4, 5) Os nós secundários de um conjunto de réplicas agora registram entradas de oplog que levam mais tempo do que o limite de lentidão das operações para serem aplicadas. Essas mensagens de lentidão no oplog:
  • São registradas para os secundários no diagnostic log.
  • São registrados no componente REPL com o texto applied op: <oplog entry> took <num>ms.
  • Não dependem dos níveis de registro (seja no nível do sistema ou do componente)
  • Não dependem do nível de perfil.
  • São afetados por slowOpSampleRate.
O perfilador não captura entradas de oplog lentas.

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:

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.

Para ver um exemplo de uma entrada de oplog de agregação lenta, consulte Operação lenta.

Tempo de remoteOpWaitMillis espera por shards registrados no campo

Novidades na versão 5.0.

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:

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

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

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

Supressão de registros

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.

Analisar mensagens de registro estruturadas

A análise de logs é o ato de pesquisar e analisar programaticamente arquivos de log, geralmente de maneira automatizada. Com a introdução do log estruturado, a análise de log ficou mais simples e mais avançada. Por exemplo:

  • Os campos de mensagens de registro são apresentados como pares de valores-chave. Os analisadores de registro podem realizar queries por chaves de interesse específicas para filtrar os resultados com eficiência.

  • As mensagens de registro sempre contêm a mesma estrutura de mensagem. Os analisadores de registros podem extrair informações de forma confiável de qualquer mensagem de registro, sem a necessidade de codificar para casos em que as informações estejam ausentes ou formatadas de forma diferente.

Os exemplos a seguir demonstram fluxos de trabalho de análise de registro típicos ao trabalhar com saída de registros JSON do MongoDB.

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.

Contando mensagens exclusivas

O exemplo a seguir mostra os 10 principais valores de mensagem únicos em um determinado arquivo de log, classificados por frequência:

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

Monitoramento de conexões

As conexões de clientes remotos são mostradas no registro sob a chave "remota" no objeto de atributo. O seguinte conta todas as conexões exclusivas ao longo do arquivo de registro e as apresenta em ordem decrescente por número de ocorrências:

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

Observe que as conexões do mesmo endereço IP, mas que se conectam por portas diferentes, são tratadas como conexões diferentes por esse comando. Você poderia limitar a saída para considerar apenas endereços IP, com a seguinte alteração:

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

Analisando conexões de drivers

O exemplo a seguir conta todas as conexões do driver MongoDB remoto e apresenta cada tipo e versão de driver em ordem decrescente por número de ocorrências:

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

Analisando tipos de cliente

O exemplo a seguir examina os dados de clientes que se conectam ao MongoDB através de drivers e aplicativos remotos, incluindo mongosh, e gera um relatório com a contagem de conexões para cada tipo de sistema operacional único que se conectou, ordenado por frequência:

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

A string "Darwin", conforme apresentada neste campo de registro, representa um cliente macOS.

Analisando queries lentas

Com o log de operação lenta habilitado, somente as operações lentas que levaram mais de 2000 milissegundos serão retornadas para análise posterior:

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

Consulte a documentação do jq para obter mais informações sobre os filtros jq mostrados neste exemplo.

Filtragem por componente

Os componentes de log (o terceiro campo no formato de saída de log JSON) indicam a categoria geral em que uma determinada mensagem de log se enquadra. A filtragem por componente costuma ser um ótimo ponto de partida ao analisar mensagens de log para eventos relevantes.

O exemplo a seguir imprime apenas as mensagens de log do tipo componente REPL:

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

O exemplo a seguir imprime todas as mensagens de log , exceto aquelas do tipo de componente REPL:

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

O exemplo a seguir imprime mensagens de log do tipo componente REPL ou STORAGE:

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

Consulte a documentação do jq para obter mais informações sobre os filtros jq mostrados neste exemplo.

Filtrando por ID de registro conhecido

As ID de log (o quinto campo no formato de saída de log JSON) são mapeadas para eventos de log específicos e podem ser usadas para permanecer estáveis em sucessivas versões do MongoDB.

Como exemplo, você pode estar interessado nos dois eventos de registro a seguir, que mostram uma conexão de cliente seguida de uma desconexão:

{"t":{"$date":"2020-06-01T13:06:59.027-0500"},"s":"I", "c":"NETWORK", "id":22943,"ctx":"listener","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","msg":"end connection {remote} ({connectionCount}{word} now open)","attr":{"remote":"127.0.0.1:61298","connectionCount":10,"word":" connections"}}

As IDs de registro para essas duas entradas são 22943 e 22944, respectivamente. Você pode então filtrar a saída do registro para mostrar apenas esses IDs de registro, mostrando efetivamente apenas a atividade de conexão do cliente, usando a seguinte sintaxe jq:

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

Consulte a documentação do jq para obter mais informações sobre os filtros jq mostrados neste exemplo.

Filtragem por faixa de datas

A saída do registro pode ser ainda mais refinada filtrando-se o campo de registro de data e hora, limitando as entradas de registro retornadas a uma faixa de datas específica. Por exemplo, o seguinte retorna todas as entradas de registro que ocorreram em 15 de abril de 2020:

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

Observe que essa sintaxe inclui o carimbo de data/hora completo, incluindo milissegundos, mas excluindo o ajuste do fuso horário.

A filtragem por faixa de datas pode ser combinada com qualquer um dos exemplos acima, criando relatórios semanais ou resumos anuais, por exemplo. A sintaxe a seguir amplia o exemplo "Monitorando Conexões" anterior para restringir os resultados ao mês de maio de 2020:

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

Consulte a documentação do jq para obter mais informações sobre os filtros jq mostrados neste exemplo.

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.

Exemplos de mensagens de registro

Os exemplos a seguir mostram mensagens de registro no formato de saída JSON.

Estas mensagens de registro são apresentadas em formato pretty-print para maior conveniência.

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",
  "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",
  "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

Este exemplo mostra uma mensagem de operação lenta:

{
  "t": {
    "$date": "2020-05-20T20:10:08.731+00:00"
  },
  "s": "I",
  "c": "COMMAND",
  "id": 51803,
  "ctx": "conn281",
  "msg": "Slow query",
  "attr": {
    "type": "command",
    "ns": "stocks.trades",
    "appName": "MongoDB Shell",
    "command": {
      "aggregate": "trades",
      "pipeline": [
        {
          "$project": {
            "ticker": 1,
            "price": 1,
            "priceGTE110": {
              "$gte": [
                "$price",
                110
              ]
            },
            "_id": 0
          }
        },
        {
          "$sort": {
            "price": -1
          }
        }
      ],
      "allowDiskUse": true,
      "cursor": {},
      "lsid": {
        "id": {
          "$uuid": "fa658f9e-9cd6-42d4-b1c8-c9160fabf2a2"
        }
      },
      "$clusterTime": {
        "clusterTime": {
          "$timestamp": {
            "t": 1590005405,
            "i": 1
          }
        },
        "signature": {
          "hash": {
            "$binary": {
              "base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
              "subType": "0"
            }
          },
          "keyId": 0
        }
      },
      "$db": "test"
    },
    "planSummary": "COLLSCAN",
    "cursorid": 1912190691485054700,
    "keysExamined": 0,
    "docsExamined": 1000001,
    "hasSortStage": true,
    "usedDisk": true,
    "numYields": 1002,
    "nreturned": 101,
    "queryFramework": "classic"
    "reslen": 17738,
    "locks": {
      "ReplicationStateTransition": {
        "acquireCount": {
          "w": 1119
        }
      },
      "Global": {
        "acquireCount": {
          "r": 1119
        }
      },
      "Database": {
        "acquireCount": {
          "r": 1119
        }
      },
      "Collection": {
        "acquireCount": {
          "r": 1119
        }
      },
      "Mutex": {
        "acquireCount": {
          "r": 117
        }
      }
    },
    "storage": {
      "data": {
        "bytesRead": 232899899,
        "timeReadingMicros": 186017
      },
      "timeWaitingMicros": {
        "cache": 849
      }
    },
    "remote": "192.168.14.15:37666",
    "protocol": "op_msg",
    "durationMillis": 22427
  }
}

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",
  "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",
   "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,
         "queryHash": "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",
         "durationMillis": 0
      }
   }
}

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
 },

Baixe seus registros

Você pode usar o MongoDB Atlas para baixar um arquivo compactado contendo os logs de um nome de host ou processo selecionado em sua implantação de banco de dados. Para saber mais, consulte Exibir e baixar logs do MongoDB.

Voltar

Glossário

Próximo

Limites e limites