Tek Bir Sunucuda Log Yönetimi

Tek bir sunucuda bir şeyler ters gittiğinde logların hepsi genellikle oradadır. Sadece /var/log/nginx/, /var/log/postgresql/, systemd journal'ı ve uygulamanın kendi canının istediği dizinler arasına saçılmış durumdadır.

İlgili log satırını bulmak, bu beş yerden tam olarak hangisine bakacağınızı bilmek demektir. Eğer uygulamanız yapılandırılmış (structured) JSON formatı yerine serbest metin (free-text) formatında log yazıyorsa, "Nginx ve uygulama dahil, son bir saatte bu IP'den gelen tüm istekler" gibi bir veriyi bulmak, tamamen farklı formatlara sahip birden fazla grep komutu yazmayı gerektirir. Teknik olarak sistem bozuk değildir. Ancak olması gerekenden çok daha yavaştır, özellikle de zaman baskısı altında hata ayıklamaya (debug) çalışıyorsanız.

Tam teşekküllü bir ELK yığını (Elasticsearch, Logstash, Kibana) bunu kesinlikle çözer. Ancak tek bir sunucu için gerçekten çok ağırdır. Elasticsearch sadece boşta çalışmak (idle) için bile ciddi bir bellek miktarı talep eder. Tek bir sunucu için gerçekten işe yarayacak o mantıklı orta yol bundan çok daha küçüktür.

Yapılandırılmış loglar geri kalan her şeyi kolaylaştırır

Sistemde yapabileceğiniz açık ara en yüksek etkiye sahip değişiklik, uygulama loglarınızı serbest metin yerine yapılandırılmış formata (JSON) çevirmektir. Şu ikisini karşılaştırın:

2026-10-28 14:32:01 ERROR Failed to process order 4821 for user 1029: timeout

{"time":"2026-10-28T14:32:01Z","level":"error","msg":"failed to process order","order_id":4821,"user_id":1029,"reason":"timeout"}

İkincisi, terminale göz ucuyla bakan bir insan için anında daha okunaklı değildir. Ancak sorgulanabilir. "1029 numaralı kullanıcıya ait tüm hatalar" veya "son bir saatteki tüm timeout olayları", yanlışlıkla aynı rakamları içeren alakasız metinleri yakalama ihtimali olan bulanık bir Regex yerine, belirli bir alan (field) üzerinde nokta atışı bir filtreye dönüşür. Modern loglama kütüphanelerinin çoğu, koda hiç dokunmadan sadece bir konfigürasyon değişikliği ile yapılandırılmış JSON çıktısını destekler.

journald zaten insanların kullandığından çok daha fazlasını yapıyor

Sistemde bir systemd servisi olarak çalışan her şey için (ki modern bir Linux sunucusundaki neredeyse her şey böyledir), journalctl halihazırda stdout ve stderr çıktılarını kesin zaman damgalarıyla (timestamp) merkezi bir yerde toplar. Ayrıca şaşırtıcı sayıda sistem yöneticisinin (admin) hiç elinin gitmediği güçlü filtreleme yetenekleri sunar:

# Sadece uygulamadan gelen son bir saatlik her şey
journalctl -u myapp --since "1 hour ago"

# Birden fazla servisten gelen logları aynı anda canlı izle
journalctl -u myapp -u nginx -f

# Sistem genelinde sadece hata (error) seviyesindeki her şey
journalctl -p err --since today

Bu son komut—yani tüm sistem genelinde öncelik (priority) seviyesine göre filtreleme—sağa sola saçılmış .log dosyalarının harici bir araç olmadan kelimenin tam anlamıyla asla yapamayacağı bir şeydir. Uygulama loglarınız (ayrı bir dosyaya gitmek yerine) doğrudan JSON formatında stdout'a düşüyorsa, journalctl'in o servis için ürettiği çıktı zaten yapılandırılmış durumdadır ve belirli alanlarda filtreleme yapmak için doğrudan jq aracına yönlendirilebilir (pipe).

İlla dashboard istiyorsanız daha hafif bir yığın (stack)

Eğer Elasticsearch'in devasa kaynak tüketimi olmadan gerçek bir log görüntüleyicisine yakın bir şey istiyorsanız, güncel varsayılan tavsiye Grafana Loki ve Promtail ikilisidir.

Promtail log dosyalarını izler (veya systemd journal'ını doğrudan okur) ve bunları Loki'ye gönderir. Grafana da daha sonra Loki'yi sorgular ve logları, (eğer zaten kuruluysa) Prometheus metrik (metrics) dashboard'larınızın hemen yanında görüntüler. Loki'nin kaynak tüketimi (footprint), aynı VPS üzerinde uygulamanızın yanında rahatça çalışabilecek kadar düşüktür. Elasticsearch'in kesinlikle barınamayacağı bir yere tam olarak oturmasının ana nedeni de budur.

# promtail-config.yml (minimal)
scrape_configs:
  - job_name: journal
    journal:
      max_age: 12h
    relabel_configs:
      - source_labels: ['__journal__systemd_unit']
        target_label: 'unit'

Log rotasyonunu unutmayın

Eğer diskiniz sessiz sedasız kimsenin bakmadığı loglarla %100 dolarsa, yukarıdakilerin hiçbirinin önemi kalmaz. logrotate standart servisler için genellikle halihazırda yapılandırılmıştır, ancak uygulamanın kendi özel dizinine yazdığı logların kesinlikle kendi özel girdisine (entry) ihtiyacı vardır:

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

Systemd journal'ın kendisine gelince, boyutuna kesin bir sınır koymak, journal'ın yıllar içinde sessizce sınırsızca büyümesini engeller:

# /etc/systemd/journald.conf
SystemMaxUse=1G

Asıl Hedef

Bunların hiçbirinin çok karmaşık veya kurumsal (enterprise) seviyede bir kurulum olması gerekmez. Tüm amaç, gece saat 2'de bir şeyler patladığında, "Ne oldu ve ne zaman oldu?" sorusunun yanıtını alabileceğiniz tek bir sabit yerin olmasıdır. İlgili satır gözünüze çarpar umuduyla sonsuz düz metin satırları arasında kaydırma yapmak yerine, gerçekten önemli olan şeylere (bir kullanıcı kimliği, bir hata türü, bir zaman aralığı) göre filtre uygulayacak kadar bir yapıya (structure) ihtiyacınız vardır.

Yapılandırılmış loglama (structured logging) ve journalctl'in yerleşik filtrelemesi, bunun büyük bir kısmını size bedavaya sağlar. Loki ve Grafana ise, "bedava" olanın yetmediği anlar için tüm bunların üzerine göze hitap eden, tıklanabilir bir arayüz ekler.