Linux Günlük Yönetimi: systemd Günlükleri için journalctl Komutlarını Kullanma
Seviye: Başlangıç
Tahmini süre: ~20 dakika
Amaç: Sistem ve hizmet günlüklerini sorgulamayı, filtrelemeyi ve yönetmeyi öğrenmek; sorun giderme için Linux günlüklerinden yararlanarak sorunları çözmek ve sunucunun kesintisiz çalışmasını sağlamak.
Giriş
Güvenilir Linux günlük yönetimi, sunucunun kesintisiz çalışmasını sağlamak ve Linux sunucu tanılaması yapmak için gereklidir. Web sunucularını yönetirken bir sorunun kök nedenini bulmak için sistem günlüklerini journalctl ile hızlıca analiz etmeniz gerekir. Systemd (çoğu modern Linux dağıtımının init sistemi ve hizmet yöneticisi) sistem günlüklerini (sistem işlemlerinin ve sistem genelindeki olayların genel kayıtları) toplar. Tek bir günlük (log) (bir işletim sistemi veya yazılım uygulaması içinde gerçekleşen olayların kaydı), Systemd-journald (günlük verilerini toplayan ve depolayan bir sistem hizmeti) tarafından toplanır ve Journal (systemd-journald tarafından üretilen ve yönetilen ikili biçimdeki günlük verileri) içinde saklanır. Bu verileri görüntülemek için Journalctl (systemd günlüklerini sorgulamak ve görüntülemek için kullanılan bir komut satırı aracı) kullanılır. Bu eğitim, journalctl systemd günlüklerini sorgulamak, filtrelemek ve yönetmek için journalctl komutlarının kullanımına odaklanır. Sonunda komut satırında rahatça gezinebilecek ve sorunları verimli biçimde çözmek için Linux sorun giderme günlüklerini kullanabileceksiniz.
Ön koşullar
Başlamadan önce aşağıdaki koşulların karşılandığından emin olun:
- İşletim sistemi: Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 veya AlmaLinux/Rocky 8/9/10
- Donanım ve ağ gereksinimleri: yok (bu kılavuz temel komut satırı araçlarını kullanır)
- Erişim: sunucuya sudo veya root erişimi
- Gerekli bilgi: temel Linux komut satırı kullanımı
Adım 1: Linux günlük yönetimi: Geçici ve kalıcı günlükleri anlama
Bazı sistemler varsayılan olarak journal'ı geçici günlükleri (yalnızca RAM'de tutulan ve yeniden başlatmada kaybolan günlükler) kullanacak şekilde yapılandırır. Etkili Linux günlük yönetimi için, yeniden başlatmadan sonra da çökmeleri inceleyebilmeniz amacıyla kalıcı günlüklere (yeniden başlatmalar boyunca diske kaydedilen günlükler) ihtiyaç vardır.
Depolama yapılandırmanızı kontrol etmek için aşağıdaki komutu çalıştırın:
sudo grep -i 'storage' /etc/systemd/journald.conf
Beklenen çıktı:
#Storage=auto
Depolamanın auto, persistent veya volatile olarak ayarlandığını gösteren bir çıktı görmelisiniz. Yorum satırı hâlindeki #Storage=auto, varsayılan auto davranışının kullanıldığı anlamına gelir.
RHEL/AlmaLinux/Rocky sistemlerinde /etc/systemd/journald.conf dosyası varsayılan olarak bulunmayabilir. Bu durumda /usr/lib/systemd/journald.conf dosyasını kontrol edebilir veya /etc/systemd/journald.conf.d/persistent.conf dosyasını oluşturarak yapılandırabilirsiniz.
Ubuntu 24.04 ve Debian 13'te /var/log/journal dizini zaten mevcuttur ve kalıcı günlük kaydı ek yapılandırma gerektirmeden çalışır. Dizin yoksa (örneğin yeni bir AlmaLinux kurulumunda) ve kalıcı günlük kaydını zorunlu kılmak istiyorsanız, dizini oluşturun ve systemd günlük sistemini yeniden başlatın (bu dizini systemd-journald hizmeti yönetir):
sudo mkdir -p /var/log/journal sudo systemctl restart systemd-journald
AlmaLinux/RHEL sistemlerinde ayrıca günlükleri geçici /run/log/journal konumundan yeni kalıcı disk depolamasına aktarmanız (flush) gerekir:
sudo journalctl --flush
Herhangi bir çıktı görmemelisiniz. Bu, hizmetin başarıyla yeniden başlatıldığını ve artık kalıcı verileri diske yazacağını doğrular.
Adım 2: systemd günlükleri için temel journalctl komutları
Mevcut tüm kayıtları görüntülemek için varsayılan komutu kullanın.
Aşağıdaki komutu çalıştırın:
sudo journalctl
Beklenen çıktı:
May 20 10:00:00 server systemd[1]: Started Logging Service. May 20 10:00:01 server kernel: Linux version 5.15.0-101-generic...
Sunucunuzdaki tüm systemd günlüklerinin sayfalandırılmış bir listesini görmelisiniz. Sayfalayıcıdan (pager) çıkmak için q tuşuna basın.
systemd 255 ve sonraki sürümlerde (örneğin Ubuntu 24.04, Debian 13 ve AlmaLinux 10), -- Logs begin at... başlığı artık varsayılan olarak görüntülenmez.
Günlükleri journalctl ile etkili biçimde analiz etmek için çoğu zaman her şeyi baştan okumak istemezsiniz. -r bayrağıyla çıktıyı ters çevirip en yeni kayıtları önce görebilirsiniz.
Aşağıdaki komutu çalıştırın:
sudo journalctl -r
Beklenen çıktı:
May 23 20:00:00 server sshd[1234]: Accepted publickey for user from 192.168.1.50... May 23 19:59:58 server systemd[1]: Session 4 created for user.
En yeni günlük kayıtlarını ekranın üst kısmında görmelisiniz. Bu, bir olaydan sonra günlükleri journalctl ile hızla analiz etmek için çok önemli bir tekniktir.
-r bayrağı, sunucunuz aylardır çalışıyorsa özellikle yararlıdır; binlerce eski olayı anında atlamanızı sağlar.
Adım 3: Hizmet günlükleri nasıl kontrol edilir
Çoğu zaman belirli bir unit'in (systemd'nin yönetmeyi bildiği bir nesne) sorununu gidermeniz gerekir; örneğin nginx veya sshd gibi bir hizmeti denetleyen hizmet unit'i (service unit). nginx web sunucusu gibi belirli hizmetlerin hizmet günlüklerini kontrol etmek için -u bayrağını kullanın.
Aşağıdaki komutu çalıştırın (hizmetin kurulu olduğunu varsayarak; örneğin sudo apt install nginx -y veya sudo dnf install nginx -y ile):
sudo journalctl -u nginx
Beklenen çıktı:
May 23 18:00:00 server systemd[1]: Starting A high performance web server and a reverse proxy server... May 23 18:00:01 server systemd[1]: Started A high performance web server and a reverse proxy server.
Yalnızca nginx hizmeti tarafından üretilen günlük kayıtlarını görmelisiniz. Bu, web trafiği hatalarını diğer arka plan sistem olaylarından ayırmaya yardımcı olur. Hizmet kurulu değilse yalnızca -- No entries -- görürsünüz.
SSH daemon'unun hizmet günlüklerini kontrol etmek için unit adı dağıtıma göre değişir.
Ubuntu/Debian için şunu çalıştırın:
sudo journalctl -u ssh
AlmaLinux/RHEL/Rocky için şunu çalıştırın:
sudo journalctl -u sshd
Beklenen çıktı:
May 23 19:50:00 server sshd[1234]: Invalid user admin from 10.0.0.5 port 55432 May 23 19:55:00 server sshd[1235]: Accepted publickey for root from 10.0.0.2 port 44322
Kimlik doğrulama girişimlerini ve SSH daemon olaylarını görmelisiniz.
Adım 4: journalctl ile günlükleri zamana ve türe göre filtreleme
Büyük veri hacimleriyle çalışırken günlük filtrelemeye (günlük çıktısını belirli ölçütlere göre daraltma işlemi) ihtiyaç duyarsınız. journalctl ile günlükleri zamana göre filtrelemek, bir kesinti bilinen bir zamanda yaşandığında son derece yararlıdır.
Son açılıştan bu yana üretilen mesajları görmek için önyükleme günlüklerine (sistem başlatma sürecinde gerçekleşen olayların kayıtları) bakarız.
Aşağıdaki komutu çalıştırın:
sudo journalctl -b
Beklenen çıktı:
May 23 08:00:00 server kernel: Linux version 5.15.0-101-generic... May 23 08:00:00 server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz...
Çıktı, geçerli önyükleme dizisinin ilk olayıyla başlamalıdır.
Zamana dayalı journalctl filtrelemesi için --since ve --until seçeneklerini kullanın.
Aşağıdaki komutu çalıştırın:
sudo journalctl --since "1 hour ago"
Beklenen çıktı:
May 23 19:00:00 server cron[567]: (root) CMD (/usr/local/bin/backup.sh) May 23 19:05:00 server sudo[580]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls
Son 60 dakikada gerçekleşen tüm olayları görmelisiniz.
Çekirdek günlüklerini (Linux çekirdeği tarafından üretilen, genellikle donanım ve sürücü olaylarına ilişkin mesajlar) görüntülemek için -k bayrağını kullanın.
Aşağıdaki komutu çalıştırın:
sudo journalctl -k
Beklenen çıktı:
May 23 08:00:00 server kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex May 23 08:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Donanım veya sürücü sorunlarının tanılanmasında yararlı olan düşük seviyeli çekirdek mesajlarını görmelisiniz.
Adım 5: Önceliğe göre filtreleme
Her kaydın bir önceliği (bir günlük mesajına atanan önem düzeyi) vardır. Düzeyler, Debug (ayrıntılı sorun giderme bilgileri için kullanılan en düşük öncelik düzeyi) ile Error (bir hizmette veya süreçte arıza olduğunu belirten öncelik düzeyi) arasında değişir. Sık kontrol edilen bir düzey de Warning'dir (henüz hata olmayan olası sorunları belirten öncelik düzeyi).
Önceliğe göre journalctl ile günlük filtrelemesi için -p bayrağını kullanın.
Yalnızca hataları görmek için aşağıdaki komutu çalıştırın:
sudo journalctl -p err
Beklenen çıktı:
May 23 10:15:20 server systemd[1]: Failed to start Custom Application Service. May 23 14:30:00 server sshd[1122]: error: kex_exchange_identification: Connection closed by remote host
Yalnızca hata düzeyindeki mesajları içeren, normal işlemlerin filtrelendiği özet bir liste görmelisiniz.
Uyarıları ve hataları görmek için aşağıdaki komutu çalıştırın:
sudo journalctl -p warning
Beklenen çıktı:
May 23 10:15:15 server systemd-udevd[330]: vda: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vda' failed with exit code 1. May 23 10:15:20 server dhcpcd[400]: eth0: no IPv6 Routers available
Hem uyarıları hem de hataları görmelisiniz; bu, olası sorunlara daha geniş bir bakış sağlar. Temiz bir işletim sisteminde, kritik hizmet arızalarından çok multipathd, irqbalance, dhcpcd veya udev gibi hizmetlerden gelen rutin uyarı mesajlarını görmek yaygındır. Kesin çıktı büyük ölçüde sisteminizin yapılandırmasına ve ortamına bağlıdır.
Adım 6: Linux günlükleri gerçek zamanlı olarak nasıl izlenir
Yapılandırma değişiklikleri uygularken veya bir sorunu yeniden üretirken Linux günlüklerini gerçek zamanlı izlemek en iyisidir. -f (follow) bayrağını kullanın.
Aşağıdaki komutu çalıştırın:
sudo journalctl -f
Beklenen çıktı:
May 23 20:05:00 server sudo[2001]: user : TTY=pts/1 ; PWD=/ ; USER=root ; COMMAND=/bin/bash May 23 20:05:00 server su[2002]: (to root) user on pts/1 May 23 20:05:00 server su[2002]: pam_unix(su:session): session opened for user root by user(uid=1000)
En son günlük kayıtlarını görmelisiniz; terminal açık kalır ve yeni olaylar gerçekleştikçe ekrana yazdırır. Çıkmak için Ctrl+C tuşlarına basın.
SSH daemon'unun günlüklerini gerçek zamanlı izlemek için unit adı dağıtıma göre değişir.
Ubuntu/Debian için şunu çalıştırın:
sudo journalctl -u ssh -f
AlmaLinux/RHEL/Rocky için şunu çalıştırın:
sudo journalctl -u sshd -f
Beklenen çıktı:
May 23 20:10:15 server sshd[2100]: Connection from 192.168.1.100 port 45678 May 23 20:10:17 server sshd[2100]: Accepted publickey for admin from 192.168.1.100 port 45678 May 23 20:10:17 server sshd[2100]: pam_unix(sshd:session): session opened for user admin by (uid=0)
SSH kimlik doğrulama girişimlerini gerçekleştikleri anda canlı olarak görmelisiniz.
Adım 7: Disk alanı ve günlük döndürme
systemd journal'ı zamanla büyüyebilir. Yer kazanmak için eski günlüklerin arşivlenmesi ve silinmesi uygulamasına günlük döndürme (log rotation) denir. systemd journal'ının şu anda ne kadar alan kullandığını kontrol edebilirsiniz.
Aşağıdaki komutu çalıştırın:
sudo journalctl --disk-usage
Beklenen çıktı:
Archived and active journals take up 200.0M in the file system.
Günlük dosyalarınızın kullandığı toplam alanı gösteren bir çıktı görmelisiniz.
Günlük döndürmeyi elle gerçekleştirmek ve disk alanı boşaltmak için verileri zamana veya boyuta göre temizleyebilirsiniz (vacuum).
Yalnızca son 500 MB veriyi tutmak için aşağıdaki komutu çalıştırın:
sudo journalctl --vacuum-size=500M
Beklenen çıktı:
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Toplam boyut 500 MB'ın altına inene kadar eski dosyaların silindiğini gösteren bir çıktı görmelisiniz.
Journal'ı temizlemek (vacuum) eski kayıtları kalıcı olarak siler. Bu komutu çalıştırmadan önce, bu kayıtlara uyumluluk veya inceleme amacıyla ihtiyaç duymadığınızdan emin olun.
systemd-journald hizmeti, /etc/systemd/journald.conf dosyasındaki sınırlara göre otomatik döndürmeyi yönetir. Disk aniden dolmadıkça genellikle elle vacuum çalıştırmanız gerekmez.
Doğrulama
Günlük kaydı kurulumunuzun doğru çalıştığından ve kalıcı depolamanın etkin olduğundan emin olmak için:
- Günlük depolama konumunun oluşturulduğunu doğrulayın:
root'a ait bir dizin görmelisiniz. Dağıtımınıza bağlı olarak grupls -ld /var/log/journal
systemd-journalveyarootolabilir (ikisi de normaldir). - journald'ın çalıştığını doğrulayın:
Hizmetinsudo systemctl status systemd-journald
active (running)durumunda olduğunu görmelisiniz.
Sorun giderme
Günlükleri yönetirken sorunlarla karşılaşırsanız şu yaygın senaryoları kontrol edin:
- Boş hizmet günlükleri (
-- No entries --): Hizmetin gerçekten kurulu ve çalışır durumda olduğundan emin olun. Ayrıca dağıtımınız için doğru unit adını kullandığınızı doğrulayın (örneğin Debian/Ubuntu'dassh, RHEL/AlmaLinux'tasshd). /var/log/journaleksik: Bazı sistemlerde (AlmaLinux gibi) kalıcı günlükleri etkinleştirmek için bu dizini elle oluşturmanız ve günlük hizmetini yeniden başlatmanız gerekir. Bu adımı atlarsanız günlükler geçici bellekte (/run/log/journal) kalır.- Erişim reddedildi (Permission denied): Günlükleri sudo olmadan okuyamıyorsanız kullanıcınızın
systemd-journalveyaadmgrubunun üyesi olduğundan emin olun (sudo usermod -aG systemd-journal $USER).
Değişiklikleri geri alma
Kalıcı günlük kaydını devre dışı bırakıp geçici günlüklere dönmek isterseniz (örneğin disk alanından tasarruf etmek için):
- Kalıcı depolama dizinini kaldırın:
sudo rm -rf /var/log/journal
- Geçici depolamayı
/run/log/journaliçinde yeniden oluşturmak için günlük hizmetini yeniden başlatın:sudo systemctl restart systemd-journald
Sonuç
İşte bu kadar. Artık Linux günlük yönetiminin temellerini biliyorsunuz. Doğru journalctl komutlarıyla systemd günlükleri arasında verimli biçimde gezinebilir, filtre uygulayabilir ve disk alanını yönetebilirsiniz. Bir çökmenin ardından günlükleri journalctl ile analiz etmeniz gerekse de yalnızca rutin hizmet sağlığını kontrol etseniz de, journalctl'de ustalaşmak sağlıklı bir altyapıyı sürdürmenin kritik bir adımıdır.
Belge sürümü: 1.0
Son güncelleme: Mayıs 2026
Sahibi: Teknik Dokümantasyon Ekibi