atop ile Anlık ve Geçmiş Kaynak Kullanımı Analizi

Yazar:komut.io ekibi Süreç ve Sistem İzleme Komutları
0 Yorum

Bir üretim sunucusunda bellek tüketiminin gece yarısı zirve yaptığını, sabah geldiğinizde ise her şeyin normal göründüğünü biliyor musunuz? İşte tam bu senaryoda top veya htop sizi kurtaramaz, çünkü o anlık görüntü çoktan geçmişte kalmıştır. atop ise hem anlık hem de geçmişe dönük sistem kaynak analizini tek bir araçta sunan, özellikle post-mortem analizlerde hayat kurtaran bir izleme aracıdır.

atop Nedir ve Neden Kullanmalısınız

atop, Advanced System and Process Monitor kelimelerinin kısaltmasıdır. Hollandalı sistem yöneticisi Gerlof Langeveld tarafından geliştirilmiş olan bu araç, standart izleme araçlarından temel bir farklılıkla öne çıkar: kalıcı kayıt. Varsayılan kurulumda atop, sistem istatistiklerini düzenli aralıklarla diske yazar ve bu sayede saatler, hatta günler öncesindeki kaynak kullanım verilerine erişebilirsiniz.

htop ile karşılaştırdığınızda farkı hemen anlarsınız. htop size şu anı gösterir. atop ise şu anı, geçmişi ve bu ikisi arasındaki farkı gösterir. Üstelik CPU, bellek ve disk I/O bilgilerinin yanı sıra ağ arayüzü istatistiklerini, blok cihaz aktivitesini ve hatta container istatistiklerini de raporlayabilir.

Türkiye’deki birçok kurumsal ortamda gördüğüm kadarıyla sysadmin ekipleri performans sorunlarını ancak kullanıcı şikayeti aldıktan sonra araştırmaya başlıyor. atop bu reaktif döngüyü kırmanın en kolay yollarından biridir.

Kurulum

Çoğu dağıtımda atop paket depolarında mevcuttur:

# Debian/Ubuntu
sudo apt update && sudo apt install atop

# RHEL/CentOS/AlmaLinux
sudo dnf install atop

# Arch Linux
sudo pacman -S atop

Kurulumun ardından atop servisini etkinleştirmenizi şiddetle tavsiye ederim. Bu servis arka planda çalışarak verileri otomatik olarak kayıt altına alır:

sudo systemctl enable --now atop
sudo systemctl status atop

Varsayılan kayıt dosyaları /var/log/atop/ dizininde atop_YYYYMMDD formatında tutulur. Kayıt aralığını değiştirmek isterseniz /etc/default/atop (Debian tabanlı) veya /etc/sysconfig/atop (RHEL tabanlı) dosyasını düzenleyebilirsiniz.

# /etc/default/atop içeriği örneği
INTERVAL=30        # saniye cinsinden kayıt aralığı
LOGPATH=/var/log/atop
OUTFILE=${LOGPATH}/daily.log

Temel Kullanım ve Arayüz Okuma

atop’u çalıştırmak basittir:

atop

Açılan arayüz iki ana bölümden oluşur. Üst bölüm sistem genelini özetlerken alt bölüm süreç listesini gösterir.

Üst bölümde şu satırları görürsünüz:

  • PRC: Toplam süreç sayısı, çalışan ve uyuyan süreçler
  • CPU: Her çekirdek için kullanım yüzdesi (user, system, idle, wait)
  • CPL: CPU load average ve context switch sayısı
  • MEM: Fiziksel bellek kullanımı (toplam, boş, önbellek, tampon)
  • SWP: Swap kullanımı
  • DSK: Disk I/O (okuma/yazma işlemi sayısı ve bant genişliği)
  • NET: Ağ arayüzü başına gelen/giden paket ve byte miktarı

Arayüzde gezinmek için kullanabileceğiniz tuşlar:

  • g: Genel görünüm (varsayılan)
  • m: Bellek odaklı süreç sıralaması
  • d: Disk I/O odaklı sıralama
  • n: Ağ kullanımına göre sıralama
  • c: Komut satırı detaylarını göster
  • u: Kullanıcıya göre filtrele
  • k: Belirli bir sürecin sinyalini gönder
  • q: Çıkış

Komut Satırı Parametreleri

atop, terminal üzerinden doğrudan farklı modlarda çalıştırılabilir:

-a: Tüm süreçleri göster, aktif olmayanlar dahil -r: Kayıtlı log dosyasını oynat (replay modu) -b: Belirli bir saat/tarihten itibaren başla -e: Belirli bir saat/tarihe kadar göster -i: Örnekleme aralığını saniye cinsinden ayarla -P: Belirli alt sistemlerin çıktısını al (CPU, MEM, DSK vb.) -R: İnsan tarafından okunabilir format -n: Gösterilecek örnek sayısı -L: Süreç listesindeki sütun sayısını sınırla –top: Belirtilen metriğe göre en yüksek süreçleri göster

Pratikte sık kullandığım kombinasyonlar:

# 5 saniyelik örnekleme ile başlat
atop 5

# 10 örnek topla ve çık
atop -n 10 5

# Dün akşam 23:00'dan bu sabah 08:00'a kadar olan veriyi oynat
atop -r /var/log/atop/atop_$(date -d "yesterday" +%Y%m%d) -b 23:00 -e 08:00

Geçmiş Analizi: Replay Modu

atop’un en güçlü özelliği budur. Bir sorun yaşandıktan sonra neyin ne zaman ne kadar kaynak tükettiğini görmek için kayıt dosyalarını replay modunda açarsınız:

# Bugünün kayıt dosyasını aç
atop -r /var/log/atop/atop_$(date +%Y%m%d)

# Belirli bir tarihin kaydını aç
atop -r /var/log/atop/atop_20241115

# Replay modunda belirli zaman dilimine git
atop -r /var/log/atop/atop_20241115 -b 14:30 -e 16:00

Replay modunda t tuşuna basarak bir sonraki örnekleme noktasına, T ile bir öncekine geçebilirsiniz. Bu sayede olayın tam olarak ne zaman başladığını dakika dakika takip edebilirsiniz.

Metin Tabanlı Çıktı ile Otomasyon

atop’u script içinde kullanmak veya belirli metrikleri loglamak için -P parametresi son derece işlevseldir:

# CPU ve bellek bilgisini metin olarak çıkar
atop -P CPU,MEM 1 5

# Disk I/O istatistiklerini al
atop -P DSK 2 3

# Belirli bir kayıt dosyasından CPU verilerini çek
atop -r /var/log/atop/atop_$(date +%Y%m%d) -P CPU 1 1

Bu çıktıları awk veya grep ile işleyerek kendi izleme scriptlerinizi yazabilirsiniz:

#!/bin/bash
# Dün gece bellek kullanımı zirve anını bul

LOGFILE="/var/log/atop/atop_$(date -d 'yesterday' +%Y%m%d)"

atop -r "$LOGFILE" -P MEM 60 1440 2>/dev/null | 
awk '$1=="MEM" {
    used = $5
    total = $3
    pct = (used/total)*100
    if (pct > max_pct) {
        max_pct = pct
        max_line = $0
    }
}
END {
    print "Peak memory usage:"
    print max_line
    printf "Usage: %.1f%%n", max_pct
}'

Gerçek Dünya Senaryosu 1: Gece Yarısı Bellek Sızıntısı

Bir fintech müşterisinde Java tabanlı bir uygulama her gece 02:00-04:00 arasında belleği dolduruyor, OOM killer devreye giriyor ve uygulama yeniden başlıyordu. Sabahları kimse fark etmiyordu çünkü uygulama zaten ayaktaydı. Müşteri bunu ancak transaction loglarındaki boşluklardan keşfetti.

atop replay modu ile analiz tam böyle yapıldı:

# Olayın yaşandığı gece kayıtlarını incele
atop -r /var/log/atop/atop_20241112 -b 01:30 -e 04:30

# Replay modunda 'm' tuşuna basarak bellek sıralamasını aktifleştir
# ve hangi Java sürecinin belleği tükettiğini gözlemle

Ardından daha detaylı analiz için:

# Belirli pid'e ait süreç geçmişini metne dök
atop -r /var/log/atop/atop_20241112 -P PRM 60 180 | grep "java"

Bu analiz sonucunda heap dump almak için doğru zaman penceresini tespit ettik ve problemi uygulama ekibine gösterdik. Soyut bir “bazen bellek doluyordu” şikayeti yerine somut verilerle konuştuk.

Gerçek Dünya Senaryosu 2: Disk I/O Darboğazı Tespiti

Bir e-ticaret platformunda yoğun kampanya saatlerinde veritabanı sorguları aniden yavaşlıyordu. DBA ekibi sorgu optimizasyonunu suçlarken altyapı ekibi disk kapasitesinin yeterli olduğunu söylüyordu. atop ile aradaki gerçeği bulduk:

# O günün disk I/O verilerini çek
atop -r /var/log/atop/atop_20241118 -P DSK 60 1440 | 
awk '$1=="DSK" && $3=="sda" {
    print $2, "read:", $7, "write:", $9, "util%:", $NF
}' | sort -k8 -rn | head -20

Çıktı bize ssd’nin yüzde 94-98 utilization seviyesine ulaştığı zaman aralıklarını gösterdi. Sorun disk kapasitesi değil, I/O bant genişliğiydi. PostgreSQL WAL yazma işlemleri ile anlık yedekleme zamanlaması çakışıyordu.

# Hangi süreçlerin disk I/O yaptığını aynı zaman dilimine bak
atop -r /var/log/atop/atop_20241118 -b 15:00 -e 16:00
# Arayüzde 'd' tuşu ile disk I/O sıralaması

Gerçek Dünya Senaryosu 3: CPU Steal Time Analizi

Sanal makine ortamlarında zaman zaman CPU steal time yükselmesi yaşanır. Bu, hypervisor’ın CPU’yu başka VM’lere tahsis etmesinden kaynaklanır ve atop bunu güzelce gösterir:

# CPU istatistiklerini metne dök, steal time'a bak
atop -r /var/log/atop/atop_20241120 -P CPU 30 2880 | 
awk '$1=="CPU" {
    steal = $9
    if (steal > 10) {
        print "HIGH STEAL at", $2, ":", steal"%"
    }
}'

Eğer steal time sürekli yüzde 10’un üzerindeyse, bulut sağlayıcınızda fiziksel sunucu üzerinde overcommit var demektir ve bu VM’i farklı bir host’a taşıması için destek açmanız gerekebilir.

atopsar: atop’un Sar Alternatifi

atop paketi ile birlikte gelen atopsar komutu, sar benzeri raporlama imkanı sunar. Komut satırından doğrudan okunabilir raporlar üretmek için kullanılır:

# CPU raporunu göster
atopsar -c

# Bellek raporunu göster
atopsar -m

# Disk I/O raporu
atopsar -d

# Ağ istatistikleri
atopsar -n

# Belirli bir tarihin raporunu üret
atopsar -r /var/log/atop/atop_20241115 -c -b 10:00 -e 18:00

atopsar çıktısı zaman damgalıdır ve belirli zaman dilimleri için ortalama değerleri gösterir. Bu özellik özellikle kapasite planlama raporları için çok kullanışlıdır.

Log Rotasyonu ve Depolama Yönetimi

atop logları zamanla ciddi yer kaplayabilir. Varsayılan ayarlarla her gün yaklaşık 20-50 MB arasında veri birikir. Bunu kontrol altında tutmak için:

# Log boyutlarını kontrol et
du -sh /var/log/atop/*

# Eski logları temizle (30 günden eski olanlar)
find /var/log/atop/ -name "atop_*" -mtime +30 -delete

atop servisinin kendisi de log rotasyonu için bir script içerir. /etc/cron.d/atop veya /usr/share/atop/atop.daily dosyasını inceleyerek rotasyon politikasını özelleştirebilirsiniz.

# Saklama süresini 14 güne düşür
# /etc/default/atop veya /etc/sysconfig/atop dosyasında
LOGGENERATIONS=14

Prometheus ve Grafana ile Entegrasyon

Modern gözlemlenebilirlik (observability) altyapısında atop verilerini Prometheus’a aktarmak için atop-exporter gibi araçlar kullanılabilir. Ancak basit bir yöntem olarak atop çıktısını parse edip Prometheus text format’a çeviren kendi scripti yazmak da mümkündür:

#!/bin/bash
# Basit atop metrik exporter

METRICS_FILE="/var/lib/node_exporter/textfile_collector/atop_metrics.prom"

CPU_DATA=$(atop -P CPU 1 1 2>/dev/null | grep "^CPU" | head -1)
MEM_DATA=$(atop -P MEM 1 1 2>/dev/null | grep "^MEM" | head -1)

CPU_USR=$(echo "$CPU_DATA" | awk '{print $5}')
CPU_SYS=$(echo "$CPU_DATA" | awk '{print $6}')
MEM_USED=$(echo "$MEM_DATA" | awk '{print $5}')
MEM_TOTAL=$(echo "$MEM_DATA" | awk '{print $3}')

cat > "$METRICS_FILE" << EOF
# HELP atop_cpu_user_percent CPU user time percentage
# TYPE atop_cpu_user_percent gauge
atop_cpu_user_percent $CPU_USR

# HELP atop_cpu_system_percent CPU system time percentage
# TYPE atop_cpu_system_percent gauge
atop_cpu_system_percent $CPU_SYS

# HELP atop_memory_used_bytes Memory used in bytes
# TYPE atop_memory_used_bytes gauge
atop_memory_used_bytes $MEM_USED

# HELP atop_memory_total_bytes Total memory in bytes
# TYPE atop_memory_total_bytes gauge
atop_memory_total_bytes $MEM_TOTAL
EOF

Bu scripti cron’a ekleyerek Prometheus’un node_exporter textfile_collector dizinine düzenli metrikler yazabilirsiniz.

Performans Karşılaştırması: atop vs Alternatifleri

Sıkça sorulan soruya direkt cevap vereyim: ne zaman atop, ne zaman başka bir şey kullanmalısınız?

  • Anlık basit izleme: top veya htop yeterli, atop’a gerek yok
  • Geçmiş analizi ve post-mortem: atop’un rakibi yok, alternatif olarak sar kullanılabilir ama daha az detaylıdır
  • Uzun vadeli trend analizi ve görselleştirme: Prometheus + Grafana daha iyi, ancak atop ile birlikte kullanılabilir
  • Container ortamları: cAdvisor daha uygun, atop container metrikleri için ek konfigürasyon gerektirir
  • Kernel level I/O analizi: iostat, iotop veya blktrace daha derine iner

atop’un yerini doldurmak zor çünkü kurulumu son derece basit ve ek bir altyapı gerektirmiyor. Bir sisteme ssh açtığınızda atop kuruluysa ve servisi çalışıyorsa, o sistemin geçmişine bakabilirsiniz. Bu basitlik çok değerlidir.

atop Konfigürasyon İpuçları

Bazı ince ayarlar günlük kullanımı önemli ölçüde kolaylaştırır:

# ~/.atoprc dosyası ile kişisel ayarlar
# Varsayılan sıralama belleğe göre olsun
sortorder m

# Renk eşiklerini özelleştir (yüzde cinsinden)
cpucritical 80
memcritical 85
dskcritical 70

# Çıkmadan önce onay isteme

Kritik sistemler için atop alarmı oluşturmak da mümkündür. Örneğin bellek kullanımı belirli bir eşiği aştığında mail atmak:

#!/bin/bash
# /usr/local/bin/atop-alert.sh

THRESHOLD=90
MEM_DATA=$(atop -P MEM 1 1 2>/dev/null | grep "^MEM" | head -1)
MEM_USED=$(echo "$MEM_DATA" | awk '{print $5}')
MEM_TOTAL=$(echo "$MEM_DATA" | awk '{print $3}')
MEM_PCT=$(echo "scale=0; $MEM_USED * 100 / $MEM_TOTAL" | bc)

if [ "$MEM_PCT" -gt "$THRESHOLD" ]; then
    echo "UYARI: $(hostname) sunucusunda bellek kullanimi $MEM_PCT% seviyesinde!" | 
    mail -s "Kritik Bellek Uyarisi - $(hostname)" [email protected]
fi

Bu scripti 5 dakikada bir cron’dan çalıştırmak için:

*/5 * * * * root /usr/local/bin/atop-alert.sh

Sonuç

atop, sistem yöneticiliği araç kutusunun vazgeçilmez parçalarından biridir. Kurulumu beş dakika, öğrenmesi ise bir-iki saat sürer; ancak sağladığı değer bununla kıyaslanamaz. Özellikle Türkiye’deki kurumsal ortamlarda gördüğüm en büyük eksiklik, performans sorunlarının geçmişe dönük analiz edilememesi. “Dün bir şeyler oldu ama ne olduğunu bilmiyoruz” durumu, atop servisi aktif olan bir sistemde yaşanmaz.

Yapmanız gereken minimum şey şu: yönettiğiniz her Linux sunucusuna atop kurun, servisi etkinleştirin ve log rotasyonunu makul bir süreye (14-30 gün) ayarlayın. Bu kadar. Geri kalanını sorun çıktığında öğrenirsiniz; çünkü o gün elinizdeki veri sizi kurtaracak.

Bir de şunu ekleyeyim: atop verilerini düzenli olarak inceleme alışkanlığı edinin, sadece sorun çıktığında değil. Haftalık beş dakikanızı geçen haftanın atop loglarına ayırırsanız, büyük problemleri çıkmadan önce fark etmeye başlarsınız. Bu reaktif olmaktan proaktif olmaya geçişin en basit yollarından biridir.

Bir yanıt yazın

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