VPS’iniz zaman zaman yavaşlıyor, ama sorunun CPU’dan mı, RAM’den mi, disk IO’dan mı yoksa ağ trafiğinden mi kaynaklandığını net göremiyor musunuz? Proje planlama toplantısında kaç vCPU’ya, ne kadar RAM’e ihtiyacınız olduğunu tartışırken, elinizde somut metrikler olsun istiyorsanız doğru yerdesiniz. Bu rehberde, komut satırından grafik panellere kadar farklı seviyelerde VPS kaynak kullanımı izleme yöntemlerini adım adım ele alacağız.
DCHost altyapısında her gün onlarca VPS’i izlerken en çok işimize yarayan araçlar; hızlı teşhis için htop ve iotop, tek VPS’i görsel olarak takip etmek için Netdata, çoklu VPS ve ileri seviye senaryolar için de Prometheus ve exporter’lar oluyor. Burada da aynı yaklaşımı paylaşacağız: önce anlık teşhis, ardından sürekli izleme ve alarm katmanı. Böylece ister tek bir WordPress sitesi, ister WooCommerce mağazası, ister küçük bir SaaS uygulamanız olsun, VPS’inizde neler olup bittiğini net rakamlarla görebileceksiniz.
Anlatım boyunca hem pratik komut örnekleri vereceğiz, hem de gerçekçi senaryolardan bahsedeceğiz. Ayrıca CPU, IO ve MySQL darboğazlarını derinlemesine incelemek isterseniz CPU, IO ve MySQL darboğazı teşhisi rehberimizi de mutlaka gözden geçirmenizi öneririz.
İçindekiler
- 1 VPS’te İzlemeniz Gereken Temel Kaynaklar
- 2 Komut Satırında Hızlı Teşhis: htop ile CPU ve RAM Analizi
- 3 Disk IO Darboğazlarını Bulmak: iotop ve Temel IO Metrikleri
- 4 Anlık Görsel Gösterge Paneli: Netdata ile Tek VPS’i İzlemek
- 5 Çoklu VPS ve Ölçekli Senaryolar: Prometheus ile Metrik Toplama
- 6 Network ve TCP Seviyesinde Ekstra İpuçları
- 7 Metrikleri Operasyon Süreçlerine Bağlamak
- 8 Sonuç ve Sonraki Adımlar
VPS’te İzlemeniz Gereken Temel Kaynaklar
İzleme araçlarına geçmeden önce, hangi metriklere baktığımızı netleştirelim. Aksi halde htop’ta renkli grafikler görürsünüz ama ne anlama geldiğini çıkarmak zor olur.
CPU kullanım oranı ve load average
CPU kullanımı, işlemcinin ne kadar meşgul olduğunu gösterir. Ancak tek başına yüzdeye bakmak yanıltıcı olabilir. Önemli noktalar:
- %user: Uygulama kodlarınızın (PHP, Node.js, Java vb.) tükettiği CPU.
- %system: Kernel tarafında harcanan CPU (ağ, disk, sistem çağrıları).
- %steal: Sanallaştırma ortamında başka VPS’lerin sizden çaldığı CPU süresi. Düşük olmalı.
load average ise CPU kuyruğundaki iş sayısını gösterir. Genel kural: 1 vCPU’lu bir VPS için load 1’in üstüne uzun süre çıkıyorsa, kuyruk oluşuyordur. 4 vCPU’lu bir VPS’te load 4–5 civarı genelde kabul edilebilir, ama 10+ seviyeleri alarmdır.
RAM kullanımı ve swap
RAM yetmezse, kernel verileri diske swap eder; bu da gecikmeleri katlar. Dikkat etmeniz gerekenler:
- Uygulamaların gerçekten kullandığı RAM (resident memory).
- Disk cache alanı (boş RAM’i kullanan faydalı cache, her doluluk kötü değildir).
- Swap kullanım oranı ve swap-in/out hızları.
Sürekli artan swap kullanımı, VPS planınızı büyütmeniz gerektiğinin en net sinyallerinden biridir. Bu konuda daha geniş perspektif için yeni web sitesinde CPU ve RAM ihtiyacını hesaplama rehberimize de göz atabilirsiniz.
Disk IO, IOPS ve doluluk oranı
Disk tarafında iki temel metrik vardır:
- IOPS (Input/Output Operations Per Second): Saniyedeki IO işlemi sayısı.
- Throughput (MB/s): Saniyedeki veri aktarım miktarı.
Veritabanı ağırlıklı uygulamalarda IOPS kritik, büyük dosya transferlerinde throughput daha kritiktir. Buna ek olarak disk doluluk oranını mutlaka izlemelisiniz; %90+ seviyeleri hem performansı düşürür hem de log’lar yüzünden “No space left on device” hataları almanıza sebep olur. Bu konuyu detaylı anlattığımız VPS disk kullanımı ve logrotate ayarları rehberini mutlaka okumanızı öneririm.
Ağ trafiği, bağlantı sayısı ve gecikme
Ağ tarafında bakmanız gereken başlıca metrikler şunlardır:
- Giden ve gelen trafik hızı (Mb/s veya KB/s).
- Açık TCP bağlantı sayısı ve durumları (ESTABLISHED, TIME_WAIT vb.).
- Paket kaybı ve RTT (ping gecikmesi).
Özellikle kampanya dönemlerinde anlık trafik patlamalarında, network metrikleri ile CPU ve disk IO’yu birlikte görmek, gerçek darboğazı bulmanızı kolaylaştırır.
Komut Satırında Hızlı Teşhis: htop ile CPU ve RAM Analizi
VPS’e SSH ile bağlanıp ilk bakmanız gereken araçlardan biri htop’tur. Klasik top komutunun daha okunabilir, renkli ve etkileşimli halidir.
htop kurulumu
- Debian/Ubuntu tabanlı VPS’lerde:
apt update && apt install htop -y - AlmaLinux/Rocky/CentOS tabanlı VPS’lerde:
yum install htop -y
htop ekranını doğru okumak
htop yazıp çalıştırdığınızda üst kısımda CPU, RAM ve swap kullanım çubuklarını, aşağıda ise süreç listesini görürsünüz. Dikkat etmeniz gereken ana noktalar:
- CPU barları: Her vCPU çekirdeği ayrı gösterilir. Birkaç çekirdeğin sürekli %90+ olması, kod veya sorgu tarafında darboğaz işaretidir.
- Load average: Sağ üstte genelde 1, 5 ve 15 dakikalık load değerleri bulunur.
- MEM ve SWAP: RAM kullanımının tavan yapması ve swap’in devreye girmesi performans düşüşü demektir.
Alt tarafta süreç listesinde CPU% ve MEM% kolonlarına göre sıralama yaparak en çok kaynağı tüketen süreçleri anında bulabilirsiniz. F6 tuşu ile görünen kolonları özelleştirebilir, IO ile ilgili alanları da ekleyebilirsiniz.
htop ile örnek bir senaryo: WooCommerce kampanyası
Örneğin, DCHost üzerindeki bir VPS’te WooCommerce mağazası çalıştıran bir müşterimizi düşünelim. Kampanya saatlerinde site yavaşlıyor, ancak neden belli değil. htop’ta baktığımızda:
- Load average: 1 vCPU’lu VPS’te 3–4 seviyelerine çıkmış.
- PHP-FPM süreçleri CPU’yu %90 üstü kullanıyor.
- RAM %80 civarında, ama swap kullanılmıyor.
Bu durumda asıl sorun CPU darboğazı gibi görünür. Çözüm olarak geçici kampanya süresince VPS’i daha yüksek vCPU’lu bir plana taşımak veya PHP-FPM ve önbellekleme ayarlarını optimize etmek gerekir. Bu optimizasyonları detaylı anlattığımız PHP-FPM ayar rehberine göz atabilirsiniz.
Disk IO Darboğazlarını Bulmak: iotop ve Temel IO Metrikleri
CPU ve RAM tarafı sağlıklı görünmesine rağmen siteniz yavaş açılıyorsa, büyük ihtimalle disk IO tarafında sorun vardır. Özellikle veritabanı ve log yazma trafiği yoğun sitelerde bu çok sık karşımıza çıkar.
iotop kurulumu
- Debian/Ubuntu:
apt update && apt install iotop -y - AlmaLinux/Rocky/CentOS:
yum install iotop -y
iotop çalıştırabilmek için genellikle root olmanız veya gerekli yetkiye sahip olmanız gerekir.
iotop çıktısını yorumlamak
iotop komutunu verdiğinizde, süreç bazlı disk IO kullanımını görürsünüz. Ana kolonlar:
- DISK READ ve DISK WRITE: Sürecin saniyede ne kadar veri okuduğu veya yazdığı.
- SWAPIN: Sürecin swap’ten ne kadar veri okuduğu; yüksekse RAM yetmiyor demektir.
- IO%: Sürecin ne kadar IO beklediğini gösterir; yüksek IO% genelde disk kuyruğu anlamına gelir.
Örneğin MySQL sürecinin DISK WRITE kolonunda sürekli yüksek değerler görüyorsanız, veritabanı sorgularınız ağır çalışıyor olabilir veya log seviyeniz çok ayrıntılı ayarlanmıştır.
Disk doluluğu ve log kaynaklı sorunlar
Disk sadece IO’dan değil, kapasite doluluğundan da yavaşlar. SSH üzerinden şu komutlar ile hızlı kontrol yapabilirsiniz:
df -h
%90 üzeri doluluk özellikle / veya /var bölümlerinde ise tehlikelidir. Çoğu zaman sebep kontrolsüz büyüyen log dosyalarıdır. Bu durumda logrotate ayarlarını elden geçirmek şart olur. Adım adım örneklerle anlattığımız logrotate ile disk doluluk sorunlarını önleme rehberini burada yeniden hatırlatmakta fayda var.
Anlık Görsel Gösterge Paneli: Netdata ile Tek VPS’i İzlemek
Komut satırında teşhis yapmak hızlıdır, ancak uygulama sahibine veya ekip arkadaşlarınıza durumu anlatmak için görsel panellere ihtiyaç duyarsınız. Bu noktada Netdata, tek VPS’i detaylı ve etkileşimli grafiklerle izlemek için oldukça pratik bir çözümdür.
Netdata kurulumu (temel örnek)
Resmi kurulum komutu zamanla değişebildiği için her zaman Netdata’nın dokümantasyonuna bakmakta fayda var, ancak tipik bir kurulum:
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
Kurulum sonrası sunucunuzda genelde 19999 portundan çalışan bir Netdata arayüzü açılır: http://sunucu-ip:19999. Güvenlik için bu portu doğrudan internete açmamanız, ya VPN üzerinden erişmeniz ya da HTTP auth / IP kısıtlaması yapmanız gerekir.
Netdata’da görebileceğiniz temel paneller
Netdata arayüzünde aşağıdaki metrikleri grafiklerle, saniye hassasiyetinde görebilirsiniz:
- CPU: Çekirdek bazlı kullanım, steal time, context switch sayıları.
- RAM ve swap: Kullanılan, cache edilen, boş RAM ile swap hareketleri.
- Disk IO: Okuma/yazma hızları, IO kuyruğu, IOPS.
- Network: Arayüz bazlı trafik, paket sayıları, hata oranları.
- Uygulama spesifik metrikler (Nginx, Apache, MySQL vb. için hazır paneller).
Örneğin DCHost üzerinde çalışan bir WooCommerce mağazasında, Netdata üzerinden kampanya saatlerinde CPU’nun nasıl pik yaptığını, MySQL sorgu sayılarının nasıl arttığını ve disk IO eğrisinin nasıl değiştiğini tek ekranda görebilirsiniz. Bu görseller, ekip içi performans analizi toplantılarında çok işimize yarıyor.
Netdata ne zaman yeterli, ne zaman yetmez?
Netdata tek VPS veya birkaç sunucu için ideal bir “hemen-kur-kullan” çözümüdür. Ancak:
- Onlarca VPS’iniz varsa,
- Uzun süreli metrik saklamak istiyorsanız (aylarca-yıllarca),
- Gelişmiş alarm kuralları ve dashboard’lar tasarlamak istiyorsanız,
o noktada bir metrik toplama ve sorgulama sistemi olan Prometheus gibi çözümlere geçmeniz gerekir. Birazdan bu yapıyı da ele alacağız.
Çoklu VPS ve Ölçekli Senaryolar: Prometheus ile Metrik Toplama
Birden fazla VPS, ayrı veritabanı sunucuları, cache katmanı, arka plan işleyicileri (queue workers) devreye girdiğinde, tek bir panel yeterli olmamaya başlar. İşte burada Prometheus + exporter mimarisi devreye girer.
Prometheus mimarisine hızlı bakış
Basitleştirerek şöyle anlatabiliriz:
- Her VPS’e Node Exporter gibi küçük bir ajan kurarsınız.
- Bu ajan, CPU, RAM, disk, network ve sistem metriklerini HTTP üzerinden metrik formatında sunar.
- Merkezi bir Prometheus sunucusu belirli aralıklarla bu endpoint’leri “scrape” eder ve metrikleri kendi zaman serisi veritabanına yazar.
- Görsel paneller için genelde Grafana kullanılır.
Bu yapıyı adım adım uygulamalı olarak görmek isterseniz, hazırladığımız Prometheus ve Grafana ile VPS izleme başlangıç rehberini inceleyebilirsiniz.
Node Exporter ile temel VPS metrikleri
Node Exporter, Linux VPS’ler için en temel exporter’dır. Başlıca metrikler:
- CPU kullanım oranları, context switch, load average.
- RAM, swap, file cache, page fault metrikleri.
- Disk IO, IOPS, disk doluluk oranları.
- Network trafiği, TCP bağlantı sayıları, hata oranları.
Prometheus + Grafana ile şu tip grafikler hazırlayabilirsiniz:
- Son 30 gündeki CPU kullanım yüzdesi ve load grafiği.
- Disk doluluk oranının zaman içindeki değişimi; %80’i geçtiğinde alarm.
- Ağ trafiği piklerini saatlik veya günlük olarak gösteren grafikler.
Alarm kuralları: Sorun çıkmadan uyarı almak
Sadece grafik görmek çoğu zaman yeterli değildir; problem büyümeden haberiniz olmalı. Prometheus tarafında alerting rules yazarak şu tip kurallar oluşturabilirsiniz:
node_filesystem_avail_bytes < 10GiBve durum 15 dakikadan uzun sürüyorsa “Disk %85’e dayandı” alarmı.- Son 5 dakikada CPU kullanım ortalaması %90 üzerindeyse “CPU darboğazı” alarmı.
- Swap kullanımı belirli bir eşiği geçtiğinde “RAM yetmiyor” uyarısı.
Bu alarmları e-posta, Slack, Telegram gibi kanallara bağlayabilirsiniz. DCHost olarak kendi altyapımızda da benzer kurallar kullanıyor, kritik eşiklere gelinmeden aksiyon alıyoruz. Daha gelişmiş senaryolar için Prometheus, Grafana ve Node Exporter ile uyarı kurma rehberimizi inceleyebilirsiniz.
Network ve TCP Seviyesinde Ekstra İpuçları
Kaynak izlerken çoğu kişi CPU ve diskten öteye bakmıyor, ama özellikle yüksek trafikli WordPress/Laravel sitelerinde network ve TCP ayarları ciddi fark yaratıyor.
Bağlantı sayıları ve TIME_WAIT seli
Aşağıdaki komutlarla kabaca bağlantı durumlarını görebilirsiniz:
ss -s
ss -ant | head -n 20
Çok sayıda TIME_WAIT bağlantı görüyorsanız, yoğun kısa ömürlü HTTP bağlantıları veya eksik keep-alive ayarları olabilir. Nginx/Apache tarafında keep-alive ve timeout ayarlarını gözden geçirmek, TCP tuning yapmak (örneğin net.core.somaxconn, net.ipv4.ip_local_port_range gibi) gerekebilir. Bu alanda daha derine inmek isterseniz, Linux TCP tuning rehberimiz size iyi bir başlangıç sağlar.
Network metriklerini Prometheus ile izlemek
Node Exporter üzerinden şu metrikleri izlemek özellikle faydalıdır:
node_network_receive_bytes_total/node_network_transmit_bytes_total: Gelen/giden trafik.node_netstat_Tcp_CurrEstab: Aktif TCP bağlantı sayısı.node_network_receive_errs_totalve benzeri hata sayaçları.
Bu metrikler sayesinde kampanya veya saldırı dönemlerinde gerçek durumu sayılarla görebilir, örneğin DDoS atağı ile organik trafik artışını birbirinden ayırabilirsiniz.
Metrikleri Operasyon Süreçlerine Bağlamak
İzleme araçlarını kurup birkaç grafik açmak güzel; ama asıl değer, bu metrikleri karar süreçlerinize bağladığınızda ortaya çıkar. DCHost olarak müşterilerle yaptığımız kapasite ve mimari değerlendirme görüşmelerinde genelde şu soruları soruyoruz:
- Son 30 günde CPU kullanımınız düzenli olarak %70+ seviyelerine çıkıyor mu?
- RAM kullanımı sürekli tavan yapıp swap’e düşüyor mu?
- Disk doluluk oranı son dönemde hızla artıyor mu?
- Ağ trafiği piklerinde latency ciddi şekilde yükseliyor mu?
Bu soruların cevabını Prometheus grafikleri veya Netdata panelleri ile verebiliyorsanız, “VPS planını büyütmeli miyiz, ayrı bir veritabanı sunucusuna mı geçmeliyiz, yoksa sadece uygulamayı optimize etmek mi yeterli?” gibi kararları çok daha sağlıklı alırsınız. Örneğin veritabanı yükünüz tutarlı şekilde artıyorsa, veritabanını uygulama sunucusundan ayırma zamanının gelip gelmediğini değerlendirebilirsiniz.
Benzer şekilde, log miktarınız ve disk yazma trafiğiniz artıyorsa, merkezi loglama çözümlerine (örneğin Loki veya ELK stack) geçmeyi düşünebilirsiniz. Bu konuda adım adım rehber arıyorsanız, VPS log yönetimi ve Loki rehberimize göz atmanızda fayda var.
Sonuç ve Sonraki Adımlar
VPS kaynak kullanımı izleme konusu ilk bakışta karmaşık görünebilir; ama doğru adımlarla ilerlediğinizde oldukça yönetilebilir hale gelir. Komut satırında htop ve iotop ile anlık teşhis, Netdata ile tek VPS’i görsel olarak takip etme ve Prometheus ile çoklu VPS / uzun dönem metrik toplama yaklaşımını birleştirdiğinizde, artık “Sunucu niye yavaş?” sorusunu tahmine değil, verilere dayalı olarak cevaplayabilirsiniz.
DCHost olarak kendi altyapımızda da benzer bir katmanlı izleme mimarisi kullanıyoruz: önce temel metrikler, ardından gelişmiş alarm kuralları ve gerektiğinde merkezi loglama ile derin analiz. Siz de VPS’inizde bu adımları uygulamaya başlarken, Prometheus ve Grafana başlangıç rehberimizden veya ileri uyarı senaryolarından yararlanabilirsiniz.
Eğer DCHost üzerinde bir VPS kullanıyorsanız ve metriklere baktığınız halde yorumlamakta zorlanıyorsanız, destek ekibimizle iletişime geçmekten çekinmeyin. CPU, RAM, IO ve network verilerine birlikte bakıp, gerekirse plan yükseltme, mimari iyileştirme veya uygulama tarafı optimizasyonu konusunda size yol haritası çizebiliriz. Böylece hem performans problemlerini erkenden yakalar, hem de kaynaklarınızı gereksiz yere şişirmeden, kontrollü şekilde büyüyebilirsiniz.
