Ubuntu MongoDB日志管理技巧分享

Ubuntu 上 MongoDB 日志管理实用技巧

一 日志位置与快速查看

• 默认路径与配置文件
  • 日志目录：/var/log/mongodb/（常见文件：mongod.log）
  • 数据目录：/var/lib/mongodb/
  • 可执行文件：/usr/bin/mongod
  • 配置文件：/etc/mongod.conf
• 实时查看与基础过滤
  • 实时跟踪：tail -f /var/log/mongodb/mongod.log
  • 仅看错误与致命：grep -E 'E|F' /var/log/mongodb/mongod.log
  • 按时间窗口过滤（示例）：grep -E 'E|F' /var/log/mongodb/mongod.log | awk '$1 > "2025-08-20T14:00"'
    以上路径与命令适用于常见 Ubuntu + MongoDB 部署场景，便于快速定位问题。

二 日志轮转的三种方式

• 方式一 MongoDB 内置命令或信号
  • 在 mongo shell 中执行：db.adminCommand({ logRotate: "server" } )（可单独轮转审计日志：{ logRotate: "audit" } ）
  • 向进程发送信号：kill -SIGUSR1 $(cat /var/log/mongodb/mongod.lock)（按实际 lock 文件路径调整）
• 方式二 配置 logRotate=reopen 与系统 logrotate 配合
  • 配置示例（/etc/mongod.conf）：

    systemLog:
      destination: file
      path: /var/log/mongodb/mongod.log
      logAppend: true
      logRotate: reopen
    

  • 创建 /etc/logrotate.d/mongodb：

    /var/log/mongodb/mongod.log {
        
      daily
      rotate 7
      compress
      missingok
      notifempty
      sharedscripts
      postrotate
        if pgrep mongod >
        /dev/null;
         then
          systemctl kill --signal=SIGUSR1 mongod 2>
        /dev/null || \
          /bin/kill -SIGUSR1 $(cat /var/log/mongodb/mongod.lock 2>
    /dev/null)
        fi
      endscript
    }
    
    

• 方式三 使用 copytruncate（无需信号，但注意短暂锁与截断风险）
  • 在 /etc/logrotate.d/mongodb 中使用 copytruncate 替代 postrotate 发送信号的逻辑，适合无法使用信号的环境。
    以上三种方式覆盖了手动、内置与系统工具的主流实践，生产环境推荐“内置命令或信号”与“logrotate+reopen”的组合使用。

三 日志级别与组件控制

• 动态调节全局日志级别：db.setLogLevel(1)（数值越大越详细，便于临时排障）
• 查看与调整组件日志：db.getLogComponents()（按需开启更细粒度的组件日志，减少噪声）
• 慢查询阈值示例：mongod --setParameter slowMS=100（将阈值设为 100ms，配合应用侧抓取长耗时操作）
  通过组件级与全局级别的配合，可以在不影响性能的前提下获取关键线索。

四 常见异常模式与定位要点

• 连接风暴与文件描述符不足
  • 日志特征：W NETWORK [threadmongod] Too many open files (96% threshold)
  • 处理：检查 ulimit -n，在 /etc/security/limits.conf 为 mongod 提升上限（如 soft/hard 至 64000）
• 查询性能瓶颈（全表扫描）
  • 日志特征：COLLSCAN、keysExamined:0、docsExamined 很大
  • 处理：建立合适索引（如 db.users.createIndex({ age:1} )），并优化查询条件
• 副本集心跳异常
  • 日志特征：E REPL [replication] heartbeat failed to secondary2:27017
  • 处理：先做网络连通性测试，再检查副本集状态与 Oplog 窗口，必要时安排重新同步
• 存储引擎异常
  • 日志特征：F STORAGE [WT-Thread] WiredTiger error: 31802
  • 处理：用 db.serverStatus().storageEngine 核验引擎状态，必要时执行修复流程（如 --repair，务必先做好完整备份）
    以上模式与处置路径可快速缩小排查范围，优先处理 F 级错误，建立 W 级告警基线。

五 分析与归档工具链

• 命令行与可视化
  • 使用 mtools 做筛选与可视化：mlogfilter ... --slow 60000、mplotqueries ...
  • 使用 jq 做结构化分析（示例）：jq '. | select(.attr.durationMillis > = 6000)' replsvr.log
  • 将日志接入 Elastic Stack（ELK），在 Kibana 构建仪表盘，做趋势与异常聚合
• 归档与清理
  • 按天轮转并压缩旧日志，保留 7–30 天；结合 find ... -mtime +N -delete 或 logrotate 的 rotate N 策略自动清理
  • 审计日志与服务器日志可分别配置轮转策略，避免相互影响
    工具化分析能显著提升定位效率，长期建议引入集中式日志平台做可观测性建设。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！