Melihat dan Mengelola Berkas Log

Aturan ditentukan oleh bagian filter, yang memilih subset pesan syslog, dan bagian action, yang menentukan apa yang harus dilakukan dengan pesan yang dipilih. Untuk menentukan aturan dalam berkas konfigurasi /etc/rsyslog.conf Anda, tentukan keduanya, filter dan tindakan, pada satu baris dan memisahkan mereka dengan satu atau beberapa spasi atau tab.

rsyslog menawarkan berbagai cara untuk memfilter pesan syslog sesuai dengan properti yang dipilih. Metode pemfilteran yang tersedia dapat dibagi menjadi Filter berbasis Fasilitas/Prioritas, Berbasis properti, dan Berbasis ekspresi.

dimana:

Sintaks yang disebutkan di atas memilih pesan syslog dengan prioritas yang ditentukan atau lebih tinggi. Dengan mendahului kata kunci prioritas apa pun dengan tanda sama dengan (=), Anda menentukan bahwa hanya pesan syslog dengan prioritas yang ditentukan yang akan dipilih. Semua prioritas lainnya akan diabaikan. Sebaliknya, sebelum kata kunci prioritas dengan tanda seru (!) memilih semua pesan syslog kecuali yang memiliki prioritas yang ditentukan.

Selain kata kunci yang ditentukan di atas, Anda juga dapat menggunakan tanda bintang (*) untuk menentukan semua fasilitas atau prioritas (tergantung di mana Anda menempatkan tanda bintang, sebelum atau sesudah koma). Menentukan kata kunci prioritas none berfungsi untuk fasilitas tanpa prioritas yang diberikan. Baik fasilitas dan kondisi prioritas tidak peka huruf besar/kecil.

Untuk menentukan beberapa fasilitas dan prioritas, pisahkan dengan koma (,). Untuk menentukan beberapa pemilih pada satu baris, pisahkan mereka dengan titik koma (;). Perhatikan bahwa setiap pemilih di bidang pemilih mampu menimpa yang sebelumnya, yang dapat mengecualikan beberapa prioritas dari pola.

Filter berbasis properti harus dimulai dengan titik dua (:). Untuk menentukan filter, gunakan sintaks berikut:

dimana:

Sintaks dasar filter berbasis ekspresi terlihat sebagai berikut:

dimana:

Dengan filter berbasis ekspresi, Anda dapat membuat syarat berlapis dengan menggunakan skrip yang diapit kurung kurawal seperti pada Filter berbasis ekspresi. Skrip memungkinkan Anda menggunakan filter facility/priority-based di dalam ekspresi. Di sisi lain, filter berbasis properti tidak direkomendasikan di sini. RainerScript mendukung ekspresi reguler dengan fungsi khusus re_match() dan re_extract().

Lihat Dokumentasi Daring untuk lebih banyak contoh berbagai filter berbasis ekspresi. RainerScript adalah dasar untuk format konfigurasi baru rsyslog, lihat Menggunakan Format Konfigurasi Baru

Tindakan menentukan apa yang harus dilakukan dengan pesan yang difilter oleh pemilih yang sudah ditentukan. Berikut ini adalah beberapa tindakan yang dapat Anda tentukan dalam aturan Anda:

di mana FILTER adalah singkatan dari pemilih yang ditentukan pengguna dan PATH adalah path berkas target.

Misalnya, aturan berikut terdiri dari pemilih yang memilih semua pesan syslog cron dan tindakan yang menyimpannya ke dalam berkas log /var/log/cron.log:

Secara baku, berkas log disinkronkan setiap kali pesan syslog dibuat. Gunakan tanda hubung (-) sebagai prefiks path berkas yang Anda tentukan untuk meniadakan sinkronisasi:

Perhatikan bahwa Anda mungkin kehilangan informasi jika sistem berakhir tepat setelah upaya penulisan. Namun, pengaturan ini dapat meningkatkan kinerja, terutama jika Anda menjalankan program yang menghasilkan pesan log yang sangat bertele-tele.

Path berkas yang Anda tentukan dapat berupa statik atau dinamik. Berkas statik diwakili oleh path berkas tetap seperti yang ditunjukkan pada contoh di atas. Path berkas dinamik dapat berbeda sesuai dengan pesan yang diterima. Path berkas dinamik diwakili oleh templat dan prefiks tanda tanya (?):

di mana DynamicFile adalah nama templat yang telah ditentukan yang memodifikasi path keluaran. Anda dapat menggunakan prefiks tanda hubung (-) untuk menonaktifkan sinkronisasi, juga Anda dapat menggunakan beberapa templat yang dipisahkan oleh titik dua (;) . Untuk informasi selengkapnya tentang templat, lihat Menghasilkan Nama Berkas Dinamik.

Jika berkas yang Anda tentukan adalah perangkat terminal atau /dev/console yang sudah ada, pesan syslog masing-masing dikirim ke keluaran standar (menggunakan penanganan terminal khusus) atau konsol Anda (menggunakan penanganan khusus /dev/console) saat menggunakan X Window System.

dimana:

Saat menentukan alamat IPv6 sebagai host, lampirkan alamat dalam tanda kurung siku ([, ]).

dimana:

Untuk menggunakan saluran keluaran yang ditentukan sebagai tindakan di dalam aturan, ketik:

Di sini keluaran dari kondisi FILTER diproses oleh program yang diwakili oleh EXECUTABLE. Program ini dapat berupa executable yang valid. Ganti TEMPLATE dengan nama templat pemformatan.

dimana:

Tindakan membuang sebagian besar digunakan untuk menyaring pesan sebelum melakukan pemrosesan lebih lanjut. Ini bisa efektif jika Anda ingin menghilangkan beberapa pesan berulang yang jika tidak akan memenuhi berkas log. Hasil tindakan buang tergantung pada di mana dalam berkas konfigurasi ditentukan, untuk hasil terbaik tempatkan tindakan ini di atas daftar tindakan. Harap dicatat bahwa setelah pesan telah dibuang, tidak ada cara untuk mengambilnya di baris berkas konfigurasi nanti.

Misalnya, aturan berikut membuang pesan syslog cron apa pun:

Untuk setiap pemilih, Anda diizinkan untuk menentukan beberapa tindakan. Untuk menentukan beberapa tindakan untuk satu pemilih, tulis setiap tindakan pada baris terpisah dan mendahuluinya dengan karakter ampersand (&):

Menentukan beberapa tindakan meningkatkan kinerja keseluruhan dari hasil yang diinginkan karena pemilih yang ditentukan harus dievaluasi hanya sekali.

Tindakan apa pun dapat diikuti oleh templat yang memformat pesan. Untuk menentukan templat, tambahkan titik koma (;) di akhir tindakan dan tentukan nama templat. Untuk informasi selengkapnya tentang templat, lihat Templat.

Setiap keluaran yang dihasilkan oleh rsyslog dapat dimodifikasi dan diformat sesuai dengan kebutuhan Anda dengan menggunakan templat. Untuk membuat templat, gunakan sintaks berikut di /etc/rsyslog.conf:

dimana:

Templates can be used to generate dynamic file names. By specifying a property as a part of the file path, a new file will be created for each unique property, which is a convenient way to classify syslog messages.

For example, use the timegenerated property, which extracts a time stamp from the message, to generate a unique file name for each syslog message:

Keep in mind that the $template directive only specifies the template. You must use it inside a rule for it to take effect. In /etc/rsyslog.conf, use the question mark (?) in an action definition to mark the dynamic file name template:

Properties defined inside a template (between two percent signs (%)) enable access various contents of a syslog message through the use of a property replacer. To define a property inside a template (between the two quotation marks (“…”)), use the following syntax:

dimana:

The following are some examples of simple properties:

This section presents a few examples of rsyslog templates.

A verbose syslog message template shows a template that formats a syslog message so that it outputs the message’s severity, facility, the time stamp of when the message was received, the host name, the message tag, the message text, and ends with a new line.

A wall message template shows a template that resembles a traditional wall message (a message that is send to every user that is logged in and has their mesg(1) permission set to yes). This template outputs the message text, along with a host name, message tag and a time stamp, on a new line (using \r and \n) and rings the bell (using \7).

A database formatted message template shows a template that formats a syslog message so that it can be used as a database query. Notice the use of the sql option at the end of the template specified as the template option. It tells the database writer to format the message as an MySQL SQL query.

rsyslog also contains a set of predefined templates identified by the RSYSLOG_ prefix. These are reserved for the syslog’s use and it is advisable to not create a template using this prefix to avoid conflicts. The following list shows these predefined templates along with their definitions.

Global directives are configuration options that apply to the rsyslogd daemon. They usually specify a value for a specific predefined variable that affects the behavior of the rsyslogd daemon or a rule that follows. All of the global directives must start with a dollar sign ($). Only one directive can be specified per line. The following is an example of a global directive that specifies the maximum size of the syslog message queue:

The default size defined for this directive (10,000 messages) can be overridden by specifying a different value (as shown in the example above).

You can define multiple directives in your /etc/rsyslog.conf configuration file. A directive affects the behavior of all configuration options until another occurrence of that same directive is detected. Global directives can be used to configure actions, queues and for debugging. A comprehensive list of all available configuration directives can be found in Online Documentation. Currently, a new configuration format has been developed that replaces the $-based syntax (see Using the New Configuration Format). However, classic global directives remain supported as a legacy format.

The following is a sample /etc/logrotate.conf configuration file:

All of the lines in the sample configuration file define global options that apply to every log file. In our example, log files are rotated weekly, rotated log files are kept for four weeks, and all rotated log files are compressed by gzip into the .gz format. Any lines that begin with a hash sign (#) are comments and are not processed.

You may define configuration options for a specific log file and place it under the global options. However, it is advisable to create a separate configuration file for any specific log file in the /etc/logrotate.d/ directory and define any configuration options there.

The following is an example of a configuration file placed in the /etc/logrotate.d/ directory:

The configuration options in this file are specific for the /var/log/messages log file only. The settings specified here override the global settings where possible. Thus the rotated /var/log/messages log file will be kept for five weeks instead of four weeks as was defined in the global options.

The following is a list of some of the directives you can specify in your logrotate configuration file:

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

Leaving special directives aside, rsyslog handles messages as defined by rules that consist of a filter condition and an action to be performed if the condition is true. With a traditionally written /etc/rsyslog.conf file, all rules are evaluated in order of appearance for every input message. This process starts with the first rule and continues until all rules have been processed or until the message is discarded by one of the rules.

However, rules can be grouped into sequences called rulesets. With rulesets, you can limit the effect of certain rules only to selected inputs or enhance the performance of rsyslog by defining a distinct set of actions bound to a specific input. In other words, filter conditions that will be inevitably evaluated as false for certain types of messages can be skipped. The legacy ruleset definition in /etc/rsyslog.conf can look as follows:

The rule ends when another rule is defined, or the default ruleset is called as follows:

With the new configuration format in rsyslog 7, the input() and ruleset() statements are reserved for this operation. The new format ruleset definition in /etc/rsyslog.conf can look as follows:

Replace rulesetname with an identifier for your ruleset. The ruleset name cannot start with RSYSLOG_ since this namespace is reserved for use by rsyslog. RSYSLOG_DefaultRuleset then defines the default set of rules to be performed if the message has no other ruleset assigned. With rule and rule2 you can define rules in filter-action format mentioned above. With the call parameter, you can nest rulesets by calling them from inside other ruleset blocks.

After creating a ruleset, you need to specify what input it will apply to:

Here you can identify an input message by input_type, which is an input module that gathered the message, or by port_num – the port number. Other parameters such as file or tag can be specified for input(). Replace rulesetname with a name of the ruleset to be evaluated against the message. In case an input message is not explicitly bound to a ruleset, the default ruleset is triggered.

You can also use the legacy format to define rulesets, for more information see Online Documentation.

From rsyslog version 6, compatibility mode specified via the -c option has been removed. Also, the syslogd-style command-line options are deprecated and configuring rsyslog through these command-line options should be avoided. However, you can use several templates and directives to configure rsyslogd to emulate syslogd-like behavior.

For more information on various rsyslogd options, see the rsyslogd(8)manual page.

Based on where the messages are stored, there are several types of queues: direct, in-memory, disk, and disk-assisted in-memory queues that are most widely used. You can choose one of these types for the main message queue and also for action queues. Add the following into /etc/rsyslog.conf:

Here, you can apply the setting for the main message queue (replace object with MainMsg) or for an action queue (replace object with Action). Replace queue_type with one of direct, linkedlist or fixedarray (which are in-memory queues), or disk.

The default setting for a main message queue is the FixedArray queue with a limit of 10,000 messages. Action queues are by default set as Direct queues.

For many simple operations, such as when writing output to a local file, building a queue in front of an action is not needed. To avoid queuing, use:

Replace object with MainMsg or with Action to use this option to the main message queue or for an action queue respectively. With direct queue, messages are passed directly and immediately from the producer to the consumer.

Disk queues store messages strictly on a hard drive, which makes them highly reliable but also the slowest of all possible queuing modes. This mode can be used to prevent the loss of highly important log data. However, disk queues are not recommended in most use cases. To set a disk queue, type the following into /etc/rsyslog.conf:

Replace object with MainMsg or with Action to use this option to the main message queue or for an action queue respectively. Disk queues are written in parts, with a default size 10 Mb. This default size can be modified with the following configuration directive:

where size represents the specified size of disk queue part. The defined size limit is not restrictive, rsyslog always writes one complete queue entry, even if it violates the size limit. Each part of a disk queue matches with an individual file. The naming directive for these files looks as follows:

This sets a name prefix for the file followed by a 7-digit number starting at one and incremented for each file.

With in-memory queue, the enqueued messages are held in memory which makes the process very fast. The queued data is lost if the computer is power cycled or shut down. However, you can use the $ActionQueueSaveOnShutdown setting to save the data before shutdown. There are two types of in-memory queues:

In general, use LinkedList queues when in doubt. Compared to FixedArray, it consumes less memory and lowers the processing overhead.

Use the following syntax to configure in-memory queues:

Replace object with MainMsg or with Action to use this option to the main message queue or for an action queue respectively.

Both disk and in-memory queues have their advantages and rsyslog lets you combine them in disk-assisted in-memory queues. To do so, configure a normal in-memory queue and then add the $objectQueueFileName directive to define a file name for disk assistance. This queue then becomes disk-assisted, which means it couples an in-memory queue with a disk queue to work in tandem.

The disk queue is activated if the in-memory queue is full or needs to persist after shutdown. With a disk-assisted queue, you can set both disk-specific and in-memory specific configuration parameters. This type of queue is probably the most commonly used, it is especially useful for potentially long-running and unreliable actions.

To specify the functioning of a disk-assisted in-memory queue, use the so-called watermarks:

Replace object with MainMsg or with Action to use this option to the main message queue or for an action queue respectively. Replace number with a number of enqueued messages. When an in-memory queue reaches the number defined by the high watermark, it starts writing messages to disk and continues until the in-memory queue size drops to the number defined with the low watermark. Correctly set watermarks minimize unnecessary disk writes, but also leave memory space for message bursts since writing to disk files is rather lengthy. Therefore, the high watermark must be lower than the whole queue capacity set with $objectQueueSize. The difference between the high watermark and the overall queue size is a spare memory buffer reserved for message bursts. On the other hand, setting the high watermark too low will turn on disk assistance unnecessarily often.

All types of queues can be further configured to match your requirements. You can use several directives to modify both action queues and the main message queue. Currently, there are more than 20 queue parameters available, see Online Documentation. Some of these settings are used commonly, others, such as worker thread management, provide closer control over the queue behavior and are reserved for advanced users. With advanced settings, you can optimize rsyslog's performance, schedule queuing, or modify the behavior of a queue on system shutdown.

You can limit the number of messages that queue can contain with the following setting:

Replace object with MainMsg or with Action to use this option to the main message queue or for an action queue respectively. Replace number with a number of enqueued messages. You can set the queue size only as the number of messages, not as their actual memory size. The default queue size is 10,000 messages for the main message queue and ruleset queues, and 1000 for action queues.

Disk assisted queues are unlimited by default and can not be restricted with this directive, but you can reserve them physical disk space in bytes with the following settings:

Replace object with MainMsg or with Action. When the size limit specified by number is hit, messages are discarded until sufficient amount of space is freed by dequeued messages.

When a queue reaches a certain number of messages, you can discard less important messages in order to save space in the queue for entries of higher priority. The threshold that launches the discarding process can be set with the so-called discard mark:

Replace object with MainMsg or with Action to use this option to the main message queue or for an action queue respectively. Here, number stands for a number of messages that have to be in the queue to start the discarding process. To define which messages to discard, use:

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). With this setting, both newly incoming and already queued messages with lower than defined priority are erased from the queue immediately after the discard mark is reached.

You can configure rsyslog to process queues during a specific time period. With this option you can, for example, transfer some processing into off-peak hours. To define a time frame, use the following syntax:

With hour you can specify hours that bound your time frame. Use the 24-hour format without minutes.

A worker thread performs a specified action on the enqueued message. For example, in the main message queue, a worker task is to apply filter logic to each incoming message and enqueue them to the relevant action queues. When a message arrives, a worker thread is started automatically. When the number of messages reaches a certain number, another worker thread is turned on. To specify this number, use:

Replace number with a number of messages that will trigger a supplemental worker thread. For example, with number set to 100, a new worker thread is started when more than 100 messages arrive. When more than 200 messages arrive, the third worker thread starts and so on. However, too many working threads running in parallel becomes ineffective, so you can limit the maximum number of them by using:

where number stands for a maximum number of working threads that can run in parallel. For the main message queue, the default limit is 1 thread. Once a working thread has been started, it keeps running until an inactivity timeout appears. To set the length of timeout, type:

Replace time with the duration set in milliseconds. Without this setting, a zero timeout is applied and a worker thread is terminated immediately when it runs out of messages. If you specify time as -1, no thread will be closed.

To increase performance, you can configure rsyslog to dequeue multiple messages at once. To set the upper limit for such dequeueing, use:

Replace number with the maximum number of messages that can be dequeued at once. Note that a higher setting combined with a higher number of permitted working threads results in greater memory consumption.

When terminating a queue that still contains messages, you can try to minimize the data loss by specifying a time interval for worker threads to finish the queue processing:

Specify time in milliseconds. If after that period there are still some enqueued messages, workers finish the current data element and then terminate. Unprocessed messages are therefore lost. Another time interval can be set for workers to finish the final element:

In case this timeout expires, any remaining workers are shut down. To save data at shutdown, use:

If set, all queue elements are saved to disk before rsyslog terminates.

Rsyslog 7 has a number of different templates styles. The string template most closely resembles the legacy format. Reproducing the templates from the example above using the string format would look as follows:

These templates can also be written in the list format as follows:

This template text format might be easier to read for those new to rsyslog and therefore can be easier to adapt as requirements change.

To complete the change to the new syntax, we need to reproduce the module load command, add a rule set, and then bind the rule set to the protocol, port, and ruleset:

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).

Penyimpanan persisten yang diaktifkan memiliki keunggulan berikut

Penyimpanan persisten juga memiliki kelemahan tertentu:

Untuk mengaktifkan penyimpanan persisten bagi Jurnal, buat direktori jurnal secara manual seperti yang ditunjukkan dalam contoh berikut. Sebagai root ketikkan:

Kemudian, jalankan ulang journald untuk menerapkan perubahan:

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.

Saat Anda memilih opsi Tampilkan hanya kecocokan, hanya string yang cocok yang akan ditampilkan dalam berkas log yang saat ini Anda lihat.

Untuk menambahkan berkas log yang ingin Anda lihat dalam daftar, pilih Berkas    Buka. Ini akan menampilkan jendela Buka Log di mana Anda dapat memilih direktori dan nama berkas dari berkas log yang ingin Anda lihat. Log Sistem - menambahkan berkas log menggambarkan jendela Buka Log.

Klik tombol Buka untuk membuka berkas. Berkas segera ditambahkan ke daftar tampilan di mana Anda dapat memilihnya dan melihat isinya.

Log Sistem memantau semua log yang dibuka secara baku. Jika baris baru ditambahkan ke berkas log yang dipantau, nama log akan muncul dalam huruf tebal di daftar log. Jika berkas log dipilih atau ditampilkan, baris baru muncul dalam huruf tebal di bagian bawah berkas log. Log Sistem - peringatan log baru menggambarkan peringatan baru dalam berkas log cron dan dalam berkas log messages. Mengklik berkas log messages menampilkan log dalam berkas dengan baris baru memakai huruf tebal.