Mensajes de registro

Esta versión de la documentación está archivada y ya no recibe soporte. Para actualizar su implementación 6.0, consulte Procedimientos de actualización de MongoDB.7.0

Overview

Como parte de la operación normal, MongoDB mantiene un registro continuo de eventos, incluyendo entradas como conexiones entrantes, comandos ejecutados y problemas encontrados. Por lo general, los mensajes de registro son útiles para diagnosticar problemas, supervisar la implementación y optimizar el rendimiento.

Para obtener sus mensajes de registro, puede utilizar cualquiera de los siguientes métodos:

Ver los registros en el destino de registro configurado.
Ejecutar el getLog dominio.
Descarga los registros a través de MongoDB Atlas. Para aprender más, consulta Descargar tus registros.

Registro estructurado

Las instancias mongod / mongos generan todos los mensajes de registro en formato JSON estructurado. Las entradas de registro se escriben como una serie de pares clave-valor, donde cada clave indica un tipo de campo de mensaje de registro, como "gravedad", y cada valor correspondiente registra la información de registro asociada a ese tipo de campo, como "informativa". Anteriormente, las entradas de registro se generaban en texto plano.

Ejemplo

El siguiente es un mensaje de registro de ejemplo en formato JSON tal como aparecería en la entrada de registro de 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"}}

Las entradas de registro JSON se pueden formatear de manera legible para facilitar su lectura. Aquí está la misma entrada de registro con formato legible:

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

En esta entrada de registro, por ejemplo, la clave s, que representa la gravedad, tiene un valor correspondiente de I, que representa "Informativo", y la clave c, que representa el componente, tiene un valor correspondiente de NETWORK, indicando que el componente "red" fue responsable de este mensaje en particular. Los distintos tipos de campos se presentan en detalle en la sección Tipos de campos de mensajes de registro.

El registro estructurado con pares clave-valor permite un análisis eficiente mediante herramientas automatizadas o servicios de ingestión de registros, y facilita la búsqueda y el análisis programático de los mensajes de registro. Se pueden encontrar ejemplos de análisis de mensajes de registro estructurados en la sección Analizar mensajes de registro estructurados.

Formato de salida de registros JSON

Toda la salida de registros está en formato JSON, incluida la salida enviada a:

Entrada de registro
Syslog
Destinos de registro Stdout (salida estándar)

La salida del comando getLog también está en formato JSON.

Cada entrada de registro se emite como un objeto JSON autónomo que sigue la especificación Relaxed Extended JSON v2.0 y tiene la siguiente disposición y orden de campos:

{
  "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)
}

Descripciones de campos:

Nombre de campo	Tipo	Descripción
`t`	Fecha y hora	Marca de tiempo del mensaje de registro en formato ISO-8601. Para ver un ejemplo, consulta Marca de tiempo.
`s`	String	Código de severidad breve del mensaje de registro. Para ver un ejemplo, consulta Severidad.
`c`	String	String completa del componente para el mensaje de registro. Para ver un ejemplo, consulta Componentes.
`id`	entero	Identificador único para la instrucción de registro. Para ver un ejemplo, consulta Filtro por ID de registro conocido.
`ctx`	String	Nombre del hilo que generó la instrucción de registro.
`msg`	String	Mensaje de salida del registro pasado desde el servidor o driver. Si es necesario, el mensaje se escapará de acuerdo con la especificación JSON.
`attr`	Objeto	Uno o más pares clave-valor para atributos de registro adicionales. Si un mensaje de registro no incluye atributos adicionales, se omite el objeto `attr`. Los valores de los atributos pueden ser referenciados por el nombre de su clave en el cuerpo del mensaje `msg`, dependiendo del mensaje. Si es necesario, los atributos se escapan de acuerdo con la especificación JSON.
`tags`	Arreglo de cadenas	Cadenas que representan cualquier etiqueta aplicable a la instrucción de registro. Por ejemplo, `["startupWarnings"]`.
`truncated`	Objeto	Información sobre el truncamiento del mensaje de registro, si es aplicable. Solo se incluye si la entrada del registro contiene al menos un atributo `attr` truncado.
`size`	Objeto	Tamaño original de una entrada de registro si se ha truncado. Solo se incluye si la entrada del registro contiene al menos un atributo `attr` truncado.

Escape

Los campos de mensaje y atributos escaparán de los caracteres de control según sea necesario de acuerdo con la especificación JSON2.0 extendido relajado v:

Carácter representado	Secuencia de escape
Comillas (`"`)	`\"`
Backslash (`\`)	`\\`
Retroceso (`0x08`)	`\b`
Formfeed (`0x0C`)	`\f`
Nueva línea (`0x0A`)	`\n`
Retorno de carro (`0x0D`)	`\r`
Horizontal tab (`0x09`)	`\t`

Los caracteres de control que no se enumeran arriba se escapan con \uXXXX, donde "XXXX" es el punto de código Unicode en hexadecimal. Los bytes con codificación UTF-8 no válida se reemplazan por el carácter de reemplazo Unicode representado por \ufffd.

En la sección de ejemplos se proporciona un ejemplo de escape de mensajes.

Truncamiento

Cualquier atributo que supere el tamaño máximo definido con maxLogSizeKB (por defecto: 10 KB) será truncado. Los atributos truncados omiten los datos de registro más allá del límite configurado, pero conservan el formato JSON de la entrada para garantizar que la entrada aún se pueda analizar.

A continuación se muestra un ejemplo de una entrada de registro con un 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}}

En este caso, el request atributo se ha truncado y la instancia específica de su subcampo _id que provocó el truncamiento (es decir, provocó que el atributo sobrepasara) se imprime sin maxLogSizeKB datos {"_id":{}} como. El resto del request atributo se omite.

Las entradas de registro que contienen uno o más atributos truncados incluyen un objeto truncated que proporciona la siguiente información para cada atributo truncado en la entrada de registro:

el atributo que fue truncado
el subobjeto específico de ese atributo que desencadenó el truncamiento, si corresponde.
Los datos type del campo truncado
el size del campo truncado

Las entradas de registro con atributos truncados también pueden incluir un campo size adicional al final de la entrada, que indica el tamaño original del atributo antes del truncamiento; en este caso, 46328 o aproximadamente 46KB. Este último campo size solo se muestra si es diferente del campo size del objeto truncated; es decir, si el tamaño total del atributo es diferente del tamaño del subobjeto truncado, como en el ejemplo anterior.

Relleno

Cuando se envía a los destinos de registro archivo o syslog, se añade relleno después de los campos de severidad, contexto e id para aumentar la legibilidad cuando se visualiza con una fuente de ancho fijo.

El siguiente extracto de la entrada de registro de MongoDB demuestra este relleno:

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

Formateo legible

Al trabajar con el registro estructurado de MongoDB, puede utilizar la utilidad de línea de comandos jq de terceros para una fácil impresión de entradas de registro y un potente filtrado y coincidencia basados en claves.

jq es un analizador JSON de código abierto y está disponible para Linux, Windows y macOS.

Puedes usar jq para las entradas de registro legibles de la siguiente manera:

Pretty-print toda la entrada del registro:
```
cat mongod.log | jq
```
Pretty-print la entrada del registro más reciente:
```
cat mongod.log | tail -1 | jq
```

Más ejemplos de trabajo con registros estructurados de MongoDB están disponibles en la sección Análisis de mensajes de registro estructurados.

Configuración de los destinos de mensajes de registro

Los mensajes de registro de MongoDB pueden enviarse a archivo, syslog o stdout (salida estándar).

Para configurar el destino de salida de los registros, utiliza una de las siguientes configuraciones, ya sea en el archivo de configuración o en la línea de comandos:

Archivo de configuración:

La opción systemLog.destination para archivo o syslog

Línea de comandos:

la opción --logpath para mongod de archivo
la opción --syslog para mongod para syslog
la opción --logpath para mongos de archivo
la opción --syslog para mongos para syslog

No especificar ni archivo ni syslog envía toda la salida de registro a stdout.

Para ver la lista completa de configuraciones y opciones de registro, consulte:

Archivo de configuración:

Lista de opciones de systemLog

Línea de comandos:

Nota

Los mensajes de error enviados a stderr (error estándar), como los errores fatales durante el inicio cuando no se utilizan los destinos de registro archivo o syslog, o los mensajes relacionados con configuraciones de registro incorrectas, no se ven afectados por la configuración del destino de salida de registro y se imprimen en stderr en formato de texto plano.

Tipos de campos de mensajes de registro

Marca de tiempo

El tipo de campo de marca de tiempo indica la fecha y hora precisas en las que ocurrió el 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"
  }
}

Al registrar en archivo o en syslog [1], el formato por defecto para la marca de tiempo es iso8601-local. Para modificar el formato de la marca de tiempo, utiliza la opción de ejecución --timeStampFormat o la configuración systemLog.timeStampFormat.

Consulta Filtrar por rango de fechas para conocer ejemplos de análisis de registros que filtran por el campo de marca de tiempo.

Nota

El formato de marca de tiempo ctime ya no es compatible.

[1]	Si se registra en syslog, el demonio `syslog` genera marcas de tiempo cuando registra un mensaje, no cuando MongoDB lo emite. Esto puede llevar a marcas de tiempo engañosas en las entradas de registro, especialmente cuando el sistema está bajo una carga pesada.

Gravedad

El tipo de campo de severidad indica el nivel de gravedad asociado con el evento de registro.

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

Los niveles de severidad varían desde "fatal" (el más severo) hasta "debug" (el menos severo):

Nivel	Descripción
`F`	Fatal
`E`	Error
`W`	Advertencia
`I`	Informativo, para el nivel de verbosidad `0`
`D1` - `D5`	Depuración, para niveles de verbosidad > `0` A partir de la 4.2 versión, MongoDB indica el nivel de verbosidad de depuración específico. Por ejemplo, si el nivel de verbosidad es,2 MongoDB `D2` indica. En versiones anteriores, los mensajes de registro de MongoDB especificaban `D` para todos los niveles de verbosidad de depuración.

Puede especificar el nivel de verbosidad de varios componentes para determinar la cantidad de mensajes Informational y Debug que MongoDB emite. Siempre se muestran las categorías de gravedad por encima de estos niveles. [2] Para establecer los niveles de verbosidad, consulte Configurar los niveles de verbosidad del registro.

Componentes

El tipo de campo del componente indica la categoría de la que es nodo un evento registrado, como RED o COMANDO.

{
  "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 es configurable individualmente mediante su propio filtro de nivel de verbosidad. Los componentes disponibles son los siguientes:

ACCESS: Mensajes relacionados con el control de acceso, como la autenticación. Para especificar el nivel de registro para los componentes de ACCESS, utiliza la configuración de systemLog.component.accessControl.verbosity.

ASSERT: Cuando una operación devuelve un error, se activa una aserción. El nivel de verbosidad por defecto es 0. Sin embargo, el nivel de verbosidad debe ser al menos 1 para que las operaciones que devuelven errores se incluyan en los registros del sistema. Para especificar el nivel de registro de los componentes de ACCESS, utiliza la configuración assert.

COMMAND: Mensajes relacionados con comandos de base de datos, como count. Para especificar el nivel de registro de los componentes de COMMAND, utiliza la configuración systemLog.component.command.verbosity.

CONTROL: Mensajes relacionados con las actividades de control, como la inicialización. Para especificar el nivel de registro de los componentes de CONTROL, utiliza la configuración systemLog.component.control.verbosity.

ELECTION

Mensajes relacionados específicamente con las elecciones del set de réplicas. Para especificar el nivel de registro para los componentes de ELECTION, configura el parámetro systemLog.component.replication.election.verbosity.

REPL es el componente matriz de ELECTION. Si systemLog.component.replication.election.verbosity no está configurado, MongoDB utiliza el nivel de verbosidad REPL para los componentes ELECTION.

FTDC: Mensajes relacionados con el mecanismo de colección de datos de diagnóstico, como estadísticas del servidor y mensajes de estado. Para especificar el nivel de registro de los componentes de FTDC, utiliza la configuración systemLog.component.ftdc.verbosity.

GEO: Mensajes relacionados con el análisis de formas geoespaciales, como la verificación de las formas GeoJSON. Para especificar el nivel de registro para los componentes de GEO, configura el parámetro systemLog.component.geo.verbosity.

INDEX: Mensajes relacionados con las operaciones de indexación, como la creación de índices. Para especificar el nivel de registro para los componentes de INDEX, configura el parámetro systemLog.component.index.verbosity.

INITSYNC

Mensajes relacionados con la operación de sincronización inicial. Para especificar el nivel de registro para los componentes de INITSYNC, configura el parámetro systemLog.component.replication.initialSync.verbosity.

REPL es el componente matriz de INITSYNC. Si systemLog.component.replication.initialSync.verbosity no está configurado, MongoDB utiliza el nivel de verbosidad REPL para los componentes INITSYNC.

JOURNAL

Mensajes relacionados específicamente con las actividades de registro en la bitácora de almacenamiento. Para especificar el nivel de registro de los componentes de JOURNAL, utiliza la configuración systemLog.component.storage.journal.verbosity.

STORAGE es el componente matriz de JOURNAL. Si systemLog.component.storage.journal.verbosity no está configurado, MongoDB utiliza el nivel de verbosidad STORAGE para los componentes JOURNAL.

NETWORK: Mensajes relacionados con actividades de red, como aceptar conexiones. Para especificar el nivel de registro de los componentes NETWORK, configura el parámetro systemLog.component.network.verbosity.

QUERY: Mensajes relacionados con consultas, incluidas las actividades del planificador de consultas. Para especificar el nivel de registro para los componentes de QUERY, configura el parámetro systemLog.component.query.verbosity.

QUERYSTATS: Mensajes relacionados con las operaciones de $queryStats. Para especificar el nivel de registro para los componentes QUERYSTATS, configura el parámetro systemLog.component.queryStats.verbosity.

RECOVERY

Mensajes relacionados con las actividades de recuperación de almacenamiento. Para especificar el nivel de registro de los componentes de RECOVERY, utilice la configuración systemLog.component.storage.recovery.verbosity.

STORAGE es el componente matriz de RECOVERY. Si systemLog.component.storage.recovery.verbosity no está configurado, MongoDB utiliza el nivel de verbosidad STORAGE para los componentes RECOVERY.

REPL

Mensajes relacionados con sets de réplicas, como la sincronización inicial, los latidos, la replicación en estado estacionario y el rollback. [2] Para especificar el nivel de registro de los componentes de REPL, configura el parámetro systemLog.component.replication.verbosity.

REPL es el componente padre de los componentes ELECTION, INITSYNC, REPL_HB, y ROLLBACK.

REPL_HB

Mensajes relacionados específicamente con los latidos del set de réplicas. Para especificar el nivel de registro de los componentes REPL_HB, configura el parámetro systemLog.component.replication.heartbeats.verbosity.

REPL es el componente matriz de REPL_HB. Si systemLog.component.replication.heartbeats.verbosity no está configurado, MongoDB utiliza el nivel de verbosidad REPL para los componentes REPL_HB.

ROLLBACK

Mensajes relacionados con las operaciones de rollback. Para especificar el nivel de registro de los componentes ROLLBACK, configura el parámetro systemLog.component.replication.rollback.verbosity.

REPL es el componente matriz de ROLLBACK. Si systemLog.component.replication.rollback.verbosity no está configurado, MongoDB utiliza el nivel de verbosidad REPL para los componentes ROLLBACK.

SHARDING: Mensajes relacionados con actividades de fragmentación, como el inicio del mongos. Para especificar el nivel de registro para los componentes de SHARDING, utiliza la configuración de systemLog.component.sharding.verbosity.

STORAGE

Mensajes relacionados con actividades de almacenamiento, como los procesos involucrados en el comando fsync. Para especificar el nivel de registro de los componentes de STORAGE, utiliza la configuración systemLog.component.storage.verbosity.

STORAGE es el componente principal de JOURNAL y RECOVERY.

TXN: Mensajes relacionados con Transacciones multi-documento. Para especificar el nivel de registro para los componentes de TXN, utiliza la configuración de systemLog.component.transaction.verbosity.

WRITE: Mensajes relacionados con operaciones de guardar, como el comando update. Para especificar el nivel de registro de los componentes de WRITE, utilice la configuración systemLog.component.write.verbosity.

WT: Novedades en la versión 5.3.
Mensajes relacionados con el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WT, utiliza la configuración systemLog.component.storage.wt.verbosity.

WTBACKUP: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de copia de seguridad realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes WTBACKUP, utiliza la configuración systemLog.component.storage.wt.wtBackup.verbosity.

WTCHKPT: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de punto de control realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTCHKPT, utiliza la configuración systemLog.component.storage.wt.wtCheckpoint.verbosity.

WTCMPCT: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de compactación realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro de los componentes de WTCMPCT, utilice la configuración systemLog.component.storage.wt.wtCompact.verbosity.

WTEVICT: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de desalojo realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes WTEVICT, utiliza la opción systemLog.component.storage.wt.wtEviction.verbosity.

WTHS: Novedades en la versión 5.3.
Mensajes relacionados con el almacén de historial del motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTHS, utiliza la configuración systemLog.component.storage.wt.wtHS.verbosity.

WTRECOV: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de recuperación realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTRECOV, utiliza la configuración systemLog.component.storage.wt.wtRecovery.verbosity.

WTRTS: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de rollback a estable (RTS) realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTRTS, utiliza la configuración systemLog.component.storage.wt.wtRTS.verbosity.

WTSLVG: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de salvamento realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTSLVG, utiliza la configuración systemLog.component.storage.wt.wtSalvage.verbosity.

WTTS: Novedades en la versión 5.3.
Mensajes relacionados con las marcas de tiempo utilizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTTS, utiliza la configuración systemLog.component.storage.wt.wtTimestamp.verbosity.

WTTXN: Novedades en la versión 5.3.
Mensajes relacionados con las transacciones realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTTXN, utiliza la configuración systemLog.component.storage.wt.wtTransaction.verbosity.

WTVRFY: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de verificación realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes WTVRFY, utiliza la opción systemLog.component.storage.wt.wtVerify.verbosity.

WTWRTLOG: Novedades en la versión 5.3.
Mensajes relacionados con las operaciones de escritura de registros realizadas por el motor de almacenamiento WiredTiger. Para especificar el nivel de registro para los componentes de WTWRTLOG, utiliza la configuración systemLog.component.storage.wt.wtWriteLog.verbosity.

-: Mensajes no asociados a un componente nombrado. Los componentes sin nombre tienen el nivel de registro por defecto especificado en la configuración systemLog.verbosity. La configuración systemLog.verbosity es la configuración por defecto para los componentes con nombre y sin nombre.

Consulta Filtro por componente para ejemplos de análisis de registros que filtran en el campo de componente.

Datos del cliente

Los controladores de MongoDB y las aplicaciones del cliente (incluidas mongosh) tienen la capacidad de enviar información de identificación en el momento de la conexión al servidor. Una vez establecida la conexión, el cliente no vuelve a enviar la información de identificación a menos que la conexión se descarte y se restablezca.

Esta información identificativa se encuentra en el campo de atributos de la entrada de registro. La información exacta incluida varía según el cliente.

A continuación, se muestra un mensaje de registro de ejemplo que contiene el documento de datos del cliente tal como se transmitió desde una conexión mongosh. Los datos del cliente están contenidos en el objeto doc en el campo de 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"}}}}

Cuando los nodos secundarios de un set de réplicas inician la conexión con un primario, envían datos similares. Un mensaje de registro de muestra que contiene esta conexión de inicio podría aparecer de la siguiente manera. Los datos del cliente están contenidos en el objeto doc en el campo de 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"}}}}

Consulta la sección de ejemplos para ver un ejemplo formateado que muestra los datos del cliente.

Para una descripción completa de la información del cliente y los campos requeridos, consulta la especificación de MongoDB Handshake.

Niveles de verbosidad

Puedes especificar el nivel de verbosidad de los registros para aumentar o disminuir la cantidad de mensajes que MongoDB emite. Los niveles de verbosidad se pueden ajustar para todos los componentes juntos o para componentes con nombre individualmente.

El nivel de verbosidad afecta las entradas de registro en las categorías de gravedad Informativa y Depuración únicamente. Siempre se muestran las categorías de gravedad por encima de estos niveles.

Puedes establecer los niveles de verbosidad en un valor alto para mostrar un registro detallado para la depuración o el desarrollo, o en un valor bajo para minimizar el guardado en el registro en una implementación de producción verificada. [2]

Ve el nivel de verbosidad del registro

Para ver los niveles de verbosidad actuales, utiliza el método db.getLogComponents():

db.getLogComponents()

Su resultado podría asemejarse a lo siguiente:

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

La entrada inicialverbosity es el nivel de verbosidad principal para todos los componentes, mientras que los componentes nombrados individuales que siguen, como accessControl, indican el nivel de verbosidad específico para ese componente, anulando el nivel de verbosidad global para ese componente en particular si se establece.

Un valor de -1 indica que el componente hereda el nivel de verbosidad de su elemento matriz, si lo tiene (como ocurre con recovery arriba, que hereda de storage), o el nivel de verbosidad global si no lo tiene (como ocurre con command). Las relaciones de herencia para el nivel de verbosidad se indican en la sección de componentes.

Configurar los niveles de verbosidad de los registros

Puedes configurar el nivel de verbosidad utilizando: la configuración systemLog.verbosity y systemLog.component.<name>.verbosity, el parámetro logComponentVerbosity o el método db.setLogLevel(). [2]

`systemLog` Configuración del nivel de verbosidad

Para configurar el nivel de registro por defecto para todos los componentes, utiliza la configuración systemLog.verbosity. Para configurar el nivel de componentes específicos, usa los ajustes systemLog.component.<name>.verbosity.

Por ejemplo, la siguiente configuración establece el systemLog.verbosity en 1, el systemLog.component.query.verbosity en 2, el systemLog.component.storage.verbosity en 2, y el systemLog.component.storage.journal.verbosity en 1:

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

Configurarías estos valores en el archivo de configuración o en la línea de comandos para su instancia de mongod o mongos.

Todos los componentes que no se especifican explícitamente en la configuración tienen un nivel de verbosidad de -1, lo que indica que heredan el nivel de verbosidad de su componente padre, si lo tienen, o el nivel de verbosidad global (systemLog.verbosity) si no lo tienen.

`logComponentVerbosity` Parameter

Para establecer el parámetro logComponentVerbosity, pasa un documento con la configuración de nivel de verbosidad que deseas cambiar.

Por ejemplo, lo siguiente configura el default verbosity level a 1, el query a 2, el storage a 2, y el storage.journal a 1.

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

Establecerías estos valores desde mongosh.

`db.setLogLevel()`

Utiliza el método db.setLogLevel() para actualizar el nivel de registro de un solo componente. Para un componente, puedes especificar un nivel de verbosidad de 0 a 5, o puedes especificar -1 para heredar el nivel de verbosidad del componente padre. Por ejemplo, a continuación se establece el systemLog.component.query.verbosity nivel de verbosidad del componente padre (es decir, el nivel de verbosidad por defecto):

db.setLogLevel(-1, "query")

Establecerías este valor desde mongosh.

[2]

(1, 2, 3, 4, 5) Los miembros secundarios de un set de réplicas ahora registran las entradas del oplog que tardan más que el umbral de operación lenta en aplicarse. Estos mensajes lentos de oplog:

Se registran para los secundarios en el diagnostic log.
Se registran bajo el componente REPL con el texto applied op: <oplog entry> took <num>ms.
No depende de los niveles de registro (ya sea a nivel del sistema o del componente)
No depende del nivel de perfil.
Se ven afectados por slowOpSampleRate.

El perfilador no captura entradas lentas del oplog.

Registro de operaciones lentas

Las operaciones del cliente (como las consultas) aparecen en el registro si su duración excede el umbral de operación lenta o cuando el nivel de verbosidad del registro es 1 o superior. [2] Estas entradas de registro incluyen el objeto de comando completo asociado con la operación.

Las entradas del perfilador y los mensajes de registro de diagnóstico (es decir, mensajes de registro de mongod/mongos) para operaciones de lectura/escritura incluyen:

queryHash para ayudar a identificar consultas lentas con la misma forma de consulta.
planCacheKey para proporcionar más perspectiva sobre la caché del plan del query para queries lentos.

Importante

Una sola operación puede registrar más de una entrada. Por ejemplo, si más de un escritura en una operación de escritura masivo supera el umbral de operación lenta, cada escritura lenta se registra por separado.

Cambios específicos de versión

La siguiente tabla enumera los cambios en el registro de queries lentos.

Versión de MongoDB	Cambios
6.0.13 (y 5.0.24)	`totalOplogSlotDurationMicros` en el mensaje de registro de query lenta muestra el tiempo entre que una operación de escritura recibe una marca de tiempo para confirmar las escrituras del motor de almacenamiento y la confirmación real. `mongod` admite escrituras paralelas. Sin embargo, confirma operaciones de escritura con marcas de tiempo de confirmación en cualquier orden. Por ejemplo, considere las siguientes opciones de guardado con marcas de tiempo de confirmación: writeA con Timestamp1 writeB con Timestamp2 writeC con Timestamp3 Supongamos que writeB realiza su primera confirmación en Timestamp2. La replicación se pausa hasta que se produzca la confirmación de writeA porque se requiere la entrada de oplog de writeA con Timestamp1 para que la replicación copie el oplog a los nodos secundarios del set de réplicas.

Versión de MongoDB

Cambios

6.0.13 (y 5.0.24)

totalOplogSlotDurationMicros en el mensaje de registro de query lenta muestra el tiempo entre que una operación de escritura recibe una marca de tiempo para confirmar las escrituras del motor de almacenamiento y la confirmación real. mongod admite escrituras paralelas. Sin embargo, confirma operaciones de escritura con marcas de tiempo de confirmación en cualquier orden.

Por ejemplo, considere las siguientes opciones de guardado con marcas de tiempo de confirmación:

writeA con Timestamp1
writeB con Timestamp2
writeC con Timestamp3

Supongamos que writeB realiza su primera confirmación en Timestamp2. La replicación se pausa hasta que se produzca la confirmación de writeA porque se requiere la entrada de oplog de writeA con Timestamp1 para que la replicación copie el oplog a los nodos secundarios del set de réplicas.

Tiempo de espera de fragmentos registrados en `remoteOpWaitMillis` el campo

Nuevo en la versión 5.0.

Con MongoDB 5.0, puedes usar el campo de registro remoteOpWaitMillis para obtener el tiempo de espera (en milisegundos) para los resultados de las particiones.

remoteOpWaitMillis solo se hace registro:

Si configuras el registro de operaciones lentas.
En la partición o mongos que fusiona los resultados.

Para determinar si una operación de fusión o un problema con el fragmento está causando un query lento, compara los campos de tiempo de durationMillis y remoteOpWaitMillis en el registro. durationMillis es el tiempo total que tardó el query en completarse. Específicamente:

Si durationMillis es ligeramente más largo que remoteOpWaitMillis, entonces la mayor parte del tiempo se pasó esperando una respuesta de una partición. Por ejemplo, durationMillis de 17 y remoteOpWaitMillis de 15.
Si durationMillis es significativamente más largo que remoteOpWaitMillis, entonces la mayor parte del tiempo se dedicó a realizar la fusión. Por ejemplo, durationMillis de 100 y remoteOpWaitMillis de 15.

Restricción de registro

Disponible solamente en MongoDB Enterprise.

Un mongod o mongos que se ejecuta con redactClientLogData restringe cualquier mensaje que acompañe a un evento de registro determinado antes de registrarlo, y deja solo los metadatos, los archivos fuente o los números de línea relacionados con el evento. redactClientLogData evita que información potencialmente sensible ingrese al registro del sistema, a costa de perder detalle diagnóstico.

Por ejemplo, la siguiente operación inserta un documento en un mongod que se ejecuta sin restricción de registros. El mongod tiene el nivel de verbosidad del registro configurado en 1:

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

Esta operación produce el siguiente 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,
         ...
      }
      ...
   }
}

Cuando mongod se ejecuta con redactClientLogData y realiza la misma operación de inserción, produce el siguiente 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": "###",
         ...
      }
      ...
   }
}

Utiliza redactClientLogData en conjunto con Cifrado en Reposo y TLS/SSL (Cifrado de Transporte) para ayudar al cumplimiento de los requisitos regulatorios.

Análisis de mensajes de registro estructurados

El análisis de registro es el proceso de buscar y analizar archivos de registro de forma programática, a menudo de manera automatizada. Con la introducción del registro estructurado, el análisis de registro se vuelve más sencillo y potente. Por ejemplo:

Los campos de los mensajes de registro se presentan como pares clave-valor. Los analizadores de registros pueden consultar por claves específicas de interés para filtrar los resultados de manera eficiente.
Los mensajes de registro siempre tienen la misma estructura. Los analizadores de registros pueden extraer información de manera confiable de cualquier mensaje de registro, sin necesidad de programar casos en los que la información falte o tenga un formato diferente.

Los siguientes ejemplos demuestran flujos de trabajo comunes para el análisis de registros al trabajar con la salida de registros JSON de MongoDB.

Ejemplos de análisis de registros

Cuando trabajes con el registro estructurado de MongoDB, puedes utilizar la utilidad de línea de comandos de terceros jq para una fácil impresión formateada de las entradas de registro y un potente filtro y coincidencia basados en claves.

jq es un analizador JSON de código abierto y está disponible para Linux, Windows y macOS.

Estos ejemplos utilizan jq para simplificar el análisis de registros.

Conteo de mensajes únicos

El siguiente ejemplo muestra los 10 valores únicos de mensajes más frecuentes en una entrada de registro determinada, ordenados por frecuencia:

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

Supervisión de conexiones

Las conexiones de clientes remotos se muestran en el registro bajo la clave "remoto" en el objeto de atributos. A continuación, se cuentan todas las conexiones únicas a lo largo de la entrada de registro y se las presenta en orden descendente según el número de ocurrencias:

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

Tenga en cuenta que las conexiones desde la misma dirección IP, pero que se conectan a través de diferentes puertos, se consideran conexiones distintas por este comando. Podría limitar la salida para considerar solo direcciones IP, con el siguiente cambio:

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

Analice las conexiones del driver

El siguiente ejemplo cuenta todas las conexiones remotas de driver de MongoDB, y presenta cada tipo y versión de driver en orden descendente por número de ocurrencias:

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

Análisis de los tipos de clientes

El siguiente ejemplo analiza los datos de cliente informados de las conexiones remotas del controlador de MongoDB y las aplicaciones cliente, incluida mongosh, e imprime un total para cada tipo de sistema operativo único que se conectó, ordenado por frecuencia:

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

La string "Darwin", según se informa en este campo de registro, representa un cliente de macOS.

Análisis de queries lentos

Con el registro de operaciones lentas activado, a continuación se devuelven solo las operaciones lentas que superaron los 2000 milisegundos, para su posterior análisis:

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

Consulta la documentación de jq para obtener más información sobre los filtros jq que se muestran en este ejemplo.

Filtrado por componente

Los componentes de registro (el tercer campo en el formato de salida de registros JSON) indican la categoría general a la que pertenece un determinado mensaje de registro. El filtrado por componente suele ser un excelente punto de partida al analizar los mensajes de registro para eventos relevantes.

El siguiente ejemplo imprime solo los mensajes de registro del tipo de componente REPL:

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

El siguiente ejemplo imprime todos los mensajes de registro excepto aquellos del tipo de componente REPL:

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

El siguiente ejemplo imprime mensajes de registro del tipo de componente REPL o ALMACENAMIENTO:

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

Consulta la documentación de jq para obtener más información sobre los filtros jq que se muestran en este ejemplo.

Filtrado por ID de registro conocido

Los ID de registro (el quinto campo en el formato de salida de registros JSON) se asignan a eventos de registro específicos, y se puede confiar en que permanezcan estables durante las sucesivas versiones de MongoDB.

Como ejemplo, podría estar interesado en los siguientes dos eventos de registro, que muestran la conexión de un cliente seguida de una desconexión:

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

Los ID de registro de estas dos entradas son 22943 y 22944 respectivamente. Luego podría filtrar la salida de su registro para mostrar solo estos ID de registro, y mostrar efectivamente solo la actividad de la conexión del cliente, usando la siguiente sintaxis jq:

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

Consulta la documentación de jq para obtener más información sobre los filtros jq que se muestran en este ejemplo.

Filtro por rango de fechas

La salida de registro puede refinarse aún más si filtra por el campo de marca de tiempo, limitando las entradas de registro devueltas a un rango de fechas específico. El siguiente ejemplo devuelve todas las entradas de registro que ocurrieron el 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

Tenga en cuenta que esta sintaxis incluye la marca de tiempo completa, incluidos los milisegundos, pero excluyendo el desplazamiento de la zona horaria.

El filtro por rango de fechas se puede combinar con cualquiera de los ejemplos anteriores, por ejemplo, creando informes semanales o resúmenes anuales. La siguiente sintaxis amplía el ejemplo de "Supervisión de conexiones" de antes para limitar los resultados al mes de mayo 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

Consulta la documentación de jq para obtener más información sobre los filtros jq que se muestran en este ejemplo.

Servicios de ingestión de registro

Los servicios de ingestión de registro son productos de terceros que reciben y agregan entradas de registro, generalmente de un clúster distribuido de sistemas, y proporcionan un análisis continuo de esos datos en una ubicación central.

El formato de registro JSON permite una mayor flexibilidad al trabajar con servicios de ingestión y análisis de registros. Mientras que los registros en texto plano generalmente requieren algún tipo de transformación antes de ser elegibles para su uso con estos productos, los archivos JSON a menudo pueden ser utilizados directamente, según el servicio. Además, los registros en formato JSON ofrecen un mayor control al realizar el filtrado para estos servicios, ya que la estructura de clave-valor ofrece la capacidad de importar específicamente solo los campos de interés, omitiendo el resto.

Para obtener más información, consulte la documentación del servicio de ingestión de registro de terceros que haya elegido.

Ejemplos de mensajes de registro

Los siguientes ejemplos muestran mensajes de registro en formato de salida JSON.

Estos mensajes de registro se presentan en formato de impresión legible para mayor comodidad.

Advertencia de empresa emergente

Este ejemplo muestra una advertencia de empresa emergente:

{
  "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"
  ]
}

Conexión del cliente

Este ejemplo muestra una conexión de cliente que incluye datos del 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"
      }
    }
  }
}

Operación lenta

Este ejemplo muestra un mensaje de operación 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
  }
}

Escape

Este ejemplo demuestra el escape de caracteres, como se muestra en el campo setName del 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 de MongoDB 5.0, los mensajes de registro para consultas lentas en vistas incluyen un campo resolvedViews que contiene los detalles de la vista:

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

El siguiente ejemplo utiliza la base de datos test y crea una vista llamada myView que ordena los documentos en myCollection por el campo firstName:

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

Asume que se ejecuta una consulta lenta en myView. El siguiente mensaje de ejemplo de registro contiene un 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
      }
   }
}

Autorización

A partir de MongoDB 5.0, los mensajes de registro para consultas lentas incluyen una sección de system.profile.authorization. Estas métricas ayudan a determinar si una solicitud se retrasa debido a la contención por la caché de autorización del usuario.

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

Descargue sus registros

Se puede utilizar MongoDB Atlas para descargar un archivo comprimido que contenga los registros de un nombre de host o proceso seleccionado en la implementación de la base de datos. Para obtener más información, se debe consultar Ver y descargar los registros de MongoDB.

Volver

Glosario

Límites y umbrales

Overview

Registro estructurado

Ejemplo

Formato de salida de registros JSON

Escape

Truncamiento

Relleno

Formateo legible

Configuración de los destinos de mensajes de registro

Nota

Tipos de campos de mensajes de registro

Marca de tiempo

Nota

Gravedad

Componentes

Datos del cliente

Niveles de verbosidad

Ve el nivel de verbosidad del registro

Configurar los niveles de verbosidad de los registros

systemLog Configuración del nivel de verbosidad

logComponentVerbosity Parameter

db.setLogLevel()

Registro de operaciones lentas

Importante

Cambios específicos de versión

Tiempo de espera de fragmentos registrados en remoteOpWaitMillis el campo

Restricción de registro

Análisis de mensajes de registro estructurados

Ejemplos de análisis de registros

Conteo de mensajes únicos

Supervisión de conexiones

Analice las conexiones del driver

Análisis de los tipos de clientes

Análisis de queries lentos

Filtrado por componente

Filtrado por ID de registro conocido

Filtro por rango de fechas

Servicios de ingestión de registro

Ejemplos de mensajes de registro

Advertencia de empresa emergente

Conexión del cliente

Operación lenta

Escape

vista

Autorización

Descargue sus registros

`systemLog` Configuración del nivel de verbosidad

`logComponentVerbosity` Parameter

`db.setLogLevel()`

Tiempo de espera de fragmentos registrados en `remoteOpWaitMillis` el campo