MongoDB运行日志实现自动分割的方法实例

前言

其实所谓自动分割MongoDB日志文件,就是指Rotate MongoDB log files,即让MongoDB每天(或每个星期,可自定义控制)生成一个日志文件,而不是将MongoDB所有的运行日志都放置在一个文件中,这样每个日志文件都相对较小,定位问题也更容易。

实现自动分割MongoDB日志的方法可以参考:https://docs.mongodb.com/manual/tutorial/rotate-log-files/

现在以一个MongoDB实例为例,可以写一个脚本来实现自动分割MongoDB日志

1、配置MongoDB实例启动参数

security:
 keyFile: /usr/local/mongodb/authentication/keyFile
sharding:
 clusterRole: shardsvr
replication:
 replSetName: rs3
net:
 port: 27023
storage:
 dbPath: /data/db_delay_rs3
systemLog:
 path: /data/log_delay_rs3/mongodb.log
 destination: file
 logAppend: true
 logRotate: rename
processManagement:
 fork: true 

配置MongoDB系统日志保存路径,并配置logRotate参数为rename

2、编写自动分割MongoDB日志脚本

#!/bin/bash
#Rotate the MongoDB logs to prevent a single logfile from consuming too much disk space. 

app=mongod 

mongodPath=/usr/local/mongodb/bin/ 

pidArray=$(pidof $mongodPath/$app) 

for pid in $pidArray;do
if [ $pid ]
then
 kill -SIGUSR1 $pid
fi
done 

exit 

:wq保存,并命名为logRotate.sh,保存到目录/data/logRotate/

3、设置Linux定时任务

vi /etc/crontab

在打开的文件底部添加如下内容

59 23 * * * root /data/logRotate/logRotate.sh 

:wq保存,表示配置一个定时任务,定时每天23:59以root身份执行脚本/data/logRotate/logRotate.sh,实现定时自动分割MongoDB日志

至此,就实现了自动分割MongoDB日志,MongoDB每天都会生成一个新的日志文件,日志文件的命名带有标识文件日期的时间戳。

如下所示:

mongodb.log  mongodb.log.2016-12-08T15-59-01 mongodb.log.2016-12-13T15-59-01
mongodb.log.2016-12-06T07-14-10 mongodb.log.2016-12-09T15-59-01 mongodb.log.2016-12-14T15-59-01
mongodb.log.2016-12-06T15-59-01 mongodb.log.2016-12-10T15-59-01 mongodb.log.2016-12-15T15-59-01
mongodb.log.2016-12-07T01-54-05 mongodb.log.2016-12-11T15-59-01 mongodb.log.2016-12-16T15-59-01
mongodb.log.2016-12-07T15-59-01 mongodb.log.2016-12-12T15-59-01

总结

以上就是关于MongoDB运行日志自动分割的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流。

(0)

相关推荐

  • nginx访问日志并删除指定天数前的日志记录配置方法

    说明: 操作系统:CentOS 站点1:bbs.jb51.net 站点2:sns.jb51.net Nginx安装路径:/usr/local/nginx Nginx配置文件路径:/usr/local/nginx/conf/nginx.conf 站点1配置文件路径:/usr/local/nginx/conf/vhost/bbs.jb51.net.conf 站点2配置文件路径:/usr/local/nginx/conf/vhost/sns.jb51.net.conf 目的: 1.对站点1和站点2的n

  • 实现Nginx中使用PHP-FPM时记录PHP错误日志的配置方法

    nginx与apache不一样,在apache中可以直接指定php的错误日志,那样在php执行中的错误信息就直接输入到php的错误日志中,可以方便查询. 在nginx中事情就变成了这样:nginx只对页面的访问做access记录日志.不会有php的error log 信息.nginx把对php的请求发给php-fpm fastcgi进程来处理,默认的php-fpm只会输出php-fpm的错误信息,在php-fpm的errors log里也看不到php的errorlog. 原因是php-fpm的配

  • nginx php-fpm中启用慢日志配置(用于检测执行较慢的PHP脚本)

    很多站长转到nginx+php-fpm后,饱受500,502问题困扰.当nginx收到如上错误码时,可以确定后端php-fpm解析php出了某种问题,比如,执行错误,执行超时. php-fpm.conf的配置文件中有一个参数request_slowlog_timeout是这样描述的 复制代码 代码如下: ; The timeout for serving a single request after which a PHP backtrace will be; dumped to the 'sl

  • Node.js和MongoDB实现简单日志分析系统

    在最近的项目中,为了便于分析把项目的日志都存成了JSON格式.之前日志直接存在了文件中,而MongoDB适时闯入了我的视线,于是就把log存进了MongoDB中.log只存起来是没有意义的,最关键的是要从日志中发现业务的趋势.系统的性能漏洞等.之前有一个用Java写的分析模块,运行在Tomcat下.实现相当的重量级,添加一个新指标的流程也比较繁琐,而且由于NFS的原因还导致分析失败.一直想改写,最初想用Ruby On Rails,可是一直没有时间学习和开发(在找借口啊!).在杭州QCon 201

  • MongoDB日志文件过大的解决方法

    MongoDB的日志文件在设置 logappend=true 的情况下,会不断向同一日志文件追加的,时间长了,自然变得非常大. 解决如下:(特别注意:启动的时候必须是--logpath指定了log路径的) 用mongo连接到服务端 复制代码 代码如下: use admin  //切换到admin数据库 db.runCommand({logRotate:1}) 这样会使mongo关闭当前日志文件,重启一个新的日志文件,不需要停止mongodb服务.

  • nginx日志配置指令详解

    日志对于统计排错来说非常有利的.本文总结了nginx日志相关的配置如access_log.log_format.open_log_file_cache.log_not_found.log_subrequest.rewrite_log.error_log. nginx有一个非常灵活的日志记录模式.每个级别的配置可以有各自独立的访问日志.日志格式通过log_format命令来定义.ngx_http_log_module是用来定义请求日志格式的. 1. access_log指令 语法: access_

  • 使用MongoDB分析Nginx日志的方法详解

    本文我们要从日志文件中找出IP访问最多的10条记录,然后判断其是否合法,从而采取对应的措施.感兴趣的朋友们一起来看看吧. 日志解析流程 正常情况下,关于Nginx日志解析的流程如下所示: 一般情况下我们会对要解析的日志提前进行切分,常用的方式是按照日期,然后保存1个星期的日志.然后接下来就是日志的解析了,在这个过程中会使用到一些工具或编程语言,例如awk.grep.perl.python. 最后的入库和可视化处理一般视业务而定,没有强制的要求. 日志查询的解决方案 而关于Nginx日志解析的常用

  • Python 分析Nginx访问日志并保存到MySQL数据库实例

    使用Python 分析Nginx access 日志,根据Nginx日志格式进行分割并存入MySQL数据库.一.Nginx access日志格式如下: 复制代码 代码如下: $remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_f

  • nginx日志切割shell脚本

    一.脚本思路 第一步就是重命名日志文件,不用担心重命名后nginx找不到日志文件而丢失日志.在你未重新打开原名字的日志文件前,nginx还是会向你重命名的文件写日志,linux是靠文件描述符而不是文件名定位文件. 第二步向nginx主进程发送USR1信号. nginx主进程接到信号后会从配置文件中读取日志文件名称,重新打开日志文件(以配置文件中的日志名称命名),并以工作进程的用户作为日志文件的所有者. 重新打开日志文件后,nginx主进程会关闭重名的日志文件并通知工作进程使用新打开的日志文件.

  • Linux服务器nginx访问日志里出现大量http 400错误的请求分析

    服务器中的错误记录类似于这种: 124.65.133.242 – – [27/Oct/2014:14:30:51 +0800] "-" 400 0 "-" "-" 124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] "-" 400 0 "-" "-" 124.65.133.242 – – [27/Oct/2014:14:31:45 +0800]

随机推荐