Linux günlüklerini journalctl ile inceleme rehberi

Linux sunucuda bir hizmetin neden durduğunu anlamak için olay anına ait kayıtları incelemek gerekir. Yeniden başlatma bazen hizmeti geçici olarak açsa da hatanın nedenini ortadan kaldırmaz. systemd kullanan sistemlerde journalctl, günlükleri hizmete, zamana ve açılışa göre süzmenize yardımcı olur. Uygulamaların ayrıca kendi dosya günlükleri bulunabileceğini unutmayın.

Olay zamanını doğru belirleyin

Önce sunucunun saat dilimini ve olayın yaklaşık başlangıcını kaydedin. Kullanıcının yerel saatiyle sunucu saati farklıysa yanlış aralığı inceleyebilirsiniz. Hata mesajının görüldüğü URL, işlem veya servis adıyla birlikte zaman bilgisi toplamak bağlantıyı kurmayı kolaylaştırır. Tek bir hata satırından önceki birkaç kayıt çoğu zaman önemli bağlam sağlar.

Temel okuma komutları

journalctl -b -n 100 --no-pager mevcut açılıştaki son 100 kaydı gösterir. journalctl -u HIZMET_ADI -n 100 --no-pager yalnız belirli hizmete odaklanır; örnekteki hizmet adını sisteminizdeki gerçek birimle değiştirin. Bazı günlükleri görmek için yönetici yetkisi gerekebilir. Yetki eksikliğinde boş sonuç almak, kayıt olmadığı anlamına gelmeyebilir.

Belirli bir aralık için --since ve --until seçenekleri kullanılabilir. Örneğin journalctl --since "30 minutes ago" --no-pager son yarım saati incelemeyi sağlar. Çok yoğun sistemde kapsamı hizmet ve zamanla daraltmak gereksiz çıktıyı azaltır. Canlı izleme için -f kullanıldığında komut beklemeye devam eder; Ctrl+C ile çıkabilirsiniz.

İnceleme sırası

1. Hizmet durumunu görün. systemctl status HIZMET_ADI --no-pager ile çalışıp çalışmadığını ve son durumu kontrol edin.
2. Olay aralığını daraltın. Hatanın öncesini ve sonrasını kapsayan zaman seçin.
3. İlk anlamlı hatayı arayın. Sonraki bağlantı hataları ilk arızanın sonucu olabilir.
4. Kaynak durumuyla karşılaştırın. Disk, bellek veya bağlantı sorunu günlükteki belirtiyi açıklayabilir.
5. Tek değişiklik yapın. Düzeltme sonrasında aynı işlemi tekrarlayıp yeni kayıtları inceleyin.
6. Sonucu belgeleyin. Hata, neden, yapılan işlem ve doğrulama zamanını kaydedin.

Günlükler neyi göstermeyebilir?

Her uygulama çıktısını systemd günlüğüne yazmaz. Web sunucusunun erişim ve hata dosyaları, PHP-FPM, veritabanı veya uygulamanın özel log konumu ayrı olabilir. Hizmet birimini ve uygulama ayarını inceleyerek doğru yeri bulun. Günlük saklama yapılandırması kalıcı değilse önceki yeniden başlatmaya ait kayıtlar bulunmayabilir.

Yalnız önem seviyesine göre filtrelemek de bağlamı eksiltebilir. “Error” içermeyen bir bağlantı zaman aşımı veya servis durdurma kaydı olayın ana ipucu olabilir. Önem seviyesini yardımcı filtre olarak kullanın; nedensellik için zaman sırasını ve ilgili hizmetleri birlikte değerlendirin.

Paylaşmadan önce gizli bilgileri ayıklayın

Günlüklerde e-posta, IP, oturum belirteci, API anahtarı veya veritabanı bağlantı bilgisi bulunabilir. Destek talebine bütün günlük arşivini eklemek yerine ilgili zaman aralığını seçip gizli değerleri maskeleyin. Orijinal kaydı güvenli yerde koruyun; maskeleme sırasında hata kodunu ve dosya yolunun inceleme için gerekli bölümünü anlamlı bırakın.

Sık sorulan sorular

Günlüğü silmek sorunu çözer mi? Genellikle hayır; teşhis kanıtını kaybettirir. Disk yönetimi gerekiyorsa saklama politikasıyla ele alınmalıdır.

Hizmet adı nasıl bulunur? Kurulu hizmetleri ve uygulamanın kurulum belgesini kontrol edin; dağıtımlar arasında adlar değişebilir.

Sunucu yeniden başladıktan önceki kayıtlar yoksa? Kalıcı günlük yapılandırması ve saklama süresini inceleyin; her sistem eski açılışları tutmaz.

İlgili teknik kaynak

• systemd journalctl kullanım belgesi