☰

mongodb 偶尔会记录整个文档，即使详细程度最低

tag-icon • tag-icon logging mongodb loglevel
mongodb 偶尔会记录整个文档，即使详细程度最低

我们在具有 Linux AMI 的 AWS 环境中使用 mongodb 版本 3。

最初，mongo 会记录整个文档。然后我们降低了 yaml 中的详细程度。这似乎使得大多数 (99%) 的文档不会被记录。但是，我们仍然发现它偶尔仍会记录记录。它似乎先执行 WRITE，然后执行 COMMAND，并且两者都包含整个记录。

有没有办法确保文档永远不会被写入日志，同时仍然具有有用的日志记录？

谢谢

systemLog:
  quiet: true
  destination: file
  path: /var/log/mongodb.log
  logAppend: true
  logRotate: rename
  traceAllExceptions: false
  timeStampFormat: iso8601-utc
  verbosity: 1 # This will be inherited by any component with verbosity -1
  component:
    accessControl:
      verbosity: -1 # NOTE: Negative one (-1) means "inherit"
    command:
      verbosity: 0 # MUST BE ZERO!!! Otherwise, inserted/updated records (all the data) will get logged.
    control:
      verbosity: -1
    geo:
      verbosity: 0
    index:
      verbosity: -1
    network:
      verbosity: -1
    query:
      verbosity: -1
    replication:
      verbosity: -1
    sharding:
      verbosity: 0
    storage:
      verbosity: -1
    write:
      verbosity: 0 # MUST BE ZERO!!! Otherwise, inserted/updated records (all the data) will get logged.

版本和日志如下所示。请注意，我输入了数据，因此任何无效的 json 或拼写错误都是我的错，而不是 mongo 的错。

版本 3.0.6

TIMESTAMP I WRITE [conn0001] insert project.collection query {<insert our json document here>}
ninserted:1 
keyUpdates:0
writeConflicts:0
numYields:0
locks:{Global: {acquireCount: {r: 2, w: 2}}, MMAPV1Journal: {acquireCount: {w:2},aquireWaitCount: {w:2}, 
timeAquiringMicros: {w: 119326}}, Database: {acquireCount:w: 2}}, Collection" {acquireCount: {W:1}}, oplog: {acquireCount: {w: 1}}} 119ms



TIMESTAMP I COMMAND [conn0001] insert project.$cmd command:  insert {<insert our json document here>}
ninserted:1 
keyUpdates:0
writeConflicts:0
numYields:0
reslen: 80
locks:{Global: {acquireCount: {r: 2, w: 2}}, MMAPV1Journal: {acquireCount: {w:2},aquireWaitCount: {w:2}, 
timeAquiringMicros: {w: 119326}
timeAquiringMicros: {w: 119326}}, Database: {acquireCount:w: 2}}, Collection" {acquireCount: {W:1}}, oplog: {acquireCount: {w: 1}}} 119ms

答案1

您的插入查询被记录，因为它们被视为慢速查询——比默认的查询耗时更长operationProfiling.slowOpThresholdMs值为 100ms。与 MongoDB 3.2 一样，没有任何配置来记录慢查询的详细信息，因为此上下文有助于了解查询慢的原因。

slowOpThresholdMs您可以通过在配置文件中增加来避免记录缓慢的插入/命令mongod。例如，设置更高的slowOpThresholdMs250ms 可能足以确保大多数插入不会被记录（尽管真正缓慢的插入仍可能会被记录）：

operationProfiling:
    slowOpThresholdMs: 250

如果您想确保永远不会记录缓慢的操作，您可以设置一个更高的值，但这可能会抑制与您的部署性能相关的详细信息。

有没有办法确保文档永远不会被写入日志，同时仍然具有有用的日志记录？

一般来说，用于故障排除的有用日志记录包括慢速查询的详细信息以及连接/复制/身份验证信息（您已使用quiet:true）。

如果不记录这些详细信息，您可能会难以调整和支持生产环境。

如果您担心mongod日志文件中的私人信息会被访问，我会确保您通过操作系统和文件系统权限适当限制对日志文件的访问，并加密备份或排除敏感日志文件。访问mongod服务器日志需要的权限比仅通过 shell 登录要多mongo，并且任何有权查看服务器日志的人可能也有权复制数据文件。

由于您的部署在 AWS 上，您可以考虑Amazon EBS 加密它将加密卷内静态数据、卷与实例之间移动的数据以及从卷创建的所有快照。

需要考虑的另一种选择是加密应用程序中的敏感字段，以便它们永远不会以明文形式传输、记录或保存。

有关保护部署的更多信息，请参阅MongoDB 安全检查表。

相关内容