Documentation for a newer release is available. View Latest

Melihat dan Mengelola Berkas Log

Berkas log bisa sangat berguna ketika mencoba memecahkan masalah sistem seperti mencoba memuat driver kernel atau saat mencari upaya login yang tidak sah ke sistem. Bab ini membahas di mana menemukan berkas log, cara melihat berkas log, dan apa yang harus dicari dalam berkas log. Beberapa berkas log dikendalikan oleh daemon yang disebut rsyslogd. Daemon rsyslogd adalah pengganti yang disempurnakan untuk sysklogd, dan menyediakan pemfilteran yang diperluas, penyampaian pesan yang dilindungi enkripsi, berbagai opsi konfigurasi, modul masukan dan keluaran, dukungan untuk transportasi melalui protokol TCP atau UDP. Perhatikan bahwa rsyslog kompatibel dengan sysklogd.

Berkas log juga dapat dikelola oleh daemon journald – komponen systemd. Daemon journald menangkap pesan Syslog, pesan log kernel, disk RAM awal, dan pesan boot awal serta pesan yang ditulis ke keluaran standar dan keluaran kesalahan standar dari semua layanan, mengindeksnya dan membuat ini tersedia bagi pengguna. Format berkas jurnal asli, yang merupakan berkas biner terstruktur dan terindeks, memperbaiki pencarian dan memberikan operasi yang lebih cepat, dan juga menyimpan informasi data meta seperti stempel waktu atau ID pengguna. Berkas log yang dihasilkan oleh journald secara baku tidak persisten, berkas log hanya disimpan dalam memori atau penyangga cincin kecil di direktori /run/log/journal/. Banyaknya data yang dicatat tergantung pada memori bebas, ketika Anda mencapai batas kapasitas, entri tertua akan dihapus. Namun, pengaturan ini dapat diubah – lihat Memfungsikan Penyimpanan Persisten. Untuk informasi lebih lanjut tentang Jurnal lihat Memakai Jurnal.

Secara default, hanya journald yang dipasang pada sistem Anda. Anda harus memasang rsyslog sendiri. Juga jangan lupa untuk mengaktifkan dan memulainya setelah memasang sebelum melanjutkan dengan sisa panduan ini. Daemon journald adalah alat utama untuk pemecahan masalah. Ini juga menyediakan data tambahan yang diperlukan untuk membuat pesan log terstruktur. Data yang diperoleh oleh journald diteruskan ke soket /run/systemd/journal/syslog yang dapat digunakan oleh rsyslogd untuk memroses data lebih lanjut. Namun, rsyslog melakukan integrasi aktual secara default melalui modul masukan imjournal, sehingga menghindari soket yang disebutkan di atas. Anda juga dapat mentransfer data ke arah yang berlawanan, dari rsyslogd ke journald dengan menggunakan modul omjournal. Lihat Interaksi Rsyslog dan Jurnal untuk informasi lebih lanjut. Integrasi ini memungkinkan mempertahankan log berbasis teks dalam format yang konsisten untuk memastikan kompatibilitas dengan kemungkinan aplikasi atau konfigurasi yang bergantung pada rsyslogd. Selain itu, Anda dapat memelihara pesan rsyslog dalam format terstruktur (lihat Pencatatan Log Terstruktur dengan Rsyslog).

Menemukan Berkas Log

Daftar berkas log yang dikelola oleh rsyslogd dapat ditemukan di berkas konfigurasi /etc/rsyslog.conf. Sebagian besar berkas log terletak di direktori /var/log/. Beberapa aplikasi seperti httpd dan samba memiliki direktori dalam /var/log/ untuk berkas log mereka. Anda mungkin melihat beberapa berkas di direktori /var/log/ dengan angka setelahnya (misalnya, cron-20100906). Angka-angka ini mewakili stempel waktu yang telah ditambahkan ke berkas log yang diputar. Berkas log dirotasi sehingga ukuran berkas mereka tidak menjadi terlalu besar. Paket logrotate berisi tugas cron yang secara otomatis memrotasi berkas log sesuai dengan berkas konfigurasi /etc/logrotate.conf dan berkas konfigurasi di direktori /etc/logrotate.d/.

Konfigurasi Dasar Rsyslog

Berkas konfigurasi utama untuk rsyslog adalah /etc/rsyslog.conf. Di sini, Anda dapat menentukan direktif global, modul, dan aturan yang terdiri dari bagian filter dan action. Selain itu, Anda dapat menambahkan komentar dalam bentuk teks setelah tanda hash (#).

Tapis

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.

Filter berbasis fasilitas/prioritas

Cara yang paling banyak digunakan dan terkenal untuk memfilter pesan syslog adalah dengan menggunakan filter berbasis fasilitas/prioritas yang memfilter pesan syslog berdasarkan dua kondisi: facility dan priority dipisahkan oleh titik. Untuk membuat pemilih, gunakan sintaks berikut:

FACILITY.PRIORITY

dimana:

  • FACILITY menentukan subsistem yang menghasilkan pesan syslog tertentu. Misalnya, subsistem mail menangani semua pesan syslog terkait email. FACILITY dapat diwakili oleh salah satu kata kunci berikut (atau dengan kode numerik): kern (0), user (1), mail (2), daemon (3), auth (4), syslog (5), lpr (6), news (7), uucp (8), cron (9), authpriv (10), ftp (11), ntp (12), logaudit (13), logalert (14), clock (15), dan local0 sampai local7 (16 - 23).

  • PRIORITY menentukan prioritas pesan syslog. PRIORITY dapat diwakili oleh salah satu kata kunci berikut (atau dengan angka): debug (7), info (6), notice (5), warning (4), err (3), crit (2), alert (1), dan emerg (0).

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.

Contoh 1. Filter Berbasis Fasilitas/Prioritas

Berikut ini adalah beberapa contoh filter berbasis fasilitas/prioritas sederhana yang dapat ditentukan dalam /etc/rsyslog.conf. Untuk memilih semua pesan syslog kernel dengan prioritas apa pun, tambahkan teks berikut ke dalam berkas konfigurasi:

kern.*

Untuk memilih semua pesan syslog surel dengan prioritas crit dan yang lebih tinggi, gunakan bentuk ini:

mail.crit

Untuk memilih semua pesan cron syslog kecuali yang memiliki prioritas info atau debug, atur konfigurasi dalam bentuk berikut:

cron.!info,!debug
Filter Berbasis Properti

Filter berbasis properti memungkinkan Anda memfilter pesan syslog berdasarkan properti apa pun, seperti timegenerated atau syslogtag. Untuk informasi selengkapnya tentang properti, lihat Properti. Anda dapat membandingkan masing-masing properti yang ditentukan dengan nilai tertentu menggunakan salah satu operasi perbandingan yang tercantum dalam Operasi perbandingan berbasis properti. Kedua nama properti dan operasi perbandingan peka huruf besar/kecil.

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

:PROPERTY, [!]COMPARE_OPERATION, "STRING"

dimana:

  • Atribut PROPERTY menentukan properti yang diinginkan.

  • Tanda seru opsional (!) meniadakan keluaran dari operasi perbandingan. Operator Boolean lainnya saat ini tidak didukung dalam filter berbasis properti.

  • Atribut COMPARE_OPERATION menentukan salah satu operasi perbandingan yang tercantum dalam Operasi perbandingan berbasis properti.

  • Atribut STRING menentukan nilai yang dibandingkan dengan teks yang disediakan oleh properti. Nilai ini harus diapit dalam tanda kutip. Untuk meng-escape karakter tertentu di dalam string (misalnya tanda kutip (")), gunakan karakter garis miring terbalik (\).

Tabel 1. Operasi perbandingan berbasis properti
Operasi-perbandingan Deskripsi

contains

Memeriksa apakah string yang disediakan cocok dengan bagian mana pun dari teks yang disediakan oleh properti. Untuk melakukan perbandingan tidak peka huruf besar kecil, gunakan contains_i.

isequal

Membandingkan string yang disediakan dengan semua teks yang disediakan oleh properti. Kedua nilai ini harus sama persis agar cocok.

startswith

Memeriksa apakah string yang disediakan ditemukan persis di awal teks yang disediakan oleh properti. Untuk melakukan perbandingan tidak peka huruf besar kecil, gunakan startswith_i.

regex

Membandingkan POSIX BRE (Basic Regular Expression) yang disediakan dengan teks yang disediakan oleh properti.

ereregex

Membandingkan ekspresi reguler POSIX ERE (Extended Regular Expression) yang disediakan terhadap teks yang disediakan oleh properti.

isempty

Memeriksa apakah properti kosong. Nilainya dibuang. Ini sangat berguna ketika bekerja dengan data yang dinormalisasi, di mana beberapa bidang dapat diisi berdasarkan hasil normalisasi.

Contoh 2. Filter Berbasis Properti

Berikut ini adalah beberapa contoh filter berbasis properti yang dapat ditentukan dalam /etc/rsyslog.conf. Untuk memilih pesan syslog yang berisi string error dalam teks pesannya, gunakan:

:msg, contains, "error"

Filter berikut memilih pesan syslog yang diterima dari nama host host1:

:hostname, isequal, "host1"

Untuk memilih pesan syslog yang tidak berisi penyebutan kata fatal dan error dengan teks apa pun atau tanpa teks di antara mereka (misalnya, fatal lib error), ketik:

:msg, !regex, "fatal .* error"
Filter berbasis ekspresi

Filter berbasis ekspresi memilih pesan syslog sesuai dengan operasi aritmatika, Boolean, atau string yang ditentukan. Filter berbasis ekspresi menggunakan bahasa skrip rsyslog sendiri yang disebut RainerScript untuk membuat filter yang kompleks.

Sintaks dasar filter berbasis ekspresi terlihat sebagai berikut:

if EXPRESSION then ACTION else ACTION

dimana:

  • Atribut EXPRESSION mewakili ekspresi yang akan dievaluasi, misalnya: $msg startswith 'DEVNAME' atau $syslogfacility-text == 'local0'. Anda dapat menentukan lebih dari satu ekspresi dalam satu filter dengan menggunakan operator and dan or.

  • Atribut ACTION mewakili tindakan yang akan dilakukan jika ekspresi mengembalikan nilai true. Ini bisa berupa tindakan tunggal, atau sebarang skrip kompleks yang diapit kurung kurawal.

  • Filter berbasis ekspresi ditunjukkan oleh kata kunci if di awal baris baru. Kata kunci then memisahkan EXPRESSION dari ACTION. Secara opsional, Anda dapat menggunakan kata kunci else untuk menentukan tindakan apa yang harus dilakukan jika kondisi tidak terpenuhi.

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

Contoh 3. Filter Berbasis Ekspresi

The following expression contains two nested conditions. The log files created by a program called prog1 are split into two files based on the presence of the "test" string in the message.

if $programname == 'prog1' then {
   action(type="omfile" file="/var/log/prog1.log")
   if $msg contains 'test' then
     action(type="omfile" file="/var/log/prog1test.log")
   else
     action(type="omfile" file="/var/log/prog1notest.log")
}

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

Aksi

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:

Menyimpan pesan syslog ke berkas log

Sebagian besar tindakan menentukan ke berkas log mana pesan syslog disimpan. Ini dilakukan dengan menentukan path berkas setelah pemilih yang sudah ditentukan:

FILTER PATH

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:

cron.* /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:

FILTER -PATH

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 (?):

FILTER ?DynamicFile

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.

Mengirim pesan syslog melalui jaringan

rsyslog memungkinkan Anda mengirim dan menerima pesan syslog melalui jaringan. Fitur ini memungkinkan Anda untuk mengelola pesan syslog dari beberapa host pada satu mesin. Untuk meneruskan pesan syslog ke mesin jarak jauh, gunakan sintaks berikut:

@(zNUMBER)HOST:PORT

dimana:

  • Tanda at (@) menunjukkan bahwa pesan syslog diteruskan ke host menggunakan protokol UDP. Untuk menggunakan protokol TCP, gunakan dua tanda tanpa spasi di antara mereka (@@).

  • Pengaturan opsional zNUMBER memungkinkan kompresi zlib untuk pesan syslog. Atribut NUMBER menentukan tingkat kompresi (dari 1 – terendah hingga 9 – maksimum). Penguatan kompresi secara otomatis diperiksa oleh rsyslogd, pesan dikompresi hanya jika ada penguatan kompresi dan pesan di bawah 60 byte tidak pernah dikompresi.

  • Atribut HOST menentukan host yang menerima pesan syslog yang dipilih.

  • Atribut PORT menentukan port mesin host.

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

Contoh 4. Mengirim Pesan syslog Melalui Jaringan

Berikut ini adalah beberapa contoh tindakan yang meneruskan pesan syslog melalui jaringan (perhatikan bahwa semua tindakan didahului dengan pemilih yang memilih semua pesan dengan prioritas apa pun). Untuk meneruskan pesan ke 192.168.0.1 melalui protokol UDP, ketik:

*.* @192.168.0.1

To forward messages to "example.com" using port 18 and the TCP protocol, use:

*.* @@example.com:18

Berikut ini mengompresi pesan dengan zlib (kompresi level 9) dan meneruskannya ke 2001:db8::1 menggunakan protokol UDP

*.* @(z9)[2001:db8::1]
Kanal keluaran

Saluran keluaran terutama digunakan untuk menentukan ukuran maksimum berkas log dapat tumbuh. Ini sangat berguna untuk rotasi berkas log (untuk informasi lebih lanjut lihat Rotasi Log). Saluran keluaran pada dasarnya adalah kumpulan informasi tentang aksi keluaran. Saluran keluaran didefinisikan oleh direktif $outchannel. Untuk menentukan saluran keluaran di /etc/rsyslog.conf, gunakan sintaks berikut:

$outchannel NAME, FILE_NAME, MAX_SIZE, ACTION

dimana:

  • Atribut NAME menentukan nama saluran keluaran.

  • Atribut FILE_NAME menentukan nama berkas keluaran. Saluran keluaran hanya dapat menulis ke dalam berkas, bukan pipa, terminal, atau jenis keluaran lainnya.

  • Atribut MAX_SIZE mewakili ukuran maksimum berkas yang ditentukan (dalam FILE_NAME) dapat tumbuh. Nilai ini ditentukan dalam byte.

  • Atribut ACTION menentukan tindakan yang diambil ketika ukuran maksimum, yang didefinisikan dalam MAX_SIZE, tercapai.

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

FILTER :omfile:$NAME
Contoh 5. Rotasi log kanal keluaran

Keluaran berikut menunjukkan rotasi log sederhana melalui penggunaan saluran keluaran. Pertama, saluran keluaran didefinisikan melalui direktif $outchannel:

 $outchannel log_rotation, /var/log/test_log.log, 104857600, /home/joe/log_rotation_script

dan kemudian digunakan dalam aturan yang memilih setiap pesan syslog dengan prioritas apa pun dan mengeksekusi saluran keluaran yang ditentukan sebelumnya pada pesan syslog yang diperoleh:

*.* :omfile:$log_rotation

Setelah batas (dalam contoh 100 MB) tercapai, /home/joe/log_rotation_script dijalankan. Skrip ini dapat berisi apa saja mulai dari memindahkan berkas ke folder yang berbeda, menyunting konten tertentu darinya, atau hanya menghapusnya.

Mengirim pesan syslog ke pengguna tertentu

rsyslog dapat mengirim pesan syslog ke pengguna tertentu dengan menentukan nama pengguna pengguna yang ingin Anda kirimi pesan (seperti pada Menentukan Beberapa Tindakan). Untuk menentukan lebih dari satu pengguna, pisahkan setiap nama pengguna dengan koma (,). Untuk mengirim pesan ke setiap pengguna yang saat ini masuk, gunakan tanda bintang (*).

Mengeksekusi program

rsyslog memungkinkan Anda menjalankan program untuk pesan syslog yang dipilih dan menggunakan panggilan system() untuk menjalankan program dalam shell. Untuk menentukan program yang akan dieksekusi, awali dengan karakter caret (^). Akibatnya, tentukan templat yang memformat pesan yang diterima dan meneruskannya ke executable yang ditentukan sebagai parameter satu baris (untuk informasi lebih lanjut tentang templat, lihat Templat).

FILTER ^EXECUTABLE; TEMPLATE

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.

Contoh 6. Mengeksekusi Program

Dalam contoh berikut, pesan syslog apa pun dengan prioritas apa pun dipilih, diformat dengan templat template dan diteruskan sebagai parameter ke program test-program, yang kemudian dijalankan dengan parameter yang disediakan:

*.* ^test-program;template
Berhati-hatilah saat menggunakan tindakan eksekusi shell

Saat menerima pesan dari host mana pun, dan menggunakan tindakan eksekusi shell, Anda mungkin rentan terhadap injeksi perintah. Penyerang dapat mencoba menyuntikkan dan menjalankan perintah dalam program yang Anda tentukan untuk dieksekusi dalam tindakan Anda. Untuk menghindari kemungkinan ancaman keamanan, pertimbangkan secara menyeluruh penggunaan tindakan eksekusi shell.

Menyimpan pesan syslog dalam suatu basis data

Pesan syslog yang dipilih dapat langsung ditulis ke dalam tabel basis data menggunakan tindakan database writer. Penulis basis data menggunakan sintaks berikut:

:PLUGIN:DB_HOST,DB_NAME,DB_USER,DB_PASSWORD;TEMPLATE

dimana:

  • PLUGIN memanggil plug-in yang ditentukan yang menangani penulisan basis data (misalnya, plug-in ommysql).

  • Atribut DB_HOST menentukan nama host basis data.

  • Atribut DB_NAME menentukan nama basis data.

  • Atribut DB_USER menentukan pengguna basis data.

  • Atribut DB_PASSWORD menentukan kata sandi yang digunakan dengan pengguna basis data yang disebutkan di atas.

  • Atribut TEMPLATE menentukan penggunaan opsional templat yang memodifikasi pesan syslog. Untuk informasi selengkapnya tentang templat, lihat Templat.

Menggunakan MySQL dan PostgreSQL

Saat ini, rsyslog hanya menyediakan dukungan untuk basis data MySQL dan PostgreSQL. Untuk menggunakan fungsi penulis basis data MySQL dan PostgreSQL, pasang masing-masing paket rsyslog-mysql dan rsyslog-pgsql. Juga, pastikan Anda memuat modul yang sesuai dalam berkas konfigurasi /etc/rsyslog.conf Anda:

$ModLoad ommysql    # Output module for MySQL support
$ModLoad ompgsql    # Output module for PostgreSQL support

Untuk informasi lebih lanjut tentang modul rsyslog, lihat Menggunakan Modul Rsyslog.

Atau, Anda dapat menggunakan antarmuka basis data generik yang disediakan oleh modul omlibdb (mendukung: Firebird/Interbase, MS SQL, Sybase, SQLLite, Ingres, Oracle, mSQL).

Membuang pesan syslog

Untuk membuang pesan yang Anda pilih, gunakan karakter tilde (~).

FILTER ~

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:

cron.* ~
Menentukan Beberapa Tindakan

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 (&):

FILTER ACTION
& ACTION
& ACTION

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

Contoh 7. Menentukan Beberapa Tindakan

Dalam contoh berikut, semua pesan syslog kernel dengan prioritas kritis (crit) dikirim ke pengguna user1, diproses oleh template temp dan diantar ke test-program yang dapat dieksekusi, dan diteruskan ke 192.168.0.1 melalui protokol UDP.

kern.=crit user1
& ^test-program;temp
& @192.168.0.1

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.

Menggunakan templat

Templat harus didefinisikan sebelum digunakan dalam suatu tindakan, jika tidak maka diabaikan. Dengan kata lain, definisi templat harus selalu mendahului definisi aturan di /etc/rsyslog.conf.

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:

$template TEMPLATE_NAME,"text %PROPERTY% more text", OPTION

dimana:

  • $template adalah direktif templat yang menunjukkan bahwa teks yang mengikutinya, mendefinisikan suatu templat.

  • TEMPLATE_NAME adalah nama templat. Gunakan nama ini untuk merujuk ke templat.

  • Apa pun di antara dua tanda kutip (`…​ `") adalah teks templat yang sebenarnya. Dalam teks ini, karakter khusus, seperti \n untuk baris baru atau \r untuk carriage return, dapat digunakan. Karakter lain, seperti % atau ", harus dihindari jika Anda ingin menggunakan karakter tersebut secara harafiah.

  • Teks yang ditentukan antara dua tanda persen (%) menentukan properti yang memungkinkan Anda mengakses konten tertentu dari pesan syslog. Untuk informasi selengkapnya tentang properti, lihat Properti.

  • The OPTION attribute specifies any options that modify the template functionality. The currently supported template options are sql and stdsql, which are used for formatting the text as an SQL query.

Opsi sql dan stdsql

Note that the database writer checks whether the sql or stdsql options are specified in the template. If they are not, the database writer does not perform any action. This is to prevent any possible security threats, such as SQL injection.

See section Storing syslog messages in a database in Actions for more information.

Menghasilkan Nama Berkas Dinamis

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:

$template DynamicFile,"/var/log/test_logs/%timegenerated%-test.log"

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:

*.* ?DynamicFile
Properti

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:

%PROPERTY_NAME:FROM_CHAR:TO_CHAR:OPTION%

dimana:

  • The PROPERTY_NAME attribute specifies the name of a property. A list of all available properties and their detailed description can be found in the rsyslog.conf(5) manual page under the section Available Properties.

  • FROM_CHAR and TO_CHAR attributes denote a range of characters that the specified property will act upon. Alternatively, regular expressions can be used to specify a range of characters. To do so, set the letter R as the FROM_CHAR attribute and specify your desired regular expression as the TO_CHAR attribute.

  • The OPTION attribute specifies any property options, such as the lowercase option to convert the input to lowercase. A list of all available property options and their detailed description can be found in the rsyslog.conf(5) manual page under the section Property Options.

The following are some examples of simple properties:

  • The following property obtains the whole message text of a syslog message:

%msg%
  • The following property obtains the first two characters of the message text of a syslog message:

%msg:1:2%
  • The following property obtains the whole message text of a syslog message and drops its last line feed character:

%msg:::drop-last-lf%
  • The following property obtains the first 10 characters of the time stamp that is generated when the syslog message is received and formats it according to the RFC 3339 date standard.

%timegenerated:1:10:date-rfc3339%
Contoh Templat

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.

Contoh 8. A verbose syslog message template
$template verbose, "%syslogseverity%, %syslogfacility%, %timegenerated%, %HOSTNAME%, %syslogtag%, %msg%\n"

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

Contoh 9. Templat pesan wall
$template wallmsg,"\r\n\7Message from syslogd@%HOSTNAME% at %timegenerated% ...\r\n %syslogtag% %msg%\n\r"

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.

Contoh 10. Templat pesan terformat basis data
$template dbFormat,"insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values (%msg%, %syslogfacility%, %HOSTNAME%, %syslogpriority%, %timereported:::date-mysql%, %timegenerated:::date-mysql%, %iut%, %syslogtag%)", sql

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.

RSYSLOG_DebugFormat

A special format used for troubleshooting property problems.

"Debug line with all properties:\nFROMHOST: %FROMHOST%, fromhost-ip: %fromhost-ip%, HOSTNAME: %HOSTNAME%, PRI: %PRI%,\nsyslogtag %syslogtag%, programname: %programname%, APP-NAME: %APP-NAME%, PROCID: %PROCID%, MSGID: %MSGID%,\nTIMESTAMP: %TIMESTAMP%, STRUCTURED-DATA: %STRUCTURED-DATA%,\nmsg: %msg%\nescaped msg: %msg:::drop-cc%\nrawmsg: %rawmsg%\n\n\"
RSYSLOG_SyslogProtocol23Format

The format specified in IETF’s internet-draft ietf-syslog-protocol-23, which is assumed to become the new syslog standard RFC.

"%PRI%1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n\"
RSYSLOG_FileFormat

A modern-style logfile format similar to TraditionalFileFormat, but with high-precision time stamps and time zone information.

"%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\"
RSYSLOG_TraditionalFileFormat

The older default log file format with low-precision time stamps.

"%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\"
RSYSLOG_ForwardFormat

A forwarding format with high-precision time stamps and time zone information.

"%PRI%%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"
RSYSLOG_TraditionalForwardFormat

The traditional forwarding format with low-precision time stamps.

"%PRI%%TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"

Direktif Global

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:

$MainMsgQueueSize 50000

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.

Rotasi Log

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

# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# uncomment this if you want your log files compressed
compress

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:

/var/log/messages {
    rotate 5
    weekly
    postrotate
    /usr/bin/killall -HUP syslogd
    endscript
}

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:

  • weekly — Specifies the rotation of log files to be done weekly. Similar directives include:

    • daily

    • monthly

    • yearly

  • compress — Enables compression of rotated log files. Similar directives include:

    • nocompress

    • compresscmd — Specifies the command to be used for compressing.

    • uncompresscmd

    • compressext — Specifies what extension is to be used for compressing.

    • compressoptions — Specifies any options to be passed to the compression program used.

    • delaycompress — Postpones the compression of log files to the next rotation of log files.

  • rotate INTEGER — Specifies the number of rotations a log file undergoes before it is removed or mailed to a specific address. If the value 0 is specified, old log files are removed instead of rotated.

  • mail ADDRESS — This option enables mailing of log files that have been rotated as many times as is defined by the rotate directive to the specified address. Similar directives include:

    • nomail

    • mailfirst — Specifies that the just-rotated log files are to be mailed, instead of the about-to-expire log files.

    • maillast — Specifies that the about-to-expire log files are to be mailed, instead of the just-rotated log files. This is the default option when mail is enabled.

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

Menggunakan Format Konfigurasi Baru

In rsyslog version 6, a new configuration syntax was introduced. This new configuration format aims to be more powerful, more intuitive, and to prevent common mistakes by not permitting certain invalid constructs. The syntax enhancement is enabled by the new configuration processor that relies on RainerScript. The legacy format is still fully supported and it is used by default in the /etc/rsyslog.conf configuration file.

RainerScript is a scripting language designed for processing network events and configuring event processors such as rsyslog. RainerScript was first used to define expression-based filters, see Expression-based Filters. The version of RainerScript in rsyslog version 7 implemented the input() and ruleset() statements, which permit the /etc/rsyslog.conf configuration file to be written in the new syntax. The new syntax differs mainly in that it is much more structured; parameters are passed as arguments to statements, such as input, action, template, and module load. The scope of options is limited by blocks. This enhances readability and reduces the number of bugs caused by misconfiguration. There is also a significant performance gain. Some functionality is exposed in both syntaxes, some only in the new one.

Compare the configuration written with legacy-style parameters:

$InputFileName /tmp/inputfile
$InputFileTag tag1:
$InputFileStateFile inputfile-state
$InputRunFileMonitor

and the same configuration with the use of the new format statement:

input(type="imfile" file="/tmp/inputfile" tag="tag1:" statefile="inputfile-state")

This significantly reduces the number of parameters used in configuration, improves readability, and also provides higher execution speed. For more information on RainerScript statements and parameters see Online Documentation.

Rulesets

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:

$RuleSet rulesetname
rule
rule2

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

$RuleSet RSYSLOG_DefaultRuleset

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:

ruleset(name="rulesetname") {
      rule
      rule2
      call rulesetname2
      …
}

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:

input(type="input_type" port="port_num" ruleset="rulesetname");

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.

Contoh 11. Using rulesets

The following rulesets ensure different handling of remote messages coming from different ports. Add the following into /etc/rsyslog.conf:

ruleset(name="remote-10514") {
    action(type="omfile" file="/var/log/remote-10514")
}

ruleset(name="remote-10515") {
    cron.* action(type="omfile" file="/var/log/remote-10515-cron")
    mail.* action(type="omfile" file="/var/log/remote-10515-mail")
}

input(type="imtcp" port="10514" ruleset="remote-10514");
input(type="imtcp" port="10515" ruleset="remote-10515");

Rulesets shown in the above example define log destinations for the remote input from two ports, in case of 10515, messages are sorted according to the facility. Then, the TCP input is enabled and bound to rulesets. Note that you must load the required modules (imtcp) for this configuration to work.

Kompatibilitas dengan syslogd

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.

Bekerja dengan Antrian di Rsyslog

Queues are used to pass content, mostly syslog messages, between components of rsyslog. With queues, rsyslog is capable of processing multiple messages simultaneously and to apply several actions to a single message at once. The data flow inside rsyslog can be illustrated as follows:

Alur Pesan di Rsyslog
Gambar 1. Alur Pesan di Rsyslog

Whenever rsyslog receives a message, it passes this message to the preprocessor and then places it into the main message queue. Messages wait there to be dequeued and passed to the rule processor.

The rule processor is a parsing and filtering engine. Here, the rules defined in /etc/rsyslog.conf are applied. Based on these rules, the rule processor evaluates which actions are to be performed. Each action has its own action queue. Messages are passed through this queue to the respective action processor which creates the final output. Note that at this point, several actions can run simultaneously on one message. For this purpose, a message is duplicated and passed to multiple action processors.

Only one queue per action is possible. Depending on configuration, the messages can be sent right to the action processor without action queuing. This is the behavior of direct queues (see below). In case the output action fails, the action processor notifies the action queue, which then takes an unprocessed element back and after some time interval, the action is attempted again.

To sum up, there are two positions where queues stand in rsyslog: either in front of the rule processor as a single main message queue or in front of various types of output actions as action queues. Queues provide two main advantages that both lead to increased performance of message processing:

  • they serve as buffers that decouple producers and consumers in the structure of rsyslog

  • they allow for parallelization of actions performed on messages

Apart from this, queues can be configured with several directives to provide optimal performance for your system. These configuration options are covered in the following sections.

If an output plug-in is unable to deliver a message, it is stored in the preceding message queue. If the queue fills, the inputs block until it is no longer full. This will prevent new messages from being logged via the blocked queue. In the absence of separate action queues this can have severe consequences, such as preventing SSH logging, which in turn can prevent SSH access. Therefore it is advised to use dedicated action queues for outputs which are forwarded over a network or to a database.

Mendefinisikan Antrian

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:

$objectQueueType queue_type

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.

Antrian Langsung

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:

$objectQueueType Direct

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.

Antrean Diska

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:

$objectQueueType Disk

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:

$objectQueueMaxFileSize size

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:

$objectQueueFilename name

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

Antrean Dalam Memori

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:

  • FixedArray queue — the default mode for the main message queue, with a limit of 10,000 elements. This type of queue uses a fixed, pre-allocated array that holds pointers to queue elements. Due to these pointers, even if the queue is empty a certain amount of memory is consumed. However, FixedArray offers the best run time performance and is optimal when you expect a relatively low number of queued messages and high performance.

  • LinkedList queue — here, all structures are dynamically allocated in a linked list, thus the memory is allocated only when needed. LinkedList queues handle occasional message bursts very well.

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:

$objectQueueType LinkedList
$objectQueueType FixedArray

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

Disk-Assisted In-memory Queues

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:

$objectQueueHighWatermark number
$objectQueueLowWatermark number

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.

Contoh 12. Reliable Forwarding of Log Messages to a Server

Rsyslog is often used to maintain a centralized logging system, where log messages are forwarded to a server over the network. To avoid message loss when the server is not available, it is advisable to configure an action queue for the forwarding action. This way, messages that failed to be sent are stored locally until the server is reachable again. Note that such queues are not configurable for connections using the UDP protocol. To establish a fully reliable connection, for example when your logging server is outside of your private network, consider using the RELP protocol described in Using RELP.

Penerusan Ke Satu Server

Suppose the task is to forward log messages from the system to a server with host name example.com, and to configure an action queue to buffer the messages in case of a server outage. To do so, perform the following steps:

  1. Create a working directory to store the queue files. For example:

~]# mkdir /rsyslog/work/
  1. Use the following configuration in /etc/rsyslog.conf or create a file with the following content in the /etc/rsyslog.d/ directory:

$WorkDirectory /rsyslog/work

$ActionQueueType LinkedList
$ActionQueueFileName example_fwd
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
*.*       @@example.com:18

Dimana:

  • the /rsyslog/work/ directory created in the previous step is marked as a working directory,

  • $ActionQueueType enables a LinkedList in-memory queue,

  • $ActionFileName defines a disk storage, in this case the backup files are created in the /rsyslog/work/ directory with the example_fwd prefix,

  • the $ActionResumeRetryCount -1 setting prevents rsyslog form dropping messages when retrying to connect if server is not responding,

  • enabled $ActionQueueSaveOnShutdown saves in-memory data if rsyslog shuts down,

  • the last line forwards all received messages to the logging server, port specification is optional.

With the above configuration, rsyslog keeps messages in memory if the remote server is not reachable. A file on disk is created only if rsyslog runs out of the configured memory queue space or needs to shut down, which benefits the system performance.

Penerusan ke Beberapa Server

The process of forwarding log messages to multiple servers is similar to the previous procedure:

  1. Create a working directory for rsyslog to store the queue files. For example:

~]# mkdir /rsyslog/work/
  1. Each destination server requires a separate forwarding rule, action queue specification, and backup file on disk. For example, use the following configuration in /etc/rsyslog.conf or create a file with the following content in the /etc/rsyslog.d/ directory:

$WorkDirectory /rsyslog/work

$ActionQueueType LinkedList
$ActionQueueFileName example_fwd1
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
*.*       @@example1.com

$ActionQueueType LinkedList
$ActionQueueFileName example_fwd2
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
*.*       @@example2.com

Mengelola Antrean

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.

Membatasi Ukuran Antrean

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

$objectQueueHighWatermark number

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:

$objectQueueMaxDiscSpace number

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.

Membuang Pesan

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:

$objectQueueDiscardMark number

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:

$objectQueueDiscardSeverity priority

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.

Using Timeframes

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:

$objectQueueDequeueTimeBegin hour
$objectQueueDequeueTimeEnd hour

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

Configuring Worker Threads

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:

$objectQueueWorkerThreadMinimumMessages number

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:

$objectQueueWorkerThreads number

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:

$objectQueueWorkerTimeoutThreadShutdown time

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.

Batch Dequeuing

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

$objectQueueDequeueBatchSize number

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.

Mengakhiri Antrian

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:

$objectQueueTimeoutShutdown time

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:

$objectQueueTimeoutActionCompletion time

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

$objectQueueTimeoutSaveOnShutdown time

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

Configuring rsyslog on a Logging Server

The rsyslog service provides facilities both for running a logging server and for configuring individual systems to send their log files to the logging server. See Reliable Forwarding of Log Messages to a Server for information on client rsyslog configuration.

The rsyslog service must be installed on the system that you intend to use as a logging server and all systems that will be configured to send logs to it. Rsyslog is installed by default in Fedora Rawhide. If required, to ensure that it is, enter the following command as root:

~]# dnf install rsyslog

The steps in this procedure must be followed on the system that you intend to use as your logging server. All steps in this procedure must be made as the root user:

  1. Configure the firewall to allow rsyslog TCP traffic.

    1. The default port for rsyslog TCP traffic is 514. To allow TCP traffic on this port, enter a command as follows:

~]# firewall-cmd --zone=zone --add-port=514/tcp
success

Where zone is the zone of the interface to use.

  1. Open the /etc/rsyslog.conf file in a text editor and proceed as follows:

    1. Add these lines below the modules section but above the Provides UDP syslog reception section:

# Define templates before the rules that use them

### Per-Host Templates for Remote Systems ###
$template TmplAuthpriv, "/var/log/remote/auth/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
$template TmplMsg, "/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
  1. Replace the default Provides TCP syslog reception section with the following:

# Provides TCP syslog reception
$ModLoad imtcp
# Adding this ruleset to process remote messages
$RuleSet remote1
authpriv.*   ?TmplAuthpriv
*.info;mail.none;authpriv.none;cron.none   ?TmplMsg
$RuleSet RSYSLOG_DefaultRuleset   #End the rule set by switching back to the default rule set
$InputTCPServerBindRuleset remote1  #Define a new input and bind it to the "remote1" rule set
$InputTCPServerRun 514

Save the changes to the /etc/rsyslog.conf file.

  1. The rsyslog service must be running on both the logging server and the systems attempting to log to it.

    1. Use the systemctl command to start the rsyslog service.

~]# systemctl start rsyslog
  1. To ensure the rsyslog service starts automatically in future, enter the following command as root:

~]# systemctl enable rsyslog

Your log server is now configured to receive and store log files from the other systems in your environment.

Using The New Template Syntax on a Logging Server

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:

template(name="TmplAuthpriv" type="string"
         string="/var/log/remote/auth/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
        )

template(name="TmplMsg" type="string"
         string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
        )

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

template(name="TmplAuthpriv" type="list") {
    constant(value="/var/log/remote/auth/")
    property(name="hostname")
    constant(value="/")
    property(name="programname" SecurePath="replace")
    constant(value=".log")
    }
template(name="TmplMsg" type="list") {
    constant(value="/var/log/remote/msg/")
    property(name="hostname")
    constant(value="/")
    property(name="programname" SecurePath="replace")
    constant(value=".log")
    }

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:

module(load="imtcp")

ruleset(name="remote1"){
     authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
      *.info;mail.none;authpriv.none;cron.none action(type="omfile" DynaFile="TmplMsg")
}

input(type="imtcp" port="514" ruleset="remote1")

Menggunakan Modul Rsyslog

Due to its modular design, rsyslog offers a variety of modules which provide additional functionality. Note that modules can be written by third parties. Most modules provide additional inputs (see Input Modules below) or outputs (see Output Modules below). Other modules provide special functionality specific to each module. The modules may provide additional configuration directives that become available after a module is loaded. To load a module, use the following syntax:

$ModLoad MODULE

where $ModLoad is the global directive that loads the specified module and MODULE represents your desired module. For example, if you want to load the Text File Input Module (imfile) that enables rsyslog to convert any standard text files into syslog messages, specify the following line in the /etc/rsyslog.conf configuration file:

$ModLoad imfile

rsyslog offers a number of modules which are split into the following main categories:

  • Input Modules — Input modules gather messages from various sources. The name of an input module always starts with the im prefix, such as imfile and imjournal.

  • Output Modules — Output modules provide a facility to issue message to various targets such as sending across a network, storing in a database, or encrypting. The name of an output module always starts with the om prefix, such as omsnmp, omrelp, and so on.

  • Parser Modules — These modules are useful in creating custom parsing rules or to parse malformed messages. With moderate knowledge of the C programming language, you can create your own message parser. The name of a parser module always starts with the pm prefix, such as pmrfc5424, pmrfc3164, and so on.

  • Message Modification Modules — Message modification modules change content of syslog messages. Names of these modules start with the mm prefix. Message Modification Modules such as mmanon, mmnormalize, or mmjsonparse are used for anonymization or normalization of messages.

  • String Generator Modules — String generator modules generate strings based on the message content and strongly cooperate with the template feature provided by rsyslog. For more information on templates, see Templates. The name of a string generator module always starts with the sm prefix, such as smfile or smtradfile.

  • Library Modules — Library modules provide functionality for other loadable modules. These modules are loaded automatically by rsyslog when needed and cannot be configured by the user.

A comprehensive list of all available modules and their detailed description can be found at http://www.rsyslog.com/doc/rsyslog_conf_modules.html.

Note that when rsyslog loads any modules, it provides them with access to some of its functions and data. This poses a possible security threat. To minimize security risks, use trustworthy modules only.

Mengimpor Berkas Teks

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:

$ModLoad imfile
$InputFilePollInterval int

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:

# File 1
$InputFileName path_to_file
$InputFileTag tag:
$InputFileStateFile state_file_name
$InputFileSeverity severity
$InputFileFacility facility
$InputRunFileMonitor

# File 2
$InputFileName path_to_file2
...

Four settings are required to specify an input text file:

  • replace path_to_file with a path to the text file.

  • replace tag: with a tag name for this message.

  • replace state_file_name with a unique name for the state file. State files, which are stored in the rsyslog working directory, keep cursors for the monitored files, marking what partition has already been processed. If you delete them, whole files will be read in again. Make sure that you specify a name that does not already exist.

  • add the $InputRunFileMonitor directive that enables the file monitoring. Without this setting, the text file will be ignored.

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.

Contoh 13. Mengimpor Berkas Teks

The Apache HTTP server creates log files in text format. To apply the processing capabilities of rsyslog to apache error messages, first use the imfile module to import the messages. Add the following into /etc/rsyslog.conf:

$ModLoad imfile

$InputFileName /var/log/httpd/error_log
$InputFileTag apache-error:
$InputFileStateFile state-apache-error
$InputRunFileMonitor

Mengekspor Pesan ke Basis Data

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.

Contoh 14. Exporting Rsyslog Messages to a Database

To store the rsyslog messages in a MySQL database, add the following into /etc/rsyslog.conf:

$ModLoad ommysql

$ActionOmmysqlServerPort 1234
*.* :ommysql:database-server,database-name,database-userid,database-password

First, the output module is loaded, then the communication port is specified. Additional information, such as name of the server and the database, and authentication data, is specified on the last line of the above example.

Enabling Encrypted Transport

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.

Menggunakan RELP

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.

Interaction of Rsyslog and Journal

As mentioned above, Rsyslog and Journal, the two logging applications present on your system, have several distinctive features that make them suitable for specific use cases. In many situations it is useful to combine their capabilities, for example to create structured messages and store them in a file database (see Structured Logging with Rsyslog). A communication interface needed for this cooperation is provided by input and output modules on the side of Rsyslog and by the Journal's communication socket.

By default, rsyslogd uses the imjournal module as a default input mode for journal files. With this module, you import not only the messages but also the structured data provided by journald. Also, older data can be imported from journald (unless forbidden with the $ImjournalIgnorePreviousMessages directive). See Importing Data from Journal for basic configuration of imjournal.

As an alternative, configure rsyslogd to read from the socket provided by journal as an output for syslog-based applications. The path to the socket is /run/systemd/journal/syslog. Use this option when you want to maintain plain rsyslog messages. Compared to imjournal the socket input currently offers more features, such as ruleset binding or filtering. To import Journal data trough the socket, use the following configuration in /etc/rsyslog.conf:

$ModLoad imuxsock
$OmitLocalLogging off

The above syntax loads the imuxsock module and turns off the $OmitLocalLogging directive, which enables the import trough the system socket. The path to this socket is specified separately in /etc/rsyslog.d/listen.conf as follows:

$SystemLogSocketName /run/systemd/journal/syslog

You can also output messages from Rsyslog to Journal with the omjournal module. Configure the output in /etc/rsyslog.conf as follows:

$ModLoad omjournal

*.* :omjournal:

For instance, the following configuration forwards all received messages on tcp port 10514 to the Journal:

$ModLoad imtcp
$ModLoad omjournal

$RuleSet remote
*.* :omjournal:

$InputTCPServerBindRuleset remote
$InputTCPServerRun 10514

Structured Logging with Rsyslog

On systems that produce large amounts of log data, it can be convenient to maintain log messages in a structured format. With structured messages, it is easier to search for particular information, to produce statistics and to cope with changes and inconsistencies in message structure. Rsyslog uses the JSON (JavaScript Object Notation) format to provide structure for log messages.

Compare the following unstructured log message:

Oct 25 10:20:37 localhost anacron[1395]: Jobs will be executed sequentially

with a structured one:

{"timestamp":"2013-10-25T10:20:37", "host":"localhost", "program":"anacron", "pid":"1395", "msg":"Jobs will be executed sequentially"}

Searching structured data with use of key-value pairs is faster and more precise than searching text files with regular expressions. The structure also lets you to search for the same entry in messages produced by various applications. Also, JSON files can be stored in a document database such as MongoDB, which provides additional performance and analysis capabilities. On the other hand, a structured message requires more disk space than the unstructured one.

In rsyslog, log messages with meta data are pulled from Journal with use of the imjournal module. With the mmjsonparse module, you can parse data imported from Journal and from other sources and process them further, for example as a database output. For parsing to be successful, mmjsonparse requires input messages to be structured in a way that is defined by the Lumberjack project.

The Lumberjack project aims to add structured logging to rsyslog in a backward-compatible way. To identify a structured message, Lumberjack specifies the @cee: string that prepends the actual JSON structure. Also, Lumberjack defines the list of standard field names that should be used for entities in the JSON string. For more information on Lumberjack, see Online Documentation.

The following is an example of a lumberjack-formatted message:

            @cee: {"pid":17055, "uid":1000, "gid":1000, "appname":"logger", "msg":"Message text."}

To build this structure inside Rsyslog, a template is used, see Filtering Structured Messages. Applications and servers can employ the libumberlog library to generate messages in the lumberjack-compliant form. For more information on libumberlog, see Online Documentation.

Mengimpor Data dari Jurnal

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:

$ModLoad imjournal

$imjournalPersistStateInterval number_of_messages
$imjournalStateFile path
$imjournalRatelimitInterval seconds
$imjournalRatelimitBurst burst_number
$ImjournalIgnorePreviousMessages off/on
  • With number_of_messages, you can specify how often the journal data must be saved. This will happen each time the specified number of messages is reached.

  • Ganti path dengan jalur ke berkas status. Berkas ini melacak entri jurnal yang terakhir diproses.

  • With seconds, you set the length of the rate limit interval. The number of messages processed during this interval can not exceed the value specified in burst_number. The default setting is 20,000 messages per 600 seconds. Rsyslog discards messages that come after the maximum burst within the time frame specified.

  • With $ImjournalIgnorePreviousMessages you can ignore messages that are currently in Journal and import only new messages, which is used when there is no state file specified. The default setting is off. Please note that if this setting is off and there is no state file, all messages in the Journal are processed, even if they were already processed in a previous rsyslog session.

You can use imjournal simultaneously with imuxsock module that is the traditional system log input. However, to avoid message duplication, you must prevent imuxsock from reading the Journal’s system socket. To do so, use the $OmitLocalLogging directive:

$ModLoad imuxsock
$ModLoad imjournal

$OmitLocalLogging on
$AddUnixListenSocket /run/systemd/journal/syslog

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.

Memfilter Pesan Terstruktur

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

template(name="CEETemplate" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n")

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:

($!hostname == "hostname" && $!UID== "UID")

Mengurai JSON

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:

$ModLoad mmjsonparse

*.* :mmjsonparse:

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.

Storing Messages in the MongoDB

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

$ModLoad ommongodb

*.* action(type="ommongodb" server="DB_server" serverport="port" db="DB_name" collection="collection_name" uid="UID" pwd="password")
  • Replace DB_server with the name or address of the MongoDB server. Specify port to select a non-standard port from the MongoDB server. The default port value is 0 and usually there is no need to change this parameter.

  • With DB_name, you identify to which database on the MongoDB server you want to direct the output. Replace collection_name with the name of a collection in this database. In MongoDB, collection is a group of documents, the equivalent of an RDBMS table.

  • You can set your login details by replacing UID and password.

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.

Debugging Rsyslog

To run rsyslogd in debugging mode, use the following command:

rsyslogd -dn

With this command, rsyslogd produces debugging information and prints it to the standard output. The -n stands for "no fork". You can modify debugging with environmental variables, for example, you can store the debug output in a log file. Before starting rsyslogd, type the following on the command line:

export RSYSLOG_DEBUGLOG="path"
export RSYSLOG_DEBUG="Debug"

Replace path with a desired location for the file where the debugging information will be logged. For a complete list of options available for the RSYSLOG_DEBUG variable, see the related section in the rsyslogd(8) manual page.

To check if syntax used in the /etc/rsyslog.conf file is valid use:

rsyslogd -N 1

Where 1 represents level of verbosity of the output message. This is a forward compatibility option because currently, only one level is provided. However, you must add this argument to run the validation.

Troubleshooting Logging to a Server

  • Ensure the time is correctly set on the systems generating the log messages as well as on any logging servers. See Configuring the Date and Time for information on checking and setting the time. See Configuring NTP Using ntpd and Configuring NTP Using the chrony Suite for information on using NTP to keep the system clock accurately set.

  • On a logging server, check that the firewall has the appropriate ports open to allow ingress of either UDP or TCP, depending on what traffic and port the sending systems are configured to use. For example:

~]# firewall-cmd --zone=public --list-ports

For more information on opening and closing ports in firewalld, see the Red Hat Enterprise Linux 7 Security Guide. Review the configuration of the logging server to ensure it is listening on the same port the sending systems are configured to send on, and all are set to use the same protocol.

  • Use the logger command to generate test log messages. For example:

~]$ logger -p authpriv.info "Test Secret"
~]$ logger -p auth.info "Test Info"

See the logger(1) manual page for more information on the logger command.

Menggunakan Jurnal

The Journal is a component of systemd that is responsible for viewing and management of log files. It can be used in parallel, or in place of a traditional syslog daemon, such as rsyslogd. The Journal was developed to address problems connected with traditional logging. It is closely integrated with the rest of the system, supports various logging technologies and access management for the log files.

Logging data is collected, stored, and processed by the Journal’s journald service. It creates and maintains binary files called journals based on logging information that is received from the kernel, from user processes, from standard output, and standard error output of system services or via its native API. These journals are structured and indexed, which provides relatively fast seek times. Journal entries can carry a unique identifier. The journald service collects numerous meta data fields for each log message. The actual journal files are secured, and therefore cannot be manually edited.

Melihat Berkas Log

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

journalctl

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:

  • the priority of entries is marked visually. Lines of error priority and higher are highlighted with red color and a bold font is used for lines with notice and warning priority

  • the time stamps are converted for the local time zone of your system

  • all logged data is shown, including rotated logs

  • the beginning of a boot is tagged with a special line

Contoh 15. Contoh Keluaran journalctl

The following is an example output provided by the journalctl tool. When called without parameters, the listed entries begin with a time stamp, then the host name and application that performed the operation is mentioned followed by the actual message. This example shows the first three entries in the journal log:

# journalctl
-- Logs begin at Thu 2013-08-01 15:42:12 CEST, end at Thu 2013-08-01 15:48:48 CEST. --
Aug 01 15:42:12 localhost systemd-journal[54]: Allowing runtime journal files to grow to 49.7M.
Aug 01 15:42:12 localhost kernel: Initializing cgroup subsys cpuset
Aug 01 15:42:12 localhost kernel: Initializing cgroup subsys cpu

[...]

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:

journalctl -n Number

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:

journalctl -o form

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.

Contoh 16. Keluaran journalctl Terrinci

To view full meta data about all entries, type:

# journalctl -o verbose
[...]

Fri 2013-08-02 14:41:22 CEST [s=e1021ca1b81e4fc688fad6a3ea21d35b;i=55c;b=78c81449c920439da57da7bd5c56a770;m=27cc
        _BOOT_ID=78c81449c920439da57da7bd5c56a770
        PRIORITY=5
        SYSLOG_FACILITY=3
        _TRANSPORT=syslog
        _MACHINE_ID=69d27b356a94476da859461d3a3bc6fd
        _HOSTNAME=localhost.localdomain
        _PID=562
        _COMM=dbus-daemon
        _EXE=/usr/bin/dbus-daemon
        _CMDLINE=/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
        _SYSTEMD_CGROUP=/system/dbus.service
        _SYSTEMD_UNIT=dbus.service
        SYSLOG_IDENTIFIER=dbus
        SYSLOG_PID=562
        _UID=81
        _GID=81
        _SELINUX_CONTEXT=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
        MESSAGE=[system] Successfully activated service 'net.reactivated.Fprint'
        _SOURCE_REALTIME_TIMESTAMP=1375447282839181

[...]

This example lists fields that identify a single log entry. These meta data can be used for message filtering as shown in Advanced Filtering. For a complete description of all possible fields see the systemd.journal-fields(7) manual page.

Kontrol Akses

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:

usermod -a -G adm username

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.

Using The Live View

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:

journalctl -f

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.

Memfilter Pesan

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.

Pemfilteran menurut Prioritas

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:

journalctl -p priority

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

Contoh 17. Pemfilteran menurut Prioritas

To view only entries with error or higher priority, use:

journalctl -p err
Pemfilteran menurut Waktu

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

journalctl -b

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:

journalctl --since=value --until=value

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.

Contoh 18. Pemfilteran berdasarkan Waktu dan Prioritas

Filtering options can be combined to reduce the set of results according to specific requests. For example, to view the warning or higher priority messages from a certain point in time, type:

journalctl -p warning --since="2013-3-16 23:59:59"
Pemfilteran Tingkat Lanjut

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:

journalctl -F fieldname

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:

journalctl fieldname=value

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.

Tab Completion on Field Names

As the number of meta data fields stored by systemd is quite large, it is easy to forget the exact name of the field of interest. When unsure, type:

journalctl

and press the Tab key two times. This shows a list of available field names. Tab completion based on context works on field names, so you can type a distinctive set of letters from a field name and then press Tab to complete the name automatically. Similarly, you can list unique values from a field. Type:

journalctl fieldname=

and press Tab two times. This serves as an alternative to journalctl -F fieldname.

You can specify multiple values for one field:

journalctl fieldname=value1 fieldname=value2 ...

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:

journalctl fieldname1=value fieldname2=value ...

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:

journalctl fieldname1=value + fieldname2=value ...

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

Contoh 19. Pemfilteran tingkat lanjut

To display entries created by avahi-daemon.service or crond.service under user with UID 70, use the following command:

journalctl _UID=70 _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=crond.service

Since there are two values set for the _SYSTEMD_UNIT field, both results will be displayed, but only when matching the _UID=70 condition. This can be expressed simply as: (UID=70 and (avahi or cron)).

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:

journalctl -f fieldname=value ...

Mengaktifkan Penyimpanan Persisten

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

  • Data yang lebih kaya dicatat untuk pemecahan masalah dalam jangka waktu yang lebih lama

  • Untuk pemecahan masalah segera, data yang lebih kaya tersedia setelah reboot

  • Konsol server saat ini membaca data dari jurnal, bukan berkas log

Penyimpanan persisten juga memiliki kelemahan tertentu:

  • Bahkan dengan penyimpanan persisten, banyaknya data yang disimpan tergantung pada memori bebas, tidak ada jaminan untuk mencakup rentang waktu tertentu

  • Lebih banyak ruang disk diperlukan untuk log

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

mkdir -p /var/log/journal

Kemudian, jalankan ulang journald untuk menerapkan perubahan:

systemctl restart systemd-journald

Mengelola Berkas Log di Lingkungan Grafis

As an alternative to the aforementioned command-line utilities, Red Hat Enterprise Linux 7 provides an accessible GUI for managing log messages.

Melihat Berkas Log

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.

Memasang paket gnome-system-log

In order to use the System Log, first ensure the gnome-system-log package is installed on your system by running, as root:

~]# dnf install gnome-system-log

For more information on installing packages with DNF, see Installing Packages.

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:

~]$ gnome-system-log

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

Log Sistem
Gambar 2. Log Sistem

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.

Log Sistem - Filter
Gambar 3. Log Sistem - Filter

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

Log Sistem - Mendefinisikan Filter
Gambar 4. Log Sistem - mendefinisikan filter

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

  • Name — Specifies the name of the filter.

  • Regular Expression — Specifies the regular expression that will be applied to the log file and will attempt to match any possible strings of text in it.

  • Effect

    • Highlight — If checked, the found results will be highlighted with the selected color. You may select whether to highlight the background or the foreground of the text.

    • Hide — If checked, the found results will be hidden from the log file you are viewing.

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.

Log Sistem - Mengaktifkan Filter
Gambar 5. Log Sistem - mengaktifkan filter

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

Menambahkan Berkas Log

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.

Log Sistem - Menambahkan Berkas Log
Gambar 6. Log Sistem - menambahkan berkas log

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

Membaca berkas log yang di-zip

Log Sistem juga memungkinkan Anda untuk membuka berkas log yang di-zip dalam format .gz.

Memantau Berkas Log

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.

Log Sistem - Peringatan Log Baru
Gambar 7. Log Sistem - peringatan log baru

Sumber Daya Tambahan

Untuk informasi selengkapnya tentang cara mengonfigurasi daemon rsyslog dan cara menemukan, melihat, dan memantau berkas log, lihat sumber daya yang tercantum di bawah ini.

Dokumentasi Terpasang
  • rsyslogd(8) — Halaman manual untuk daemon rsyslogd mendokumentasikan penggunaannya.

  • rsyslog.conf(5) — Halaman manual bernama rsyslog.conf mendokumentasikan opsi konfigurasi yang tersedia.

  • logrotate(8) — Halaman manual untuk utilitas logrotate menjelaskan secara lebih rinci cara mengonfigurasi dan menggunakannya.

  • journalctl(1) — Halaman manual untuk daemon journalctl mendokumentasikan penggunaannya.

  • journald.conf(5) — Halaman manual ini mendokumentasikan opsi konfigurasi yang tersedia.

  • systemd.journal-fields(7) — Halaman manual ini mencantumkan bidang khusus Jurnal.

Dokumentasi Daring