Kurumsal ortamlarda log toplama hattının en zayıf anı, ağın kısa süreli bozulduğu anlardır. Uygulama veya sunucu log üretmeye devam eder; fakat merkezi sisteme taşıma katmanı bu esnada satır kaybedebilir. Özellikle güvenlik, audit ve işletim kayıtları için bu kayıp kabul edilemez. Rsyslog ile RELP kullanımı tam bu noktada değer üretir: taşımanın yalnızca “gönderdim” demesine değil, karşı tarafın alımı teyit etmesine dayanır.
RELP neden klasik syslog TCP’den farklı?
TCP kullanmak çoğu ekip için yeterli güvence gibi görünür. Ancak bağlantı koptuğunda, yeniden bağlanma sırasında ve hedef tarafın yavaşladığı anlarda hangi mesajın gerçekten işlendiğini bilmek zordur. RELP bu açığı kapatır:
- Her mesaj işlem kimliğiyle taşınır
- Hedef alımı teyit eder
- Kesinti sonrası iletim daha güvenilir devam eder
Bu özellikler özellikle güvenlik olayları, sudo kayıtları, sistem logları ve kritik uygulama günlükleri için önemlidir.
Sunucu tarafı kurulumu
Önce merkezi log sunucusunda gerekli modülleri açalım. Debian tabanlı bir örnek için:
sudo apt update
sudo apt install rsyslog rsyslog-relp -yArdından /etc/rsyslog.d/10-relp-server.conf içine temel dinleme yapılandırmasını ekleyebiliriz:
module(load="imrelp")
module(load="builtin:omfile")
input(type="imrelp" port="2514")
template(name="PerHostFile" type="string"
string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
action(type="omfile" dynaFile="PerHostFile" createDirs="on")Bu yapı tek başına çalışır; ama üretimde dizin yetkileri, disk alanı ve log rotate stratejisi ayrıca düşünülmelidir.
İstemci tarafı yapılandırma
İstemci düğümde kuyruk ve yeniden deneme ayarları en kritik bölümdür. Sadece uzak hedefi tanımlamak yeterli değildir. /etc/rsyslog.d/60-relp-forward.conf için örnek:
module(load="omrelp")
action(
type="omrelp"
target="10.50.10.20"
port="2514"
tls="off"
queue.type="LinkedList"
queue.filename="relp-forward"
queue.size="200000"
queue.saveonshutdown="on"
action.resumeRetryCount="-1"
)Bu yapı, hedef ulaşılamadığında logları geçici olarak diske tutar ve hedef geri geldiğinde akışı sürdürür.
TLS ne zaman eklenmeli?
Eğer log koridoru paylaşımlı ağdan geçiyor, farklı segmentler arasında taşınıyor veya regülasyon baskısı taşıyorsa RELP üzerine TLS eklemek gerekir. Rsyslog bu konuda esnek davranır; fakat sertifika yaşam döngüsünü yönetmeden TLS açmak operasyon borcu üretir.
Genel yaklaşım şöyle olabilir:
- Önce iç, güvenilen koridorda şifrelemesiz akışı doğrula
- Sonra istemci ve sunucu sertifikalarını dağıt
- Bağlantıyı TLS ile zorunlu hâle getir
- Yenileme ve iptal sürecini otomasyona bağla
Hangi logları bu hatta almalıyım?
Ben RELP hattını özellikle şu tür kayıtlar için ayırmayı faydalı buluyorum:
auth.logve sudo kayıtları- Güvenlik ajanı ve EDR olayları
- Sistem olay günlükleri
- Kritik middleware ve ERP entegrasyon logları
Her debug logunu aynı hatta koymak gereksizdir. Çünkü amaç her şeyi pahalı güvenilirlikle taşımak değil; kaybı kabul edilemeyecek veriyi doğru koridorla iletmektir.
Doğrulama nasıl yapılır?
Kurulum sonrasında sadece servis ayağa kalktı diye yetinmeyin. Şu testleri özellikle uygulayın:
- İstemciden test logu üretin
- Sunucuda doğru dosyaya düştüğünü görün
- Ağ bağlantısını kısa süre kesip kuyruk davranışını izleyin
- Bağlantı geri geldiğinde satırların teslim edildiğini doğrulayın
Basit test komutu:
logger -p authpriv.notice "relp-test $(date +%s)"Ardından merkezi sunucuda ilgili host ve program dosyasında girdiyi arayın.
Sık yapılan hatalar
En yaygın hata, güvenilir taşıma hedefi kurup hedef sunucudaki disk baskısını hesaba katmamak. İkinci hata, tüm istemcileri tek dizin ve tek dosyada toplamaya çalışmak. Böyle olunca sorgulama, rotate ve olay inceleme zorlaşır.
Bir başka hata da RELP hattını kurup bu hattın durumunu izlememektir. Kuyruk boyutu, başarısız teslim sayısı ve disk tüketimi de gözlemlenmelidir. Aksi halde sistem sessizce biriken risk yaratır.
Sonuç
Rsyslog RELP ile güvenilir uzak log taşıma, log toplama hattını “en iyi ihtimalle gider” modelinden çıkarıp operasyonel güvenceye taşır. Özellikle Linux sunucular, güvenlik kayıtları ve kurumsal entegrasyon servisleri için bu yaklaşım basit ama güçlü bir dayanıklılık katmanıdır. Kritik loglar için önemli olan yalnızca toplamak değil, bozuk ağ anlarında da kaybetmemektir.