
Linux System Logs (journalctl) Nedir? Sunucu Hataları
Linux System Logs (journalctl) Nedir? Sunucu Hataları Nasıl İncelenir? journalctl, syslog ve servis loglarıyla hata analizi rehberi.

Cenk ŞEKERCİ
Operasyon Yöneticisi
Bir sunucuda sorun çıktığında çoğu zaman ilk ipucu ekranda değil, log dosyalarında saklıdır. Linux System Logs (journalctl) Nedir? Sunucu Hataları Nasıl İncelenir? sorusu da tam olarak burada önem kazanır: sistemin ne zaman, neden ve hangi servis yüzünden hata verdiğini anlamak için doğru kayıtları okumak gerekir.
İçindekiler
- Linux Systemctl Log
- Linux Syslog Nedir
- Linux Sistem Logları
- Linux Journalctl Service Log
- Linux Systemctl Service Logs
- Linux System Logs (journalctl) Nedir?Linux System Logs (journalctl) Ne İşe Yarar
- Linux System Logs (journalctl) Nasıl Çalışır
- Sunucu Hataları Nasıl İncelenir?
- Sıkça Sorulan Sorular
- İlgili İçerikler
Linux Systemctl Log
Linux systemctl log, systemd ile yönetilen servislerin durumunu ve hatalarını incelemek için kullanılan kayıt yaklaşımını ifade eder. systemctl servis durumunu gösterir; ayrıntılı loglar ise genellikle journalctl üzerinden okunur.
systemctl status komutu, bir servisin çalışıp çalışmadığını, son hata satırlarını ve process bilgisini hızlıca gösterir. Ancak bu çıktı sınırlıdır; geçmiş kayıtlar, filtreleme ve zaman aralığı analizi için journalctl daha doğru araçtır.
Örnek kullanım:

systemctl status nginx
systemctl status ssh
systemctl status mysql
Bu komutlar özellikle “servis neden başlamıyor?” sorusuna ilk yanıtı verir.
| Komut | Ne Gösterir? | Ne Zaman Kullanılır? |
|---|---|---|
| `systemctl status servis` | Servis durumu ve son log satırları | Hızlı kontrol |
| `journalctl -u servis` | Servise ait ayrıntılı günlükler | Hata analizi |
| `systemctl restart servis` | Servisi yeniden başlatır | Düzeltme sonrası test |
| `systemctl enable servis` | Açılışta başlatmayı etkinleştirir | Kalıcı servis yönetimi |
İpucu:
systemctl statusçıktısındaki hata satırı çoğu zaman sadece başlangıç noktasıdır. Kök nedeni görmek için aynı servisijournalctl -u servis-adiile incelemek gerekir.
Linux Syslog Nedir
Linux syslog nedir sorusunun kısa yanıtı şudur: Syslog, Linux sistemlerinde çekirdek, servis, güvenlik ve uygulama olaylarını kayıt altına alan geleneksel log mekanizmasıdır. Modern dağıtımlarda systemd journal ile birlikte ya da onun yanında çalışabilir.
Syslog kayıtları çoğunlukla /var/log/ dizini altında tutulur. Dağıtıma göre dosya adları değişebilir; örneğin Debian/Ubuntu tarafında /var/log/syslog, RHEL/CentOS tarafında /var/log/messages sık görülür.
Yaygın syslog dosyaları:
| Dosya | İçerik | Dağıtım Notu |
|---|---|---|
| `/var/log/syslog` | Genel sistem olayları | Debian/Ubuntu |
| `/var/log/messages` | Genel sistem mesajları | RHEL/CentOS türevleri |
| `/var/log/auth.log` | Kimlik doğrulama kayıtları | Debian/Ubuntu |
| `/var/log/secure` | SSH ve güvenlik olayları | RHEL/CentOS |
| `/var/log/kern.log` | Kernel mesajları | Bazı Debian sistemleri |
Syslog hâlâ birçok sistemde kullanılır; fakat journald, logları yapılandırılmış biçimde tuttuğu için filtreleme açısından daha esnektir.
Linux Sistem Logları
Linux sistem logları, işletim sistemi, servisler, kernel, kullanıcı oturumları, paket yöneticisi ve güvenlik olayları hakkında bilgi veren kayıtlardır. Sunucu yönetiminde loglar yalnızca hata bulmak için değil, performans ve güvenlik takibi için de kullanılır.
Bir Linux sunucuda log okumaya başlarken önce olayın türünü belirlemek gerekir. Örneğin bağlantı sorunu SSH loglarıyla, disk hatası kernel loglarıyla, web hatası ise web sunucusu loglarıyla ilişkilidir.
| Sorun Türü | Bakılacak Yer | Örnek Komut |
|---|---|---|
| SSH giriş sorunu | Auth/Secure logları | `journalctl -u ssh` |
| Servis başlamıyor | systemd journal | `journalctl -u servis` |
| Disk hatası | Kernel logları | `journalctl -k` |
| Yeniden başlama | Boot kayıtları | `journalctl -b -1` |
| Yüksek kaynak kullanımı | Servis ve sistem logları | `journalctl --since "1 hour ago"` |
Log Seviyeleri
Linux loglarında mesajların önem derecesi farklıdır. Her “warning” kritik değildir; her “error” da sistemin tamamen çöktüğü anlamına gelmez.
| Seviye | Anlamı | Öncelik |
|---|---|---|
| `emerg` | Sistem kullanılamaz durumda | Çok kritik |
| `alert` | Acil müdahale gerekir | Çok yüksek |
| `crit` | Kritik hata | Yüksek |
| `err` | Hata | Yüksek |
| `warning` | Uyarı | Orta |
| `notice` | Dikkat edilmesi gereken olay | Orta |
| `info` | Bilgilendirme | Düşük |
| `debug` | Geliştirici detayı | Düşük |
Uyarı: Loglarda tek bir satıra bakarak karar vermek yanıltıcı olabilir. Hatanın birkaç dakika öncesi ve sonrası birlikte incelenmelidir.
Linux Journalctl Service Log
Linux journalctl service log, belirli bir systemd servisine ait kayıtları incelemek için kullanılan en pratik yöntemdir. journalctl -u parametresiyle servis bazlı filtreleme yapılır ve gereksiz sistem kayıtları ayıklanır.
Örnekler:
journalctl -u nginx
journalctl -u nginx --since "2026-10-15 10:00"
journalctl -u nginx -f
Burada -f parametresi canlı takip anlamına gelir. Özellikle bir servisi yeniden başlatırken anlık olarak ne olduğunu görmek için kullanışlıdır.
Zaman Aralığıyla Servis Logu İnceleme
Belirli bir zaman aralığı vermek, log kalabalığını azaltır. Örneğin gece 03:00’te kesinti olduysa tüm günün logunu okumak yerine sadece ilgili dakikalara odaklanmak daha doğru olur.
journalctl -u postgresql --since "03:00" --until "03:20"
Bu yaklaşım, hata analizini hızlandırır ve yanlış ipuçlarına takılmayı azaltır.
Linux Systemctl Service Logs
Linux systemctl service logs, systemctl status ile görülen kısa servis çıktıları ve journalctl ile ulaşılan ayrıntılı servis günlüklerinin birlikte değerlendirilmesidir. İki komut aynı amaca hizmet etmez; birbirini tamamlar.
systemctl servis yönetim aracıdır. journalctl ise systemd journal kayıtlarını okur. Hata incelemesinde önce servis durumu kontrol edilir, ardından ayrıntılı loga geçilir.
| İhtiyaç | Kullanılacak Komut | Açıklama |
|---|---|---|
| Servis çalışıyor mu? | `systemctl status servis` | Aktif/pasif durumu gösterir |
| Neden hata verdi? | `journalctl -u servis` | Detaylı kayıtları listeler |
| Canlı izleme | `journalctl -u servis -f` | Yeni logları anlık gösterir |
| Son açılıştaki kayıtlar | `journalctl -u servis -b` | Mevcut boot içindeki logları getirir |
| Önceki açılış | `journalctl -u servis -b -1` | Reboot öncesi kayıtları gösterir |
Pratik akış şöyle olabilir:
- Servis durumunu kontrol et.
- Hata kodunu ve son log satırlarını oku.
journalctl -uile ayrıntıya in.- Zaman aralığı kullan.
- Konfigürasyon değişikliklerini kontrol et.
- Düzeltme sonrası servisi yeniden başlatıp logu canlı izle.
Linux System Logs (journalctl) Nedir?Linux System Logs (journalctl) Ne İşe Yarar
Linux System Logs (journalctl), systemd kullanan Linux sistemlerde servis, kernel, boot ve sistem olaylarını okumak için kullanılan günlük görüntüleme aracıdır. Sunucu hatalarının kaynağını bulmak, servis davranışını izlemek ve olay geçmişini analiz etmek için kullanılır.
journalctl, klasik düz metin log dosyalarından farklı olarak logları yapılandırılmış biçimde saklar. Bu sayede servis adı, zaman, öncelik seviyesi, boot oturumu veya kullanıcı bazlı filtreleme yapılabilir.
Sık kullanılan journalctl komutları:
| Komut | Amaç |
|---|---|
| `journalctl` | Tüm journal kayıtlarını gösterir |
| `journalctl -xe` | Son hataları açıklamalı gösterir |
| `journalctl -u servis` | Belirli servis loglarını listeler |
| `journalctl -f` | Logları canlı takip eder |
| `journalctl -k` | Kernel kayıtlarını gösterir |
| `journalctl -p err` | Sadece hata seviyesindeki kayıtları getirir |
| `journalctl --disk-usage` | Journal loglarının disk kullanımını gösterir |
Journalctl Hangi Durumlarda Kullanılır?
journalctl özellikle servis çökmesi, başarısız başlatma, boot hatası, kernel uyarısı, erişim problemi ve zaman bazlı kesintilerde değerlidir.
Örneğin bir web servisi çalışmıyorsa yalnızca uygulama loguna bakmak yetmeyebilir. Port çakışması, izin hatası, eksik dosya, hatalı environment değişkeni veya bağımlılık sorunu journal kayıtlarında görülebilir.
Linux System Logs (journalctl) Nasıl Çalışır
Linux System Logs (journalctl) nasıl çalışır sorusunun yanıtı systemd-journald servisinde saklıdır. Bu servis, sistemden gelen olayları toplar, indeksler ve journalctl komutu ile okunabilir hâle getirir.
Journald kayıtları genellikle /run/log/journal/ veya /var/log/journal/ altında tutulur. /run altında tutulan kayıtlar geçicidir; yeniden başlatma sonrası silinebilir. Kalıcı journal için /var/log/journal/ yapılandırması gerekir.
Kalıcı Log Kayıtları
Bazı sistemlerde journal kayıtları varsayılan olarak kalıcı olmayabilir. Önceki boot kayıtlarını göremiyorsanız kalıcılık ayarı kapalı olabilir.
Kontrol için:
journalctl --list-boots
Eğer yalnızca mevcut boot görünüyorsa, kalıcı loglama yapılandırması incelenmelidir.
Bilgi kutusu: Kalıcı log tutmak hata analizi için faydalıdır; fakat disk kullanımını da takip etmek gerekir. Yoğun trafikli sistemlerde journal boyutu düzenli kontrol edilmelidir.
Disk kullanımını görmek için:
journalctl --disk-usage
Eski kayıtları temizlemek için:
journalctl --vacuum-time=7d
journalctl --vacuum-size=1G
Sunucu Hataları Nasıl İncelenir?
Sunucu hataları, doğru sırayla incelendiğinde daha hızlı çözülebilir. Önce hatanın zamanı ve etkilenen servis belirlenmeli, ardından systemd, kernel, uygulama ve güvenlik logları birlikte değerlendirilmelidir.
Başarılı bir hata analizi için rastgele log okumak yerine kanıt odaklı ilerlemek gerekir. “Ne zaman başladı?”, “Hangi servis etkilendi?”, “Öncesinde ne değişti?” soruları çoğu zaman çözümü hızlandırır.
Pratik Hata Analizi Akışı
- Zamanı belirleyin: Kesinti ne zaman başladı?
- Servisi kontrol edin:
systemctl status servis - Servis loglarını okuyun:
journalctl -u servis --since "..." - Sistem hatalarını süzün:
journalctl -p err - Kernel kayıtlarını inceleyin:
journalctl -k - Disk ve bellek durumunu kontrol edin:
df -h,free -m - Son değişiklikleri değerlendirin: paket güncellemesi, config değişikliği, deploy.
- Düzeltmeden sonra canlı takip yapın:
journalctl -u servis -f
Yaygın Hata Senaryoları
| Belirti | Olası Neden | Bakılacak Log |
|---|---|---|
| Servis başlamıyor | Hatalı config, port çakışması | `journalctl -u servis` |
| Sunucu yavaş | Bellek, CPU, disk I/O | Sistem ve uygulama logları |
| SSH bağlantısı yok | Firewall, auth hatası, servis kapalı | `auth.log`, `journalctl -u ssh` |
| Beklenmeyen reboot | Kernel panic, güç, OOM | `journalctl -b -1`, `journalctl -k` |
| Web sitesi 502 veriyor | Backend servis hatası | Web server ve app logları |
İpucu: Hata anından hemen önceki 5 dakika çoğu zaman en değerli bölümdür. Servisin düştüğü satıra değil, düşmeden önceki uyarılara odaklanın.
Sıkça Sorulan Sorular
Journalctl Nedir?
journalctl, systemd kullanan Linux sistemlerde günlük kayıtlarını görüntülemek için kullanılan komuttur. Servis hataları, boot kayıtları, kernel mesajları ve sistem olayları bu araçla incelenebilir. Klasik log dosyalarına göre daha esnek filtreleme sağlar. Belirli servis, zaman aralığı, hata seviyesi veya boot oturumu bazında kayıt okumak mümkündür. Sunucu yönetiminde özellikle servis neden başlamıyor, sistem neden yeniden başladı veya hangi hata tekrar ediyor sorularına yanıt verir.
Systemctl İle Journalctl Arasındaki Fark Nedir?
systemctl, systemd servislerini yönetmek için kullanılır; servis başlatma, durdurma, yeniden başlatma ve durum kontrolü yapar. journalctl ise bu servislerin ve sistemin ürettiği log kayıtlarını okur. Yani systemctl status nginx servisin mevcut durumunu gösterirken, journalctl -u nginx geçmiş ve ayrıntılı kayıtları listeler. Hata analizinde ikisi birlikte kullanılmalıdır: önce durum kontrol edilir, sonra ayrıntılı log incelenir.
Linux’ta Servis Logları Nasıl Görülür?
Linux’ta servis loglarını görmek için en yaygın yöntem journalctl -u servis-adi komutudur. Örneğin journalctl -u nginx komutu Nginx servisine ait kayıtları listeler. Canlı izleme için -f, belirli zaman aralığı için --since ve --until parametreleri kullanılabilir. Eğer servis systemd ile yönetilmiyorsa uygulamanın kendi log dizini de kontrol edilmelidir. Web, veritabanı ve özel uygulamalarda ek log dosyaları bulunabilir.
Journalctl İle Son Hatalar Nasıl Görülür?
Son hataları görmek için journalctl -xe veya hata seviyesine göre journalctl -p err komutları kullanılabilir. -xe çıktısı son olayları daha açıklamalı biçimde gösterir. -p err ise yalnızca hata seviyesindeki kayıtları filtreler. Daha doğru analiz için bu komutlar zaman filtresiyle birlikte kullanılabilir. Örneğin journalctl -p err --since "1 hour ago" son bir saatteki hata kayıtlarını listeler.
Önceki Boot Logları Nasıl İncelenir?
Önceki boot kayıtlarını incelemek için önce journalctl --list-boots komutu çalıştırılır. Bu komut sistem açılışlarını listeler. Ardından journalctl -b -1 ile bir önceki açılışa ait kayıtlar görüntülenir. Belirli bir servisin önceki boot içindeki loglarını görmek için journalctl -u servis -b -1 kullanılabilir. Eğer önceki boot görünmüyorsa journal kayıtları kalıcı tutulmuyor olabilir ve journald yapılandırması kontrol edilmelidir.
Journalctl Logları Diskte Yer Kaplar mı?
Evet, journal kayıtları diskte yer kaplayabilir. Kullanılan alanı görmek için journalctl --disk-usage komutu çalıştırılır. Yoğun log üreten sistemlerde bu alan zamanla büyüyebilir. Eski kayıtları temizlemek için journalctl --vacuum-time=7d veya journalctl --vacuum-size=1G gibi komutlar kullanılabilir. Ancak log temizlemeden önce güvenlik, denetim ve hata analizi ihtiyaçları dikkate alınmalıdır.
Linux Syslog Hâlâ Kullanılıyor mu?
Evet, syslog birçok Linux sisteminde hâlâ kullanılır. Özellikle /var/log/syslog, /var/log/messages, /var/log/auth.log ve /var/log/secure gibi dosyalar sistem ve güvenlik olaylarını takip etmek için önemlidir. Modern dağıtımlarda systemd journal daha yaygın hâle gelse de syslog tamamen ortadan kalkmış değildir. Bazı uygulamalar hâlâ doğrudan klasik log dosyalarına kayıt yazar. Bu nedenle sorun analizinde iki yapı birlikte değerlendirilebilir.
Sunucu Neden Yeniden Başladı Nasıl Anlaşılır?
Sunucunun neden yeniden başladığını anlamak için last reboot, journalctl -b -1 ve journalctl -k -b -1 komutları kullanılabilir. Önceki boot kayıtlarında kernel panic, OOM killer, güç kesintisi, watchdog veya manuel yeniden başlatma izleri aranır. Eğer loglar aniden kesiliyorsa güç veya sanallaştırma platformu tarafı da kontrol edilmelidir. Sadece işletim sistemi kayıtları her zaman tek başına yeterli olmayabilir.
Servis Başlamıyorsa Hangi Loglara Bakılmalı?
Servis başlamıyorsa önce systemctl status servis komutu ile hata özeti görülmelidir. Ardından journalctl -u servis komutu ile ayrıntılı kayıtlar incelenir. Hatalı yapılandırma, eksik dosya, izin problemi, port çakışması veya bağımlı servisin çalışmaması sık görülen nedenlerdir. Eğer servis bir web uygulamasıysa uygulamanın kendi log dizini de kontrol edilmelidir. Düzeltmeden sonra journalctl -u servis -f ile canlı izleme yapılabilir.
Journalctl Canlı Log Takibi Nasıl Yapılır?
Canlı log takibi için journalctl -f komutu kullanılır. Belirli bir servisi canlı izlemek için journalctl -u servis -f daha kullanışlıdır. Örneğin journalctl -u nginx -f, Nginx servisine ait yeni kayıtları anlık gösterir. Bu yöntem servis yeniden başlatılırken, hata tekrar üretilirken veya deploy sonrası kontrol yapılırken faydalıdır. Canlı takip sırasında yalnızca yeni kayıtlar aktığı için olayın tam anını yakalamak kolaylaşır.
Kapanış
Linux’ta log okumak, ezber komutlardan çok doğru sırayı kurma işidir. systemctl ile servisin durumunu görüp journalctl ile ayrıntıya inmek, sunucu hatalarında en sağlam başlangıçtır. Özellikle kritik sistemlerde logların kalıcı tutulması, disk kullanımının izlenmesi ve hata zamanlarının not edilmesi müdahale süresini ciddi biçimde kısaltır.
Sunucu yönetimi, Linux bakım süreçleri veya log analizi konusunda daha düzenli bir altyapı kurmak istiyorsanız Netlen’in teknik içeriklerini ve hizmetlerini inceleyerek ihtiyaçlarınıza uygun bir yol haritası oluşturabilirsiniz: netlen.com.tr
İlgili İçerikler
- Linux Sunucu Yönetimi Rehberi
- SSH Güvenliği Nasıl Sağlanır?
- Nginx Logları Nasıl İncelenir?
- Linux’ta Disk Kullanımı Nasıl Kontrol Edilir?
- Sunucu Performans Sorunları Nasıl Analiz Edilir?
Netlen'i Google'da Takip Edin
En güncel rehberlerimize, duyurularımıza ve teknik içeriklerimize Google üzerinden öncelikli ulaşmak için Netlen'i tercih ettiğiniz kaynaklar arasına ekleyin.
Bu yazıyı paylaşın

Yazar Hakkında
Cenk ŞEKERCİ
Operasyon Yöneticisi
Bulut teknolojileri, ağ altyapıları ve veri merkezi operasyonları üzerine çalışıyorum. Öğrendiğim yeni teknolojileri ve sahada karşılaştığım gerçek deneyimleri anlaşılır şekilde paylaşmayı seviyorum.
Yorumlar
Bu yazı hakkında okuyucu yorumları


