Zimbra Log Analizi ve Sorun Giderme Rehberi

Yazar:komut.io ekibi Zimbra Mail Sunucusu Kurulum ve Yönetimi
0 Yorum

Zimbra ortamında bir şeyler ters gittiğinde, çoğu sysadmin’in ilk tepkisi servisi yeniden başlatmak olur. Kimi zaman işe yarar, kimi zaman sadece sorunu birkaç dakika ileriye atar. Asıl mesele logları okumayı bilmek. Zimbra’nın log yapısı ilk bakışta karmaşık görünebilir; onlarca farklı dosya, farklı servisler, farklı format. Ama bir kez alıştığınızda, sorunun tam olarak nerede olduğunu dakikalar içinde tespit edebilirsiniz. Bu rehber, yıllarca Zimbra yöneten birisinin “keşke baştan bilseydim” dediği şeyleri aktarıyor.

Zimbra Log Mimarisi: Nerede Ne Var?

Zimbra, birden fazla servisten oluşan bir yapıdır ve her servisin logları farklı yerlerde tutulur. Bunu kafanızda oturtmadan log analizi yapmaya çalışmak, karanlıkta anahtar aramak gibidir.

Ana log konumları şunlardır:

  • /var/log/zimbra.log: Postfix ve amavisd dahil tüm mail akışının ana logu. Günlük işlerde en çok burasına bakacaksınız.
  • /opt/zimbra/log/mailbox.log: Zimbra mailbox servisine ait loglar. Webmail erişim sorunları, hesap hataları burada.
  • /opt/zimbra/log/audit.log: Başarısız login denemeleri, yetki değişiklikleri. Güvenlik olayları için birincil kaynak.
  • /opt/zimbra/log/nginx.log: Proxy katmanı logları. HTTP/HTTPS erişim sorunları burada.
  • /opt/zimbra/log/zmmailboxd.out: Mailbox Java servisinin stdout çıktısı. OutOfMemory hataları gibi kritik JVM sorunları burada belirir.
  • /var/log/syslog veya /var/log/messages: Sistem geneli olaylar.

Zimbra kullanıcısı ile çalışmayı alışkanlık edinmenizi şiddetle tavsiye ederim. Logları okurken bile:

su - zimbra
tail -f /opt/zimbra/log/mailbox.log

Mail Akışını Adım Adım İzlemek

Bir kullanıcı “mail gitmiyor” dediğinde, önce o mailin sisteme girip girmediğini anlamanız gerekir. Bunun için en etkili yol, mesaj ID’si üzerinden takip yapmaktır.

grep "[email protected]" /var/log/zimbra.log | tail -50

Örneğin [email protected] adresine gelen bir mail kaybolmuşsa:

grep "[email protected]" /var/log/zimbra.log | grep "$(date +%b %d)" | less

Postfix log satırlarını okurken şu akışa göz atın: postfix/smtpd mesajı kabul etti mi, postfix/cleanup işledi mi, postfix/qmgr kuyruğa aldı mı, postfix/smtp ya da postfix/lmtp teslim etti mi? Her adım logda ayrı satır bırakır.

Tipik bir başarılı teslimat şöyle görünür:

Jan 15 09:23:11 mailsunucu postfix/smtpd[12345]: NOQUEUE: connect from unknown[1.2.3.4]
Jan 15 09:23:11 mailsunucu postfix/smtpd[12345]: ABC123DEF456: client=unknown[1.2.3.4]
Jan 15 09:23:11 mailsunucu postfix/cleanup[12346]: ABC123DEF456: message-id=<[email protected]>
Jan 15 09:23:11 mailsunucu postfix/qmgr[789]: ABC123DEF456: from=<[email protected]>, size=2048, nrcpt=1
Jan 15 09:23:12 mailsunucu postfix/lmtp[12347]: ABC123DEF456: to=<[email protected]>, status=sent

Eğer son satırda status=sent yerine status=bounced veya status=deferred görüyorsanız, sorunun kaynağı hemen yanında yazıyor demektir.

Kuyruktaki Mailleri Yönetmek

Deferred mailler biriktiğinde sunucu yavaşlar, kullanıcılar şikayetçi olur. Kuyruk durumunu görmek için:

su - zimbra -c "mailq | head -30"

ya da daha ayrıntılı:

su - zimbra -c "postqueue -p | grep -c '^[A-F0-9]'"

Bu komut kuyruktaki mail sayısını verir. Yüzlerce hatta binlerce mail biriktiğinde, önce nedenini anlamanız gerekir. Körü körüne kuyruk boşaltmak, spam döngüsü yaratabilir.

Belirli bir alıcıya giden takılmış mailleri bulmak için:

postqueue -p | grep "[email protected]" | awk '{print $1}' | tr -d '*' | xargs -I{} postcat -qv {}

Eğer belirli bir domain’e giden tüm mailleri silmeniz gerekiyorsa (spam durumunda işe yarar):

postqueue -p | grep "@hedef-domain.com" | awk '{print $1}' | tr -d '*!' | while read id; do postsuper -d $id; done

Yaygın Hata Senaryoları ve Çözümleri

Senaryo 1: “Authentication Failed” Hataları

Sabah işe geldiniz, kullanıcılar mail istemcilerinden bağlanamıyor. İlk bakış audit.log’a:

grep "authentication failed" /opt/zimbra/log/audit.log | tail -20
grep "invalid password" /opt/zimbra/log/audit.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -10

İkinci komut size en fazla başarısız giriş denemesi olan hesapları sıralı şekilde verir. Eğer tek bir hesap binlerce kez görünüyorsa, ya kullanıcı şifresini değiştirdi ve istemcisini güncellemedi, ya da kaba kuvvet saldırısı altındasınız demektir.

Bir IP’nin sistemi bombaladığını tespit etmek için:

grep "authentication failed" /opt/zimbra/log/audit.log | grep "$(date +%Y-%m-%d)" | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Senaryo 2: Mail Gönderilemiyor, Relay Hatası

Kullanıcı “Mail gönderemiyorum, relay erişimi reddedildi” diyor. Bu klasik bir yapılandırma sorunudur:

grep "Relay access denied" /var/log/zimbra.log | tail -20
grep "relay" /var/log/zimbra.log | grep "reject" | tail -20

Zimbra’nın relay ayarlarını kontrol etmek için:

su - zimbra -c "postconf mynetworks"
su - zimbra -c "postconf smtpd_relay_restrictions"

Eğer dahili bir sunucudan relay yapılması gerekiyorsa ve IP listede yoksa:

su - zimbra -c "zmprov ms `zmhostname` zimbraMtaMyNetworks '127.0.0.0/8 192.168.1.0/24'"
su - zimbra -c "postfix reload"

Senaryo 3: Mailbox Servisi Yanıt Vermiyor

Webmail açılmıyor, kullanıcılar IMAP/POP3’e bağlanamıyor. mailbox.log’a bakın:

tail -100 /opt/zimbra/log/mailbox.log | grep -E "ERROR|FATAL|Exception"

OutOfMemory hatası mı var? zmmailboxd.out’a bakın:

grep -i "outofmemory|heap space|gc overhead" /opt/zimbra/log/zmmailboxd.out | tail -20

Eğer JVM heap dolmuşsa, kısa vadeli çözüm servisi yeniden başlatmaktır:

su - zimbra -c "zmmailboxdctl restart"

Ama kalıcı çözüm için heap boyutunu artırmanız gerekir. Mevcut ayarı görmek için:

su - zimbra -c "zmprov gs `zmhostname` zimbraMailboxdJavaMaxHeapSize"

8 GB RAM’li bir sunucuda 4 GB heap makul bir başlangıç noktasıdır:

su - zimbra -c "zmprov ms `zmhostname` zimbraMailboxdJavaMaxHeapSize 4096m"
su - zimbra -c "zmcontrol restart"

Spam ve Virüs Filtresi Logları

Amavisd ve SpamAssassin logları da /var/log/zimbra.log içine yazar, ama onları filtrelemek gerekir:

grep "amavis" /var/log/zimbra.log | grep "SPAM|VIRUS|BANNED" | tail -30

Bir mailin spam olarak işaretlenip işaretlenmediğini anlamak için mesaj ID’si ile arayın:

grep "ABC123DEF456" /var/log/zimbra.log | grep -E "amavis|spam|virus"

SpamAssassin skorlarını görmek bazen hangi kuralın tetiklendiğini anlamanıza yardımcı olur. Bir mailin başlıklarına bakın; X-Spam-Status ve X-Spam-Score satırları size skoru ve hangi kuralların devreye girdiğini gösterir.

Spam eşiğini değiştirmek için:

su - zimbra -c "zmprov mcf zimbraSpamKillPercent 75"
su - zimbra -c "zmprov mcf zimbraSpamTagPercent 33"

Performans Sorunlarını Log ile Tespit Etmek

Zimbra yavaş çalışıyorsa, hangi sorgu ya da işlemin ne kadar sürdüğünü görmek istersiniz. mailbox.log içinde yavaş SOAP isteklerini bulmak için:

grep "elapsed" /opt/zimbra/log/mailbox.log | awk -F'elapsed=' '{print $2}' | awk '{print $1}' | sort -n | tail -20

5 saniyenin üzerinde süren işlemleri bulmak için:

grep "elapsed" /opt/zimbra/log/mailbox.log | awk -F'elapsed=' '{if ($2+0 > 5000) print $0}' | tail -20

Veritabanı bağlantı sorunları da performansı etkiler. MySQL/MariaDB loglarına bakın:

grep -i "error|warning|deadlock" /opt/zimbra/log/mysql_error.log | tail -30

LDAP servisinin sağlıklı çalışıp çalışmadığını kontrol etmek de önemlidir çünkü hesap doğrulama LDAP üzerinden geçer:

su - zimbra -c "ldap status"
su - zimbra -c "zmldappasswd" # Şifre doğrulaması için

Gerçek Zamanlı Log Takibi için Script

Birden fazla logu aynı anda takip etmek günlük operasyonları kolaylaştırır. Basit ama etkili bir yaklaşım:

#!/bin/bash
# zimbra-log-watch.sh
# Zimbra kritik loglarini gercek zamanli izle

LOG_FILES=(
    "/var/log/zimbra.log"
    "/opt/zimbra/log/mailbox.log"
    "/opt/zimbra/log/audit.log"
)

FILTER="ERROR|FATAL|WARN|authentication failed|relay|rejected|SPAM|VIRUS"

tail -f "${LOG_FILES[@]}" | grep --line-buffered -E "$FILTER" | while read line; do
    TIMESTAMP=$(date '+%H:%M:%S')
    echo "[$TIMESTAMP] $line"
done

Bu scripti screen veya tmux içinde çalıştırırsanız, gün boyunca kritik olayları kaçırmazsınız.

Log Rotasyonu ve Arşivleme

Zimbra’nın log dosyaları hızla büyür. /etc/logrotate.d/zimbra dosyasını kontrol edin ve makul bir politika belirleyin:

cat /etc/logrotate.d/zimbra

Eğer yoksa veya yetersizse, şu içerikle oluşturun:

/var/log/zimbra.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/bin/killall -HUP syslogd 2>/dev/null || true
    endscript
}

/opt/zimbra/log/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    su zimbra zimbra
}

Eski loglardan istatistik çıkarmak için, örneğin dün kaç mail alındığını görmek:

DUN=$(date -d "yesterday" "+%b %e")
grep "$DUN" /var/log/zimbra.log | grep "postfix/lmtp" | grep "status=sent" | wc -l

Güvenlik Olaylarını Tespit Etmek

Bir hesabın ele geçirilip geçirilmediğini anlamak için o hesabın aktivitesine bakın:

grep "[email protected]" /opt/zimbra/log/audit.log | grep -v "authentication failed" | tail -30

Normalden farklı IP adreslerinden giriş yapılıyorsa şüphelenin. Aynı hesaba birden fazla ülkeden eşzamanlı giriş varsa, bu ciddi bir uyarıdır.

Aktif SMTP bağlantılarını gerçek zamanlı görmek için:

ss -tnp | grep ":25|:587|:465" | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Eğer tek bir IP’den onlarca bağlantı varsa ve bu IP güvenilir bir sunucu değilse, geçici olarak engelleyin:

iptables -I INPUT -s SUPHELI_IP -j DROP
# Zimbra loguna not düşün
echo "$(date): $SUPHELI_IP engellendi - spam/brute force" >> /var/log/zimbra-security.log

Zimbra Servis Durumunu Düzenli Kontrol Etmek

Sorun çıkmadan önce önlem almak için her gün çalışan basit bir sağlık kontrolü scripti işinizi görür:

#!/bin/bash
# zimbra-healthcheck.sh - crontab: 0 * * * * /opt/scripts/zimbra-healthcheck.sh

ALERT_MAIL="[email protected]"
HOSTNAME=$(hostname)

# Servis durumunu kontrol et
SERVIS_DURUMU=$(su - zimbra -c "zmcontrol status" 2>&1)
if echo "$SERVIS_DURUMU" | grep -q "Stopped|Failed"; then
    echo "$SERVIS_DURUMU" | mail -s "UYARI: $HOSTNAME Zimbra Servis Sorunu" $ALERT_MAIL
fi

# Kuyruk boyutunu kontrol et
KUYRUK=$(su - zimbra -c "mailq 2>/dev/null | tail -1" | awk '{print $1}')
if [ "$KUYRUK" -gt 100 ] 2>/dev/null; then
    echo "Mail kuyrugunda $KUYRUK mesaj birikti." | mail -s "UYARI: $HOSTNAME Mail Kuyrugu" $ALERT_MAIL
fi

# Disk kullanimi kontrol et
DISK=$(df /opt/zimbra | awk 'NR==2{print $5}' | tr -d '%')
if [ "$DISK" -gt 85 ]; then
    echo "Zimbra diski %$DISK dolu!" | mail -s "UYARI: $HOSTNAME Disk Dolulugu" $ALERT_MAIL
fi

Sonuç

Zimbra log analizi, bir kez doğru öğrenildiğinde sorun giderme sürecini dramatik biçimde kısaltır. Önemli olan, panik yapmadan sistematik davranmak: önce hangi servisin sorun yaşadığını belirle, ilgili loga git, zaman damgasına göre olayları sırala, ve neden-sonuç ilişkisi kur.

Bu yazıda anlattıklarım, gerçek ortamlarda defalarca karşılaşılan senaryolara dayanıyor. Her Zimbra kurulumu biraz farklıdır; sürüm farkları, özelleştirmeler, donanım kapasitesi bunların hepsi log çıktılarını etkiler. Bu yüzden kendi ortamınızda “normal” durumu bilmek çok önemli. Normal trafiği, tipik log satırlarını, ortalama kuyruk boyutunu bilen bir sysadmin, anomaliyi hemen fark eder.

Son bir tavsiye: Bu komutları ve scriptleri bir runbook’a yazın. Gece yarısı uyandırıldığınızda, yarı uyanık halde logları analiz ederken iyi hazırlanmış bir runbook hayat kurtarır. Deneyim önemlidir, ama iyi belgeler onun yerini tutabilir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir