Performans Raporlama: sar ile Geçmişe Yönelik Analiz

Sunucu başı belaya girdiğinde herkesin aklına gelen ilk soru şudur: “Bu ne zamandan beri böyle?” İşte tam bu noktada sar komutu devreye giriyor. System Activity Reporter’ın kısaltması olan sar, Linux sistemlerinde performans verilerini düzenli aralıklarla toplayıp diske yazan ve sonra bunları analiz etmenizi sağlayan bir araç. Anlık izleme araçlarından farklı olarak geçmişe dönük analiz yapmanıza olanak tanıması, özellikle “dün gece tam olarak ne oldu?” sorusunu cevaplamak için biçilmiş kaftan.

sar Nedir ve Neden Kullanmalısınız?

sar, sysstat paketinin bir parçasıdır. Bu paket aynı zamanda iostat, mpstat, pidstat gibi araçları da içerir. Ancak sar‘ı özel yapan şey, verileri otomatik olarak kaydetmesi ve bu kayıtları daha sonra sorgulayabilmenizdir. Cron job’lar aracılığıyla belirli aralıklarla sistem aktivitesini toplayıp /var/log/sa/ dizininde saklayan sadc (System Activity Data Collector) daemon’ı arka planda sessizce çalışır.

Gerçek dünyadan bir senaryo düşünelim: Pazartesi sabahı işe geldiniz, uygulama ekibi Cuma gecesi sistemin çok yavaş çalıştığını söylüyor. O sırada kimse izlemiyordu, alertler de tetiklenmemişti. Eğer sysstat kurulu ve çalışıyorsa, o geceye ait CPU, bellek, disk I/O ve ağ verilerine erişebilirsiniz. Kurulu değilse, tek yapabileceğiniz “bir daha yaşanırsa bakarız” demek.

Kurulum ve Temel Yapılandırma

Çoğu dağıtımda sysstat varsayılan olarak gelmez, elle kurmanız gerekir.

# Debian/Ubuntu
sudo apt-get install sysstat

# RHEL/CentOS/Rocky Linux
sudo yum install sysstat
# veya
sudo dnf install sysstat

# Arch Linux
sudo pacman -S sysstat

Kurulumun ardından veri toplamayı aktif etmeniz gerekiyor. Debian tabanlı sistemlerde /etc/default/sysstat dosyasını düzenleyin:

sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable sysstat
sudo systemctl start sysstat

RHEL/CentOS sistemlerinde sysstat servisi kurulumla birlikte cron tablosuna eklenir. Veri toplama sıklığını ayarlamak için /etc/cron.d/sysstat veya systemd timer kullanıyorsanız ilgili unit dosyasını inceleyebilirsiniz. Varsayılan olarak her 10 dakikada bir veri toplanır, bu çoğu ortam için yeterlidir. Kritik sistemlerde bunu 2-5 dakikaya indirmek mantıklıdır.

Toplanan veriler /var/log/sa/ dizininde günlük dosyalar halinde saklanır. sa01, sa02 gibi adlandırılan bu dosyalar ikili formattadır, direkt açamazsınız.

ls -la /var/log/sa/
# sa01, sa02 ... sa31 formatında dosyalar göreceksiniz
# sar01, sar02 gibi metin formatında da olabilir

Temel sar Kullanımı

sar komutunun temel sözdizimi şöyledir: sar [seçenekler] [aralık] [sayı]

Hiçbir argüman vermeden çalıştırırsanız bugünkü CPU verilerini gösterir:

sar

Belirli bir tarihte toplanan verilere bakmak için -f parametresiyle dosyayı belirtebilirsiniz:

# 15. günün verilerine bakmak için
sar -f /var/log/sa/sa15

# Sadece belirli saat aralığı
sar -s 14:00:00 -e 16:00:00 -f /var/log/sa/sa15

-s: Başlangıç saatini belirtir -e: Bitiş saatini belirtir -f: Hangi dosyadan okuyacağını belirtir

CPU Analizi

CPU kullanımı genellikle analizin başladığı yerdir. -u parametresi CPU istatistiklerini gösterir:

# Bugünkü CPU kullanımı
sar -u

# Tüm CPU'ları ayrı ayrı göster
sar -u ALL

# Belirli bir gün, belirli saatler
sar -u -s 09:00:00 -e 18:00:00 -f /var/log/sa/sa20

Çıktıda göreceğiniz alanlar şunlardır:

• %user: Kullanıcı alanı işlemlerin CPU kullanımı
• %nice: Nice değeri yüksek süreçlerin CPU kullanımı
• %system: Kernel alanı CPU kullanımı
• %iowait: I/O beklerken boşa harcanan CPU süresi
• %steal: Sanallaştırma ortamında başka VM’ler tarafından çalınan CPU süresi
• %idle: Boşta geçen CPU süresi

Burada dikkat edilmesi gereken kritik nokta %iowait değeridir. Bu değer sürekli yüksekse disk I/O darboğazı yaşıyorsunuz demektir. %steal değerinin yüksek olması ise bir VPS ortamındaysanız komşu VM’lerin sizi ezdiğini gösterir, bu durumda hosting firmanızla konuşmanın zamanı gelmiştir.

Gerçek bir senaryo: Bir e-ticaret sitesinde her gün saat 10:00-11:00 arasında yavaşlama şikayeti geliyordu. sar -u ile baktığımızda o saatlerde %user değerinin %85-90’a çıktığını gördük. Diğer saatlerde %20-30 civarındaydı. Sonuçta her gün o saatte çalışan bir raporlama job’ı suçluydu.

Bellek Analizi

RAM kullanımını incelemek için -r parametresini kullanırsınız:

# Bellek kullanımı
sar -r

# Daha detaylı bellek istatistikleri
sar -r ALL -f /var/log/sa/sa18

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

-r çıktısında önemli alanlar:

• kbmemfree: Tamamen boş RAM (KB)
• kbavail: Gerçek anlamda kullanılabilir RAM (cache dahil)
• kbbuffers: Buffer olarak kullanılan RAM
• kbcached: Cache olarak kullanılan RAM
• %memused: Bellek kullanım yüzdesi
• kbswpused: Kullanılan swap miktarı

-S ile swap analizi yaparken sürekli artan kbswpused değeri, bir bellek sızıntısına işaret edebilir. Swap kullanımı sıfırdan başlayıp saatler içinde artıyorsa hangi process’in bellek yediğini bulmak için o zaman dilimine ait pidstat verilerine bakmak gerekir.

# Swap ve bellek birlikte
sar -r -S -f /var/log/sa/sa10 | grep -v "^$"

Disk I/O Analizi

Disk performansı sorunları genellikle en sinsi problemlerdir, çünkü CPU veya RAM gibi anlık olarak fark edilmezler, birikimli etkilerini zamanla hissettirirler.

# Tüm blok aygıtları için I/O istatistikleri
sar -d

# Daha okunabilir çıktı için -p (kalıcı isimler)
sar -d -p -f /var/log/sa/sa22

# Belirli saatler arasında
sar -d -p -s 02:00:00 -e 06:00:00 -f /var/log/sa/sa22

-d çıktısında dikkat edilecek alanlar:

• tps: Saniyedeki transfer sayısı (transaction per second)
• rkB/s: Saniyede okunan KB
• wkB/s: Saniyede yazılan KB
• areq-sz: Ortalama istek boyutu (KB)
• aqu-sz: Ortalama kuyruk boyutu (disk queue length)
• await: Ortalama bekleme süresi (milisaniye)
• %util: Disk kullanım yüzdesi

await değeri üzerine biraz daha duralım. SSD için bu değer genellikle 1-5ms arasındadır. HDD için 5-20ms normal kabul edilir. Bu değer düzenli olarak 100ms’nin üzerine çıkıyorsa ciddi bir disk probleminiz var demektir. %util değerinin sürekli %80-90’ın üzerinde olması da diskin doygunluğa ulaştığını gösterir.

Bir örnek senaryo: Gece 03:00-04:00 arasında çalışan backup job’ı sistemin gündüz performansını etkilemiyordu ama log’larda yavaş sorgu uyarıları o saatlerde yoğunlaşıyordu. sar -d -p ile baktığımızda backup süresince %util değerinin sdb diskinde %95’e çıktığını, await değerinin 250ms’ye ulaştığını gördük. Backup job’ını ionice ile sınırlamak sorunu çözdü.

Ağ Trafiği Analizi

Ağ sorunlarını geriye dönük incelemek için -n parametresini kullanırsınız:

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

# Sadece belirli saatler
sar -n DEV -s 18:00:00 -e 22:00:00 -f /var/log/sa/sa25

# TCP istatistikleri
sar -n TCP -f /var/log/sa/sa25

# Hata istatistikleri
sar -n EDEV -f /var/log/sa/sa25

-n parametresi birkaç farklı anahtar kelimeyle kullanılır:

• DEV: Ağ arayüzü istatistikleri (rxpck/s, txpck/s, rxkB/s, txkB/s)
• EDEV: Ağ hata istatistikleri (rxerr/s, txerr/s, rxdrop/s)
• TCP: TCP bağlantı istatistikleri
• UDP: UDP istatistikleri
• SOCK: Socket istatistikleri

-n EDEV çıktısında yüksek rxdrop/s veya txdrop/s değerleri, ağ buffer’larının dolduğunu gösterir. Bu genellikle yüksek trafikli anlarda ring buffer yetersizliğinden kaynaklanır ve ethtool ile ring buffer boyutunu artırarak çözülebilir.

Load Average ve Çalışma Kuyruğu

Sisteme genel bir bakış için run queue ve load average verilerine bakmak önemlidir:

# Load average ve run queue analizi
sar -q -f /var/log/sa/sa14

# Belirli bir zaman dilimi
sar -q -s 10:00:00 -e 14:00:00 -f /var/log/sa/sa14

-q çıktısındaki önemli alanlar:

• runq-sz: Çalışmayı bekleyen process sayısı (run queue)
• plist-sz: Sistemdeki toplam process/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 bloklanmış process sayısı

blocked değeri üzerinde özellikle durmak lazım. Bu sayı yüksekse ve sar -d ile baktığınızda disk %util de yüksekse, sorun neredeyse kesinlikle disk I/O darboğazıdır.

Bütünleşik Analiz: Gerçek Bir Olay Sonrası İnceleme

Teorik bilgileri bir kenara bırakıp gerçek bir senaryoyu baştan sona inceleyelim. Bir web uygulaması sunucusunda geçen Çarşamba günü saat 14:30-15:00 arasında ciddi yavaşlama yaşandı. Kullanıcılar sayfa yüklemelerinin çok uzun sürdüğünü bildirdi. İşte bu durumu sar ile nasıl analiz edersiniz:

# Önce CPU'ya bakıyoruz
sar -u -s 14:00:00 -e 16:00:00 -f /var/log/sa/sa$(date -d "last wednesday" +%d)

# Belleğe bakıyoruz
sar -r -s 14:00:00 -e 16:00:00 -f /var/log/sa/sa$(date -d "last wednesday" +%d)

# Diske bakıyoruz
sar -d -p -s 14:00:00 -e 16:00:00 -f /var/log/sa/sa$(date -d "last wednesday" +%d)

# Ağa bakıyoruz
sar -n DEV -s 14:00:00 -e 16:00:00 -f /var/log/sa/sa$(date -d "last wednesday" +%d)

Bu analizde şunu gördük: CPU %iowait değeri 14:32’de ani olarak %45’e fırlamış ve 14:51’e kadar yüksek kalmış. Aynı zaman diliminde sda diskinin %util değeri %98’e çıkmış, await değeri 380ms olmuş. Bellek ve ağ tamamen normaldi. Tanı netti: disk I/O darboğazı. Sonradan anlaşıldı ki bir developer o saatte veritabanında VACUUM FULL çalıştırmış ve bu işlem tüm disk kapasitesini kullanmıştı.

Otomatik Raporlama için Basit Script

Günlük performans raporunu otomatik oluşturmak için küçük bir bash script’i işinizi kolaylaştırır:

#!/bin/bash
# /usr/local/bin/daily-sar-report.sh

YESTERDAY=$(date -d "yesterday" +%d)
REPORT_FILE="/tmp/sar-report-$(date -d 'yesterday' +%Y%m%d).txt"
SA_FILE="/var/log/sa/sa${YESTERDAY}"

if [ ! -f "$SA_FILE" ]; then
    echo "SA dosyasi bulunamadi: $SA_FILE"
    exit 1
fi

echo "=== GUNLUK PERFORMANS RAPORU ===" > $REPORT_FILE
echo "Tarih: $(date -d 'yesterday' +%Y-%m-%d)" >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "--- CPU KULLANIMI ---" >> $REPORT_FILE
sar -u -f $SA_FILE | tail -3 >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "--- BELLEK KULLANIMI ---" >> $REPORT_FILE
sar -r -f $SA_FILE | tail -3 >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "--- DISK I/O ---" >> $REPORT_FILE
sar -d -p -f $SA_FILE | tail -5 >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "--- LOAD AVERAGE ---" >> $REPORT_FILE
sar -q -f $SA_FILE | tail -3 >> $REPORT_FILE

# Mail ile gonder (mail komutu kurulu olmali)
cat $REPORT_FILE | mail -s "Sunucu Performans Raporu $(date -d 'yesterday' +%Y-%m-%d)" [email protected]

echo "Rapor olusturuldu: $REPORT_FILE"

Bu script’i crontab’a ekleyerek her sabah rapor alabilirsiniz:

# Her sabah 08:00'de rapor gonder
0 8 * * * /usr/local/bin/daily-sar-report.sh

Kısa Süreli Canlı İzleme

sar sadece geçmiş veriler için değil, gerçek zamanlı izleme için de kullanılabilir. Özellikle bir müdahale sırasında belirli metrikleri sürekli takip etmek gerektiğinde şöyle kullanılır:

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

# Her 5 saniyede bir disk I/O, sürekli göster
sar -d -p 5 0

# CPU ve disk aynı anda (farklı terminallerde)
sar -u 1 60 &
sar -d -p 1 60 &

Bu kullanım şekli iostat veya vmstat ile benzerdir, ancak sar sözdizimini zaten biliyorsanız ekstra araç öğrenmenize gerek kalmaz.

Veri Saklama Süresi Ayarı

Varsayılan olarak sysstat 28 günlük veri saklar. Bu süreyi değiştirmek için /etc/sysstat/sysstat dosyasını (veya dağıtıma göre /etc/sysconfig/sysstat) düzenleyebilirsiniz:

sudo grep -n "HISTORY" /etc/sysstat/sysstat
# HISTORY=28 satırını bulup degistirin

sudo sed -i 's/HISTORY=28/HISTORY=90/' /etc/sysstat/sysstat

Disk alanı kısıtlıysa 7 günle de idare edebilirsiniz, ancak 28 gün ayda bir yaşanan periyodik sorunları yakalamak için oldukça faydalıdır. 90 güne çıkarmak ise üç aylık dönem karşılaştırmaları yapmanıza imkan tanır.

Önemli bir not: Veri toplama sıklığını artırdıysanız dosya boyutları da artacaktır. 10 dakikalık aralıkla günlük dosyalar birkaç MB tutarken, 2 dakikalık aralıkta bu 20-30 MB’a çıkabilir. Buna göre saklama süresini ve disk kapasitesini planlayın.

Birden Fazla Sunucu Karşılaştırması

Birden fazla sunucuyu yönetiyorsanız, performans verilerini merkezi bir yere toplayıp karşılaştırmalı analiz yapmak hayat kurtarır. Basit bir yaklaşım şöyle olabilir:

#!/bin/bash
# Uzak sunuculardan sar verisi topla
SERVERS=("web01" "web02" "db01")
DATE=$(date +%d)

for server in "${SERVERS[@]}"; do
    echo "=== $server ==="
    ssh $server "sar -u -s 10:00:00 -e 11:00:00 -f /var/log/sa/sa${DATE} | tail -5"
    echo ""
done

Bu yöntem küçük ve orta ölçekli ortamlar için işe yarar. Büyük ortamlarda Grafana ile birlikte kullanılan sysstat exporter’ları veya Prometheus entegrasyonu daha sağlıklı bir merkezi izleme sağlar.

sar’ı Diğer Araçlarla Birlikte Kullanmak

sar tek başına güçlüdür ama diğer sysstat araçlarıyla birleşince çok daha kapsamlı bir tablo ortaya çıkar. Bir sorun tespit ettiğinizde şu sırayı takip edebilirsiniz:

Önce sar ile zaman dilimini ve metriği belirleyin. Sonra o zaman dilimine ait pidstat verilerine bakın:

# O saatte hangi processler CPU yiyordu?
pidstat -u -p ALL 1 > /var/log/pidstat-$(date +%Y%m%d-%H%M).log &

# Disk I/O bazında process analizi
pidstat -d -p ALL 1

# Bellek bazında
pidstat -r -p ALL 1

pidstat gerçek zamanlı çalışır ve otomatik olarak kayıt tutmaz, bu yüzden cron ile düzenli olarak çalıştırıp sonuçları dosyaya yazabilirsiniz.

Sonuç

sar, her Linux sysadmin’in araç kutusunda olması gereken ve değeri genellikle bir kriz anında anlaşılan bir uygulamadır. Anlık izleme araçları ne kadar gelişmiş olursa olsun, “dün gece ne oldu?” sorusunu cevaplayabilmek için geçmişe ait veri şarttır. sysstat‘ı kurmak ve aktif etmek beş dakika alır, ama sağladığı veri bir gün saatlerce uğraşmanızı önleyebilir.

Pratik tavsiyem şudur: Yönettiğiniz her Linux sunucusuna sysstat kurun, saklama süresini 30-60 güne çıkarın ve toplama sıklığını kritik sunucularda 5 dakikaya indirin. Bir sorun çıkmadan önce bu alışkanlığı edinin çünkü sorun çıktıktan sonra kurmak için zaten vakit olmayacak.

sar öğrenmesi biraz sabır isteyen bir araçtır, çıktılar ilk bakışta kafa karıştırıcı gelebilir. Ancak hangi parametrenin ne işe yaradığını öğrendikten sonra performans analizi için bu kadar pratik ve güvenilir başka bir araç bulmak gerçekten zordur. CPU, bellek, disk, ağ, her şey tek bir araçta, geçmişe dönük olarak erişilebilir biçimde. Bu konfor, özellikle gece üçte çalan bir alarm sonrasında paha biçilmez.