文章转自:http://www.osyunwei.com/archives/8998.html
在实际生产中,我们知道哪些应用的日志会自动分割吗?哪些应用日志需要我们通过服务进行定时分割?接下来我们来看看。
在Tomcat的软件环境中,如果我们任由日志文件无限增长,总有一天会将磁盘占满的(废话)。特别是在日志文件增长速度很快的一些情况下,按日志切割日志文件并删除,就是一件很有必要的工作了,以下介绍了切割日志文件的方法。
Logrotate是一个日志文件管理工具,它是Linux默认自带的一个日志切割工具。用来把旧文件轮转、压缩、删除,并且创建新的日志文件。我们可以根据日志文件的大小、天数等来转储,便于对日志文件管理,一般都是通过cron计划任务来完成的,让日志切割实现按小时分割,按天分割等。
nginx的日志文件没有rotate功能 编写每天生成一个日志,我们可以写一个nginx日志切割脚本来自动切割日志文件
Logrotate 程序是一个日志文件管理工具。用于分割日志文件,压缩转存、删除旧的日志文件,并创建新的日志文件,下面就对logrotate日志轮转的记录:
nginx的日志默认是不会自动切割的,所以日志体积会越来越大,因此有必要对日志进行切割
上一片老猫和大家分享了Nginx的相关的一些概念,以及一些基础的Nginx的模型,本篇开始,和大家一起探讨一下Nginx的一些配置信息,讲清楚所以然,为什么要这么配置,这么配置有什么作用,这是本节的初衷。
在Linux中如果应用程序会产生日志,那么就需要考虑日志切割,例如按照固定的大小切割、按照日期进行切割等等。同样,在编译Nginx1.9.0、MySQL5.7.7rc和PHP7后,这三个应用服务都会产生日志,尤其是Nginx进程根据配置文件ngnix.conf记录每条访问记录到access.log中。如果所有的日志都打印到同一个文件中的话,那么时间长了的话就会影响效率。
最近在做基于openresty的waf,在测试openresty的过程中用openresty替代了原nginx,结果第二天又自动切换回了原nginx,通过ps -ef 看到nginx在凌晨3点多自动重启。连续几天在多个机器上都发现同样的情况。
CentOS 5.3中编译安装Apache日志默认是不切割的,需要用用工具Cronnolog进行日志切割。
Nginx日志默认情况下写入到一个文件中,为了区分各个域下的日志,我们一般会分开存储。即时这样,文件也会变的越来越大,非常不方便查看分析。通常我们是以每日来做统计的,下面来聊聊以日期来分隔Nginx日志。
随着每天业务的增长,Tomcat 的catalina.out日志 变得越来越大,占用磁盘空间不说。要查看某个时候的日志的时候,庞大的日志让你顿时无从下手,所以日志的切割的变得刻不容缓。而且,切割后的日志,还可以定期清理掉久远的日志。
一、前言 随着每天业务的增长,Tomcat 的catalina.out日志 变得越来越大,占用磁盘空间不说。要查看某个时候的日志的时候,庞大的日志让你顿时无从下手,所以日志的切割的变得刻不容缓。而且,切割后的日志,还可以定期清理掉久远的日志...... 二、Tomcat 日志分割 我们采用日期形式切割catalina.out 日志,因此采用cronlog 软件切割: 1、安装 cronlog yum install -y cronolog httpd 2、修改bin/catalina.sh文
对于Linux系统安全来说,日志文件是极其重要的工具。不知为何,我发现很多运维同学的服务器上都运行着一些诸如每天切分Nginx日志之类的CRON脚本,大家似乎遗忘了Logrotate,争相发明自己的轮子,这真是让人沮丧啊!就好比明明身边躺着现成的性感美女,大家却忙着自娱自乐,罪过!
我们不管在生产环境还是开发环境,看日志是必不可少的,日志中往往包含很多有用的信息,有时候被DDOS、上传非法文件等等,我们都需要通过日志分析。但是日志是跟访问量成正比的,你的访问量越大,你的各种级别日志就越多,日志文件大小会增长极快,服务器会很快消耗磁盘空间,这成个很严重的问题。不仅是这个,如果你是一个日志文件的话,你阅读、打开都要花费很大力气,那么怎么才能处理好这种情况?
Linux 系统日志 : # less /var/log/messages //是系统的一个日志(服务,系统,软件等) 此日志的配置策略是自动切割,我们使用命令可以查看到: [[email protected] ~]# ls /var/log/messages* /var/log/messages /var/log/messages-20170604 /var/log/messages-20170701 /var/log/messages-20170718 # logrotate //配置切割日志 #
对于Linux系统安全来说,日志文件是极其重要的工具。日志文件包含了关于系统中发生的事件的有用信息,在排障过程中或者系统性能分析时经常被用到。当日志文件不断增长的时候,就需要定时切割,否则,写日志的速度和性能也会下降,更不便于我们归档,查询。
date命令用法 date +%Y-%m-%d, date +%y-%m-%d 年月日 date +%H:%M:%S = date +%T 时间 date +%s 时间戳 date -d @1504620492 date -d "+1day" 一天后 date -d "-1 day" 一天前 date -d "-1 month" 一月前 date -d "-1 min" 一分钟前 date +%w, date +%W 星期 date命令用法 date命令,会显示当前系统时间日期 [root@hf-01 ~]
MongoDB 默认是不会进行切割日志的,除非我们配置了 logRotate = rename,并且重启 MongoDB 服务,才会进行切割日志的,那么为了避免实际中我们一个日志文件过大,我们需要对日志进行切割,有两个办法:
rsync还可以通过服务的方式同步,这种方式首先需要开启一个服务,服务是cs架构的,也就是客户端和服务端。服务端要开启一个rsync服务,并且需要监听一个端口,默认是873端口,这个端口是可以自定义的,然后客户端可以通过这个端口与服务端进行通信,得以传输数据。
原文:https://wsgzao.github.io/post/logrotate/
对于Linux系统安全来说,日志文件是极其重要的工具。不知为何,我发现很多运维同学的服务器上都运行着一些诸如每天切分Nginx日志之类的CRON脚本,大家似乎遗忘了Logrotate,争相发明自己的轮子,这真是让人沮丧啊!就好比明明身边躺着现成的性感美女,大家却忙着自娱自乐,罪过!logrotate程序是一个日志文件管理工具。用于分割日志文件,删除旧的日志文件,并创建新的日志文件,起到“转储”作用。可以节省磁盘空间。下面就对logrotate日志轮转操作做一梳理记录: 1)配置文件介绍 Linux系统默认安
我们都知道将一个项目部署到Tomcat之后,Tomcat服务启动后的标准输出(stdout)和标准出错(stderr)都会默认重定向到${TOMCAT_HOME}/logs/catalina.out这个文件中,有时候短短一会儿这个文件就能达到几十兆甚至上百兆,日积月累这个文件如果不及时清理将会占用服务器磁盘大量空间从而影响到整个项目的正常运行; 再者这样大日志文件对于我们进行错误排查以及日志分析都不是很方便,一次打开也花上好几分钟,直接cat命令查看也要滚掉好多屏,并且那时候想要来切割的话又异常麻烦。 所以,现在我们提前做好用日期来分割日志的配置,即Tomcat运行的每天都按照日期命名新建一个日志文件。
访问日志切割目录概要 日志一直记录总有一天会把整个磁盘占满,所以有必要让它自动切割,并删除老的日志文件 把虚拟主机配置文件改成如下: <VirtualHost *:80> DocumentRoot "/data/wwwroot/www.123.com" ServerName www.123.com ServerAlias 123.com SetEnvIf Request_URI ".*\.gif$" img SetEnvIf Request_URI ".*\.jpg$
在配置nginx的时候,默认情况下我们的日志会放到conf目录同级的文件夹logs下。由于nginx在生成日志的时候是按照文件的地址进行append的追加的,所以我们需要按照一定的规则对nginx日志进行切割,切割的好处很显然就是为了更好的查看nginx日志。否则因为日志过大,打开它都是一个问题。下图为nginx日志的一般位置。
linux系统日志 /var/log/messages //是linux系统一个总的日志——>除非某些服务,有定义单独的日志 /etc/logrotate.conf 日志切割配置文件 参考日志文件文章 dmesg命令 /var/log/dmesg 日志 last命令,调用的文件/var/log/wtmp lastb命令查看登录失败的用户,对应的文件时/var/log/btmp /var/log/secure 系统日志 /var/log/messages //是linux系统一个总
上次写到《服务器日志备份超节省空间的思路》,压缩后磁盘占用由 93%降到了 62%,效果还是不错的!为什么不直接删除呢?其实是因为这些日志涉及到支付等重要业务,保存半年以上也算是保守的做法。 今早,又发现几例磁盘空间报警,占用率都在 90%+,关键居然是根分区!这要是日志突然暴涨,把根分区撑爆了,那就可以体验到“菊花一紧”的快感了吧? 索性利用 CRT 的全局命令把磁盘空间占用率超过 75%的服务器筛选出来,打算继续进行清理磁盘空间这个枯燥的工作。结果,发现好几台 nginx 方向代理服务器的日志居然还没做
点击上方蓝色“程序猿DD”,选择“设为星标” 回复“资源”获取独家整理的学习资料! 链接:https://urlify.cn/F3Uzmi 对于 Linux 系统安全来说,日志文件是极其重要的工具。不知为何,我发现很多运维同学的服务器上都运行着一些诸如每天切分 Nginx日志之类的 CRON 脚本,大家似乎遗忘了 Logrotate,争相发明自己的轮子,这真是让人沮丧啊!就好比明明身边躺着现成的性感美女,大家却忙着自娱自乐,罪过! logrotate 程序是一个日志文件管理工具。用于分割日志文件,删除旧
说明: “combined_ realip”:日志格式名称;'$remote_ addr $http_ x_ forwarded_ for [$time_ local]' ' $host "$request_uri" $status' ' "$http_ referer" "$http_ user_ agent"' :日志内容。 注释:
nginx日志对于分析网站有极大的意义,如果我们有多个网站,这些网站又分布在不同的服务器,如何高效地分析这些nginx日志?这里有两个问题:
crond的概念和crontab是不可分割的。crontab是一个命令,常见于Unix和类Unix的操作系统之中,用于设置周期性被执行的指令。该命令从标准输入设备读取指令,并将其存放于“crontab”文件中,以供之后读取和执行
centos系统中默认安装logrotate,logrotate主配置文件:/etc/logrotate.conf,其中定义了系统默认的logrotate规则,当系统中安装了RPM 软件包时,使用include定义其子配置文件的位置:/etc/logrotate.d/*,include选项十分重要,一些应用把日志转储参数存放在/etc/logrotate.d ,典型的应用有:apache,nginx,cron,syslog等,这样,只要管理一个 /etc/logrotate.conf 文件就可以了。 使用时配合crontab定期执行logrotate命令,cron的主配置文件/etc/anacrontab中定义了crontab的默认执行规则,其中系统自带的每1天执行的cron计划配置文件放在/etc/cron.daily/目录下,在该目录下的logrotate文件内容如下:
依据客户端查询来设计集合的片键及索引,最近几天突然需要查询历史数据进行分析,我们的有些集合count达到亿条以上,每个文档几百个字段。突如其来的查询分析,数据库非常的卡,尤其这几天刚刚加入一个新的分片。前天上午来看,发现主分片竟然奔溃了,至于为什么查询量大,数据库会奔溃,需要后续进行分析。
Nginx日志切割目录概要 自定义shell 脚本 vim /usr/local/sbin/nginx_log_rotate.sh//写入如下内容 #! /bin/bash ## 假设nginx的日志存放路径为/data/logs/ d=`date -d "-1 day" +%Y%m%d` logdir="/data/logs" nginx_pid="/usr/local/nginx/logs/nginx.pid" cd $logdir for log in `ls *.log` do mv $l
转自:https://www.jianshu.com/p/9693264b3e6e
常见应用服务,都会记录日志,方便问题查询和故障定位。linux系统本身也会有日志输出。
Shell脚本,就是利用Shell的命令解释的功能,对一个纯文本的文件进行解析,然后执行这些功能,也可以说Shell脚本就是一系列命令的集合。
现有的日志都会存在access.log文件中,但是随着时间的推移,这个文件的内容会越来越多,体积会越来越大,不便于运维人员查看,所以我们可以通过把文件切割为多份不同的小文件作为日志,切割规则可以以天为单位,如果每天有几百G或者几个T的日志的话,则可以按需以每半天或者每小时对日志切割
程序执行的时候,可以通过标准输出(stdout, Standard Output)与标准错误输出 (stderr, Standard Error Output)来输送信息,用户就可以了解该程序执行时发生了什么状况;可是对于在后台执行的服务器程序,或者Linux 内核本身来说,就没有办法这样做了。服务与内核启动后,会切断与终端机(Terminal) 或控制台(Console)的联机,如此一来,即使有信息通过标准输出、标准错误输出传送出去,用户也未必能从屏幕上看到信息。
Ever since I discovered PostgreSQL allowed to embed variables in log_filename allowing to split logs without using logrotate or cronolog, I've been wanting to do the same with Nginx.
一直以来做日志切割都是使用 shell + crontab 来搞,shell 脚本可以在网上找到各种版本的,改改就用了,懒省事。这样的做法很传统,却忽略了系统的给我们提供的优秀的工具 —— logrotate。
项目名称:赛克蓝德日志分析软件 seci-log 项目简介: 赛克蓝德日志分析软件,主要对日志进行收集,格式化,然后进行分析,日志可以是系统日志,也可以是业务日志,业务日志需要二次开发。目前支持
关于日志的一些问题: 单个文件过大会影响写入效率,所以会做拆分,但是到多大拆分? 最多保留几个日志文件?最多保留多少天,要不要做压缩处理? 一般都使用 lumberjack[1]这个库完成上述这些操作
日常工作中需要对日志文件进行分析,当日志文件过大时,Linux中使用vim、cat、vim、grep、awk等这些工具对大文件日志进行分析将会成为梦魇,具体表现在:
现在nodejs在服务器上使用越来越广了,常用的框架有express、koa、eggjs等,nodejs进程管理工具是pm2。 下面就说下nodejs在实战中的日志管理
众所周知,线上如果出现事故我们通常都是查看日志去进行问题定位并且进行修复。使用好Nginx日志有利于我们线上进行修复异常问题。在Nginx中日志主要分为两种:access_log(访问日志)和error_log(错误日志)。通过查看access_log我们可以查看用户ip,浏览器信息及请求时间等信息,通过查看error_log我们可以查看线上出错的具体信息,可以帮助我们定位异常的原因。本篇文章主要带领大家详细了解Nginx如何配置日志。本文将会涉及到的日志配置指令:
领取专属 10元无门槛券
手把手带您无忧上云