LİNUX LOGLAMA: JOURNALCTL, SYSLOG VE SORUN GİDERME AKIŞI

Bir servis “çalışıyor” görünüp kullanıcıya hata veriyorsa, gerçeği çoğu zaman loglar söyler. Linux dünyasında loglar sadece metin satırları değildir; zaman çizelgesi, kimlik doğrulama izleri, kernel uyarıları ve uygulama istisnaları tek bir hikâyeye dönüşür.

Bu yazıda systemd journal üzerinden journalctl ile hızlı inceleme, klasik syslog ekosistemi (rsyslog/syslog-ng) ile dosya tabanlı izleme ve pratik bir sorun giderme akışı kuracağız. Amaç “hangi komut ne yapar?” listesinden öte; doğru veriyi doğru anda bulmak.

Önceliğimiz: semptomu zaman penceresine sıkıştırmak, ilgili servis/üniteyi izole etmek, hata mesajını yakalamak ve ardından bağımlılıkları (DNS, disk, ağ, izinler, kernel) sistematik biçimde elemek.

Linux loglama mimarisi: journal ve syslog birlikte nasıl yaşar?

Modern dağıtımlarda systemd, logları ikili bir depoda tutan journald bileşeni ile toplar. Uygulamalar stdout/stderr’e yazsa bile journald bunları yakalayabilir. Öte yandan birçok ortam hâlâ syslog formatını ve dosya tabanlı arşivlemeyi tercih eder; burada devreye rsyslog veya syslog-ng girer.

Çoğu sistemde journald, logları rsyslog’a “forward” ederek /var/log altındaki dosyaları besler. Bu sayede hem journalctl ile zengin filtreleme yapılır, hem de geleneksel dosya izleme araçları (tail/grep) çalışmaya devam eder.

journald’in güçlü tarafı: yapılandırılmış meta veri

Journal kayıtları yalnızca mesajdan ibaret değildir. Her satırda ünite adı, PID, UID, boot kimliği, zaman damgası gibi alanlar vardır. Bu meta veriler sayesinde “sadece nginx hatalarını” ya da “bu boot sırasında oluşan kernel uyarılarını” hedeflemek kolaylaşır.

syslog’un güçlü tarafı: standart format ve entegrasyon

Syslog, uzun yıllardır kullanılan bir standarttır. SIEM, merkezi log sunucuları ve birçok üçüncü parti ajan syslog ile daha kolay konuşur. Ayrıca düz metin dosyaları, sürümleme/taşıma/okuma açısından basittir; ancak bağlam verisi journal kadar zengin olmayabilir.

journalctl ile hızlı başlangıç: en çok iş gören filtreler

journalctl, “her şeyi dök” komutu değildir; doğru filtre ile saniyeler içinde hedefi daraltır. En iyi pratik, önce zamanı sınırlandırmak, sonra üniteyi seçmek, sonra öncelik/seviye ve anahtar kelimelerle ayıklamaktır.

Zaman penceresi: önce “ne zaman?” sorusunu cevapla

Bir olayın etkisini ölçmek için önce zaman aralığı belirleyin. Örneğin “son 30 dakika” ile başlayıp sonra daha dar bir pencereye inebilirsiniz. Zaman damgasını netleştirmek, tekrar eden hatalarla tekil hataları ayırır.

# Son 30 dakikanın logları
journalctl --since "30 min ago"

# Belirli bir tarih/saat aralığı
journalctl --since "2026-02-04 08:00:00" --until "2026-02-04 09:00:00"

Ünite/servis bazlı inceleme: “hangi bileşen?”

Sistemdeki bir servis için en değerli filtre, ünite adıdır. Böylece farklı süreçlerin gürültüsü elimine olur. Özellikle yeniden başlatma döngüleri, bağımlılık hataları ve port çakışmaları burada hızlı görünür.

# nginx servisine ait kayıtlar
journalctl -u nginx

# Son 200 satır ve gerçek zamanlı takip
journalctl -u nginx -n 200 -f

Öncelik seviyeleri: gürültüyü azalt, sinyali yükselt

Journal’da syslog benzeri seviyeler vardır. “warning ve üzeri” ya da sadece “err” seviyesine odaklanarak ilk tanıyı hızlandırabilirsiniz. Bu yaklaşım, özellikle yoğun prod sistemlerde gereksiz satırları azaltır.

İpucu: “kritik hata yok” demek, sorun yok demek değildir; bazı uygulamalar hatayı info seviyesinde yazar. Yine de başlangıç için seviyeler güçlü bir filtredir.

Boot ve kernel bağlamı: “bu yeniden başlatmada ne oldu?”

Bir problem reboot sonrası başladıysa, “bu boot” veya “önceki boot” loglarını ayırmak çok değerli olur. Kernel mesajları, sürücü hataları, disk I/O uyarıları ve OOM olayları bu katmanda yakalanır.

Boot filtreleri ayrıca günlerce biriken log içinden tek bir restart penceresini ayıklamayı sağlar.

syslog, rsyslog ve dosya tabanlı takip: /var/log ekosistemi

Syslog hattı aktifse, birçok kayıt /var/log altında dosyalara düşer. Örneğin Debian/Ubuntu’da /var/log/syslog, RHEL türevlerinde /var/log/messages sık görülür. Uygulamaya özel dosyalar (ör. /var/log/nginx/error.log) da yaygındır.

Dosya tabanlı incelemede temel prensip: önce doğru dosyayı bul, sonra zaman penceresi ve anahtar kelimelerle filtrele, sonra olayları servis bağlamıyla ilişkilendir.

Hangi dosya nerede? hızlı keşif

Yeni bir sistemde en pratik yöntem, ilgili servisin yapılandırmasına ve paket varsayılanlarına bakmaktır. Çoğu servis kendi log yolunu konfigürasyonda belirtir. Ayrıca journald ile syslog arasında forward açıksa aynı olay iki yerde görülebilir; çakışma değil, paralel izdir.

tail ve grep ile kontrollü izleme

Dosyayı doğrudan takip etmek, özellikle uygulamanın kendi log formatı (JSON, özel alanlar) varsa faydalıdır. Ancak sadece “tail -f” yapmak yerine, hata desenlerini hedeflemek daha verimli olur.

# Son 100 satır ve takip
tail -n 100 -f /var/log/syslog

# 5 dakika içinde geçen "timeout" satırlarını bulmak için önce zaman aralığı daraltın (journal), sonra dosyada doğrulayın
grep -i "timeout" /var/log/syslog | tail -n 50

rsyslog akışı: toplama, yönlendirme, arşiv

rsyslog, gelen mesajları kurallara göre farklı dosyalara yazabilir veya uzak bir sunucuya iletebilir. Bu, merkezi gözlem ve denetim için kritiktir. Eğer “bazı loglar yok” şikâyeti varsa rsyslog konfigürasyonunda filtreleme/rota hatası ihtimali vardır; özellikle facility/severity eşleşmeleri ve dosya izinleri sık sorun çıkarır.

Sorun giderme akışı: hızlı teşhis için adım adım yöntem

Log okuma, “rastgele komut denemek” değil, tekrarlanabilir bir süreç olmalıdır. Aşağıdaki akış, hem journal hem syslog dünyasında uygulanabilir.

1. Semptomu netleştir: hata mesajı, etkilenen kullanıcı/istemci, tam zaman.
2. Zaman penceresini daralt: olay öncesi/sonrası 5–15 dakika.
3. Servisi izole et: ilgili ünite (-u), süreç (PID), port, konteyner.
4. Seviyeleri ve anahtar kelimeleri uygula: error/timeout/denied/oom gibi desenler.
5. Bağımlılıkları kontrol et: DNS, disk, ağ, TLS, izinler, kernel.
6. Doğrulama yap: değişiklik sonrası aynı zaman penceresinde hatanın kaybolduğunu kanıtla.

Örnek senaryo: servis açılıyor ama istekler 502 dönüyor

Önce reverse proxy (nginx) ve arka uç servisi aynı zaman penceresinde inceleyin. journalctl ile ünite loglarını yan yana getirip “connection refused”, “upstream timed out” gibi ifadeleri arayın. Ardından arka uç serviste “bind address”, “port already in use” veya “permission denied” sinyallerini yakalayın.

Örnek senaryo: aralıklı yavaşlama ve anlık kopmalar

Bu tür sorunlar genelde tek bir hata satırı üretmez; bunun yerine tekrar eden uyarılar olur. “watchdog”, “retransmission”, “i/o error”, “hung task” gibi mesajlar hem kernel hem uygulama katmanında ipucu verebilir. Burada korelasyon önemlidir: aynı dakikada disk uyarısı ve uygulama time-out’u görülüyorsa kök neden altyapı olabilir.

Gelişmiş journalctl teknikleri: alanlar, çıktı formatı, korelasyon

Journal’ın avantajı, alan bazlı filtrelemeyi kolaylaştırmasıdır. Sadece mesaj metnini aramak yerine, ünite, kullanıcı, PID veya boot kimliği gibi alanlarla hedefi daraltabilirsiniz. Ayrıca çıktı formatını değiştirerek logu dış sistemlere aktarmak mümkün olur.

Alan bazlı yaklaşım: kim yazdı, hangi süreç üretti?

Bir hata satırını gördüğünüzde hemen “hangi PID?” ve “hangi executable?” sorusunu sorun. Uygulamalar fork/worker modeli kullanıyorsa, tek bir PID yerine çoklu süreçler olabilir. Bu durumda ünite filtresi daha stabil sonuç verir.

JSON çıktı ile analiz: makine okunur log

İleri seviye analizde, journal çıktısını JSON olarak almak ve daha sonra jq benzeri araçlarla incelemek faydalı olur. Bu yöntem, özellikle otomasyon ve olay korelasyonu için tercih edilir.

# JSON formatında çıktı (satır bazlı)
journalctl -u nginx -o json --since "1 hour ago" | head -n 3

Tekrarlayan hatayı yakalama: frekans ve desen

“Aynı hata her 20 saniyede bir” gibi durumlarda, yalnızca son satırları görmek yerine belirli bir desenin kaç kez geçtiğini saymak teşhisi hızlandırır. Bu noktada hem journal hem syslog üzerinde sayım yapılabilir; ancak önce zaman aralığını sınırlamak doğruluğu artırır.

Log seviyeleri, rotasyon ve kalıcılık: kaybolan logların önüne geçmek

Loglar iki şekilde “kaybolur”: ya hiç yazılmıyordur (konfigürasyon/izin), ya da yazılıyor ama tutulmuyordur (rotasyon/kalıcılık). journald varsayılanında bazı dağıtımlarda depolama “volatile” olabilir; reboot sonrası eski kayıtlar silinir. Üretim sistemlerinde kalıcı depolama ve makul bir saklama politikası belirlemek önemlidir.

Log rotasyonu: disk dolmadan iz bırakmak

Dosya tabanlı syslog’da logrotate devreye girer; journald tarafında ise boyut ve zaman bazlı sınırlar vardır. Eğer disk doluyorsa uygulamalar da hata vermeye başlayabilir; bu nedenle rotasyon “bakım işi” değil, süreklilik garantisidir.

Hassas veriler ve erişim kontrolü

Loglarda token, kişisel veri, erişim anahtarı gibi bilgiler sızabilir. Bu nedenle log seviyelerini doğru seçmek, maskeleme uygulamak ve erişim yetkilerini sınırlamak gerekir. Ayrıca merkezi loglama kullanıyorsanız taşıma sırasında TLS ve kimlik doğrulama kritik olur.

Merkezi loglama ve ekip içi operasyon: tek ekrandan görünürlük

Tek sunucuda log okumak kolaydır; ancak mikroservisler ve çoklu node’lar devreye girdiğinde “hangi hostta oldu?” sorusu zaman kaybettirir. Merkezi loglama yaklaşımı; rsyslog forward, journald gateway veya ajan tabanlı çözümlerle logları tek yerde toplar. Böylece arama, dashboard ve uyarı mekanizmaları mümkün olur.

Olay korelasyonu: aynı zaman, farklı katman

Bir kullanıcı hatası, uygulama logu, reverse proxy satırı ve kernel uyarısı aynı dakika içinde bir örüntü oluşturabilir. Bu nedenle zaman senkronizasyonu (NTP) ve tutarlı zaman damgaları operasyonel kaliteyi artırır. Korelasyon, “tek satırda çözüm” değil; katmanlar arası bağlantı kurmaktır.

Pratik kontrol listesi: ilk 10 dakikada ne yapılır?

• Servis durumu: yeniden başlatma döngüsü, bağımlılık hatası, port çakışması.
• Zaman penceresi: semptomdan önce/sonra 10 dakika.
• journalctl -u: ünite loglarında error/warn desenleri.
• Kernel sinyali: OOM, I/O error, network reset.
• İzinler: denied, selinux/apparmor mesajları.
• Dosya tabanı: /var/log/* içinde uygulama özel loglar.
• Tekrar üretim: hatayı kontrollü tekrar ettirip logu aynı anda izle.

İç eğitim kaynağı: pratik komutlarla hızlı ustalaşma

Bu konuyu daha sistematik bir laboratuvar akışıyla uygulamak isterseniz, Linux eğitimi içeriğinde journald, syslog ve servis sorun giderme pratiklerini adım adım ilerletebilirsiniz.

Kapanış: log okuma refleksi, operasyonel kas hafızasıdır

Linux loglama ekosistemi geniş görünse de, doğru filtrelerle “sinyali” yakalamak kısa sürede bir refleks hâline gelir. journalctl ile meta veriden güç alın, syslog ile standart ve arşivlenebilir bir hat kurun, ardından tutarlı bir sorun giderme akışıyla kök nedene hızlı ulaşın.