Mail Sunucusu İzleme ve Uyarı Kurulumu

Mail sunucularının en sinsi yanı, arızalarının çoğunlukla gürültüsüz olmasıdır. Bir web sunucusu çöktüğünde beş dakika içinde telefonun çalar; bir mail sunucusu bozulduğunda ise hiçbir şey olmaz — postalar sessizce kuyrukta birikir, birkaç yüz mesaj geciktikten sonra karşı taraflar bounce almaya başlar ve sen olayı ancak "size mail attım ulaşmadı" diyen bir müşteri sayesinde öğrenirsin. Mail sunucusu izleme kurulumu tam olarak bu boşluğu kapatmak içindir: sorunu kullanıcıdan önce görmek.

Bu rehberde bir posta altyapısında gerçekten neyin izlenmesi gerektiğini sıralayacağım, her metrik için kullanılabilir komutları ve eşik değerlerini vereceğim, sonra bunları hem basit bir cron + script yaklaşımıyla hem de Prometheus benzeri bir toplayıcıyla nasıl bağlayacağını göstereceğim. Amaç gösterişli bir dashboard kurmak değil; doğru uyarıları doğru eşiklerle kurmak. Yanlış eşikle kurulmuş bir izleme, hiç izleme olmamasından daha zararlıdır çünkü insanları uyarıyı görmezden gelmeye alıştırır.

Mail Sunucusunda Gerçekten Neyi İzlemelisin#

İzlemeye başlarken en yaygın hata, sunucunun CPU ve RAM grafiğine bakıp "her şey yolunda" demektir. Bir mail sunucusunda CPU %5'te, RAM bol, disk boş olabilir ve buna rağmen hiçbir posta teslim edilmiyor olabilir. Çünkü mail altyapısında arıza genellikle kaynakta değil, akışta olur. İzlenmesi gereken metrikleri önem sırasına göre şöyle gruplarım:

Bu listede dikkat çekmek istediğim iki satır var. Birincisi en eski mesajın yaşı: kuyrukta yalnızca üç mesaj olabilir ama bunlar iki gündür takılıysa altyapında bir sorun var demektir ve sayıya bakan bir uyarı bunu asla yakalayamaz. İkincisi kara liste durumu: bu, sunucun tamamen sağlıklıyken teslimatın çökebileceği tek senaryodur ve yalnızca dışarıdan sorgulayarak öğrenilir.

Kuyruk İzleme: En Değerli Tek Metrik#

Eğer sadece tek bir şey izleyebilecek olsaydın kuyruğu izlerdin. Kuyruk hem gelen hem giden tarafın sağlığını aynı anda özetler. Postfix'te kuyruk sayımı için qshape ve postqueue komutları vardır:

# Toplam kuyruk sayısı (başlık satırını çıkar)
postqueue -p | tail -n 1
# -- 12 Kbytes in 3 Requests.

# Sadece sayıyı almak için (script dostu)
find /var/spool/postfix/deferred -type f | wc -l

# Hangi alan adına teslimat takılıyor, yaş dağılımıyla birlikte
qshape deferred | head -n 15

qshape deferred çıktısı teşhis açısından çok değerlidir: sütunlar mesajların yaşını (5 dakika, 10 dakika, 20 dakika...) gösterir ve satırlar alıcı alan adlarıdır. Tek bir alan adı öne çıkıyorsa sorun karşı taraftadır; tüm alan adları eşit dağılmışsa sorun sendedir. Bu ayrım, teşhisin yarısını halleder.

En eski mesajın yaşını almak için dosya zaman damgalarına bakmak yeterli:

# En eski deferred mesajın yaşı (dakika cinsinden)
find /var/spool/postfix/deferred -type f -printf '%T@\n' 2>/dev/null \
  | sort -n | head -n 1 \
  | awk -v now="$(date +%s)" '{ printf "%d\n", (now - $1) / 60 }'

Exim kullanıyorsan karşılıkları exim -bpc (kuyruk sayısı) ve exim -bp (kuyruk listesi) komutlarıdır. Haraka gibi dosya tabanlı kuyruk tutan sunucularda ise doğrudan kuyruk dizinindeki dosya sayısını ve en eski dosyanın yaşını ölçersin. Kuyruk şiştiğinde ne yapman gerektiğini adım adım mail kuyruğu birikti yazısında anlattım; izleme bu yazının yalnızca "ne zaman bakacağını" söyleyen kısmıdır.

Servis, Port ve Uçtan Uca Teslimat Kontrolü#

Süreç kontrolü en basit izleme katmanıdır ama tek başına yanıltıcıdır: systemctl is-active postfix "active" dönerken sunucu hiçbir bağlantı kabul etmiyor olabilir. Bu yüzden süreç kontrolünü mutlaka port kontrolüyle birleştir:

# Servis durumu
systemctl is-active postfix dovecot

# Portlar gerçekten dinleniyor mu
ss -lntp | grep -E ':(25|465|587|993|995)\b'

# SMTP banner'ı gerçekten dönüyor mu (protokol seviyesi kontrol)
printf 'QUIT\r\n' | timeout 10 openssl s_client -quiet -starttls smtp \
  -connect mail.firmaniz.com:587 2>/dev/null | head -n 2

Ama en değerli kontrol bunların hiçbiri değil: uçtan uca teslimat testi. Sunucudan dış bir adrese posta gönderip o postanın gerçekten geldiğini doğrulamak, aradaki tüm katmanları tek seferde test eder. Pratik kurgu şudur: harici bir posta kutusuna belirli aralıklarla bir mesaj gönder, o kutuyu IMAP ile okuyan küçük bir script mesajın gelip gelmediğini kontrol etsin, gelmemişse uyarı üretsin. Bu, "sunucum ayakta ama postalarım Gmail'e girmiyor" durumunu yakalayan tek yöntemdir.

Daha hafif bir alternatif, bir yankı (echo/ping) servisine posta göndermek ve dönen cevabı beklemektir. Kurgu ne olursa olsun, testin gerçek bir dış alan adı üzerinden geçmesine dikkat et; sunucunun kendine mail atması hiçbir şeyi kanıtlamaz. Bu testi kurmak için SMTP test aracı sayfamızdaki komut üreticisi işini kolaylaştırır.

Disk, Log ve Sertifika Süresi#

Disk dolması, mail sunucularında en sık görülen ve en kolay önlenen arızadır. /var/spool dolduğunda MTA yeni posta kabul etmeyi bırakır, /var/log dolduğunda ise servisler beklenmedik biçimde çökmeye başlar. İkisini ayrı ayrı izle:

# İlgili bölümlerin doluluk yüzdesi
df -h /var /var/spool /var/log /home

# Hangi posta kutusu diski yiyor (ilk 10)
du -sh /var/vmail/* 2>/dev/null | sort -rh | head -n 10

# inode tükenmesi de disk dolması kadar öldürücüdür
df -i /var

Son satırı özellikle vurgulamak isterim: Maildir biçiminde her posta ayrı bir dosyadır, yani milyonlarca küçük dosya demektir. Disk yüzdesi %40'ta görünürken inode'lar %100 dolabilir ve sunucu "no space left on device" hatası verir. inode izlemesini disk izlemesiyle birlikte kur.

Log tarafında iki şeyi ölçersin: log dosyalarının boyutu (logrotate çalışıyor mu) ve log içindeki hata desenleri. Kimlik doğrulama hatalarını saymak, kaba kuvvet saldırılarını erken yakalamanın en kolay yoludur:

# Son bir saatteki başarısız SASL giriş denemeleri
journalctl -u postfix --since "1 hour ago" \
  | grep -c 'SASL LOGIN authentication failed'

# En çok deneyen IP'ler
grep 'authentication failed' /var/log/mail.log \
  | grep -oE 'unknown\[[0-9.]+\]' | sort | uniq -c | sort -rn | head

TLS sertifikası ise unutulduğunda en çok utandıran kalemdir. Web sertifikasının yenilenmesini otomatikleştirmişsindir ama mail servisleri sertifikayı yeniden yüklemek için reload ister; yenileme çalışsa bile Postfix ve Dovecot eski sertifikayı bellekte tutmaya devam eder. O yüzden dosyadaki tarihi değil, portun sunduğu sertifikanın tarihini ölç:

# 993 portunda sunulan sertifikanın bitiş tarihi
echo | openssl s_client -connect mail.firmaniz.com:993 2>/dev/null \
  | openssl x509 -noout -enddate
# notAfter=Nov 14 08:12:33 2026 GMT

# Kalan gün sayısını hesapla ve 21 günün altındaysa uyar
END=$(echo | openssl s_client -connect mail.firmaniz.com:993 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ( $(date -d "$END" +%s) - $(date +%s) ) / 86400 )) gun kaldi

Kara Liste ve İtibar İzleme#

Sunucun kusursuz çalışırken teslimatın çökmesinin tek yolu, IP'nin bir kara listeye (DNSBL) düşmesidir. Bu, genellikle sızmış bir hesap ya da fark edilmemiş bir spam dalgasının ardından gelir; fark etmen bir gün sürerse o gün boyunca gerçek postaların da reddedilir. Kara liste kontrolü aslında basit bir DNS sorgusudur: IP'nin oktetlerini ters çevirip liste alan adına eklersin.

#!/bin/bash
# /usr/local/bin/dnsbl-check.sh - IP kara listede mi
IP="185.12.34.56"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')
LISTS="zen.spamhaus.org bl.spamcop.net b.barracudacentral.org dnsbl.sorbs.net"

for L in $LISTS; do
  # Cevap dönerse IP o listede demektir
  if host -W 5 "$REV.$L" > /dev/null 2>&1; then
    echo "LISTEDE: $IP -> $L"
  fi
done

Bu scripti saatlik bir cron'a bağla ve çıktı üretirse uyarı gönder. Dikkat etmen gereken iki nokta var: bazı listeler yüksek hacimli sorgularda seni engelleyebilir, o yüzden dakikalık değil saatlik çalıştır; ve bazı listeler dönen IP'nin son oktetiyle sebep kodu bildirir, yani 127.0.0.4 ile 127.0.0.11 farklı anlamlara gelir. Uyarı mesajına dönen değeri de ekle.

İtibarın ikinci ölçütü bounce oranıdır. Loglarda status=bounced sayısını status=sent sayısına oranlarsan gönderim kalitendeki bozulmayı erken görürsün:

# Bugünkü bounce/sent oranı
SENT=$(grep -c 'status=sent' /var/log/mail.log)
BOUNCED=$(grep -c 'status=bounced' /var/log/mail.log)
awk -v s="$SENT" -v b="$BOUNCED" 'BEGIN { printf "%.2f%%\n", (b/(s+b))*100 }'

Oranın aniden yükselmesi, ya listende çok sayıda geçersiz adres olduğunu ya da bir sağlayıcının seni reddetmeye başladığını gösterir. Büyük sağlayıcıların gönderici kurallarındaki değişiklikler de bu oranı yukarı çeker; Gmail ve Yahoo gönderici kuralları yazısı bu tarafta neye dikkat etmen gerektiğini özetler.

Uyarıları Nasıl Kuracaksın#

Ölçtüğün her şeyi bir yere bağlaman gerekir. İki yaklaşımdan biriyle başlayabilirsin ve küçük altyapılarda ilki fazlasıyla yeterlidir.

Yaklaşım 1 — cron + script + bildirim. Yukarıdaki kontrolleri tek bir scriptte topla, eşik aşıldığında bildirim gönder. Kritik ayrıntı şu: uyarıyı kendi mail sunucundan gönderme. Mail sunucusu çöktüğünde uyarı da gönderilemez. Bildirimi bir webhook (Slack, Discord, Telegram) ya da harici bir servis üzerinden çıkar.

#!/bin/bash
# /usr/local/bin/mail-health.sh - saatlik çalıştır
WEBHOOK="https://ornek.com/webhook/mail-alert"
ALERTS=""

Q=$(find /var/spool/postfix/deferred -type f 2>/dev/null | wc -l)
[ "$Q" -gt 500 ] && ALERTS="$ALERTS deferred_kuyruk=$Q"

D=$(df --output=pcent /var | tail -n1 | tr -dc '0-9')
[ "$D" -gt 85 ] && ALERTS="$ALERTS disk_doluluk=%$D"

systemctl is-active --quiet postfix || ALERTS="$ALERTS postfix_kapali"
systemctl is-active --quiet dovecot || ALERTS="$ALERTS dovecot_kapali"

if [ -n "$ALERTS" ]; then
  curl -s -m 10 -X POST "$WEBHOOK" \
    -H 'Content-Type: application/json' \
    -d "{\"text\":\"Mail sunucusu uyarisi:$ALERTS\"}"
fi

Yaklaşım 2 — metrik toplayıcı. Prometheus + Alertmanager ya da Zabbix kullanıyorsan, ölçümleri metrik olarak yayınlayıp eşikleri kural dosyasında tanımlarsın. Bunun avantajı geçmiş veriye sahip olman ve "kuyruk şu an 300 ama üç saattir sürekli artıyor" gibi eğilim tabanlı kurallar yazabilmendir. Kuyruk sayısını bir metrik dosyasına yazıp node_exporter'ın textfile toplayıcısına vermek en kolay yoldur:

# /usr/local/bin/queue-metric.sh
OUT=/var/lib/node_exporter/textfile/mailq.prom
Q=$(find /var/spool/postfix/deferred -type f 2>/dev/null | wc -l)
A=$(find /var/spool/postfix/active -type f 2>/dev/null | wc -l)
# Geçici dosyaya yazıp atomik olarak taşı (yarım okuma olmasın)
printf 'postfix_deferred_queue %s\npostfix_active_queue %s\n' "$Q" "$A" > "$OUT.tmp"
mv "$OUT.tmp" "$OUT"

Hangisini seçersen seç, uyarıların dış bir kanaldan çıkması ve eşiklerin gerçekçi olması iki değişmez kuraldır. Sunucunun kapasitesine göre doğru eşikleri belirlemek için mail sunucusu kaynak gereksinimleri yazısındaki tablolar iyi bir başlangıç noktası verir.

Sık Yapılan Hatalar#

En büyük hata, uyarı bildirimlerini izlenen mail sunucusunun kendisi üzerinden göndermektir. Sunucu çöktüğünde uyarı da çıkamaz ve tam ihtiyacın olduğu anda sistem sessiz kalır. İkinci hata, eşikleri fazla hassas ayarlamaktır: kuyrukta 20 mesaj gördüğünde uyaran bir sistem günde on kez öter ve iki hafta sonra kimse bakmaz. Eşiği, gerçekten insan müdahalesi gerektiren seviyeye koy.

Üçüncü hata, yalnızca "servis ayakta mı" kontrolü kurmaktır. Postfix ayakta olabilir ama disk dolu olduğu için hiçbir postayı kabul etmiyordur. Dördüncü hata, sertifika süresini dosyadan okumaktır — dosya yenilenmiş olabilir ama servis eski sertifikayı sunmaya devam ediyordur; ölçümü mutlaka portun sunduğu sertifikadan yap. Beşinci hata, kara liste kontrolünü hiç kurmamaktır; bu, sunucusu tamamen sağlıklı görünürken teslimatı çökmüş yöneticilerin en çok geç fark ettiği kalemdir. Son olarak, izlemeyi kurup uyarıyı test etmemek de yaygın bir hatadır: kurulumdan sonra bir eşiği yapay olarak aş ve bildirimin gerçekten geldiğini gör.

Sıkça Sorulan Sorular#

Mail sunucusu izleme için hangi araç en iyisi#

Tek bir doğru cevap yok; ölçek belirleyici. Tek sunuculu bir kurulumda cron ile çalışan bir bash scripti ve bir webhook bildirimi fazlasıyla yeterlidir, hatta daha güvenilirdir çünkü bağımlılığı azdır. Birden fazla sunucun ve geçmiş veriye ihtiyacın varsa Prometheus + Alertmanager ya da Zabbix mantıklı olur. Aracın kendisinden çok, doğru metrikleri ve doğru eşikleri seçmen fark yaratır.

Kuyruk kaç mesajı geçince uyarı almalıyım#

Bu, normal trafiğine bağlıdır; önce bir hafta boyunca kuyruk sayını ölçüp temel çizgini (baseline) çıkar. Genel bir başlangıç olarak aktif kuyrukta 100, deferred kuyrukta 500 mesaj eşiği çoğu küçük ve orta ölçekli kurulum için makuldür. Ama sayıdan daha değerli olan metriği unutma: en eski mesajın yaşı dört saati geçtiğinde, kuyrukta kaç mesaj olursa olsun uyarı almalısın.

Kara liste kontrolünü ne sıklıkla yapmalıyım#

Saatte bir yeterlidir ve önerilen sıklık budur. Daha sık sorgulamak listelerin sorgu limitlerine takılmana ve kendi IP'nin sorgu kaynağı olarak engellenmesine yol açabilir. Kritik gönderim yapan bir altyapıda saatlik kontrol, bir kara liste kaydını fark etmen için ortalama yarım saatlik bir gecikme demektir ki bu kabul edilebilir bir süredir.

İzleme sunucusunu aynı makineye kurabilir miyim#

Kurabilirsin ama uyarı kanalını kesinlikle aynı makineden çıkarma. Metrik toplama ve grafik tarafını aynı sunucuda tutmak küçük kurulumlarda kabul edilebilir; ancak sunucu tamamen çöktüğünde hem izleme hem uyarı susar. En azından "sunucu erişilebilir mi" kontrolünü dışarıdan yapan harici bir kontrol noktası ekle.

Postfix loglarını izlemek için ne kullanmalıyım#

Küçük kurulumlarda journalctl -u postfix ve grep kombinasyonu yeterlidir; belirli desenleri saymak için basit script'ler yazarsın. Log hacmi büyüdüğünde ve birden fazla sunucun olduğunda merkezî bir log toplayıcıya geçmek mantıklıdır. Hangi yolu seçersen seç, logrotate yapılandırmasının çalıştığını doğrula; dolmuş bir log bölümü mail sunucusunu tamamen durdurur.

Sunucum ayakta ama postalar teslim edilmiyor, izleme bunu yakalar mı#

Yalnızca süreç ve port kontrolü kuran bir izleme bunu yakalayamaz. Bu senaryoyu yakalayan iki kontrol vardır: kuyruk büyüklüğü ile en eski mesajın yaşı, ve uçtan uca teslimat testi. İkincisi, dış bir posta kutusuna belirli aralıklarla mesaj gönderip gelip gelmediğini doğrulayan bir kontroldür ve sunucunun sağlıklı görünürken teslimatın çöktüğü durumları yakalayan tek yöntemdir.

Kapanış#

İyi bir mail izleme kurulumu karmaşık olmak zorunda değil; doğru şeyleri ölçmesi yeterli. Aklında kalması gereken dört alışkanlık: kuyruğun hem sayısını hem en eski mesajın yaşını izle, çünkü ikincisi olmadan takılmaları göremezsin; disk yanında inode kullanımını da ölç, Maildir dosya sayısıyla dolar; TLS sertifikasının süresini dosyadan değil portun sunduğu sertifikadan oku; ve uyarıları asla izlediğin mail sunucusu üzerinden gönderme. Bunlara saatlik bir kara liste kontrolü eklersen, sorunları müşterinden önce görürsün.

Altyapının izlenmesini ve bakımını kendin üstlenmek istemiyorsan Clou.TR tarafında hazır seçenekler var. Sunucu yönetimi hizmetimiz izleme, yedekleme ve müdahaleyi birlikte üstlenirken, kendi kurulumunu yapmak isteyenler için VDS ve bulut sunucu paketlerimiz tam root erişimi sunuyor. Yalnızca gönderim tarafını ayırmak istersen SMTP sunucu çözümümüz, hazır kurumsal posta kutuları içinse e-posta paketlerimiz uygun bir başlangıç noktası olur.