数据库
首页 > 数据库> > MongoDB之Log Messages

MongoDB之Log Messages

作者：互联网

概述

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

日志格式

       从MongoDB 4.4开始，mongod / mongos实例以SON格式输出所有日志消息。日志条目被写成一系列键值对，其中每个键表示一个日志消息字段类型，比如“severity”，每个对应的值记录该字段类型的相关日志信息，比如“informational”。以前，日志条目以明文形式输出。

 

下面是MongoDB日志文件中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"}}

为了可读性，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"
  }
}

注释：

 

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

JSON日志格式输出

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

每个日志条目都输出为一个自包含的JSON对象，遵循Relaxed Extended JSON v2.0

规范，并具有以下布局和字段顺序:

{
  "t": <Datetime>, // timestamp
  "s": <String>, // severity
  "c": <String>, // component
  "ctx": <String>, // context
  "id": <Integer>, // 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)
}

注释：

 

Escaping

根据Relaxed Extended JSON v2.0规范，必要时消息和属性字段将转义控制字符:

需要转义的字符 转义字符
双引号（"） \"
反斜杠（\） \\
退格键（0x08） \b
换页（0x0C） \f
换行符（0x0A） \n
回车符（0x0D） \r
制表符（0x09） \t

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

Truncation

任何超过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}}

在这种情况下，请求属性已经被截断，它的子字段_id的特定实例触发了截断(即导致属性溢出maxLogSizeKB)被打印出来，没有数据作为{"_id":{}}。然后省略请求属性的其余部分。

包含一个或多个截断属性的日志项包含一个截断的对象，该对象为日志项中的每个截断属性提供以下信息:

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

Padding

当输出到文件或syslog日志目的地时，在严重性、上下文和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"}}}

Pretty Printing

在使用MongoDB结构化日志记录时，jq command-line utility是一个非常有用的第三方工具，它允许轻松地打印日志条目，并支持强大的基于密钥的匹配和过滤。

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

您可以使用jq对日志项进行如下的格式美化打印:

Configuring Log Message Destinations

MongoDB的日志信息可以输出为file、syslog或stdout(标准输出)。

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

如果不指定文件或syslog会将所有日志输出发送到stdout。

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

日志字段类型

Timestamp

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设置。

注意：

如果将日志记录为syslog，则syslog守护进程在记录消息时生成时间戳，而不是在MongoDB发出消息时生成时间戳。这可能会导致日志条目的时间戳具有误导性，特别是在系统负载较重的情况下。

Severity

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

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

Severity由“Fatal”(最严重)至“Debug”(最不严重):

等级 描述
F Fatal
E Error
W Warning
I Informational，详细级别为0
D1-D5

调试模式，级别>0

从4.2版开始，MongoDB指示了特定的调试详细级别。例如，详细级别为2时，MongoDB表示D2。

在以前的版本中，MongoDB日志消息为所有调试详细级别指定D。

您可以指定各种组件的详细级别，以确定MongoDB输出的信息和调试消息的数量。高于这些级别的严重性类别总是显示出来详细级别。

Components

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

每个组件都可以通过过滤器进行单独配置。可选组件如下:

 

 

 

 

 

 

 

未完成，待更新！！！

 

参考官网文档：Log Messages

标签：00,Log,MongoDB,Messages,component,组件,日志,id
来源： https://www.cnblogs.com/haha029/p/16107009.html