journald ile Uzak Log Sunucusuna Gönderme

Merkezi log yönetimi, üzerinde çalıştığı ortam büyüdükçe sysadmin’lerin en çok ihtiyaç duyduğu şeylerden biri haline geliyor. Onlarca sunucu varken her birine tek tek bağlanıp log okumak yerine, tüm logları tek bir noktada toplamak hem zaman kazandırıyor hem de sorun gidermeyi çok daha kolay hale getiriyor. Systemd’nin log yönetim bileşeni olan journald, sadece lokal log tutmakla kalmıyor; uzak sunuculara log gönderme konusunda da ciddi yeteneklere sahip. Bu yazıda journald ile uzak log sunucusu kurulumunu, güvenli aktarımı ve gerçek dünya senaryolarını ele alacağız.

journald’nin Uzak Log Mimarisini Anlamak

Journald, systemd-journal-remote ve systemd-journal-upload bileşenleri üzerinden uzak log aktarımını sağlıyor. Mimariyi kafanda oturtmak için şu üç bileşeni iyi anlamak gerekiyor:

systemd-journal-upload: Log gönderen tarafta çalışır, yani “client” tarafında. Logları HTTPS üzerinden hedef sunucuya iletir.
systemd-journal-remote: Log alan tarafta çalışır, yani “server” tarafında. Gelen logları dinler ve dosyaya yazar.
systemd-journal-gatewayd: HTTP üzerinden journal loglarına REST API erişimi sağlar. Doğrudan uzak log aktarımında kullanılmaz ama Grafana gibi araçlarla entegrasyon için işe yarar.

Varsayılan iletişim portu 19532‘dir ve trafik TLS ile şifrelenebilir. Bu, özellikle farklı ağ segmentlerindeki sunucular arasında log aktarırken kritik önem taşıyor.

Gerekli Paketlerin Kurulumu

Hem sunucu hem de istemci tarafında gerekli paketlerin yüklü olması gerekiyor. Çoğu modern dağıtımda bu paketler systemd ile birlikte geliyor ama bazı dağıtımlarda ayrıca yüklemeniz gerekebilir.

Ubuntu/Debian tabanlı sistemlerde:

# Server tarafı
apt install systemd-journal-remote

# Kurulumu doğrula
systemctl status systemd-journal-remote.socket

RHEL/CentOS/AlmaLinux tabanlı sistemlerde:

# Her iki taraf için de aynı paket
dnf install systemd-journal-remote

# Alternatif olarak yum ile
yum install systemd-journal-remote

Paket kurulduktan sonra hangi binary’lerin geldiğini kontrol etmek iyi bir alışkanlık:

rpm -ql systemd-journal-remote | grep bin
# veya Debian tabanlı için:
dpkg -L systemd-journal-remote | grep bin

TLS Sertifikası Hazırlığı

Logların şifreli aktarımı için TLS sertifikalarına ihtiyacımız var. Üretim ortamında Let’s Encrypt veya kurumsal CA kullanmanızı öneririm. Test ve iç ağ için self-signed sertifika oluşturacağız.

# Sertifika dosyaları için dizin oluştur
mkdir -p /etc/ssl/journal
cd /etc/ssl/journal

# CA key ve sertifikası oluştur
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt 
  -subj "/C=TR/ST=Istanbul/O=SirketAdi/CN=Journal-CA"

# Server için key ve CSR oluştur
openssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr 
  -subj "/C=TR/ST=Istanbul/O=SirketAdi/CN=log-server.internal"

# Server sertifikasını CA ile imzala
openssl x509 -req -days 365 -in server.csr 
  -CA ca.crt -CAkey ca.key -CAcreateserial 
  -out server.crt

# Client için key ve CSR oluştur
openssl genrsa -out client.key 4096
openssl req -new -key client.key -out client.csr 
  -subj "/C=TR/ST=Istanbul/O=SirketAdi/CN=web-server-01.internal"

# Client sertifikasını CA ile imzala
openssl x509 -req -days 365 -in client.csr 
  -CA ca.crt -CAkey ca.key -CAcreateserial 
  -out client.crt

# Dosya izinlerini ayarla
chmod 600 *.key
chmod 644 *.crt

Sertifikaları oluşturduktan sonra client sertifikalarını ilgili sunuculara kopyalaman gerekiyor:

# Client sertifikalarını uzak sunucuya kopyala
scp ca.crt client.key client.crt [email protected]:/etc/ssl/journal/

Log Sunucusu Yapılandırması (Server Tarafı)

Log sunucusunda önce gelen logların yazılacağı dizini oluşturalım:

# Log dizinini oluştur
mkdir -p /var/log/journal/remote
chown systemd-journal-remote:systemd-journal-remote /var/log/journal/remote
chmod 755 /var/log/journal/remote

Şimdi /etc/systemd/journal-remote.conf dosyasını düzenliyoruz:

cat > /etc/systemd/journal-remote.conf << 'EOF'
[Remote]
# Gelen logların yazılacağı dizin
ServerKeyFile=/etc/ssl/journal/server.key
ServerCertificateFile=/etc/ssl/journal/server.crt
TrustedCertificateFile=/etc/ssl/journal/ca.crt

# Her client için ayrı dosya oluştur (önerilen)
SplitMode=host

# Log dosyalarının yazılacağı yer
OutputDirectory=/var/log/journal/remote
EOF

Servisi etkinleştirip başlatalım:

# Socket ve servisi etkinleştir
systemctl enable --now systemd-journal-remote.socket
systemctl enable --now systemd-journal-remote.service

# Durumu kontrol et
systemctl status systemd-journal-remote.socket
systemctl status systemd-journal-remote.service

# 19532 portunu dinlediğini doğrula
ss -tlnp | grep 19532

Firewall ayarı yapmayı unutma. Bu adımı atlayan onlarca sysadmin gördüm, saatler geçiyor nedeni bulunamıyor:

# firewalld kullanıyorsan
firewall-cmd --permanent --add-port=19532/tcp
firewall-cmd --reload

# ufw kullanıyorsan
ufw allow 19532/tcp

Log Gönderen Sunucuların Yapılandırması (Client Tarafı)

Her client sunucuda /etc/systemd/journal-upload.conf dosyasını düzenliyoruz:

cat > /etc/systemd/journal-upload.conf << 'EOF'
[Upload]
# Log sunucusunun adresi
URL=https://log-server.internal:19532

# Client sertifika bilgileri
ServerKeyFile=/etc/ssl/journal/client.key
ServerCertificateFile=/etc/ssl/journal/client.crt
TrustedCertificateFile=/etc/ssl/journal/ca.crt
EOF

Servisi etkinleştirip başlatalım:

systemctl enable --now systemd-journal-upload.service
systemctl status systemd-journal-upload.service

Servis düzgün çalışıyorsa journalctl ile loglarını takip edebilirsin:

journalctl -u systemd-journal-upload.service -f

Gönderilen Logları Okuma ve Sorgulama

Log sunucusuna gelenler /var/log/journal/remote/ altında .journal uzantılı dosyalar olarak saklanır. Bu dosyaları okumak için journalctl’nin -D parametresini kullanıyoruz:

# Belirli bir client'ın loglarını oku
journalctl -D /var/log/journal/remote/ 
  --file=/var/log/journal/remote/remote-web-server-01.internal.journal

# Tüm remote logları birlikte görüntüle
journalctl -D /var/log/journal/remote/

# Son 100 satırı göster
journalctl -D /var/log/journal/remote/ -n 100

# Belirli bir servisin loglarını filtrele (örneğin nginx)
journalctl -D /var/log/journal/remote/ -u nginx.service

# Belirli bir zaman aralığını sorgula
journalctl -D /var/log/journal/remote/ 
  --since "2024-01-15 08:00:00" 
  --until "2024-01-15 18:00:00"

# Priority bazlı filtreleme (sadece hata ve üzeri)
journalctl -D /var/log/journal/remote/ -p err

Birden fazla client’tan gelen logları merge ederek görmek istiyorsan --merge parametresini kullanabilirsin:

journalctl -D /var/log/journal/remote/ --merge -n 50

Gerçek Dünya Senaryosu: Web Sunucu Grubunun Log Yönetimi

Diyelim ki 5 adet Nginx web sunucun var ve bunların tüm loglarını merkezi bir yerde toplamak istiyorsun. Her sunucuda journal-upload yapılandırması aynı, sadece sertifikalar farklı. Bu senaryoyu Ansible ile otomatize etmek çok zaman kazandırıyor.

Ama önce temel sorun giderme akışına bakalım. Diyelim ki bir web sunucusunda 502 hataları başladı ve ne zaman başladığını bulmak istiyorsun:

# Tüm web sunucularının loglarını merge ederek nginx hatalarını filtrele
journalctl -D /var/log/journal/remote/ 
  --merge 
  -u nginx.service 
  -p warning 
  --since "2 hours ago" 
  -o json-pretty | grep -E '"MESSAGE"|"_HOSTNAME"'

Veya belirli bir host’tan gelen logları kernel seviyesinde incelemek istiyorsan:

# Sadece kernel logları
journalctl -D /var/log/journal/remote/ 
  --file=/var/log/journal/remote/remote-web-server-03.internal.journal 
  -k 
  --since today

Log Rotasyonu ve Disk Yönetimi

Uzak loglar disk doldurmaya devam ederse ciddi sorunlar çıkabilir. /etc/systemd/journald.conf ile sınırları belirleyebilirsin ama remote loglar için bu ayarlar doğrudan geçerli değil. Remote log dosyaları için ayrı bir strateji lazım.

/etc/systemd/journal-remote.conf dosyasına şu satırları ekleyebilirsin:

cat >> /etc/systemd/journal-remote.conf << 'EOF'

# Maksimum disk kullanımı (tüm remote loglar için)
MaxUse=10G

# Disk doluluk eşiği - bu kadar alan kalmalı
KeepFree=2G

# Tek bir remote log dosyasının maksimum boyutu
MaxFileSize=500M
EOF

Ayrıca logrotate ile de yönetebilirsin:

cat > /etc/logrotate.d/journal-remote << 'EOF'
/var/log/journal/remote/*.journal {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        systemctl restart systemd-journal-remote.service
    endscript
}
EOF

Mevcut disk kullanımını düzenli olarak izlemek için basit bir script işe yarıyor:

#!/bin/bash
# /usr/local/bin/journal-remote-disk-check.sh

REMOTE_LOG_DIR="/var/log/journal/remote"
MAX_SIZE_GB=8
ALERT_EMAIL="[email protected]"

current_size=$(du -sGB "$REMOTE_LOG_DIR" | cut -f1 | tr -d 'G')

if [ "$current_size" -gt "$MAX_SIZE_GB" ]; then
    echo "UYARI: Remote journal logs $current_size GB kulaniyor (limit: $MAX_SIZE_GB GB)" | 
    mail -s "Journal Remote Log Disk Uyarisi" "$ALERT_EMAIL"
fi

Bu scripti cron’a ekle:

# Saatte bir çalıştır
echo "0 * * * * root /usr/local/bin/journal-remote-disk-check.sh" > /etc/cron.d/journal-remote-check

Systemd-journal-upload Servisini Sağlamlaştırma

Varsayılan ayarlarla journal-upload servisi bir hata durumunda kendini iyi kurtaramayabilir. Bir override dosyası oluşturalım:

mkdir -p /etc/systemd/system/systemd-journal-upload.service.d/

cat > /etc/systemd/system/systemd-journal-upload.service.d/override.conf << 'EOF'
[Service]
# Hata durumunda yeniden başlatma
Restart=always
RestartSec=30s

# Yeniden deneme sayısını artır
StartLimitBurst=10
StartLimitIntervalSec=600

# Bellek limiti
MemoryMax=128M

# Log seviyesini artır (debug için geçici olarak kullanılabilir)
# Environment=SYSTEMD_LOG_LEVEL=debug
EOF

# Değişiklikleri uygula
systemctl daemon-reload
systemctl restart systemd-journal-upload.service

TLS Olmadan HTTP ile Kullanım (Sadece İç Ağ İçin)

Kapalı, izole bir iç ağda TLS sertifikası yönetimi yük oluşturuyorsa HTTP ile de çalışabilirsin. Ama bunu sadece gerçekten izole, güvenilir ağlarda yapmanı öneririm.

Server tarafında:

cat > /etc/systemd/journal-remote.conf << 'EOF'
[Remote]
# TLS ayarlarını kaldır veya yorum satırına al
# ServerKeyFile=
# ServerCertificateFile=
# TrustedCertificateFile=

SplitMode=host
OutputDirectory=/var/log/journal/remote
EOF

Client tarafında:

cat > /etc/systemd/journal-upload.conf << 'EOF'
[Upload]
# HTTP kullan (TLS YOK - sadece güvenilir iç ağ!)
URL=http://log-server.internal:19532
EOF

Uyarı: Bu yapılandırmada loglarınız açık metin olarak ağda dolaşır. VPN veya izole VLAN olmadan kullanmayın.

Bağlantı Sorunlarını Giderme

En sık karşılaştığım sorunları ve çözümlerini listeleyelim:

Servis başlamıyor, “Connection refused” hatası: Port 19532’nin server tarafında açık olduğunu ve firewall kurallarının doğru ayarlandığını kontrol et. telnet log-server.internal 19532 ile test edebilirsin.

TLS sertifika hatası: Sertifika CN’inin hostname ile eşleştiğinden emin ol. openssl s_client -connect log-server.internal:19532 komutu detaylı TLS bilgisi verir.

Upload servisi başlıyor ama log gelmiyor: /run/systemd/journal/socket üzerinden journal’ın çalıştığını ve upload servisinin journal’a erişebildiğini kontrol et.

Remote dizinde dosya oluşmuyor: systemd-journal-remote kullanıcısının /var/log/journal/remote/ dizinine yazma yetkisi olduğunu kontrol et.

# Gerçek zamanlı bağlantı testi
curl -v --cacert /etc/ssl/journal/ca.crt 
  --cert /etc/ssl/journal/client.crt 
  --key /etc/ssl/journal/client.key 
  https://log-server.internal:19532/

# SELinux varsa context kontrolü
ls -laZ /var/log/journal/remote/
restorecon -rv /var/log/journal/remote/

SELinux kullanan sistemlerde özellikle port ve dosya context sorunları çıkabiliyor. audit2allow ile özel policy oluşturmak gerekebilir.

Logları Elasticsearch veya Loki’ye Aktarmak

journald’yi doğrudan merkezi log altyapısına bağlamak isteyenler için köprü çözümler mevcut. Filebeat ile .journal dosyalarını okuyup Elasticsearch’e gönderebilirsin:

# Filebeat journal input yapılandırması (snippet)
cat >> /etc/filebeat/filebeat.yml << 'EOF'
filebeat.inputs:
- type: journald
  id: remote-journals
  paths:
    - /var/log/journal/remote/

output.elasticsearch:
  hosts: ["elasticsearch:9200"]
  index: "syslog-%{+yyyy.MM.dd}"
EOF

Veya Promtail ile Loki’ye aktarım yapabilirsin. Bu entegrasyonlar merkezi log sistemlerini journald’nin gücüyle birleştirmenin en temiz yolu.

Sonuç

journald ile uzak log sunucusu kurulumu, sysadmin araç kutusuna eklenmesi gereken ciddi bir beceri. Özellikle 10’dan fazla sunucu yönetiyorsan merkezi log toplamanın değeri katlanarak artıyor. systemd-journal-remote ve systemd-journal-upload ikilisi, özellikle TLS şifreleme ile birleşince hem güvenli hem de performanslı bir çözüm sunuyor.

Bu yazıda anlattıklarımı özetlersek:

Server tarafında systemd-journal-remote servisi çalışıyor ve gelen logları host bazında ayrı dosyalara yazıyor.
Client tarafında systemd-journal-upload servisi journal’ı takip edip sunucuya gönderiyor.
TLS sertifikaları hem kimlik doğrulama hem de şifreleme için kullanılıyor.
Disk yönetimi için MaxUse ayarları ve logrotate birlikte kullanılıyor.
Sorun gidermede önce firewall, sonra TLS, sonra dosya izinleri kontrol ediliyor.

Kurulum tamamlandıktan sonra birkaç gün izleyerek logların düzgün geldiğini ve disk kullanımının kontrol altında olduğunu doğrula. Sonrasında Grafana, Kibana veya benzeri araçlarla bu merkezi log deposunu görselleştirmek bir sonraki mantıklı adım olacaktır.

journald ile Uzak Log Sunucusuna Günlük Gönderme