Linux’ta sorun araştırırken terminale akan binlerce satırın tamamı yararlı kanıt değildir. Asıl ihtiyaç hangi servis, hangi zaman ve hangi sistem açılışı sırasında hata oluştuğunu belirlemektir. systemd journal kullanan bir sistemde journalctl bu seçimi daraltmaya yardım eder. Bunu VDS izleme planındaki ölçüm zamanlarıyla eşleştirerek inceleyin; farklı saatlere ait iki kayıt aynı olayı göstermeyebilir.
Saat dilimini ve olay aralığını yazın
Önce kullanıcı şikâyetinin zamanını alın: tarih, yaklaşık saat ve saat dilimi. Sunucunun saatini ayrıca karşılaştırın. Saat dilimi rehberi, görünen saat ile ortak zaman çizelgesini ayırır. Sorunun öncesinden ve sonrasından küçük bir pay bırakın; yalnız tek saniyeye kilitlenmek ilk uyarıyı kaçırabilir. Buna karşılık aylarca kaydı toplamak gereksiz veri üretir.
Servis ve zaman filtrelerini birlikte kullanın
journalctl -u uygulama.service --since '2026-10-23 09:00:00' --until '2026-10-23 09:15:00' --no-pager örneği, kendi olay tarihiniz ve gerçek birim adınızla uyarlanmalıdır. journalctl belgesi birim, tarih ve açılış filtrelerini açıklar. Bu okuma örneği bir servisi yeniden başlatmaz veya kayıtları silmez. Çıktı yoksa önce hedef birimi ve zaman kapsamını doğrulayın.
Geçerli açılışa ait kayıtlar için journalctl -b kullanılabilir. Önceki açılışın incelenebilmesi saklanan kayıtların kapsamına bağlıdır; her sunucuda geçmişin kalıcı olduğu varsayılmamalıdır. Uygulama kendi dosyasına log yazıyorsa journal içinde tüm ayrıntı bulunmayabilir. Erişim kısıtıyla karşılaşırsanız yetkileri genel olarak genişletmek yerine sistem yöneticisinden ilgili kayıtları isteyin.
Hata öncesini ve sonrasını birlikte değerlendirin
Son satır bazen yalnız işlemin kapandığını söyler; asıl neden daha önce yazılmış olabilir. Aynı zaman aralığında uygulama ayarı değişikliği, bağımlı servis hatası veya bakım işi var mı? Tek kelime üzerinden arama yapıp kalan satırları tamamen atmak bağlamı kaybettirebilir. Kaynak olaylarını Linux bellek rehberindeki açıklamalarla karşılaştırın; bir süreç kaydından doğrudan RAM yükseltme kararı çıkarmayın.
Paylaşılabilir bir hata özeti hazırlayın
Kısa özet şu bilgileri içermelidir: beklenen iş, gerçekleşen belirti, servis adı, zaman aralığı ve son değişiklik. Ham kayıtta kullanıcı adresi, erişim belirteci veya bağlantı dizeleri bulunabilir. Paylaşmadan önce inceleyin; kaydın anlamını değiştirecek şekilde hata numarasını veya zamanı silmeyin. Gerekirse hassas alanları yer tutucuyla değiştirip neyi maskelediğinizi belirtin.
VDS hizmetinin sağlıklı görünmesi uygulama logunu gereksiz yapmaz; uygulama hatası da otomatik olarak altyapı arızası değildir. İki katmanı aynı zaman çizelgesinde okumak doğru müdahaleyi seçmeyi kolaylaştırır. Kayıt saklama ve disk kullanımı sorununu ise ayrı bakım işi olarak planlayın; teşhis sırasında log temizliği yapmayın.
Birden fazla ekip aynı olayla ilgileniyorsa herkesin kullandığı zaman aralığını ortaklaştırın. Ağ ekibinin başka saat dilimindeki kaydıyla uygulama kaydını yan yana koymak yanlış neden-sonuç ilişkisi kurdurabilir. İnceleme sonunda hangi kaydın hangi iddiayı desteklediğini kısa maddelerle yazın; şüphe ile doğrulanmış bulguyu ayrı tutmak sonraki müdahalenin daha güvenli seçilmesini sağlar.
Sıkça Sorulan Sorular
Hiç kayıt çıkmaması hata olmadığı anlamına mı gelir?
Hayır. Yanlış birim, zaman aralığı, erişim yetkisi veya kayıt saklama kapsamı sonucu etkileyebilir.
Bu komutlar logları temizler mi?
Buradaki servis ve zaman filtreleri okumak içindir. Silme veya vacuum seçenekleri bu rehberin parçası değildir.
Önceki açılış kayıtları her zaman bulunur mu?
Hayır. Kalıcılık ve saklama ayarlarına bağlıdır; bulunacağını varsaymayın.
Tüm logu destek kaydına yükleyeyim mi?
Önce dar zaman aralığını inceleyin. Gizli değer, müşteri verisi ve iç sistem adlarını paylaşmadan önce temizleyin.