日志消息

在本页面

作为正常操作的一部分，MongoDB维护事件的运行日志，包括传入的连接、运行的命令和遇到的问题等条目。通常，日志消息对于诊断问题、监视部署和调优性能非常有用。

结构化日志

在MongoDB 4.4开始,mongod /mongos实例中所有日志消息输出结构化的JSON格式。日志条目以一系列键值对的形式写入，其中每个键表示一个日志消息字段类型，比如“severity”，而每个对应的值记录该字段类型的相关日志信息，比如“information”。以前，日志条目是以明文输出的。

例子

以下是一个示例日志消息在JSON格式，因为它将出现在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"}}

JSON日志条目可以完美打印以提高可读性。下面是相同的日志条目，打印得很整洁:

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

例如，在这个日志条目中，代表严重性的键s具有相应的值I，表示severity，而表示component的键c具有相应的值NETWORK，表示“网络”组件负责该特定消息。日志消息字段类型部分详细介绍了各种字段类型。

具有键值对的结构化日志记录允许通过自动化工具或日志摄入量服务进行高效解析，并使日志消息的编程搜索和分析更容易执行。分析结构化日志消息的示例可以在解析结构化日志消息小节中找到。

JSON日志输出格式

在MongoDB 4.4中，所有日志输出现在都是JSON格式。这包括日志输出文件发送到 syslog 和 stdout (标准输出)log destinations,以及getLog的输出命令。

每个日志条目作为一个自包含的JSON对象输出，遵循放宽扩展JSON v2.0规范，并有以下布局和字段顺序:

{
  "t": <Datetime>, // timestamp
  "s": <String>, // severity
  "c": <String>, // component
  "ctx": <String>, // context
  "id": <String>, // unique identifier
  "msg": <String>, // message body
  "attr": <Object> // additional attributes (optional)
  "tags": <Array of strings> // tags (optional)
  "truncated": <Object> // truncation info (if truncated)
  "size": <Integer> // original size of entry (if truncated)
}
  • 时间戳 - 日志消息的时间戳，ISO-8601格式。参见时间戳。
  • 严重程度 - 表示日志消息的不足严重性代码的字符串。参见严重性。
  • 组件 - 表示日志消息的完整组件字符串的字符串。参见组件。
  • 上下文 - 表示发出日志语句的线程的名称的字符串。
  • id - 表示日志语句的唯一标识符的字符串。参见根据已知日志ID进行过滤以获得一个示例。
  • 消息 - 表示从服务器或驱动程序传递的原始日志输出消息的字符串。该消息根据JSON规范根据需要进行转义。
  • 属性 -(可选)对象，其中包含一个或多个键值对，用于提供任何附加属性。如果日志消息不包含任何附加属性，则省略此对象。属性值可以在消息正文中通过其键名引用，具体取决于消息。与message类似，属性根据JSON规范根据需要进行转义。
  • 标签 - (可选)字符串数组，表示适用于日志语句的任何标记，例如:[startupWarnings]。
  • 截断 - （如果被截断）对象，包含有关日志消息截断的信息（如果适用）。仅当日志条目包含至少一个被截断的属性时，此对象才会存在。

  • 大小 - (如果被截断)整数，表示已被 截断的日志条目的原始大小。只有当日志条目包含至少一个被截断的属性时，该字段才会出现。

    转译

根据放宽扩展JSON v2.0规范，message和属性字段将根据需要转译控制字符:

字符表示 转义序列
引号(") \"
反斜杠 (\) \\
回退 (0x08) \b
跳页 (0x0C) \f
换行符 (0x0A) \n
回车 (0x0D) \r
水平选项卡 (0x09) \t

上面没有列出的控制字符用 \uXXXX 转义，其中 XXXX 是十六进制的unicode码点。UTF-8编码无效的字节被替换为 \ufffd 表示的unicode替换字符。

examples提供了一个消息转译的示例。

截断

任何超过maxLogSizeKB定义的最大大小的属性(默认为10kb)被截断。被截断的属性省略了超出配置限制的日志数据，但是保留了条目的JSON格式，以确保条目仍然可解析。

下面是一个带有截断属性的日志条目示例:

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

In this case, the request attribute has been truncated and the specific instance of its subfield _id that triggered truncation (i.e. caused the attribute to overrun maxLogSizeKB) is printed without data as {"_id":{}}. The remainder of the request attribute is then omitted.

在本例中，request属性被截断，其子字段_id的特定实例触发了截断(即导致属性溢出maxLogSizeKB)被打印为{"_id":{}}，没有数据。然后省略request属性的其余部分。

包含一个或多个截断属性的日志实体包括一个truncated对象，该对象为日志条目中的每个截断属性提供以下信息:

  • 被截断的属性
  • 触发截断的属性的特定子对象(如果适用)
  • 截断字段的数据类型
  • 截断字段的大小

Log entries with truncated attributes may also include an additional size field at the end of the entry which indicates the original size of the attribute before truncation, in this case 46328 or about 46KB. This final size field is only shown if it is different from the size field in the truncated object, i.e. if the total object size of the attribute is different from the size of the truncated subobject, as is the case in the example above.

属性被截断的日志条目还可能在条目的末尾包含一个额外的size字段，该字段表示截断之前属性的原始大小，在本例中为46328或大约46KB。最后的size字段只在与truncated对象中的size字段不同的情况下显示，也就是说，如果属性的对象总大小与被截断的子对象的大小不同，就像上面的例子一样。

填充

当输出到file或syslog log目的地时，在severity、context和id字段之后添加填充，以增加固定宽度字体时的可读性。

下面的MongoDB日志文件摘录演示了这种填充:

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

完美的印刷

当使用MongoDB结构化日志时，jq命令行实用程序是一个非常有用的工具，它允许轻松地打印日志条目，以及强大的基于密钥的匹配和过滤。

jq是一个开源的JSON解析器，可用于Linux、Windows和macOS。

您可以使用jq来编辑打印日志内容，如下所示:

  • 完整打印日志文件:

    cat mongod.log | jq

  • 完美地打印最近的日志条目:

    cat mongod.log | tail -1 | jq

更多使用MongoDB结构化日志的例子可以在解析结构化日志消息小节中找到。

配置日志消息目的地

MongoDB日志消息可以输出到file、syslog或stdout(标准输出)。

要配置日志输出目的地，使用以下设置之一，要么在配置文件或在命令行:

配置文件:

命令行:

不指定file或syslog将把所有日志输出发送到stdout。

有关日志设置和选项的完整列表，请参阅:

配置文件:

命令行:

  • 为 mongod的日志选项列表
  • 为mongos的日志选项列表

注意

Error messages sent to stderr (standard error), such as fatal errors during startup when not using the file or syslog log destinations, or messages having to do with misconfigured logging settings, are not affected by the log output destination setting, and are printed to stderr in plaintext format.

发送到stderr的错误消息(标准错误)，比如在启动时没有使用file或syslog日志目的地时发生的致命错误，或者与日志设置配置错误有关的消息，不受日志输出目的地设置的影响，并以明文格式打印到stderr。

日志消息字段类型

时间戳

timestamp字段类型表示所记录事件发生的确切日期和时间。

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

当登录到file或syslog时，时间戳的默认格式是iso8601-local。修改时间戳格式,使用--timeStampFormat运行时选项或systemLog.timeStampFormat设置。

请参见按日期范围过滤，了解在时间戳字段上过滤的日志解析示例。

注意

从MongoDB 4.4开始，不再支持“ctime”时间戳格式。

严重程度

严重性字段类型指示与日志事件关联的严重性级别。

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

严重级别从“致命”(最严重)到“调试”(最不严重):

标准 Description
F Fatal
E Error
W Warning
I 信息性，用于详细程度级别0
D1 - D5 从4.2版本开始，MongoDB指出了特定的调试详细级别。例如，如果冗余级别为2,MongoDB表示“D2”。
在以前的版本中，MongoDB日志消息为所有调试冗长级别指定 D。

您可以指定各个组件的冗余级别，以确定MongoDB输出的信息和调试消息的数量。这些级别以上的严重性类别总是显示出来。设置详细级别，请参见配置日志详细级别。

组件

组件字段类型指示日志事件所属的类别，如NETWORK或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"
  }
}

每个组件都可以通过其自己的verbosity过滤器进行单独配置。可提供的组件如下:

MongoDB驱动程序和客户端应用程序(包括mongo shell)有能力在连接到服务器的时候发送识别信息。连接建立后，客户端不会再次发送标识信息，除非连接被删除并重新建立。

该标识信息包含在日志条目的attributes字段中。所包括的确切信息因客户端而异。

下面是一个示例日志消息，包含从一个mongo shell连接传输的客户端数据文档。客户端数据包含在 doc 对象的属性字段中:

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

当replica set的次要成员初始化到主节点的连接时，它们发送类似的数据。包含此启动连接的日志消息示例如下所示。客户端数据包含在 doc 对象的属性字段中:

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

参见示例部分以获得一个显示客户端数据的格式打印示例。

有关客户端信息和必需字段的完整描述，请参见MongoDB握手规范。

详细程度

您可以指定日志记录冗余级别，以增加或减少MongoDB输出的日志消息数量。可以针对所有组件一起调整详细级别，也可以针对特定的已命名组件单独调整详细级别。

详细程度只影响severity类别information和Debug中的日志名称。这些级别以上的严重性类别总是显示出来。

您可以将冗余级别设置为高值，以显示用于调试或开发的详细日志记录，或设置为低值，以尽量减少对经过审查的生产部署上的日志的写操作。

查看当前日志的详细程度

要查看当前的详细级别，使用db.getLogComponents()方法:

db.getLogComponents()

您的输出可能类似如下:

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

最初的冗长为所有组件条目父冗长水平,而个人命名组件,如accessControl,指示组件的特定详细级别,覆盖全球冗长的水平如果设置特定的组件。

值-1表示，如果组件有父组件的冗余级别(与上面的recovery一样，从storage继承)，则组件继承父组件的冗余级别，如果没有，则继承全局冗余级别(与command一样)。详细级别的继承关系在components部分中指明。

配置日志冗余级别

您可以配置使用冗长水平:systemLog.verbosity和 systemLog.component.<name>.verbosity 设置,logComponentVerbosity的参数,或db.setLogLevel()方法。

systemLog冗长的设置

要为所有组件配置默认的日志级别，使用systemLog.verbosity设置。要配置特定组件的级别，请使用 systemLog.component.<name>.verbosity 设置。

例如,下面的配置设置 systemLog.verbosity 冗长1,在systemLog.component.query.verbosity冗长2, systemLog.component.storage.verbosity冗长 2,和systemLog.component.storage.journal.verbosity到1:

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

你会设置这些值配置文件或在命令行上为你的mongod或mongos实例。

所有组件未指定明确的配置有一个冗长的1,表明他们继承冗长的父级,如果他们有一个,或全球冗长级别(systemLog.verbosity)如果他们不这样做。

logComponentVerbosity参数

要设置logComponentVerbosity参数，需要传递一个文档，其中包含要更改的冗长设置。

For example, the following sets the default verbosity level to 1, the query to 2, the storage to 2, and the storage.journal to 1.

例如,下面的设置默认的详细级别 冗长1,在‘查询’冗长2,storage冗长2 ,和storage.journal到1。

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

您可以从mongoshell中设置这些值。

db.setLogLevel()

使用db.setLogLevel()方法更新单个组件日志级别。对于组件，可以指定0到5的冗余级别，也可以指定-1来继承父组件的冗余。例如，下面将systemLog.component.query.verbosity设置为其父级的冗长(即默认冗长):

db.setLogLevel(-1, "query")

您可以从mongoshell中设置该值。

日志记录操作缓慢

客户操作(例如查询)出现在日志如果他们的持续时间超过缓慢操作阈值或者日志详细级别是1或更高。这些日志条目包括与操作关联的完整命令对象。

从MongoDB 4.2开始，用于读/写操作的profiler条目和诊断日志消息(即mongod/mongos日志消息)包括:

下面的示例输出包含一个缓慢的聚合操作的信息:

{"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.0,"price":1.0,"priceGTE110":{"$gte":["$price",110.0]},"_id":0.0}},{"$sort":{"price":-1.0}}],"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":1912190691485054730,"keysExamined":0,"docsExamined":1000001,"hasSortStage":true,"usedDisk":true,"numYields":1002,"nreturned":101,"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}},"protocol":"op_msg","durationMillis":22427}}

参见examples部分，以获得该日志条目的pretty- printing版本。

解析结构化日志消息

日志解析是通过编程方式搜索和分析日志文件的行为，通常采用自动化的方式。随着MongoDB 4.4中结构化日志的引入，日志解析变得更加简单和强大。例如:

  • 日志消息字段以键值对的形式显示。日志解析器可以根据感兴趣的特定键进行查询，从而有效地筛选结果。
  • 日志消息总是包含相同的消息结构。日志解析器可以可靠地从任何日志消息中提取信息，而不需要为信息丢失或格式不同的情况编写代码。

下面的示例演示使用MongoDB JSON日志输出时常见的日志解析工作流。

日志解析的例子

当使用MongoDB结构化日志时，jq命令行实用程序是一个非常有用的工具，它允许轻松地打印日志条目，以及强大的基于密钥的匹配和过滤。

jq是一个开源的JSON解析器，可用于Linux、Windows和macOS。

这些示例使用jq来简化日志解析。

计数独特的消息

下面的示例显示了给定日志文件中按频率排序的前10个唯一消息值:

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

监视连接

远程客户端连接显示在属性对象的“Remote”键下的日志中。下面将计算整个日志文件过程中的所有唯一连接，并按出现次数降序显示它们:

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

请注意，来自相同IP地址但通过不同端口连接的连接将被此命令视为不同的连接。您可以限制输出仅考虑IP地址，如下更改:

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

分析客户类型

下面的例子分析报告客户端数据 log-messages-client-data远程MongoDB驱动连接的客户机应用程序,包括 mongo shell,并打印每个独特的操作系统类型,总联系,按频率:

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

这个日志字段中报告的字符串“Darwin”表示macOS客户机。

慢速查询分析

启用了慢操作日志，下面只返回耗时超过2000毫秒的慢操作:，供进一步分析:

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

查阅jq文档以获得更多关于本例中显示的jq过滤器的信息。

过滤已知的日志ID

日志id (JSON日志输出格式中的第5个字段)映射到特定的日志事件，可以依赖它在后续的MongoDB版本中保持稳定。

例如，您可能对以下两个日志事件感兴趣，它们显示了客户机连接后断开连接:

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

这两个实体的日志id分别是22943和22944。然后，您可以过滤日志输出，只显示这些日志id，有效地只显示客户端连接活动，使用以下jq语法:

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

查阅jq文档以获得更多关于本例中显示的jq过滤器的信息。

日期范围过滤

通过过滤timestamp字段，限制返回到特定日期范围的日志记录，可以进一步细化日志输出。例如，下面返回发生在2020年4月15日的所有日志条目:

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

注意，该语法包含完整的时间戳，包括毫秒，但不包括时区偏移量。

按日期范围进行筛选可以与上面的任何示例结合使用，例如创建周报告或年度摘要。下面的语法扩展了“监视连接”示例，将结果限制在2020年5月:

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

查阅jq文档以获得更多关于本例中显示的jq过滤器的信息。

日志摄入服务

日志摄取服务是接收和聚合日志文件(通常来自分布式系统集群)的第三方产品，并在中心位置提供对该数据的持续分析。

JSON日志格式，在MongoDB 4.4中引入，在处理日志接收和分析服务时允许更大的灵活性。纯文本日志通常需要某种转换方式才能与这些产品一起使用，而JSON文件通常可以开箱即用，这取决于服务。此外，在对这些服务执行过滤时，json格式的日志提供了更多的控制，因为键-值结构提供了仅具体导入感兴趣的字段，而忽略其他字段的能力。

有关更多信息，请参阅您所选择的第三方日志摄取服务的文档。

日志消息事例

下面的示例展示了JSON输出格式的日志消息。

为了方便起见，这些日志消息以完美打印格式的形式呈现。

启动预警

这个例子显示了一个启动警告:

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

客户端连接

这个例子显示了一个客户端连接，它包含了客户端数据:

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

缓慢操作

这个例子显示了一个慢速操作消息:

{
  "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,
    "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
      }
    },
    "protocol": "op_msg",
    "durationMillis": 22427
  }
}

转义

这个例子演示了字符转义，如属性对象的 setName 字段所示:

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

参见

原文 - Log Messages

Copyright © 上海锦木信息技术有限公司 all right reserved，powered by Gitbook文件修订时间： 2023-09-01 17:10:26

results matching ""

    No results matching ""