Pengenalan kepada Jurnal Sistem

Systemd kini sistem init yang diterima pakai oleh hampir semua pengagihan Linux, dari Red Hat Enterprise Linux ke Debian dan Ubuntu. Salah satu perkara yang menjadikan sistem sasaran banyak pengkritik adalah bahawa ia cuba menjadi lebih daripada sistem init mudah dan cuba mencipta semula beberapa subsistem linux.

Sistem pembalakan tradisional yang digunakan di Linux, sebagai contoh adalah rsyslog, versi moden tradisional syslog. Systemd memperkenalkan sistem pembalakannya sendiri: ia dilaksanakan oleh daemon, jurnal, yang menyimpan log dalam format binari ke dalam "jurnal", yang boleh dipertimbangkan oleh Journalctl utiliti.

Dalam tutorial ini kita akan mempelajari beberapa parameter yang boleh kita gunakan untuk mengubah suai jurnal tingkah laku daemon, dan beberapa contoh bagaimana untuk menanyakan jurnal dan format output yang terhasil daripada pertanyaan tersebut.

Dalam tutorial ini anda akan belajar:

• Cara menukar tetapan jurnal lalai
• Bagaimana jurnal boleh wujud bersama syslog
• Cara Meminta Jurnal Dan Beberapa Cara Untuk Memformat Output Pertanyaan

Keperluan perisian dan konvensyen yang digunakan

Fail konfigurasi jurnal

Tingkah laku jurnal Daemon boleh diubahsuai dengan menukar tetapan dalam fail konfigurasinya: /etc/systemd/jurnal.Conf. Pengubahsuaian langsung fail ini tidak disyorkan; Sebaliknya, kita harus membuat beberapa fail konfigurasi berasingan yang mengandungi parameter yang kita ingin menukar, simpan dengan mereka dengan .Conf lanjutan, dan letakkan di dalam /etc/systemd/jurnal.Conf.d direktori.

Fail yang diletakkan di dalam /etc/systemd/jurnal.Conf.d Direktori mempunyai keutamaan yang lebih besar daripada /etc/systemd/jurnal.Conf: mereka disusun dengan nama mereka di Perintah Lexicographic dan dihuraikan mengikut urutan itu, semuanya selepas fail utama. Sekiranya tetapan pilihan yang sama wujud dalam lebih daripada satu fail, yang terakhir akan dihuraikan akan berkesan.

The /etc/systemd/jourlnald.Conf fail, secara lalai, mengandungi senarai pilihan yang dikomentari di dalamnya [Jurnal] Stanza: Mereka mewakili nilai lalai yang digunakan pada masa penyusunan (kandungan di bawah adalah dari sistem fedora):

[Jurnal] #penyimpanan = auto #compress = ya #meterai = ya #splitmode = uid #syncIntervalsec = 5m #ratelimitintervalsec = 30s #ratelimitburst = 10000 #SystemMaxuse = #SystemKree = #SystemMaxFileSize = #SystemMaxFiles = 100 #Runtimaxuse = #RuntimemaxFileSize = #runtimemaxfiles = 100 #maxRetentionsec = #maxFilesec = 1month #forwardTosySlog = no #forwardTokmsg = no #forwardToConsole = no #forwardToWall = yes #ttypath =/dev/console #maxLevels = maxLoVeSt = maks. MaxLevelConsole = info #maxLevelWall = muncul #linemax = 48k #readkmsg = ya #audit = ya 

Mari kita lihat apakah maksud beberapa pilihan tersebut, dan bagaimana mereka dapat mengubah tingkah laku jurnal Daemon.

Pilihan "penyimpanan"

Pilihan pertama yang kita hadapi dalam fail adalah Penyimpanan. Pilihan ini mengawal di mana data jurnal disimpan. Nilai lalai yang digunakan pada masa penyusunan di sini adalah Auto, Tetapi ada kemungkinan untuk memilih antara:

• tidak menentu
• berterusan
• Auto
• Tiada

Jika kita menggunakan tidak menentu Sebagai nilai pilihan ini, data jurnal akan disimpan hanya dalam ingatan di bawah /lari/log/jurnal (/lari ialah tmpfs: kandungannya disimpan dalam ingatan), jadi ia tidak akan bertahan dengan reboot sistem.

Jika berterusan digunakan sebaliknya, data jurnal akan disimpan pada cakera, di bawah /var/log/jurnal, yang dibuat jika tidak wujud. Sekiranya atas sebab tertentu cakera tidak boleh ditulis, /lari/log/jurnal digunakan sebagai sandaran balik.

The Auto nilai untuk Penyimpanan pilihan, yang mana digunakan sebagai lalai, berfungsi pada dasarnya seperti berterusan Dalam erti kata bahawa apabila digunakan, data jurnal disimpan di bawah /var/log/jurnal. Perbezaannya ialah jika jalan tidak wujud, ia tidak dibuat, dan log akan disimpan hanya dalam ingatan.

Akhirnya, jika Tiada Nilai digunakan, semua penyimpanan dimatikan: semasa penghantaran ke sistem pembalakan lain seperti syslog masih akan berfungsi, semua data yang diterima akan dijatuhkan.

Pilihan "kompres"

Pilihan "kompres" mengawal sama ada jika data melebihi ambang ambang 512 bait dimampatkan sebelum disimpan ke cakera. Pilihan ini menerima dua jenis nilai: a Boolean seperti dalam kes di atas (Ya), atau nombor yang menetapkan ambang mampatan itu sendiri. Sekiranya yang terakhir disediakan, mampatan diaktifkan secara tersirat. Nilai ambang adalah, secara lalai, menyatakan dalam bait, tetapi K, M atau G Akhiran boleh digunakan sebagai gantinya.

Pilihan "ForwardTosySlog"

Seperti yang telah disebutkan, dalam era pra-sistem, balak di mana yang diuruskan oleh syslog sistem pembalakan (rsyslog sebenarnya). Sistem pembalakan ini dapat mengemukakan log ke banyak destinasi, seperti fail teks, terminal, atau mesin lain di rangkaian. SystemD melaksanakan sistem pembalakannya sendiri, yang merupakan objek tutorial ini: jurnal.

Kedua -dua sistem ini boleh wujud bersama (ini kadang -kadang perlu kerana jurnal merindui beberapa ciri seperti pembalakan berpusat, Atau hanya kerana kita, sebagai pentadbir mungkin suka log untuk disimpan dalam fail teks dan bukannya dalam format binari, sehingga mereka dapat dimanipulasi dengan alat UNIX standard).

Ini Forwardtosyslog pilihan mengambil a Boolean Nilai: Sekiranya ditetapkan ke Ya, mesej akan dikemukakan ke /Run/Systemd/Journal/Syslog soket, di mana boleh dibaca oleh syslog. Tingkah laku ini juga boleh ditetapkan di boot melalui sistemd.jurnal.forward_to_syslog pilihan.

Pilihan serupa boleh digunakan untuk meneruskan mesej ke KMSG (Buffer Log Kernel), Konsol atau "Dinding" (dihantar sebagai mesej log kepada pengguna log masuk). Hanya yang terakhir ditetapkan ke Ya Secara lalai.

Menanyakan jurnal

Alat yang boleh kita gunakan untuk memeriksa log sistem dan menanyakan jurnal sistemd adalah Journalctl. Sekiranya arahan dipanggil tanpa parameter lanjut, semua kandungan jurnal dipaparkan. Nasib baik, beberapa strategi dapat dilaksanakan untuk menapis log. Mari lihat sebahagian daripada mereka.

Penapisan mesej mengikut unit

Salah satu pilihan yang paling berguna yang boleh kita lalui Journalctl adalah -u, yang merupakan versi pendek dari --unit. Dengan pilihan ini, kita dapat menapis kandungan jurnal supaya hanya mesej dari spesifik SYSTEMD-UNIT diluluskan sebagai hujah pilihan dikembalikan. Contohnya, untuk memaparkan hanya mesej yang datang dari NetworkManager.perkhidmatan unit, kita boleh lari:

$ Journalctl -U NetworkManager-Log bermula pada Rabu 2020-07-01 21:47:23 CEST, berakhir pada Sabtu 2020-07-25 15:26:59 CEST. -- 01 Jul 21:48:07 ERU Systemd [1]: Pengurus Rangkaian Bermula ... Jul 01 21:48:07 Eru NetworkManager [1579]: [1593632887.7408] NetworkManager (Versi 1.22.10-1.FC32) Bermula ... (untuk kali pertama) 01 Jul 21:48:07 Eru NetworkManager [1579]: [1593632887.7413] Baca Config:/etc/NetworkManager/NetworkManager.Conf Jul 01 21:48:07 ERU Systemd [1]: Memulakan Pengurus Rangkaian. 

Selain itu, pilihan tertentu didedikasikan untuk menapis hanya mesej kernel: -k, yang merupakan bentuk pendek --DMESG.

Penapisan log mengikut tarikh

Jika kita mahu menapis mesej yang disimpan dalam jurnal mengikut tarikh kita boleh menggunakan dua pilihan khusus: -S (ringkasan untuk --sejak) dan -U (ringkasan untuk --sehingga). Kedua -dua pilihan menerima tarikh dalam format Yyyy-mm-dd hh: mm: ss. Bahagian "masa" tarikh boleh ditinggalkan, dan dalam kes itu 00:00:00 diandaikan. Katakan kita mahu menapis log bermula dari tarikh semasa; Kami akan menjalankan arahan berikut:

$ Journalctl-jadi 2020-07-25 

Untuk menyekat lagi balak dengan masa dari 16:04:21 ke 16:04:26:

$ Journalctl--Since "2020-07-25 16:04:21" --Until "2020-07-25 16:04:26" 

Satu siri alias juga wujud: mereka boleh digunakan dan bukannya tarikh biasa:

Hanya memaparkan log terkini

Sekiranya kita melancarkan Journalctl perintah dengan -f (--ikuti) pilihan, kita hanya dapat memvisualisasikan log yang diterima terkini, dan masih diperhatikan kerana log baru dilampirkan kepadanya (pada dasarnya seperti memanggil ekor dengan -f pilihan). Sebaliknya, jika kita hanya ingin memvisualisasikan akhir jurnal kita boleh menggunakannya -e pilihan (--pager-end).

Memformat output jurnal

Output yang kami terima semasa menggunakan Journalctl boleh diformat dengan mudah menggunakan pilihan khusus: -o, atau versi panjangnya, --pengeluaran. Apabila menggunakan pilihan ini, kita boleh menentukan antara satu siri "Gaya". Antara (banyak) yang lain:

• pendek
• verbose
• JSON-PETTY

The pendek Format adalah lalai: satu baris setiap entri dipaparkan dalam output yang serupa dengan syslog tradisional:

01 Jul 21:48:07 ERU Systemd [1]: Memulakan Pengurus Rangkaian .. 

The verbose Format, sebaliknya, menjadikan semua bidang entri akan dipaparkan:

Wed 2020-07-01 21:48:07.603130 CEST [s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d;m=2e82666;t=5a966922b0155;x=6668aad5e895da03] PRIORITY=6 _BOOT_ID=1c06b8c553624a5f94e1d3ef384fb50d _MACHINE_ID=afe15f1a401041f4988478695a02b2bf _HOSTNAME=eru SYSLOG_FACILITY=3 SYSLOG_IDENTIFIER=systemd _UID=0 _GID= 0 _Transport = Journal _cap_effective = 3FFFFFFFFF CODE_FILE = SRC/CORE/JOB.code_type = code_line = 574 code_funce_message.skop _systemd_unit = init.skop _systemd_slice =-.slice _selinux_context = system_u: system_r: init_t: s0 _cmdline =/usr/lib/systemd/systemd --switched-root --system-deserialize 34 message = permulaan pengurus rangkaian ... job_id = 243 unit = networkmanager.Perkhidmatan Invocation_ID = 6416439E51FF4543A76BDED5984C6CF3 _SOURCE_REALTIME_TIMESTAMP = 1593632887603130 

The JSON-PETTY Format memaparkan penyertaan sebagai Json objek dengan cara yang boleh dibaca manusia. Dalam format ini penyertaan dipisahkan oleh garis baru:

"__Realtime_timestamp": "1593632887603541", "keutamaan": "6", "_systemd_unit": "init.skop "," _systemd_cgroup ":"/init.skop "," _uid ":" 0 "," _comm ":" Systemd "," _systemd_slice ":"-.slice", "_CAP_EFFECTIVE" : "3fffffffff", "_BOOT_ID" : "1c06b8c553624a5f94e1d3ef384fb50d", "_SELINUX_CONTEXT" : "system_u:system_r:init_t:s0", "__CURSOR" : "s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d; m = 2E82666; t = 5A9666922B0155; Memulakan pengurus rangkaian ... "," _exe ":"/usr/lib/systemd/systemd "," __monotonic_timestamp ":" 48768614 "," _transport ":" Journal "," syslog_facility ":" 3 "," unit ":" NetworkManager.perkhidmatan "," job_id ":" 243 "," job_type ":" start "," _gid ":" 0 "," code_file ":" src/core/job.c "," _machine_id ":" AFE15F1A401041F49888478695A02B2BF "," _cmdline ":"/usr/lib/systemd/systemd-switched-boot --system --serialize 34 "," syslog_ ": syslog_ "574", "invocation_id": "6416439e51ff4543a76bded5984c6cf3", "_source_realtime_timestamp": "1593632887603130" 

Kesimpulan

Dalam tutorial ini kami menghampiri jurnal Daemon Systemd yang melaksanakan jurnal pembalakan. Sistem pembalakan ini dimaksudkan untuk digunakan dan bukannya syslog yang merupakan sistem tradisional yang digunakan di linux. Mengenai banyak pengagihan, atas alasan atau yang lain kedua -dua sistem masih wujud bersama.

Kita melihat apa itu jurnal fail konfigurasi dan apakah maksud beberapa pilihan penting yang boleh digunakan untuk mengubah suai tingkah lakunya, dan kami belajar bagaimana kami dapat menanyakan jurnal sistem dengan Journalctl utiliti. Sekiranya anda ingin mengetahui lebih lanjut mengenai jurnal dan Journalctl. Saya cadangkan anda membaca manual masing -masing (Man Journald.Conf dan Man Journalctl adalah arahan yang anda cari).

Tutorial Linux Berkaitan:

• Pembalakan Lanjutan dan Pengauditan di Linux
• Perkara yang hendak dipasang di Ubuntu 20.04
• Fail Konfigurasi Linux: 30 teratas yang paling penting
• Perkara yang perlu dilakukan setelah memasang ubuntu 20.04 Focal Fossa Linux
• Muat turun linux
• Pengenalan kepada Automasi, Alat dan Teknik Linux
• Perkara yang perlu dilakukan setelah memasang Ubuntu 22.04 Jur -ubur Jammy ..
• Bolehkah linux mendapat virus? Meneroka kelemahan Linux ..
• Distro linux terbaik untuk pemaju
• Perkara yang perlu dipasang di Ubuntu 22.04