查看和管理日志文件

规则由 filter 部分指定，它选择 syslog 消息的子集，以及用选定的消息做什么的 action 部分。要在 /etc/rsyslog.conf 配置文件中定义规则，请在一行上定义过滤器和操作，并用一个或多个空格或制表符分隔它们。

rsyslog 提供了多种方法来根据选定的属性过滤 syslog 消息。可用的过滤方法可分为 Facility/Priority-based、Property-based 和 Expression-based 过滤器。

其中：

上述语法选择具有定义或 更高 优先级的系统日志消息。通过在任何优先级关键字前面加上等号 (=)，您可以指定仅选择具有指定优先级的系统日志消息。所有其他优先级将被忽略。相反，在优先级关键字前面加上感叹号 (!) 会选择除具有已定义优先级的消息之外的所有 syslog 消息。

除了上面指定的关键字之外，您还可以使用星号 (*) 来定义所有设施或优先级（取决于您把星号放在逗号之前或之后）。指定优先级关键字“none”用于没有给定优先级的设施。设施条件和优先级条件都不区分大小写。

要定义多个设施和优先级，请用逗号 (,) 分隔它们。要在一行上定义多个选择器，请用分号 (;) 分隔它们。请注意，选择器字段中的每个选择器都能够覆盖前面的选择器，这可以从模式中排除一些优先级。

基于属性的过滤器必须以冒号 (:) 开头。要定义过滤器，请使用以下语法：

其中：

基于表达式的过滤器的基本语法如下所示：

其中：

使用基于表达式的过滤器，您可以使用用大括号括起来的脚本来嵌套条件，如 Expression-based Filters 中所示。该脚本允许您在表达式中使用 facility/priority-based 过滤器。另一方面，这里不推荐使用 property-based 过滤器。RainerScript 支持具有专用函数 re_match() 和 re_extract() 的正则表达式。

参考 Online Documentation 以获取更多基于表达式的过滤器的示例。RainerScript 是 rsyslog 的新配置格式的基础，参见 Using the New Configuration Format。

操作指定要对已定义的选择器过滤掉的消息执行什么操作。以下是您可以在规则中定义的一些操作：

其中 FILTER 代表用户指定的选择器，PATH 是目标的路径文件。

例如，以下规则由选择所有 cron syslog 消息的选择器和将它们保存到 /var/log/cron.log 日志文件的操作组成：

默认情况下，每次生成 syslog 消息时都会同步日志文件。使用破折号 (-) 作为您指定省略同步的文件路径的前缀：

请注意，如果系统在写入尝试后立即终止，可能会造成信息丢失。但是，此设置可以提高性能，尤其是在您运行产生非常冗长的日志消息的程序时。

您指定的文件路径可以是 static 或 dynamic 的。静态文件由固定文件路径表示，如上例所示。动态文件路径可以根据收到的消息而有所不同。动态文件路径由模板和问号 (?) 前缀表示：

其中 DynamicFile 是修改输出路径的预定义模板的名称。您可以使用破折号前缀 (-) 禁用同步，也可以使用由冒号 (:) 分隔的多个模板。有关模板的详细信息，请参照 Generating Dynamic File Names。

如果您指定的文件是现有的 terminal 或 /dev/console 设备，在使用 X Window 系统时，系统日志消息将分别发送到标准输出（使用特殊的 terminal-handling）或您的控制台（使用特殊的 /dev/console-handling) 。

其中：

将“IPv6”地址指定为主机时，请将地址括在方括号中([, ])。

其中：

要将定义的输出通道用作规则内的操作，请键入：

这里 FILTER 条件的输出由 EXECUTABLE 表示的程序处理。该程序可以是任何有效的可执行文件。将 TEMPLATE 替换为格式模板的名称。

其中：

丢弃动作主要用于在进行任何进一步处理之前过滤掉消息。如果您想省略一些会填满日志文件的重复消息，它可能会很有效。丢弃操作的结果取决于在配置文件中指定的位置，为了获得最佳结果，请将这些操作放在操作列表的顶部。请注意，一旦消息被丢弃，就无法在以后的配置文件行中检索它。

例如，以下规则丢弃任何 cron 系统日志消息：

对于每个选择器，您可以指定多个操作。要为一个选择器指定多个操作，请将每个操作写在单独的行上，并在其前面加上一个 & 字符：

多个操作提高了预期结果的整体性能，因为指定的选择器只需评估一次。

任何操作都可以跟随一个模板来格式化消息。要指定模板，请使用分号 (;) 为操作添加后缀并指定模板的名称。有关模板的详细信息，请参阅：Templates 。

rsyslog 生成的任何输出都可以使用 templates 根据您的需要进行修改和格式化。要创建模板，请在 /etc/rsyslog.conf 中使用以下语法：

其中：

模板可用于生成动态文件名。通过将属性指定为文件路径的一部分，将为每个唯一属性创建一个新文件，这是对 syslog 消息进行分类的便捷方式。

例如，使用从消息中提取时间戳的 timegenerated 属性为每个 syslog 消息生成唯一的文件名：

请记住，$template 指令仅指定模板。您必须在规则中使用它才能生效。在 /etc/rsyslog.conf 中，在操作定义中使用问号 (?) 来标记动态文件名模板：

Properties 在模板内定义的属性（在两个百分号 (%) 之间）允许通过使用 property replacer 访问系统日志消息的各种内容。要在模板内定义属性（在两个引号之间 (“…”)），请使用以下语法：

其中：

以下是一些简单属性的示例：

本节介绍 rsyslog 模板的几个示例。

A verbose syslog message template 显示了一个格式化 syslog 消息的模板，以便输出消息的严重性、设施、收到消息时的时间戳、主机名、消息标签、消息文本，并以新行结束。

A wall message template 显示了一个类似于传统墙上消息的模板（该消息发送给每个登录的用户，并且他们的 mesg(1) 权限设置为 yes）。此模板在新行上输出消息文本以及主机名、消息标记和时间戳（使用 \r 和 \n）并响铃（使用 \7）。

A database formatted message template 显示了一个格式化系统日志消息的模板，以便它可以用作数据库查询。请注意模板末尾指定了 sql 选项。它告诉数据库写入器将消息格式化为 MySQL SQL 查询。

rsyslog 还包含一组由 RSYSLOG_ 前缀标识的预定义模板。这些是为 syslog 保留的，建议不要使用此前缀创建模板以避免冲突。以下列表显示了这些预定义模板及其定义。

全局指令是适用于 rsyslogd 守护进程的配置选项。他们通常为特定的预定义变量指定一个值，该变量会影响 rsyslogd 守护进程的行为或遵循的规则。所有全局指令都必须以美元符号 ($) 开头。每行只能指定一个指令。以下是指定 syslog 消息队列最大大小的全局指令示例：

该指令的默认大小为 10,000 条消息，可以通过指定不同的值来覆盖它（如上例所示）。

您可以在 /etc/rsyslog.conf 配置文件中定义多个指令。指令会影响所有配置选项的行为，直到检测到同一指令再次出现。全局指令可用于配置操作、队列和调试。可以在参考 在线文档中找到所有可用配置指令的完整列表。目前，已开发出一种新的配置格式来替代基于 $ 的语法（请参阅：Using the New Configuration Format）。但是，经典的全局指令仍然作为传统格式得到支持。

以下是一个示例 /etc/logrotate.conf 配置文件：

示例配置文件中的所有行都定义了适用于每个日志文件的全局选项。在我们的示例中，日志文件每周轮换一次，轮换的日志文件保存 4 周，所有轮换的日志文件都通过 gzip 压缩为 .gz 格式。任何以井号 (#) 开头的行都是注释，不会被处理。

您可以为特定日志文件定义配置选项并将其放在全局选项下。但是，建议在 /etc/logrotate.d/ 目录中为任何特定日志文件创建一个单独的配置文件，并在那里定义任何配置选项。

以下是放置在 /etc/logrotate.d/ 目录中的配置文件示例：

此文件中的配置选项仅适用于 /var/log/messages 日志文件。此处指定的设置会尽可能覆盖全局设置。因此，轮换的“/var/log/messages”日志文件将保存五周，而不是全局选项中定义的四周。

以下是您可以在 logrotate 配置文件中指定的一些指令列表：

For the full list of directives and various configuration options, see the logrotate(5) manual page.

撇开特殊指令不谈，rsyslog 按照 rules 处理消息，rules 由过滤条件和条件为真时要执行的操作组成。使用传统的 /etc/rsyslog.conf 文件，所有规则都按照每个输入消息的出现顺序进行评估。此过程从第一条规则开始，一直持续到所有规则都已处理完毕或消息被其中一条规则丢弃为止。

但是，可以将规则分组为称为 rulesets 的序列。使用规则集，您可以将某些规则的影响仅限于选定的输入，或通过定义绑定到特定输入的一组不同的操作来提高 rsyslog 的性能。换句话说，对于某些类型的消息，不可避免地会被评估为假的过滤条件可以被跳过。/etc/rsyslog.conf 中的旧规则集定义如下所示：

规则在定义另一个规则时结束，或者默认规则集被如下调用：

在 rsyslog 7 的新配置格式中，input() 和 ruleset() 语句被保留用于此操作。/etc/rsyslog.conf 中的新格式规则集定义如下所示：

将 rulesetname 替换为您的规则集的标识符。规则集名称不能以 RSYSLOG_ 开头，因为此命名空间保留给 rsyslog 使用。如果消息没有分配其他规则集，则 RSYSLOG_DefaultRuleset 定义默认规则集。rule 和 rule2 定义上述过滤操作格式的规则。使用 call 参数，您可以通过从其他规则集块中调用它们来嵌套规则集。

创建规则集后，您需要指定它应用于哪些输入：

在这里，您可以通过 input_type（收集消息的输入模块）或 port_num （ 端口号）来识别输入消息。可以为 input() 指定其他参数，例如 file 或 tag。将 rulesetname 替换为要根据消息评估的规则集的名称。如果输入消息未明确绑定到规则集，则会触发默认规则集。

您还可以使用旧格式来定义规则集，有关详细信息，请参阅：在线文档。

从 rsyslog 版本 6 开始，通过 -c 选项指定的兼容模式已被删除。此外，不推荐使用 syslogd 样式的命令行选项，应避免通过这些命令行选项配置 rsyslog。但是，您可以使用多个模板和指令来配置 rsyslogd 以模拟类似 syslogd 的行为。

有关各种 rsyslogd 选项的更多信息，请参阅 rsyslogd(8) 手册页。

根据消息的存储位置，有几种类型的队列：direct、in-memory、disk 和 disk-assisted in-memory 使用最广泛的队列。您可以为主消息队列和操作队列选择其中一种类型。将以下内容添加到`/etc/rsyslog.conf`中：

在这里，您可以把设置应用于主消息队列（将 object 替换为 MainMsg）或应用于操作队列（将 object 替换为 Action）。将 queue_type 替换为 direct、linkedlist 、fixedarray（内存队列）或 disk 之一。

主消息队列的默认设置是 FixedArray 队列，限制为 10,000 条消息。动作队列默认设置为直接队列。

对于许多简单的操作，例如将输出写入本地文件时，不需要在操作之前构建队列。为避免排队，请使用：

将 object 替换为 MainMsg 或 Action 分别将此选项用于主消息队列或操作队列。使用直接队列，消息直接并立即从生产者传递到消费者。

磁盘队列将消息严格存储在硬盘驱动器上，这使得它们非常可靠，但也是所有可能的队列模式中最慢的。此模式可用于防止丢失非常重要的日志数据。但是，在大多数用例中不建议使用磁盘队列。要设置磁盘队列，请在 /etc/rsyslog.conf 中键入以下内容：

将 object 替换为 MainMsg 或 Action 以分别将此选项应用于主消息队列或操作队列。磁盘队列按部分写入，默认大小为 10 Mb。可以使用以下配置指令修改此默认大小：

其中 size 表示磁盘队列部分的大小。定义的大小限制不是限制性的，rsyslog 总是写入一个完整的队列条目，即使它违反了大小限制。磁盘队列的每个部分都与单个文件匹配。这些文件的命名指令如下所示：

这设置了一个 name 文件前缀后跟一个 7 位数字，从 1 开始，每个文件递增。

使用内存队列，排队的消息被保存在内存中，这使得进程非常快。如果计算机重启或关闭，排队的数据会丢失。但是，您可以使用 $ActionQueueSaveOnShutdown 设置在关机前保存数据。内存中的队列有两种类型：

一般来说，如有疑问，请使用 LinkedList 队列。与 FixedArray 相比，它消耗更少的内存并降低了处理开销。

使用以下语法配置内存队列：

将 object 替换为 MainMsg 或 Action 以分别将此选项用于主消息队列或操作队列。

磁盘和内存队列各有它们的优势，rsyslog 让您可以将它们组合成 磁盘辅助的内存队列。为此，请配置一个普通的内存队列，然后添加 $objectQueueFileName 指令来定义磁盘辅助的文件名。然后，此队列变为 磁盘辅助，这意味着它将内存队列与磁盘队列耦合以协同工作。

如果内存队列已满或需要在关机后保留，则磁盘队列被激活。使用磁盘辅助队列，您可以设置特定于磁盘的配置参数和特定于内存的配置参数。这种类型的队列可能是最常用的，它对于可能长时间运行且不可靠的操作特别有用。

要指定磁盘辅助内存队列的功能，请使用所谓的 watermarks：

将 object 替换为 MainMsg 或 Action 以分别将此选项用于主消息队列或操作队列。将 number 替换为排队的消息。当内存中的队列达到高水位线定义的数量时，它开始将消息写入磁盘并继续，直到内存中的队列大小下降到低水位线定义的数量。正确设置水位线可以最大程度地减少不必要的磁盘写入，也会为消息突发留出内存空间，因为写入磁盘文件的时间相当长。因此，高水位线必须低于使用 $objectQueueSize 设置的整个队列容量。高水位线和总队列大小之间的差异是为消息突发保留的备用内存缓冲区。另一方面，高水位线设置得太低会不必要地经常打开磁盘辅助。

所有类型的队列都可以进一步配置以满足您的要求。您可以使用多个指令来修改操作队列和主消息队列。目前，有 20 多个队列参数可用，请参阅：在线文档。其中一些设置是常用的，其他设置（例如工作线程管理）提供对队列行为的更密切控制，并为高级用户保留。通过高级设置，您可以优化 rsyslog 的性能、调度队列或修改系统关闭时队列的行为。

您可以使用以下设置限制队列可以包含的消息数量：

将 object 替换为 MainMsg 或 Action 以使用此选项分别用于主消息队列或动作队列。将 number 替换为排队的消息。您只能将队列大小设置为消息数，而不是它们的实际内存大小。主消息队列和规则集队列的默认队列大小为 10,000 条消息，操作队列为 1000 条。

磁盘辅助队列默认是无限的，不能用这个指令限制，但是你可以通过以下设置为它们保留物理磁盘空间：

将 object 替换为 MainMsg 或 Action。当达到 number 指定的大小限制时，消息将被丢弃，直到出队的消息释放出足够的空间。

当队列达到一定数量的消息时，您可以丢弃不太重要的消息，以便为更高优先级的条目节省队列空间。启动丢弃过程的阈值可以用所谓的 丢弃标记 设置：

将 object 替换为 MainMsg 或 Action 以分别将此选项用于主消息队列或操作队列。在这里，number 代表消息队列中的消息达到此数量才开始丢弃。要定义要丢弃的消息，请使用：

将 priority 替换为以下关键字之一（或数字）：debug (7)、info (6)、notice (5)、warning (4)、err (3)、crit (2)、alert (1) 和 emerg (0)。使用此设置，在达到丢弃标记后，将立即从队列中删除具有低于定义优先级的新传入和已排队消息。

您可以配置 rsyslog 以在特定时间段内处理队列。例如，使用此选项，您可以将一些处理转移到非高峰时间。要定义时间范围，请使用以下语法：

使用 hour 您可以指定限制时间的小时数框架。使用没有分钟的 24 小时格式。

一个 worker thread 对排队的消息执行指定的操作。例如，在主消息队列中，一个工作任务是将过滤逻辑应用于每个传入的消息，并将它们排入相关的操作队列。当消息到达时，会自动启动一个工作线程。当消息数量达到一定数量时，会开启另一个工作线程。要指定此数字，请使用：

将 number 替换为将触发补充工作线程的消息数。例如，将 number 设置为 100，当超过 100 条消息到达时启动一个新的工作线程。当超过 200 条消息到达时，第三个工作线程启动，依此类推。但是，并行运行的工作线程过多会变得低效，因此您可以使用以下方法限制它们的最大数量：

其中 number 代表可以并行运行的最大工作线程数。对于主消息队列，默认限制为 1 个线程。一旦启动了工作线程，它就会一直运行，直到出现不活动超时。要设置超时长度，请键入：

将 time 替换为以毫秒为单位的持续时间。如果没有此设置，则会应用零超时，并且工作线程在消息用完时会立即终止。如果您将 time 指定为 -1，则不会关闭任何线程。

为了提高性能，您可以配置 rsyslog 以一次将多条消息出列。要设置此类出队的上限，请使用：

将 number 替换为一次可以出队的最大消息数。请注意，更高的设置与更多的允许工作线程相结合会导致更大的内存消耗。

当终止仍然包含消息的队列时，可以尝试通过指定工作线程完成队列处理的时间间隔来尽量减少数据丢失：

以毫秒为单位指定 time。如果在那段时间之后仍有一些排队的消息，工作线程完成当前数据元素然后终止。因此，未处理的消息会丢失。可以为工作线程设置另一个时间间隔来完成最后一个元素：

如果此超时到期，任何剩余的工作线程都将关闭。要在关机时保存数据，请使用：

如果设置，所有队列元素都会在 rsyslog 终止之前保存到磁盘。

Rsyslog 7 有许多不同的模板样式。字符串模板最接近旧格式。使用字符串格式从上面的示例中复制模板如下所示：

这些模板也可以写成列表格式如下：

这种模板文本格式对于那些刚接触 rsyslog 的人来说可能更容易阅读，因此更容易适应需求改变。

完成对新语法的更改，我们需要重现模块加载命令，添加规则集，然后将规则集绑定到协议、端口和规则集：

The Text File Input Module, abbreviated as imfile, enables rsyslog to convert any text file into a stream of syslog messages. You can use imfile to import log messages from applications that create their own text file logs. To load imfile, add the following into /etc/rsyslog.conf:

It is sufficient to load imfile once, even when importing multiple files. The $InputFilePollInterval global directive specifies how often rsyslog checks for changes in connected text files. The default interval is 10 seconds, to change it, replace int with a time interval specified in seconds.

To identify the text files to import, use the following syntax in /etc/rsyslog.conf:

Four settings are required to specify an input text file:

Apart from the required directives, there are several other settings that can be applied on the text input. Set the severity of imported messages by replacing severity with an appropriate keyword. Replace facility with a keyword to define the subsystem that produced the message. The keywords for severity and facility are the same as those used in facility/priority-based filters, see Filters.

Processing of log data can be faster and more convenient when performed in a database rather than with text files. Based on the type of DBMS used, choose from various output modules such as ommysql, ompgsql, omoracle, or ommongodb. As an alternative, use the generic omlibdbi output module that relies on the libdbi library. The omlibdbi module supports database systems Firebird/Interbase, MS SQL, Sybase, SQLite, Ingres, Oracle, mSQL, MySQL, and PostgreSQL.

Confidentiality and integrity in network transmissions can be provided by either the TLS or GSSAPI encryption protocol.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communication security over the network. When using TLS, rsyslog messages are encrypted before sending, and mutual authentication exists between the sender and receiver.

Generic Security Service API (GSSAPI) is an application programming interface for programs to access security services. To use it in connection with rsyslog you must have a functioning Kerberos environment.

Reliable Event Logging Protocol (RELP) is a networking protocol for data logging in computer networks. It is designed to provide reliable delivery of event messages, which makes it useful in environments where message loss is not acceptable.

The imjournal module is Rsyslog's input module to natively read the journal files (see Interaction of Rsyslog and Journal). Journal messages are then logged in text format as other rsyslog messages. However, with further processing, it is possible to translate meta data provided by Journal into a structured message.

To import data from Journal to Rsyslog, use the following configuration in /etc/rsyslog.conf:

You can translate all data and meta data stored by Journal into structured messages. Some of these meta data entries are listed in Verbose journalctl Output, for a complete list of journal fields see the systemd.journal-fields(7) manual page. For example, it is possible to focus on kernel journal fields, that are used by messages originating in the kernel.

To create a lumberjack-formatted message that is required by rsyslog's parsing module, use the following template:

This template prepends the @cee: string to the JSON string and can be applied, for example, when creating an output file with omfile module. To access JSON field names, use the $! prefix. For example, the following filter condition searches for messages with specific hostname and UID:

The mmjsonparse module is used for parsing structured messages.

These messages can come from Journal or from other input sources, and must be formatted in a way defined by the Lumberjack project. These messages are identified by the presence of the @cee: string. Then, mmjsonparse checks if the JSON structure is valid and then the message is parsed.

To parse lumberjack-formatted JSON messages with mmjsonparse, use the following configuration in the /etc/rsyslog.conf:

In this example, the mmjsonparse module is loaded on the first line, then all messages are forwarded to it. Currently, there are no configuration parameters available for mmjsonparse.

Rsyslog supports storing JSON logs in the MongoDB document database through the ommongodb output module.

To forward log messages into MongoDB, use the following syntax in the /etc/rsyslog.conf (configuration parameters for ommongodb are available only in the new configuration format; see Using the New Configuration Format):

You can shape the form of the final database output with use of templates. By default, rsyslog uses a template based on standard lumberjack field names.

To access the journal logs, use the journalctl tool. For a basic view of the logs type as root:

An output of this command is a list of all log files generated on the system including messages generated by system components and by users. The structure of this output is similar to one used in /var/log/messages/ but with certain improvements:

In many cases, only the latest entries in the journal log are relevant. The simplest way to reduce journalctl output is to use the -n option that lists only the specified number of most recent log entries:

Replace Number with the number of lines to be shown. When no number is specified, journalctl displays the ten most recent entries.

The journalctl command allows controlling the form of the output with the following syntax:

Replace form with a keyword specifying a desired form of output. There are several options, such as verbose, which returns full-structured entry items with all fields, export, which creates a binary stream suitable for backups and network transfer, and json, which formats entries as JSON data structures. For the full list of keywords, see the journalctl(1) manual page.

By default, Journal users without root privileges can only see log files generated by them. The system administrator can add selected users to the adm group, which grants them access to complete log files. To do so, type as root:

Here, replace username with a name of the user to be added to the adm group. This user then receives the same output of the journalctl command as the root user. Note that access control only works when persistent storage is enabled for Journal.

When called without parameters, journalctl shows the full list of entries, starting with the oldest entry collected. With the live view, you can supervise the log messages in real time as new entries are continuously printed as they appear. To start journalctl in live view mode, type:

This command returns a list of the ten most current log lines. The journalctl utility then stays running and waits for new changes to show them immediately.

The output of the journalctl command executed without parameters is often extensive, therefore you can use various filtering methods to extract information to meet your needs.

Log messages are often used to track erroneous behavior on the system. To view only entries with a selected or higher priority, use the following syntax:

Here, replace priority with one of the following keywords (or with a number): debug (7), info (6), notice (5), warning (4), err (3), crit (2), alert (1), and emerg (0).

To view log entries only from the current boot, type:

If you reboot your system just occasionally, the -b will not significantly reduce the output of journalctl. In such cases, time-based filtering is more helpful:

With --since and --until, you can view only log messages created within a specified time range. You can pass values to these options in form of date or time or both as shown in the following example.

Verbose journalctl Output lists a set of fields that specify a log entry and can all be used for filtering. For a complete description of meta data that systemd can store, see the systemd.journal-fields(7) manual page. This meta data is collected for each log message, without user intervention. Values are usually text-based, but can take binary and large values; fields can have multiple values assigned though it is not very common.

To view a list of unique values that occur in a specified field, use the following syntax:

Replace fieldname with a name of a field you are interested in.

To show only log entries that fit a specific condition, use the following syntax:

Replace fieldname with a name of a field and value with a specific value contained in that field. As a result, only lines that match this condition are returned.

You can specify multiple values for one field:

Specifying two matches for the same field results in a logical OR combination of the matches. Entries matching value1 or value2 are displayed.

Also, you can specify multiple field-value pairs to further reduce the output set:

If two matches for different field names are specified, they will be combined with a logical AND. Entries have to match both conditions to be shown.

With use of the + symbol, you can set a logical OR combination of matches for multiple fields:

This command returns entries that match at least one of the conditions, not only those that match both of them.

You can apply the aforementioned filtering also in the live-view mode to keep track of the latest changes in the selected group of log entries:

By default, Journal stores log files only in memory or a small ring-buffer in the /run/log/journal/ directory. This is sufficient to show recent log history with journalctl. This directory is volatile, log data is not saved permanently. With the default configuration, syslog reads the journal logs and stores them in the /var/log/ directory. With persistent logging enabled, journal files are stored in /var/log/journal which means they persist after reboot. Journal can then replace rsyslog for some users (but see the chapter introduction).

Enabled persistent storage has the following advantages

Persistent storage has also certain disadvantages:

To enable persistent storage for Journal, create the journal directory manually as shown in the following example. As root type:

Then, restart journald to apply the change:

Most log files are stored in plain text format. You can view them with any text editor such as Vi or Emacs. Some log files are readable by all users on the system; however, root privileges are required to read most log files. To view system log files in an interactive, real-time application, use the System Log.

After you have installed the gnome-system-log package, open the System Log by clicking Applications  System Tools  System Log, or type the following command at a shell prompt:

The application only displays log files that exist; thus, the list might differ from the one shown in System Log.

The System Log application lets you filter any existing log file. Click on the button marked with the gear symbol to view the menu, select menu:[Filters > > Manage Filters] to define or edit the desired filter.

Adding or editing a filter lets you define its parameters as is shown in System Log - defining a filter.

When defining a filter, the following parameters can be edited:

When you have at least one filter defined, it can be selected from the Filters menu and it will automatically search for the strings you have defined in the filter and highlight or hide every successful match in the log file you are currently viewing.

When you select the Show matches only option, only the matched strings will be shown in the log file you are currently viewing.

To add a log file you want to view in the list, select File    Open. This will display the Open Log window where you can select the directory and file name of the log file you want to view. System Log - adding a log file illustrates the Open Log window.

Click on the Open button to open the file. The file is immediately added to the viewing list where you can select it and view its contents.

System Log monitors all opened logs by default. If a new line is added to a monitored log file, the log name appears in bold in the log list. If the log file is selected or displayed, the new lines appear in bold at the bottom of the log file. System Log - new log alert illustrates a new alert in the cron log file and in the messages log file. Clicking on the messages log file displays the logs in the file with the new lines in bold.