Linux'ta Loglar Nerede Tutulur ve Bir Sistem Problemi Nasıl Araştırılır?

Bir servis durmuşsa son log satırı her zaman kök neden değildir. “Database connection closed” mesajı gerçek arızayı anlatabileceği gibi, sürecin başka bir nedenle kapatılmasının sonucu da olabilir. İyi bir inceleme, tek bir hata kelimesi aramak yerine zaman, kapsam ve değişiklik ilişkisi kurar.

Örnek senaryomuz şu: Kullanıcılar saat 14.20 civarında API'nin zaman zaman 502 döndürdüğünü bildiriyor. Sunucuya erişebiliyoruz, ancak restart yapmadan önce olayın kanıtlarını toplamamız gerekiyor.

Önce ortamı ve zamanı netleştirin

İncelemeye olayın başlangıcı, etkilenen endpoint'ler ve son deployment bilgisiyle başlayın. Saat dilimleri tutarsızsa uygulama ve proxy logları aynı olayı farklı zamanlarda gösteriyormuş gibi görünebilir.

date -Is
uptime
systemctl status task-api --no-pager
journalctl --list-boots

Servis adını kendi sisteminize uyarlayın. uptime yeniden başlatmanın yaklaşık zamanını anlamaya yardımcı olur; tek başına arızanın nedenini açıklamaz. Önceki boot kayıtları ancak journal saklama politikası izin veriyorsa bulunabilir.

/var/log her şeyi içermez

Dağıtıma ve yapılandırmaya bağlı olarak /var/log/syslog, /var/log/messages, /var/log/auth.log veya /var/log/secure gibi dosyalar görebilirsiniz. Bu isimlerin hepsi her Linux makinesinde bulunmaz.

Systemd kullanan sistemlerde önemli bir kaynak journald'dir. Servisin stdout ve stderr çıktıları burada toplanabilir. Container uygulamaları da çoğu zaman dosyaya değil standart çıktıya yazar. Bu nedenle “log klasörü boş” gözlemi, uygulamanın hiç kayıt üretmediğini kanıtlamaz.

Journal'ın kalıcı veya geçici depolaması yapılandırmaya bağlıdır. /run/log/journal gibi geçici alan ile /var/log/journal gibi kalıcı alanın işletim sonuçları farklıdır. Saklama davranışı journald.conf içinde açıklanır.

Zaman aralığı ve servisle daraltın

journalctl -u task-api --since "2026-01-12 14:10:00" --until "2026-01-12 14:35:00" -o short-iso
journalctl -u nginx --since "30 minutes ago" --no-pager
journalctl -k -b --no-pager

İlk komut örnek olayın zaman aralığını inceler. İkinci komut proxy kayıtlarını, üçüncü komut mevcut boot'un kernel mesajlarını gösterir. journalctl -u task-api -f ise yeni kayıtları takip etmek için kullanılabilir. Filtrelerin kapsamı journalctl kılavuzunda belgelenir.

Yalnızca error seviyesine bakmak bağlamı kaybettirebilir. Hata öncesindeki “configuration loaded”, “connection pool initialized” veya deployment revision bilgisi, olayın hangi sürümde başladığını gösterebilir.

Proxy, uygulama ve kernel aynı olayı farklı anlatır

502 hatası için Nginx'in upstream bağlantısını neden tamamlayamadığını araştırın. Uygulama o anda yeniden mi başlamış, yanlış portta mı dinliyor, yoksa bağlantıyı erken mi kapatmış?

ss -ltnp
curl -i --max-time 5 http://127.0.0.1:3000/health
df -h
df -i
free -h

Bu komutlar Linux üzerinde yerel inceleme örneğidir. Süreç ayrıntıları için ek yetki gerekebilir. /health yalnızca uygulamada tanımlıysa anlamlıdır.

Kernel logunda OOM nedeniyle öldürülen bir süreç bulunursa uygulamanın son satırında “başarılı başlangıç” yazması şaşırtıcı değildir. Süreç kendi hatasını kaydedecek fırsat bulmamış olabilir. Benzer şekilde disk veya inode tükenmesi, normal log üretimini bile kesebilir.

“Error” araması yerine hipotez kurun

Bir hipotez yazın: “Yeni sürümün bellek kullanımı yükseldi, süreç öldürüldü ve proxy kısa süre 502 döndürdü.” Sonra bu hipotezi destekleyecek ve çürütecek kanıtları ayrı ayrı belirleyin.

Destekleyen kanıtlar; aynı dakikada kernel OOM kaydı, servis restart sayısının artması ve bellek grafiğindeki yükseliş olabilir. Çürüten kanıt; sürecin hiç yeniden başlamaması ve upstream adresinin yanlış yapılandırılmış olmasıdır.

Bir deployment ile hata başlangıcının aynı zamana denk gelmesi değerlidir, fakat tek başına nedensellik değildir. DNS, veritabanı veya altyapı değişiklikleri de aynı pencereye denk gelmiş olabilir.

Logların eksikliği de bir bulgudur

Journal rate limit'i, log rotasyonu, disk sorunu veya yanlış saat ayarı kayıtların görünmemesine yol açabilir. Döndürülmüş dosyalar için ilgili arşivleri de inceleyin:

ls -lh /var/log/nginx/
zgrep "upstream" /var/log/nginx/error.log.*.gz

Dosyalar mevcut değilse bu komutun sonuç vermemesi normaldir. Devasa bir logu gelişigüzel terminale basmak yerine zaman aralığını ve dosya kapsamını daraltın. Disk ölçümünün seçenekleri df(1) kılavuzunda açıklanır.

Müdahale ve olay sonrası kayıt

Önce kullanıcı etkisini azaltan kontrollü müdahaleyi seçin: hatalı sürümü geri almak, kapasite artırmak veya yanlış konfigürasyonu düzeltmek. Müdahalenin zamanını kaydedin ve aynı göstergelerin normale dönüp dönmediğini ölçün.

Olay sonunda üç çıktı bırakın: kanıta dayalı zaman çizelgesi, kök neden ile katkıda bulunan etkenler ve tekrarını azaltacak somut iş. “Servisi yeniden başlattık” bir müdahaledir; tek başına açıklama değildir. Ayrıca loglarda token, parola veya gereksiz kişisel veri tutmayın: teşhis kabiliyeti veri sızıntısı pahasına kurulmak zorunda değildir.