Syslogd, sistemin işlediği ve /dev/log sözde aygıtına gönderilen uygulamaların günlük mesajlarını toplar. Ardından mesajları /var/log/ dizinindeki uygun düz metin günlük dosyalarına yönlendirir.
Syslogd, mesajların nereye gönderileceğini bilir çünkü her biri meta veri alanlarını (bir zaman damgası ve mesajın kaynağı ve önceliği dahil) içeren başlıklar içerir.
systemd’nin ardından, Linux günlüğü artık Journald tarafından da işleniyor. Ayrıca diyorum çünkü syslogd hiçbir yere gitmedi ve hala geleneksel günlük dosyalarının çoğunu /var/log/ içinde bulabilirsiniz. Ancak kasabada (komut satırı) adı journalctl olan yeni bir şerif olduğunu bilmelisiniz .
syslogd ile oturum açma
Bir syslogd sistemindeki olaylar tarafından oluşturulan tüm günlükler /var/log/syslog dosyasına eklenir. Ancak, tanımlayıcı özelliklerine bağlı olarak, aynı dizindeki bir veya daha fazla dosyaya da gönderilebilirler.
Syslogd ile mesajların dağıtılma şekli, /etc/rsyslog.d/ dizininde bulunan 50-default.conf dosyasının içeriği tarafından belirlenir.
50-default.conf dosyasındaki bu örnek, cron ile ilgili olarak işaretlenen günlük mesajlarının cron.log dosyasına nasıl yazılacağını gösterir. Bu durumda, yıldız işareti (*), syslogd’a girişleri herhangi bir öncelik düzeyiyle (emerg veya err gibi tek bir düzeyin aksine) göndermesini söyler:
cron.* /var/log/cron.logSyslogd günlük dosyalarıyla çalışmak,journalctl gibi özel araçlar gerektirmez. Ancak bu konuda iyi olmak istiyorsanız, standart günlük dosyalarının her birinde ne tür bilgilerin tutulduğunu bilmeniz gerekir.
Aşağıdaki tablo, en yaygın syslogd günlük dosyalarını ve
amaçlarını listeler.
| Dosya adı | Amaç |
|---|---|
| auth.log | Sistem kimlik doğrulaması ve güvenlik olayları |
| boot.log | Önyüklemeyle ilgili olayların kaydı |
| dmesg | Aygıt sürücüleriyle ilgili çekirdek halkası arabelleği olayları |
| dpkg.log | Yazılım paketi yönetimi olayları |
| kern.log | Linux çekirdeği olayları |
| syslog | Tüm günlüklerin bir koleksiyonu |
| wtmp | Kullanıcı oturumlarını izler (who ve last komutlarıyla erişilir) |
Ayrıca, bireysel uygulamalar bazen kendi günlük dosyalarına yazacaktır. Uygulama verilerini almak için oluşturulmuş /var/log/apache2/ veya /var/log/mysql/ gibi dizinlerin tamamını da sıklıkla görürsünüz.
Günlük yeniden yönlendirme, daha önce gördüğünüz * sembolüne (tüm öncelik düzeyleri için) ek olarak sekiz öncelik düzeyinden herhangi biri aracılığıyla da kontrol edilebilir.
| Seviye | Tanım |
|---|---|
| debug | Hata ayıklama için yararlı |
| info | bilgilendirici |
| notice | Normal koşullar |
| warn | Uyarı gerektiren durumlar |
| err | Hata koşulları |
| crit | kritik koşullar |
| alert | Acil eylem gerekli |
| emerg | Sistem kullanılamaz |
sysglogd ile günlük dosyalarını yönetme
Varsayılan olarak, syslogd sizden yardım almadan arka planda günlük rotasyon, sıkıştırma ve silme işlemlerini gerçekleştirir. Ancak, özel işlem gerektiren günlükleriniz olması durumunda bunun nasıl yapıldığını bilmelisiniz.
Basit bir dosya ne tür bir özel muamele gerektirebilir? Şirketinizin PCI-DSS gibi düzenleyici veya endüstri standartlarıyla ilişkili işlem raporlama kurallarıyla uyumlu olması gerektiğini varsayalım. BT altyapı kayıtlarınızın daha uzun süre erişilebilir kalması gerekiyorsa, anahtar dosyalar arasında yolunuzu nasıl bulacağınızı kesinlikle bilmek isteyeceksiniz.
Logrotate sistemini çalışırken görmek için /var/log/ dizininin bazı içeriklerini listeleyin. Örneğin, auth.log dosyası üç farklı biçimde görünür:
- auth.log – Şu anda aktif olan ve üzerine yeni yetkilendirme mesajlarının yazıldığı sürüm.
- auth.log.1 – Rotasyondaki en son dosya hizmet dışı. Gerektiğinde hızlı bir şekilde tekrar harekete geçmeyi kolaylaştırmak için sıkıştırılmamış biçimde tutulur.
- auth.log.2.gz – Yer kazanmak için sıkıştırılmış eski bir koleksiyon (aşağıdaki listede .gz dosya uzantısından görebileceğiniz gibi).
Yedi gün sonra, bir sonraki rotasyon tarihi geldiğinde auth.log.2.gz, auth.log.3.gz olarak yeniden adlandırılacak, auth.log.1 sıkıştırılacak ve auth.log.2.gz, auth.log olarak yeniden adlandırılacaktır. auth.log.1 olacak ve yeni bir dosya oluşturulacak ve auth.log adı verilecek.
Varsayılan günlük döndürme döngüsü /etc/logrotate.conf dosyasında kontrol edilir. Bu listede gösterilen değerler, tek bir etkin haftadan sonra dosyaları döndürür ve dört hafta sonra eski dosyaları siler.
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# packages drop log rotation information into this directory
include /etc/logrotate./etc/logrotate.d/ dizini ayrıca bireysel hizmetlerin veya uygulamaların günlük dönüşünü yönetmek için özelleştirilmiş yapılandırma dosyaları içerir. Bu dizinin içeriğini listelerken şu yapılandırma dosyalarını görürsünüz:
$ ls /etc/logrotate.d/
apache2 apt dpkg mysql-server
rsyslog
samba
unattended-upgradeSyslog dosyaları nasıl okunur
Milyonlarca satırlık günlük girişini okumaktansa, zamanla yapacak daha iyi işlerin olduğunu biliyorsun.
Burada cat kullanmaktan tamamen kaçınılmalıdır. Sadece ekranınıza binlerce satır dökecektir.
Dosyalar arasında metin filtrelemek için grep kullanmanızı öneririm.
tail -f komutunun kullanılması , geçerli günlük dosyasını gerçek zamanlı olarak okumanıza olanak tanır . İstediğiniz metni filtrelemek için grep ile birleştirebilirsiniz.
Bazı durumlarda eski, sıkıştırılmış günlüklere erişmeniz gerekebilir. Her zaman önce dosyayı çıkarabilir ve ardından içeriğini okumak için grep, less ve diğer komutları kullanabilirsiniz, ancak daha iyi bir seçenek vardır. Sıkıştırılmış dosyalar üzerinde açıkça çıkarmadan çalışmanıza izin veren zcat, zless vb. gibi z komutları vardır.
Günlük analizinin pratik bir örneği
Başarısız oturum açma girişimlerinin kanıtı için auth.log dosyasında arama yapacak bariz bir örnek. Kelime hatası arandığında
, kimlik doğrulama hatası ifadesini içeren herhangi bir satır döndürülecektir.
Bunu arada bir kontrol etmek, doğru şifreyi tahmin ederek bir hesabın güvenliğini aşma girişimlerini tespit etmenize yardımcı olabilir. Herkes bir veya iki kez bir parolayı karıştırabilir, ancak çok fazla başarısız deneme sizi şüphelendirmelidir:
$ cat /var/log/auth.log | grep 'Authentication failure'
Sep 6 09:22:21 workstation su[21153]: pam_authenticate: Authentication failureHiç hata yapmayan türden bir yöneticiyseniz, bu arama boş gelebilir. logger adlı bir program kullanarak manuel olarak bir günlük girişi oluşturarak kendinize en az bir sonuç garanti edebilirsiniz. Bunun gibi bir şey yaparak deneyin:
logger "Authentication failure"Anlayabileceğiniz gibi, grep işi sizin için yaptı, ancak sonuçlardan görebileceğiniz tek şey bir kimlik doğrulama hatası olduğu. Kimin hesabının dahil olduğunu bilmek faydalı olmaz mıydı? Maçtan hemen önce ve sonra satırları dahil etmesini söyleyerek grep döndüren sonuçları genişletebilirsiniz.
Yazının orijinalini buradan okuyabilirsiniz.
Kariyerime 26 yıl önce başladım. Windows ve Linux sistemlerinin kurulumu, yapılandırılması, yönetimi ve bakımı dahil olmak üzere birden fazla sistem üzerinde uzmanlaştım.
Açık kaynak dünyasındaki en son gelişmelerden haberdar olmaktan ve Linux hakkındaki en son araçları, özellikleri ve hizmetleri denemekten hoşlanıyorum.
Son 6 yıldır sistem ve ağ yöneticisi olarak görev yapıyorum ayrıca Pardus Dönüşüm Projesini yönetiyorum ve Pardus İşletim Sisteminin yaygınlaşması adına uğraş gösteriyorum.
Boş zamanlarımda açık kaynaklı uygulamaların Türkçe çevirisine katılıyorum ve The Document Foundation üyesiyim.