日志系统rsync和日志切割logrotate-Linux每日一练(9)
共 4233字,需浏览 9分钟
·
2020-09-27 01:12
上一节留的问题本来是网络的,但是我还是打算把网络留到最后一次来更新,因为我任性~
我发现了一些公众号大号整天转发垃圾文章引发焦虑,让看得人怀疑自己,读者越是焦虑他们就越是开心,方便做广告卖课程,赚钱也没错,卖广告也是为了恰饭,但是一周推两三次广告谁能受得了啊。
说真的,买课程的人大多也看不完,就是买个安心,买了就相当于学了,然后继续心安理得的玩,其实现在的线上课程完课率只有不到10%,想想我买了那么多极客时间实际上看完的也只有部分,酌情安排自己的时间才是王道。
扯远了,步入正题,Linux自带的 日志系统rsync
日志系统rsync
Linux日志机制的核心是 rsyslog
守护进程,该服务负责监听Linux下的日志信息,并把日志信息追加到对应的日志文件中,一般在 /var/log
目录下。
它还可以把日志信息通过网络协议发送到另一台Linux服务器上,或者将日志存储在 MySQL
或 Oracle
等数据库中。
对于日志收集,基本所有人都听说过 ELK(ElasticSearch+Logstash+Kibana)的大名,其实所有的 Linux
日志管理系统都基于 rsyslog
,他们配置的第一步都是配置 rsyslog
发送端。
所以我们只要对这个服务进行简单配置,就可以把线上环境的日志集中化收集起来,不仅方便开发调试;还避免了直接到线上环境查看,发生安全隐患。
启动停止
在centOS5及更早版本中使用的是 syslog
, rsyslog
是 syslog
的增强版本。rsyslog
一般默认都会安装且设置为自动启动
$ ps -ef |grep rsyslogd
root 923 1 0 Aug21 ? 00:03:02 /usr/sbin/rsyslogd -n
$ /etc/init.d/rsyslog start
$ /etc/init.d/rsyslog stop
$ /etc/init.d/rsyslog restart
配置文件写法
可以参考官网:https://www.rsyslog.com/doc/master/configuration/basic_structure.html
执行文件:/sbin/rsyslogd
主配置文件: /etc/rsyslog.conf
自定义配置文件: /etc/rsyslog.d/*.conf
修改配置文件后,重启服务:sudo /etc/init.d/rsyslog restart
一份配置文件主要包括以下几个部分:MODULES
、 RULES
、全局指令,模板,模块参数等,回头有机会讲解 ELK
的时候再展开,这里只用关心 RULES
, 他表达了三个信息,只要全部满足就可以完成日志输出。
在 rsyslog.conf
文件里找如下格式内容,代表含义为:什么服务. 日志等级、输出到哪里
mail.info /var/log/maillog_info
我们自己写的程序根本没有必要使用rsyslog来自定义输出日志(个人理解,有误请指出),因为我们会用自己的日志组件输出的应该输出的位置。这里了解下日志设施有哪些即可,你可以去看这个配置文件知道这些日志被输出到哪里了,方便运维和定位问题。
日志设施有:
auth(security), authpriv: 授权和安全相关的消息 kern: 来自Linux内核的消息 mail: 由mail子系统产生的消息 cron: cron守护进程相关的信息 daemon: 守护进程产生的信息 news: 网络消息子系统 lpr: 打印相关的日志信息 user: 用户进程相关的信息 local0 to local7: 保留,本地使用
日志级别有(升序):
debug:包含详细的开发情报的信息,通常只在调试一个程序时使用。 info:情报信息,正常的系统消息,比如骚扰报告,带宽数据等,不需要处理。 notice:不是错误情况,也不需要立即处理。 warning:警告信息,不是错误,比如系统磁盘使用了85%等。 err:错误,不是非常紧急,在一定时间内修复即可。 crit:重要情况,如硬盘错误,备用连接丢失。 alert:应该被立即改正的问题,如系统数据库被破坏,ISP连接丢失。 emerg:紧急情况,需要立即通知技术人员。
例如:把所有来自cron守护进程的消息保存到/var/log/cron文件中。当指定日志级别时,所有等于或大于该日志等级的信息都要被处理。
cron.* /var/log/cron
日志切割
日积月累日志会越来越大,直到撑爆你的磁盘,历史日志就没有必要保留了,最好永远只保留近期的日志,超过某个大小或者某段保留时间的日志自动删除。
在 python
的日志组件中支持日志滚动,可以规定每个日志文件有多大,保留多少个文件;也可以规定保留几天内的日志。在 Linux
里面也有类似的组件,也是自带的:logrotate
,他本身是通过计划任务读取配置定时执行的。
呐,这就是 Linux
定时任务涉及的目录,下面的脚本会按文件名写的时间定时执行。
/etc/cron.daily:
logrotate man-db.cron mlocate
/etc/cron.hourly:
0anacron
/etc/cron.monthly:
/etc/cron.weekly:
可以看到 logrotate
在 cron.daily
下面,内容使用到了 logrotate.conf
配置文件,这个配置文件记录了日志滚动规则的全局配置,你可以手动执行下面这个脚本来手动轮转日志。
$ cat /etc/cron.daily/logrotate
#!/bin/sh
/usr/sbin/logrotate -s /var/lib/logrotate/logrotate.status /etc/logrotate.conf
....
需要注意的是这几项全局配置,一般是无须改动的,可以打开日志压缩减少空间占用
$ cat /etc/logrotate.conf
weekly //轮转的周期,一周轮转
rotate 4 //保留4份
create //轮转后创建新文件
dateext //使用日期作为后缀
#compress //是否压缩
include /etc/logrotate.d //包含该目录下的文件
日志轮转配置
假如你的服务本身不支持日志轮转,可以在/etc/logrotate.d
下新增任意名称的文件实现配置,举个例子。
$ vim /etc/logrotate.d/log-file
/var/log/log-file {
monthly
rotate 5
compress
delaycompress
missingok
notifempty
create 644 root root
postrotate
/usr/bin/killall -HUP rsyslogd
endscript
}
上面的模板是通用的,而配置参数则根据你的需求进行调整,不是所有的参数都是必要的。也可以通过man手册中的例子进行配置。
monthly 每月一次,也可以改成'daily','weekly'或者'yearly' rotate 5 保留5个日志,超过删除最老的 compress 已轮循的用gzip压缩 delaycompress 一般和compress选项一起用,最近的归档不压缩,方便查看。 missingok 在日志轮循期间忽略错误 notifempty 如果日志文件为空,轮循不会进行。 create 644 root root 以指定的权限创建全新的日志文件,同时logrotate也会重命名原始日志文件。 postrotate/endscript 在所有其它指令执行完后,中间包含的命令会被执行。在这种情况下,rsyslogd 进程将立即再次读取其配置并继续运行。也可以包含一些提醒服务重新读取配置的命令
以上信息来源 "man logrotate"
手动执行与日志验证
可以这样手动执行
logrotate /etc/logrotate.conf
也可以单独切割某个日志
logrotate -vf /etc/logrotate.d/log-file
logrotate
本身的日志位于
cat /var/lib/logrotate/logrotate.status
logrotate state -- version 2
"/var/log/yum.log" 2020-1-1-3:48:1
"/var/log/boot.log" 2020-8-22-3:17:1
"/var/log/chrony/*.log" 2019-12-21-12:0:0
"/var/log/wtmp" 2019-12-21-12:0:0
"/var/log/spooler" 2019-12-21-12:0:0
"/var/log/btmp" 2020-9-1-3:16:1
"/var/log/maillog" 2019-12-21-12:0:0
"/var/log/wpa_supplicant.log" 2019-12-21-12:0:0
"/var/log/secure" 2020-8-11-3:47:1
"/var/log/messages" 2020-8-26-3:16:1
"/var/log/cron" 2020-8-13-3:19:1
引用
https://blog.csdn.net/qq_29344757/article/details/86700898 https://medium.com/pizzas/rsyslog%E4%BB%8B%E7%B4%B9%E8%88%87%E4%BD%BF%E7%94%A8-cfb36497092d https://www.cnblogs.com/sunsky303/p/7677370.html https://www.jianshu.com/p/e129ed893362