sar Komutu ile Sistem Performans Geçmişi İnceleme

Bir sunucuda performans sorunu yaşandıktan saatler sonra fark etmek sinir bozucu bir durumdur. “Gece 3’te tam olarak ne oldu?” sorusunu yanıtlayabilmek için geriye dönük veri lazım. İşte tam bu noktada sar (System Activity Reporter) devreye giriyor. sysstat paketinin bir parçası olan bu araç, sistem aktivitelerini düzenli aralıklarla kaydederek geçmişe dönük analiz yapmanızı sağlıyor. Benim en çok değer verdiğim araçlardan biri, çünkü bir şeyleri canlı izlemek yerine “ne zaman bozuldu” sorusuna net bir cevap veriyor.

sar Nedir ve Nasıl Çalışır?

sar, Linux üzerinde CPU, bellek, disk I/O, ağ trafiği ve çok daha fazlasını belirli aralıklarla kaydeden bir izleme aracıdır. sysstat paketi kurulduğunda, arka planda sadc (System Activity Data Collector) servisi çalışmaya başlar ve topladığı verileri /var/log/sa/ dizinine yazar. Bu veriler ikili formatta saklanır ve sar komutu aracılığıyla okunabilir hale gelir.

Paket kurulumu oldukça basit:

# Debian/Ubuntu
sudo apt install sysstat

# RHEL/CentOS/Rocky Linux
sudo dnf install sysstat

# Kurulumdan sonra servisi etkinleştir
sudo systemctl enable --now sysstat

Kurulumun ardından /etc/default/sysstat (Debian tabanlı) veya /etc/sysconfig/sysstat (RHEL tabanlı) dosyasından veri toplama davranışını yapılandırabilirsiniz. Önemli bir detay: Debian/Ubuntu’da kurulumdan sonra ENABLED="true" satırını kontrol etmeyi unutmayın, aksi takdirde veri toplanmaz.

Veri toplama sıklığı ise /etc/cron.d/sysstat dosyasında tanımlıdır. Varsayılan olarak 10 dakikada bir veri toplanır ama yoğun ortamlarda bunu 2-5 dakikaya indirmek mantıklı olabilir:

# /etc/cron.d/sysstat içeriğini görüntüle
cat /etc/cron.d/sysstat

# Örnek çıktı:
# */10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

Temel Kullanım: Bugünün Verilerini Okumak

sar komutunu parametresiz çalıştırdığınızda bugüne ait CPU verilerini listeler:

sar

Bu komut, günün başından itibaren 10’ar dakikalık aralıklarla kaydedilen CPU kullanım verilerini ekrana döker. Çıktıda şu kolonları göreceksiniz:

%user: Kullanıcı alanında geçen CPU süresi yüzdesi
%system: Kernel alanında geçen CPU süresi yüzdesi
%iowait: I/O beklemesinde geçen CPU süresi (bu değer yüksekse disk sorununa işaret eder)
%idle: Boşta geçen CPU süresi yüzdesi

Belirli bir zaman aralığını incelemek istiyorsanız -s ve -e parametreleri işinizi görür:

# Sabah 09:00 ile 11:00 arasındaki CPU verilerini göster
sar -s 09:00:00 -e 11:00:00

Geçmiş Günlere Ait Verileri Okumak

İşte sar‘ı gerçekten değerli kılan özellik burası. Geçmiş günlere ait veriler /var/log/sa/ dizininde saXX formatında saklanır. Buradaki XX ayın gün numarasını temsil eder. Yani 15. günün verisi sa15 dosyasında bulunur.

# Belirli bir tarihin verisini oku
sar -f /var/log/sa/sa15

# Daha eski sistemlerde veya farklı dizin yapısında
sar -f /var/log/sysstat/sa15

Birkaç gün öncesine de kısa yoldan gidebilirsiniz:

# Dünün verilerini göster
sar -1

# 3 gün öncesinin verilerini göster
sar -3

Bu özellik sayesinde “Geçen Salı gece neden yavaşladı?” sorusunu yanıtlamak çok daha kolaylaşıyor. Ben genellikle bir olay raporunu hazırlarken bu yöntemi kullanıyorum.

CPU Analizi

CPU kullanımını detaylı incelemek için -u parametresini kullanırsınız:

# Detaylı CPU istatistikleri (ALL ile tüm alanlar görünür)
sar -u ALL -f /var/log/sa/sa20

# Her CPU çekirdeğini ayrı ayrı görmek için -P parametresi
sar -P ALL -f /var/log/sa/sa20

# Sadece 2. çekirdeği izle
sar -P 1 -f /var/log/sa/sa20

Gerçek dünya senaryosu: Bir e-ticaret sitesinde her Pazartesi sabahı yavaşlama şikayetleri geliyordu. sar -P ALL -f /var/log/sa/sa komutuyla baktığımda, 08:30 ile 09:30 arasında tek bir CPU çekirdeğinin %98-99 kullanımda olduğunu, diğerlerinin ise neredeyse boşta kaldığını gördüm. Bu durum, multi-thread kullanmayan bir batch job’ın çalıştığına işaret ediyordu. Sorunun kaynağı, her Pazartesi sabahı çalışan ve tek iş parçacığıyla büyük bir rapor üreten bir Python scriptiydi.

Bellek ve Swap Analizi

Bellek sorunları genellikle sinsi gelişir, aniden patlak vermez. sar -r ile bellek kullanım geçmişine bakabilirsiniz:

# Bellek kullanım istatistikleri
sar -r -f /var/log/sa/sa18

# Daha detaylı bellek bilgisi (ALL parametresiyle)
sar -r ALL -f /var/log/sa/sa18

# Swap kullanımını incele
sar -S -f /var/log/sa/sa18

Çıktıdaki önemli kolonlar:

kbmemfree: Boştaki bellek miktarı (KB)
kbmemused: Kullanımdaki bellek miktarı (KB)
%memused: Bellek kullanım yüzdesi
kbbuffers: Buffer cache için ayrılan bellek
kbcached: Page cache için ayrılan bellek
kbswpused: Kullanılan swap miktarı

Swap kullanımının artmaya başladığı anı tespit etmek kritik önem taşır. Eğer kbswpused değeri düzenli olarak artıyorsa, bu bellek sızıntısının habercisi olabilir.

Disk I/O Analizi

Disk kaynaklı performans sorunları en çok yanıltıcı olanlardır, çünkü yüksek CPU veya bellek kullanımı olmadan da sistemi felç edebilirler.

# Disk I/O istatistikleri
sar -d -f /var/log/sa/sa22

# Daha okunabilir çıktı için -p parametresi (cihaz isimlerini gösterir)
sar -dp -f /var/log/sa/sa22

# Transfer hızlarını görmek için -b parametresi
sar -b -f /var/log/sa/sa22

-b parametresinin çıktısında dikkat edilmesi gereken değerler:

tps: Saniyedeki toplam I/O işlemi sayısı
rtps: Saniyedeki okuma işlemi sayısı
wtps: Saniyedeki yazma işlemi sayısı
bread/s: Saniyede okunan blok sayısı
bwrtn/s: Saniyede yazılan blok sayısı

Gerçek dünya senaryosu: Bir veritabanı sunucusunda sorgu süreleri akşam saatlerinde ciddi şekilde uzuyordu. sar -dp ile baktığımda, akşam 20:00-22:00 arasında /dev/sdb diskinde await değerinin 200ms’nin üzerine çıktığını gördüm. Normal koşullarda bu değer 5-10ms olmalıydı. Araştırdığımda, akşam çalışan backup job’ının disk I/O’sunu tamamen doldurduğu ortaya çıktı. Backup zamanlamasını gece 02:00’a aldığımızda sorun çözüldü.

Ağ Trafiği Analizi

# Ağ arayüzü istatistikleri
sar -n DEV -f /var/log/sa/sa10

# Ağ hataları
sar -n EDEV -f /var/log/sa/sa10

# TCP bağlantı istatistikleri
sar -n TCP -f /var/log/sa/sa10

# Tüm ağ istatistikleri
sar -n ALL -f /var/log/sa/sa10

-n DEV çıktısında önemli kolonlar:

rxpck/s: Saniyede alınan paket sayısı
txpck/s: Saniyede gönderilen paket sayısı
rxkB/s: Saniyede alınan veri miktarı (KB)
txkB/s: Saniyede gönderilen veri miktarı (KB)
rxerr/s: Saniyede alınan hatalı paket sayısı

DDoS veya anormal trafik patlamalarını geçmişe dönük incelemek istediğinizde bu parametreler altın değerindedir. Ben bir keresinde sabah geldiğimde ağ performansının düştüğünü gören bir müşterinin sorununun kökünü, sar -n DEV ile gece 03:00-04:00 arasında rxpck/s değerinin normal zamanın 50 katına çıktığını tespit ederek buldum.

Load Average ve Sistem Yükü

# Sistem yükünü ve kuyruk istatistiklerini göster
sar -q -f /var/log/sa/sa05

# Belirli bir zaman dilimiyle birlikte
sar -q -s 14:00:00 -e 18:00:00 -f /var/log/sa/sa05

-q çıktısındaki kolonlar:

runq-sz: Çalışmayı bekleyen veya çalışan process sayısı
plist-sz: Sistemdeki toplam process ve thread sayısı
ldavg-1: 1 dakikalık load average
ldavg-5: 5 dakikalık load average
ldavg-15: 15 dakikalık load average
blocked: I/O bekleyen process sayısı

blocked değerinin sürekli yüksek kalması, disk I/O sorununu açıkça ortaya koyar.

Context Switch ve Interrupt Analizi

Sistemde beklenmedik bir yavaşlama yaşanıyorsa ve CPU, disk, bellek normal görünüyorsa, context switch veya interrupt yüküne bakmak gerekir:

# Context switch ve interrupt istatistikleri
sar -w -f /var/log/sa/sa12

# Interrupt istatistikleri
sar -I ALL -f /var/log/sa/sa12

proc/s: Saniyede oluşturulan yeni process sayısı
cswch/s: Saniyedeki context switch sayısı

Saniyede 100.000’in üzerinde context switch, genellikle kötü yazılmış bir uygulamanın belirtisidir.

Çıktıyı Farklı Formatlarda Almak

sar çıktısını doğrudan terminal dışında da kullanabilirsiniz. Özellikle raporlama veya grafik oluşturma amacıyla CSV formatına almak çok işe yarar:

# CSV formatında çıktı al
sar -u -f /var/log/sa/sa15 | grep -v "^$" | grep -v "Average" > cpu_report.txt

# sadf komutuyla CSV formatı (sysstat ile birlikte gelir)
sadf -d /var/log/sa/sa15 -- -u > cpu_data.csv

# JSON formatında çıktı (sysstat 11.7.1+)
sadf -j /var/log/sa/sa15 -- -u > cpu_data.json

# Grafik oluşturmak için SVG formatı
sadf -g /var/log/sa/sa15 -- -u > cpu_graph.svg

sadf komutu sar verilerini farklı formatlarda sunmak için tasarlanmış yardımcı bir araçtır. Özellikle sadf -d ile elde ettiğiniz CSV çıktısını Grafana’ya veya başka bir izleme aracına aktarabilirsiniz.

Kapsamlı Olay Sonrası Analiz Scripti

Bir olay yaşandıktan sonra hızlıca analiz yapmak için kullandığım basit bir script:

#!/bin/bash
# post_incident_analysis.sh
# Kullanım: ./post_incident_analysis.sh <gün_numarası> <başlangıç_saati> <bitiş_saati>
# Örnek: ./post_incident_analysis.sh 15 14:00:00 16:00:00

GUN=$1
BASLANGIC=$2
BITIS=$3
DOSYA="/var/log/sa/sa${GUN}"

if [ ! -f "$DOSYA" ]; then
    echo "Hata: $DOSYA bulunamadi."
    exit 1
fi

echo "========================================="
echo "CPU ANALIZI - $GUN. Gun ($BASLANGIC - $BITIS)"
echo "========================================="
sar -u -s "$BASLANGIC" -e "$BITIS" -f "$DOSYA"

echo ""
echo "========================================="
echo "BELLEK KULLANIMI"
echo "========================================="
sar -r -s "$BASLANGIC" -e "$BITIS" -f "$DOSYA"

echo ""
echo "========================================="
echo "DISK I/O"
echo "========================================="
sar -dp -s "$BASLANGIC" -e "$BITIS" -f "$DOSYA"

echo ""
echo "========================================="
echo "SISTEM YUKU"
echo "========================================="
sar -q -s "$BASLANGIC" -e "$BITIS" -f "$DOSYA"

echo ""
echo "========================================="
echo "AG TRAFIGI"
echo "========================================="
sar -n DEV -s "$BASLANGIC" -e "$BITIS" -f "$DOSYA"

Bu scripti çalıştırılabilir yapıp kullanmaya başlayabilirsiniz:

chmod +x post_incident_analysis.sh
./post_incident_analysis.sh 22 03:00:00 05:00:00

Veri Saklama Süresini Ayarlamak

Varsayılan olarak sysstat verileri 28 gün saklar. Bu süreyi değiştirmek için:

# /etc/sysstat/sysstat dosyasını düzenle
sudo nano /etc/sysstat/sysstat

# Aşağıdaki satırı bul ve değiştir:
# HISTORY=28
# Örneğin 90 güne çıkar:
HISTORY=90

Büyük kurumsal ortamlarda 90-180 günlük veri saklama tercih edilir. Tabi bu, disk alanı tüketimine dikkat etmeniz gerektiği anlamına gelir. Aylık yaklaşık 20-50 MB arasında değişen bir depolama ihtiyacı oluşur, bu oldukça makul bir boyuttur.

Veri toplama aralığını daha sık yapmak istiyorsanız:

# /etc/cron.d/sysstat dosyasını düzenle
# Varsayılan olan */10 yerine */5 yap (5 dakikada bir)
sudo nano /etc/cron.d/sysstat

sar ile Canlı İzleme

sar sadece geçmiş verileri okumakla kalmaz, aynı zamanda canlı izleme de yapabilir:

# Her 2 saniyede bir, 10 kez CPU verisi göster
sar -u 2 10

# Her 5 saniyede bir sürekli bellek izle (Ctrl+C ile dur)
sar -r 5

# Her saniyede disk I/O izle
sar -d 1 5

Bu kullanım şekli iostat, vmstat veya mpstat‘a benzer bir işlev görür. Anlık sorun giderme sırasında faydalı olabilir ama asıl güç, tarihsel verilerde yatıyor.

Pratik İpuçları ve Dikkat Edilmesi Gerekenler

Yıllar içinde sar kullanırken öğrendiğim birkaç önemli nokta:

Zaman dilimi tutarsızlığı: sar sunucunun sistem saatini kullanır. Eğer NTP düzgün yapılandırılmamışsa veya saat dilimi farklıysa, çıktıları yorumlarken dikkatli olun. Özellikle saat yaz/kış değişimi sonrasında veriler kafa karıştırıcı olabilir.

Sadc servisinin çalıştığını doğrulayın: Veri yoksa ilk kontrol noktanız servis durumu olmalı.

systemctl status sysstat
# veya
systemctl status crond  # cron tabanlı sistemlerde

Dosya boyutlarını kontrol edin: /var/log/sa/ dizini zamanla büyüyebilir, disk doluluk uyarılarına karşı izleme kurun.

%iowait değeri yanıltıcı olabilir: Bu değer yüksek olduğunda disk sorununa işaret eder ama her zaman böyle değildir. NFS mount’ları veya yavaş ağ depolama sistemleri de iowait‘i yükseltir.

Average satırını ihmal etme: sar çıktısının en altında bulunan Average satırı, incelenen dönemin ortalamasını verir. Hızlı bir genel bakış için bu satıra odaklanmak yeterli olabilir.

Kernel güncellemelerinden sonra eski dosyalar okunmayabilir: Büyük kernel veya sysstat güncellemelerinden sonra eski binary formattaki sa dosyaları uyumsuz hale gelebilir. Bu durumda sadf ile dönüştürme yapılabilir.

Sonuç

sar, her ciddi sysadmin’in araç kutusunda bulunması gereken bir historyci. Anlık izleme araçları gerçek zamanlı değerli bilgi sunar ama bir sorunun tam olarak ne zaman ve nasıl başladığını anlamak için geriye dönük veriye ihtiyacınız var. Gece 3’teki bellek patlaması, hafta sonu disk doygunluğu veya her Pazartesi yaşanan yavaşlama gibi sorunları çözmek için sar olmadan kör uçuş yapıyorsunuz demektir.

Temel öneri olarak: Yeni bir Linux sunucu kurduğunuzda sysstat‘ı kurmayı ve etkinleştirmeyi ilk adımlar arasına koyun. Veri toplamaya başlamadan önce olay yaşanırsa geriye dönük analiz yapma şansınız olmayacak. Küçük bir disk alanı maliyetiyle elde ettiğiniz bu tarihsel veri, kritik bir anda saatlerce sürebilecek kör hata ayıklama sürecini birkaç dakikaya indirebilir. Benim için bu takas her zaman kazançlı olmuştur.

sar Komutu ile Geçmiş Performans Verilerini İnceleme