当前位置：首页 > news >正文

系统服务包括1-4章

news 2025/9/16 5:42:55

Crond服务

一、crond简介

1、基本介绍

2、crontab文件

二、crond服务

三、crontab命令详解

1、命令格式

2、命令功能

3、命令参数

4、常用方法

1.创建一个新的crontab文件

2.列出crontab文件

3. 编辑crontab文件

4.删除crontab文件

5.恢复丢失的crontab文件

5、使用实例

四、使用注意事项

2、注意清理系统用户的邮件日志

3、系统级任务调度与用户级任务调度

4、其他注意事项

Syslog服务

Syslog 概述

syslog 协议标准

syslog API

syslog 日志文件

日志文件介绍

日志配置

产生本地日志

CentOS7搭建syslog日志服务器

1、安装rsyslog软件

2、配置rsyslog.conf文件

3、重启rsyslog服务，查看日志

Linux Journalctl命令详解

1. Journalctl简介

2. Journalctl基础使用

3. 过滤日志条目

4. 时间戳和日志轮转

5. 高级应用

6. journalctl --help指令文档

7. 补充

清空所有日志

过滤掉某个服务日志

注意事项

总结

Systemd Journalctl日志持久化配置

1. systemd和journalctl概述

2. journalctl日志持久化的重要性

3. 配置journalctl日志持久化

4. 使用journalctl进行日志查询

5. 管理journalctl日志文件大小

6. 查看日志文件，验证持久化功能

7. 故障排除与最佳实践

8. 结论

附录

journal与logrotate日志管理工具的区别

配置删除指定时间前的旧日志

Crond服务

一、crond简介

1、基本介绍

crond是linux下用来周期性的执行某种任务或等待处理某些事件的一个守护进程，与windows下的计划任务类似，当安装完成操作系统后，默认会安装此服务工具，并且会自动启动crond进程，crond进程每分钟会定期检查是否有要执行的任务，如果有要执行的任务，则自动执行该任务。Linux下的任务调度分为两类，系统任务调度和用户任务调度。

系统任务调度：系统周期性所要执行的工作，比如写缓存数据到硬盘、日志清理等。在/etc目录下有一个crontab文件，这个就是系统任务调度的配置文件。/etc/crontab文件包括下面几行：

[root@localhost ~]# cat /etc/crontab 
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root# For details see man 4 crontabs# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

前四行是用来配置crond任务运行的环境变量，第一行SHELL变量指定了系统要使用哪个shell，这里是bash，第二行PATH变量指定了系统执行命令的路径，第三行MAILTO变量指定了crond的任务执行信息将通过电子邮件发送给root用户，如果MAILTO变量的值为空，则表示不发送任务执行信息给用户，第四行的HOME变量指定了在执行命令或者脚本时使用的主目录。第六至九行表示的含义将在下个小节详细讲述。这里不在多说。

用户任务调度：用户定期要执行的工作，比如用户数据备份、定时邮件提醒等。用户可以使用 crontab 工具来定制自己的计划任务。所有用户定义的crontab 文件都被保存在 /var/spool/cron目录中。其文件名与用户名一致。下面是几个特殊的文件介绍：

文件：/etc/cron.deny 该文件中所列用户不允许使用crontab命令
文件：/etc/cron.allow 该文件中所列用户允许使用crontab命令
文件：/var/spool/cron/ 所有用户crontab文件存放的目录,以用户名命名

2、crontab文件

用户所建立的crontab文件中，每一行都代表一项任务，每行的每个字段代表一项设置，它的格式共分为六个字段，前五段是时间设定段，第六段是要执行的命令段，格式如下：

minute hour day month week command

其中：

- minute：表示分钟，可以是从0到59之间的任何整数。
- hour：表示小时，可以是从0到23之间的任何整数。
- day：表示日期，可以是从1到31之间的任何整数。
- month：表示月份，可以是从1到12之间的任何整数。
- week：表示星期几，可以是从0到7之间的任何整数，这里的0或7代表星期日。
- command：要执行的命令，可以是系统命令，也可以是自己编写的脚本文件。

在以上各个字段中，还可以使用以下特殊字符：

- 星号（*）：代表所有可能的值，例如month字段如果是星号，则表示在满足其它字段的制约条件后每月都执行该命令操作。
- 逗号（,）：可以用逗号隔开的值指定一个列表范围，例如，“1,2,5,7,8,9”
- 中杠（-）：可以用整数之间的中杠表示一个整数范围，例如“2-6”表示“2,3,4,5,6”
- 正斜线（/）：可以用正斜线指定时间的间隔频率，例如“0-23/2”表示每两小时执行一次。同时正斜线可以和星号一起使用，例如*/10，如果用在minute字段，表示每十分钟执行一次。

二、crond服务

安装crontab：

yum install crontabs

服务操作说明：

systemctl start crond #启动服务
systemctl stop crond #关闭服务
systemctl restart crond #重启服务
systemctl reload crond #重新载入配置

查看crontab服务状态：

systemctl status status

手动启动crontab服务：

systemctl start crond

查看crontab服务是否已设置为开机启动，执行命令：

ntsysv

加入开机自动启动：

systemctl enable crond

三、crontab命令详解

1、命令格式

crontab [-u user] filecrontab [-u user] [ -e | -l | -r ]

2、命令功能

通过crontab 命令，我们可以在固定的间隔时间执行指定的系统指令或 shell script脚本。时间间隔的单位可以是分钟、小时、日、月、周及以上的任意组合。这个命令非常设合周期性的日志分析或数据备份等工作。

3、命令参数

-u user：用来设定某个用户的crontab服务，例如，“-u ixdba”表示设定ixdba用户的crontab服务，此参数一般有root用户来运行。
file：file是命令文件的名字,表示将file做为crontab的任务列表文件并载入crontab。如果在命令行中没有指定这个文件，crontab命令将接受标准输入（键盘）上键入的命令，并将它们载入crontab。
-e：编辑某个用户的crontab文件内容。如果不指定用户，则表示编辑当前用户的crontab文件。
-l：显示某个用户的crontab文件内容，如果不指定用户，则表示显示当前用户的crontab文件内容。
-r：从/var/spool/cron目录中删除某个用户的crontab文件，如果不指定用户，则默认删除当前用户的crontab文件。
-i：在删除用户的crontab文件时给确认提示。

4、常用方法

1.创建一个新的crontab文件

在考虑向cron进程提交一个crontab文件之前，首先要做的一件事情就是设置环境变量EDITOR。cron进程根据它来确定使用哪个编辑器编辑crontab文件。9 9 %的UNIX和LINUX用户都使用vi，如果你也是这样，那么你就编辑profile文件，在其中加入这样一行：

EDITOR=vi; export EDITOR

然后保存并退出。不妨创建一个名为<user> cron的文件，其中<user>是用户名，例如， davecron。在该文件中加入如下的内容。

# (put your own initials here)echo the date to the console every# 15minutes between 6pm and 6am0,15,30,45 18-06 * * * /bin/echo 'date' > /dev/console

保存并退出。确信前面5个域用空格分隔。

在上面的例子中，系统将每隔1 5分钟向控制台输出一次当前时间。如果系统崩溃或挂起，从最后所显示的时间就可以一眼看出系统是什么时间停止工作的。在有些系统中，用tty1来表示控制台，可以根据实际情况对上面的例子进行相应的修改。为了提交你刚刚创建的crontab文件，可以把这个新创建的文件作为cron命令的参数：

$ crontab davecron

现在该文件已经提交给cron进程，它将每隔1 5分钟运行一次。同时，新创建文件的一个副本已经被放在/var/spool/cron目录中，文件名就是用户名(即dave)。

2.列出crontab文件

为了列出crontab文件，可以用：

$ crontab -l0,15,30,45,18-06 * * * /bin/echo `date` > dev/tty1

你将会看到和上面类似的内容。可以使用这种方法在$ H O M E目录中对crontab文件做一备份：

$ crontab -l > $HOME/mycron

这样，一旦不小心误删了crontab文件，可以用上一节所讲述的方法迅速恢复。

3. 编辑crontab文件

如果希望添加、删除或编辑crontab文件中的条目，而E D I TO R环境变量又设置为v i，那么就可以用v i来编辑crontab文件，相应的命令为：

$ crontab -e

可以像使用v i编辑其他任何文件那样修改crontab文件并退出。如果修改了某些条目或添加了新的条目，那么在保存该文件时， c r o n会对其进行必要的完整性检查。如果其中的某个域出现了超出允许范围的值，它会提示你。我们在编辑crontab文件时，没准会加入新的条目。例如，加入下面的一条：

# DT:delete core files,at 3.30am on 1,7,14,21,26,26 days of each month30 3 1,7,14,21,26 * * /bin/find -name "core' -exec rm {} \;

现在保存并退出。最好在crontab文件的每一个条目之上加入一条注释，这样就可以知道它的功能、运行时间，更为重要的是，知道这是哪位用户的作业。现在让我们使用前面讲过的crontab -l命令列出它的全部信息：

$ crontab -l # (crondave installed on Tue May 4 13:07:43 1999)# DT:ech the date to the console every 30 minites0,15,30,45 18-06 * * * /bin/echo `date` > /dev/tty1# DT:delete core files,at 3.30am on 1,7,14,21,26,26 days of each month30 3 1,7,14,21,26 * * /bin/find -name "core' -exec rm {} \;

4.删除crontab文件

要删除crontab文件，可以用：

$ crontab -r

5.恢复丢失的crontab文件

如果不小心误删了crontab文件，假设你在自己的$ H O M E目录下还有一个备份，那么可以将其拷贝到/var/spool/cron/<username>，其中<username>是用户名。如果由于权限问题无法完成拷贝，可以用：

$ crontab <filename>

其中，<filename>是你在$ H O M E目录中副本的文件名。

建议你在自己的$ H O M E目录中保存一个该文件的副本。我就有过类似的经历，有数次误删了crontab文件（因为r键紧挨在e键的右边）。这就是为什么有些系统文档建议不要直接编辑crontab文件，而是编辑该文件的一个副本，然后重新提交新的文件。

有些crontab的变体有些怪异，所以在使用crontab命令时要格外小心。如果遗漏了任何选项，crontab可能会打开一个空文件，或者看起来像是个空文件。这时敲delete键退出，不要按<Ctrl-D>，否则你将丢失crontab文件。

5、使用实例

每1分钟执行一次command

* * * * * command

每小时的第3和第15分钟执行

3,15 * * * * command

在上午8点到11点的第3和第15分钟执行

3,15 8-11 * * * command

每隔两天的上午8点到11点的第3和第15分钟执行

3,15 8-11 */2 * * command

每个星期一的上午8点到11点的第3和第15分钟执行

3,15 8-11 * * 1 command

每晚的21:30重启smb

30 21 * * * /etc/init.d/smb restart

每月1、10、22日的4 : 45重启smb

45 4 1,10,22 * * /etc/init.d/smb restart

每周六、周日的1 : 10重启smb

10 1 * * 6,0 /etc/init.d/smb restart

每天18 : 00至23 : 00之间每隔30分钟重启smb

0,30 18-23 * * * /etc/init.d/smb restart

每星期六的晚上11 : 00 pm重启smb

0 23 * * 6 /etc/init.d/smb restart

每一小时重启smb

* */1 * * * /etc/init.d/smb restart

晚上11点到早上7点之间，每隔一小时重启smb

* 23-7/1 * * * /etc/init.d/smb restart

每月的4号与每周一到周三的11点重启smb

0 11 4 * mon-wed /etc/init.d/smb restart

一月一号的4点重启smb

0 4 1 jan * /etc/init.d/smb restart

每小时执行/etc/cron.hourly目录内的脚本

01 * * * * root run-parts /etc/cron.hourly

run-parts这个参数了，如果去掉这个参数的话，后面就可以写要运行的某个脚本名，而不是目录名了

四、使用注意事项

有时我们创建了一个crontab，但是这个任务却无法自动执行，而手动执行这个任务却没有问题，这种情况一般是由于在crontab文件中没有配置环境变量引起的。

在crontab文件中定义多个调度任务时，需要特别注意的一个问题就是环境变量的设置，因为我们手动执行某个任务时，是在当前shell环境下进行的，程序当然能找到环境变量，而系统自动执行任务调度时，是不会加载任何环境变量的，因此，就需要在crontab文件中指定任务运行所需的所有环境变量，这样，系统执行任务调度时就没有问题了。

不要假定cron知道所需要的特殊环境，它其实并不知道。所以你要保证在shelll脚本中提供所有必要的路径和环境变量，除了一些自动设置的全局变量。所以注意如下3点：

1）脚本中涉及文件路径时写全局路径；

2）脚本执行要用到java或其他环境变量时，通过source命令引入环境变量，如：

cat start_cbp.sh
#!/bin/sh
source /etc/profile
export RUN_CONF=/home/d139/conf/platform/cbp/cbp_jboss.conf
/usr/local/jboss-4.0.5/bin/run.sh -c mev &

3）当手动执行脚本OK，但是crontab死活不执行时。这时必须大胆怀疑是环境变量惹的祸，并可以尝试在crontab中直接引入环境变量解决问题。如：

0 * * * * . /etc/profile;/bin/sh /var/www/java/audit_no_count/bin/restart_audit.sh

2、注意清理系统用户的邮件日志

每条任务调度执行完毕，系统都会将任务输出信息通过电子邮件的形式发送给当前系统用户，这样日积月累，日志信息会非常大，可能会影响系统的正常运行，因此，将每条任务进行重定向处理非常重要。例如，可以在crontab文件中设置如下形式，忽略日志输出：

0 */3 * * * /usr/local/apache2/apachectl restart >/dev/null 2>&1

“/dev/null 2>&1”表示先将标准输出重定向到/dev/null，然后将标准错误重定向到标准输出，由于标准输出已经重定向到了/dev/null，因此标准错误也会重定向到/dev/null，这样日志输出问题就解决了。

3、系统级任务调度与用户级任务调度

系统级任务调度主要完成系统的一些维护操作，用户级任务调度主要完成用户自定义的一些任务，可以将用户级任务调度放到系统级任务调度来完成（不建议这么做），但是反过来却不行，root用户的任务调度操作可以通过“crontab –uroot –e”来设置，也可以将调度任务直接写入/etc/crontab文件，需要注意的是，如果要定义一个定时重启系统的任务，就必须将任务放到/etc/crontab文件，即使在root用户下创建一个定时重启系统的任务也是无效的。

4、其他注意事项

新创建的cron job，不会马上执行，至少要过2分钟才执行。
如果重启cron则马上执行。当crontab突然失效时，可以尝试/etc/init.d/crond restart解决问题。或者查看日志看某个job有没有执行/报错tail -f /var/log/cron。
千万别乱运行crontab -r。它从Crontab目录（/var/spool/cron）中删除用户的Crontab文件。删除了该用户的所有crontab都没了。
在crontab中%是有特殊含义的，表示换行的意思。如果要用的话必须进行转义\%，如经常用的date ‘+%Y%m%d’在crontab里是不会执行的，应该换成date ‘+\%Y\%m\%d

Syslog服务

Syslog 概述

syslog 常被称为系统日志或系统记录，系统日志通过 syslog 进程记录系统的有关事件，也可以记录应用程序运作事件。通过适当配置，甚至可以实现运行 syslog 协议的机器之间的通信。

早期的 syslog 日志服务对应的是 syslogd 守护进程，而目前很多 linux 发行版本已经使用 rsyslog 服务替换了 syslog 服务预装在 linux 系统中了，相应的守护进程就变成了rsyslogd（ubuntu 18中已经更新为 rsyslog）。

syslog 协议标准

syslog 协议是一种用来在互联网协议（TCP/IP）的网络中传递记录档讯息的标准，属于一种主从式协议：syslog 发送端发送一条文字信息到 syslog 接收端。具体协议如下图所示：

如上图所示，syslog 消息主要分为 priority、head 以及 message 三个部分，priority 是由两个部分组成的——facility、level。

facility 表明该日志消息是由谁产生的，是内核 kern？还是用户 user？又或是邮件 mail？不同的 facility对应不同的代号，可通过 man 3 syslog 查看：

LOG_AUTHPRIV security/authorization messages (private)
LOG_CRON clock daemon (cron and at)
LOG_DAEMON system daemons without separate facility value
LOG_FTP ftp daemon
LOG_KERN kernel messages (these can’t be generated from user processes)
LOG_LOCAL0 through LOG_LOCAL7 reserved for local use
LOG_LPR line printer subsystem
LOG_MAIL mail subsystem
LOG_NEWS USENET news subsystem
LOG_SYSLOG messages generated internally by syslogd(8)
LOG_USER (default) generic user-level messages
LOG_UUCP UUCP subsystem

level 表明该日志消息的重要程度，是导致系统不能正常使用了的紧急级别 emerg？还是需要被及时处理的警告级别 alert？又或仅仅是需要调试的 debug 级别的信息？同样可通过 man 3 syslog 查看：

LOG_EMERG system is unusable
LOG_ALERT action must be taken immediately
LOG_CRIT critical conditions
LOG_ERR error conditions
LOG_WARNING warning conditions
LOG_NOTICE normal, but significant, condition
LOG_INFO informational message
LOG_DEBUG debug-level message

facility 和 level 分别定义了不同的代号，其各自的宏定义可见 /usr/include/sys/syslog.h 头文件，它们两者的组合构成了 priority 头的值。

syslog API

linux C 中提供了一套系统日志写入的接口—syslog 库，syslog 库可以将应用程序中的日志消息写入日志系统，主要涉及三个函数 openlog，syslog，closelog。如下所示：

#include <syslog.h>
void openlog(const char *ident, int option, int facility);功能：打开一个syslog连接：使用 openlog 函数来连接 syslogd 程序。参数：ident指定的字符串会放入到相应的消息日志中；option有如下可选项：LOG_CONS    Write directly to system console if there is an error while sending to system logger.LOG_NDELAY  Open the connection immediatelyLOG_NOWAIT  Don’t  wait for child processes that may have been created while logging the message.LOG_ODELAY  The converse of LOG_NDELAY; opening of the connection is delayed until syslog() is called.LOG_PERROR  (Not in POSIX.1-2001.)  Print to stderr as well.LOG_PID     Include PID with each message.facility有若干可选项，前面已经介绍过。返回值：空。

#include <syslog.h>
void syslog(int priority, const char *format, ...);
功能: 产生一条日志消息以特定的规则分发出去。
参数:priority 优先级，由 facility 和 level 的或运算组成；format 格式化输出，类似于printf函数中的format参数。
返回值：空

#include <syslog.h>
void closelog(void);
功能：关闭用来写日志记录的文件描述符。
参数：无
返回值：空

syslog 日志文件

日志文件介绍

日志一般都在 /var/log 目录下。该目录下有以下几个重要的的日志文件。

/var/log/maillog：记录邮件的往来信息，其实主要是记录 sendmail 与 dovecot 所产生的信息。
/var/log/dmesg：记录开机开始到现在的内核检测过程所产生的各项信息。如果内核编程的模块中使用printk()，将会把相关信息打印到这里。
/var/log/messages：系统发生的重要信息或者是错误信息都会记录在这个文件中，如果系统发生错误，这个文件就是需要查阅的文件之一。
/var/log/httpd：这个文件里面主要记录各种网络服务信息。
/var/log/cron：这个日志跟例行工作调度有关。即crontab有没有被执行，执行过程中有没有发生错误，在这个日子中均有体现。

上述的这些日志都是系统进程打印出的 log 日志。我们怎么能打印出自己的 log 日志呢？首先，我们要分清楚需求是什么，是通过内核打印出来？还是非内核应用中打印出来？

1、内核打印日志

相信很多使用过内核模块的朋友已经很清楚，在 linux 内核模块中编程的话，使用简单的 printk("helloworld"); 就能达到打印日志的效果。在linux中使用 dmesg 命令即可查看内核输出的日志。

2、非内核编程打印日志

若想在非内核的环境下打印日志，就必须要使用 syslog（或者 rsyslog）了。若你的系统还是使用的 syslog，那就直接运行以下测试代码：

/**
*filename:syslog_test.c
*/
#include <syslog.h>
#include <sys/types.h>
#include <unistd.h>
int main()
{openlog("syslog_test", LOG_PID, LOG_USER);syslog(LOG_INFO, "The pid of syslog_test=%d", getpid());closelog();
}

编译、运行：

yxm@192:~/myshare/process_info$ gcc -Wall -g syslog_test.c -o syslog_test
yxm@192:~/myshare/process_info$ ./syslog_test

查看日志：

Mar 16 23:48:44 是日志记录的时间；
192 是主机名；
syslog_test 是 openlog 函数的第一个参数指定的字符串；
[126266] 是openlog第二个参数指定了 LOG_PID 的结果；
The pid of syslog_test=126266 则是 syslog 函数指定的日志消息内容了。

该条日志输出到了/var/log/syslog 文件内，其实输出路径以及各种 facility 和 level 都是可以通过配置文件进行相应的设置的，我们后面再说。

【注意】大家如果想删除日志，千万不要把日志文件直接删除，如果这样很有可能系统找不到文件，就无法再打印日志，恢复起来也是比较麻烦。直接清空日志内容即可：cat /dev/null > syslog。

日志配置

如果需要修改系统日志配置，修改以下两个文件。

1）/etc/rsyslog.conf

2）/etc/rsyslog.d/50-default.conf：日志文件的记录规则和路径

rsyslogd 进程的操作：

sudo service rsyslog restart
sudo service rsyslog stop
sudo service rsyslog start

产生本地日志

1、修改 /etc/rsyslog.d/50-default.conf 配置文件：

在文件最后添加如下一行：

# mylog
local0.* /var/log/mylocal.log

【注意】

local0—local7 均可。
/var/log/mylocal.log 是自己定义的日志文件。
- 表示所有的日志，可以保存部分日志，例如 local0.info 只会保留 LOG_INFO 级别的日志。

2、配置完需要重启 rsyslogd 程序

/etc/init.d/rsyslog restart
# 或者
sudo service rsyslog restart
# 或者
systemctl restart rsyslog

3、程序中用以下记入日志

openlog("syslog_test", LOG_PID, LOG_LOCAL0);

程序编译运行后，log 信息将被记录到 mylocal。

4、动态查看日志

tail -f /var/log/mylocal.log | grep syslog_test

CentOS7搭建syslog日志服务器

1、安装rsyslog软件

yum install -y rsyslog

2、配置rsyslog.conf文件

vi /etc/rsyslog.conf

修改内容，注释打开，启用UDP、TCP协议，监听514端口
配置接收日志的存放目录和文件名规则

##配置begin

# 使用RemoteLogs模板接受客户端的日志，保存到本地的/var/log/remote目录下，然后是每台客户端的ip_年份_月份_日期的log

$template RemoteLogs,"/var/log/remote/%fromhost-ip%/%fromhost-ip%_%$YEAR%-%$MONTH%-%$DAY%.log"

# 所有服务所有级别的日志都记录

*.* ?RemoteLogs

#服务端本机的日志不记录

:fromhost-ip, !isequal, "127.0.0.1" ?Remote

#指示rsyslog在将消息写入文件后停止处理消息。如果不包含"& ~"，则消息将被写入本地文件,导致消息被记录2次。

& ~

##配置end

3、重启rsyslog服务，查看日志

systemctl restart rsyslog

日志目录： /var/log/remote/

Linux Journalctl命令详解

Linux提供了一个强大的日志系统，它可以跟踪和记录系统的各种活动。在这个系统中，journalctl是一个非常重要的工具，用于查询和操作由systemd进程管理的日志。

本文将深入探讨journalctl命令，介绍其基本使用、高级选项及示例等内容。

1. Journalctl简介

Systemd是Linux发行版的初始化系统，负责启动系统后的所有服务，并监视它们在系统运行期间的状态。Journal是Systemd的一部分，主要负责收集和存储日志数据。

journalctl是Journal的主要接口，提供丰富的功能来检索和显示日志条目。它能从磁盘上的二进制文件或者其他传输目标（如syslog）获取日志。

2. Journalctl基础使用

下面是一些基本的journalctl命令。

查看所有日志：（分页输出）

journalctl

或者：（不分页输出）

ournalctl --no-pager

按时间倒序查看所有日志：

journalctl -r

查看最新的10条日志：

journalctl -n 10

实时查看新添加的日志条目：

journalctl -f

3. 过滤日志条目

journalctl提供了多种方式来过滤和查找特定的日志条目。

以下是一些过滤日志的例子：

根据服务名称过滤：

journalctl -u nginx

根据进程ID过滤：

journalctl _PID=2001

根据优先级过滤（0-7，0表示最重要）：

journalctl -p err -b

4. 时间戳和日志轮转

对于大型系统，日志文件可能会非常大。为了解决这个问题，journalctl提供了日志轮转和时间戳功能。

日志轮转是一个过程，其中旧的日志条目被删除以释放空间给新的日志条目。默认情况下，Journal将根据配置在/var/log/journal中保存日志文件，并在磁盘空间不足时执行日志轮转。

时间戳允许你查找特定时间范围内的日志条目。例如：

journalctl --since="2021-07-01" --until="2021-07-31 03:00"

5. 高级应用

尽管journalctl提供了丰富的功能，但在某些情况下，你可能需要更高级的工具或技术。例如，你可能需要将日志发送到远程服务器，或者在多个系统上集中处理日志。

对于这些需求，你可以考虑使用像Logstash、Graylog或Fluentd这样的日志聚合工具，它们可以与journalctl结合使用，提供更强大的功能。

6. `journalctl --help`指令文档

7. 补充

清空所有日志

清除所有的系统日志，可使用 journalctl 的 --vacuum-time 或 --vacuum-size 选项。

清除所有日志：

sudo journalctl --vacuum-time=1s

这将会删除所有时间戳早于现在的日志条目，基本上等同于清空所有日志。

journalctl --vacuum-time 命令通常接受一个相对时间值，如 “1year”, “2months”, “3weeks”, “4days”, “1s” 等。这个命令会删除所有在指定时间长度之前的日志。

2.清除超过特定大小的日志：

journalctl --vacuum-size=1

这将删除所有日志，直到系统日志的总大小降到1（单位为BYTE）。

可以使用journalctl --disk-usage查看日志占用空间大小。

3.如果以上两个都没有效果，可以采用暴力方式直接删除日志文件。

sudo systemctl stop systemd-journald
sudo rm -rf /var/log/journal/*
sudo systemctl start systemd-journald

暴力删除有风险，使用需谨慎。

过滤掉某个服务日志

比如systemd服务日志太多太烦杂，可以过滤掉它：

journalctl | grep -v systemd

注意事项

journal日志不会将程序输出的空行显示，日志会被压缩得满满当当。
journal日志不会自动持久化，重启系统后，历史日志将被清除。可参考journal日志持久化配置。

总结

journalctl是一个强大而灵活的工具，可以帮助你管理和查询Linux系统的日志。通过学习和理解journalctl的各种功能和选项，你将能够更有效地管理你的系统，并在出现问题时快速找到原因。

Systemd Journalctl日志持久化配置

在此文章中，我们将详细探讨systemd journalctl日志的持久化配置。本文将首先简单介绍systemd和journalctl，然后深入探讨如何配置和使用journalctl来实现日志的持久化。

1. systemd和journalctl概述

Systemd是Linux系统的一个初始化系统和服务管理器，它负责启动系统后的所有服务。其中，Journal是systemd的一个组成部分，用于收集和存储系统日志。

Journalctl是一种工具，可以方便地从systemd的journal中检索日志信息。默认情况下，这些日志数据是易失的，也就是说，每次重启系统后，它们都会被清除。

# 查看所有日志条目
journalctl

2. journalctl日志持久化的重要性

日志持久化的主要优点在于，它可以帮助我们保存重启后的日志信息，以便在需要时进行查阅和分析。这对于故障排除、安全审计以及性能监测等场景非常有价值。

3. 配置journalctl日志持久化

为了使journalctl的日志持久化，我们需要创建一个名为/var/log/journal的目录，并设置适当的权限。

# 创建日志目录
mkdir -p /var/log/journal

# 设置权限
systemd-tmpfiles --create --prefix /var/log/journal

另外，我们还需要在/etc/systemd/journald.conf文件中修改或添加以下配置：

[Journal]
Storage=persistent

然后，重新启动systemd-journald服务来应用新的配置。

# 重新启动服务
systemctl restart systemd-journald

4. 使用journalctl进行日志查询

配置好日志持久化后，我们可以使用各种查询选项来过滤和查找日志信息。例如：

# 查看指定时间段的日志
journalctl --since "2022-01-01" --until "2022-01-31"

# 查看指定服务的日志
journalctl -u nginx.service

5. 管理journalctl日志文件大小

虽然日志持久化很有用，但如果不加以管理，日志文件可能会占用大量磁盘空间。我们可以通过配置/etc/systemd/journald.conf文件来限制日志文件的大小。

[Journal]
# 日志文件最大占用空间
SystemMaxUse=500M

（注意这里SystemMaxUse是限制所有日志总占空间大小，SystemMaxFileSize是限制单个轮转日志文件的大小；RuntimeMaxUse用于限制在 /run/log/journal/ 中的日志数据占用的空间大小，这是管理非持久性存储的日志容量大小，已经设置了默认值，我们不用管）

配置后同样要重新启动服务：

# 重新启动服务
systemctl restart systemd-journald

6. 查看日志文件，验证持久化功能

ll /var/log/journal/

由于journal的二进制格式，不能直接使用文本编辑器（如vi或nano）打开和阅读这些文件，还得使用journalctl命令进行查看。

我们来验证一下是否成功实现日志持久化保存。我用journalctl -u ky_ai_ip_change.service查看我修改ip服务的日志。

然后我把SystemMaxUse改成1M重复上面步骤再来一遍：

重启后查看日志：

Warning: journal has been rotated since unit was started, output may be incomplete.

-- Logs begin at Mon 2023-08-21 23:25:54 CST, end at Mon 2023-08-21 23:33:19 CST. --
-- No entries --

貌似是提示我说，我的修改ip服务的日志因为被轮转（rotated），已经转没了。

是因为我们设置的日志总占空间，太小辣！才1M，会很容易被别的系统服务日志冲没的。

还是改回500M。

7. 故障排除与最佳实践

对于任何系统管理员来说，了解如何处理常见问题和遵循最佳实践都是至关重要的。在使用journalctl时，我们应始终记住以下几点：

定期检查和清理日志文件
使用合适的查询选项来精确查找日志
及时更新并备份/etc/systemd/journald.conf文件

8. 结论

总的来说，journalctl日志持久化配置是一个强大而灵活的工具，可以帮助我们更好地管理和审计系统日志。通过正确的配置和使用，我们可以充分利用这个工具来提高我们的运维效率。

附录

/etc/systemd/journald.conf原始文件及配置项解析（ubuntu20.04）

原始文件

cat /etc/systemd/journald.conf

解析

# 这个文件是 systemd 的一部分。
#
# systemd 是自由软件；你可以在 GNU 较小通用公共许可证的条款下重新发布和/或修改它
# 该许可证由自由软件基金会发布；可以选择许可证的版本 2.1 或者
# (如果你愿意)任何后续版本。
#
# 此文件中的条目显示了编译时的默认设置。
# 你可以通过编辑此文件来更改设置。
# 只需删除此文件，即可恢复默认设置。
#
# 详细信息请参阅 journald.conf(5)。

就是说想要恢复默认设置，只需删除此文件即可。）

Storage：定义日志数据应存储在何处，例如 ‘volatile’（临时文件系统）或 ‘persistent’（磁盘）。
Compress：定义是否应压缩存储在日志中的数据。
Seal：确定是否使用Forward Secure Sealing (FSS) 保护日志条目免受篡改。
SplitMode：定义如何拆分日志文件，例如根据用户ID或登录会话。
SyncIntervalSec：定义系统何时将日志数据从内存同步到磁盘。
RateLimitIntervalSec和RateLimitBurst：定义日志消息的频率限制，即在给定的时间间隔内可以接受的最大消息数。
SystemMaxUse, SystemKeepFree, SystemMaxFileSize, SystemMaxFiles：定义系统日志所能使用的磁盘空间，以及应保留多少空闲空间。
RuntimeMaxUse, RuntimeKeepFree, RuntimeMaxFileSize, RuntimeMaxFiles：定义运行时日志的大小和文件数量限制。
MaxRetentionSec：定义系统应保留旧日志条目的最长时间。
MaxFileSec：定义单个日志文件的最大生存时间。
ForwardToSyslog, ForwardToKMsg, ForwardToConsole, ForwardToWall：定义是否将日志消息转发到syslog、内核消息日志、控制台或所有登录用户。
TTYPath：定义写入终端消息的TTY设备路径。
MaxLevelStore, MaxLevelSyslog, MaxLevelKMsg, MaxLevelConsole, MaxLevelWall：定义各种日志目标的最大日志级别。
LineMax：定义日志条目的最大行长度。
ReadKMsg：定义是否从内核消息日志读取并添加到系统日志。

journal与logrotate日志管理工具的区别

systemd journal 和 logrotate 都是用于管理日志文件的工具，但它们的工作方式和特性有一些区别。

日志格式：
- systemd journal 存储的日志是二进制格式，这使得它可以提供更丰富的查询功能，例如按服务、优先级或时间范围过滤日志。
- logrotate 处理的通常是文本格式的日志，这种日志对人类来说更易读，但对机器来说处理起来可能就不那么方便了。
日志切割：
- systemd journal 会自动管理日志文件的大小，当日志达到一定大小时，它会自动删除旧的日志来释放空间。你可以通过配置选项（如 SystemMaxUse 和 RuntimeMaxUse）来控制日志文件的最大大小。
- logrotate 是通过定期运行（通常是每天）来进行日志切割的，它可以根据日志文件的大小、文件的年龄或者日期来决定何时进行切割。切割后的日志文件可以选择压缩以节省空间。
使用场景：
- systemd journal 主要用于收集系统和服务的日志，它是 systemd 的一个组成部分，所以在使用 systemd 的系统上，无法避免使用 journal。
- logrotate 更多的是用于应用程序的日志管理，尤其是那些还没有采用 systemd 的系统或者那些产生大量日志的应用程序。

两者都有各自的优点，也可以结合使用，比如让 systemd journal 收集日志，然后使用 logrotate 来管理 journal 导出的文本格式日志。

20231017 发现日志达到设置上限了，日志并未自动删除，新的日志也没有储存。一时半会找不到解决办法，通过设置MaxRetentionSec=7day自动清理7天前的日志来临时解决

今天调试ip修改服务，发现重启后新的日志并未正常保存，重启前日志倒是可以看到的

查看systemd-journald服务状态：

systemctl status systemd-journald

root@nvidia:/ky/boot/journal_persistence# systemctl status systemd-journald
● systemd-journald.service - Journal ServiceLoaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)Active: active (running) since Tue 2023-10-17 18:07:39 CST; 2h 36min ago
TriggeredBy: ● systemd-journald-audit.socket● systemd-journald-dev-log.socket● systemd-journald.socketDocs: man:systemd-journald.service(8)man:journald.conf(5)Main PID: 6899 (systemd-journal)Status: "Processing requests..."Tasks: 1 (limit: 8126)Memory: 1.8MCGroup: /system.slice/systemd-journald.service└─6899 /lib/systemd/systemd-journaldOct 17 18:07:39 nvidia systemd-journald[6899]: Journal started
Oct 17 18:07:39 nvidia systemd-journald[6899]: System Journal (/var/log/journal/dbfef1aa0b064bcf9d30ec3ad0886edb) is 514.5M, max 500.0M, 0B free.
Oct 17 18:07:39 nvidia systemd-journald[6899]: System Journal (/var/log/journal/dbfef1aa0b064bcf9d30ec3ad0886edb) is 514.5M, max 500.0M, 0B free.
root@nvidia:/ky/boot/journal_persistence#

发现上面有一句：(/var/log/journal/dbfef1aa0b064bcf9d30ec3ad0886edb) is 514.5M, max 500.0M, 0B free.

表明可能自动清理旧日志功能并未正常执行。

用下面命令查看journal日志占用大小，发现已经超了。：