Teknoloji

VPS Kaynak Kullanımı İzleme Rehberi: htop, iotop, Netdata ve Prometheus

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.

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 < 10GiB ve 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_total ve 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.

Sıkça Sorulan Sorular

En basit başlangıç, SSH ile VPS’inize bağlanıp htop ve iotop gibi komut satırı araçlarını kurmakla başlar. htop ile CPU, RAM, yük (load average) ve süreç bazlı kaynak tüketimini anında görebilirsiniz. iotop ise hangi süreçlerin disk okuma/yazma yaptığını gösterir; böylece veritabanı, yedekleme veya log’ların diski ne kadar zorladığını hızlıca tespit edersiniz. Bu ilk adım, "sorun CPU’da mı, RAM’de mi, disk IO’da mı?" sorusuna dakikalar içinde cevap vermenizi sağlar. Sonrasında ihtiyaç oldukça Netdata veya Prometheus gibi daha gelişmiş çözümlere geçebilirsiniz.

Netdata ve Prometheus birbirinin rakibi değil, farklı ihtiyaçlara cevap veren araçlardır. Netdata tek VPS veya birkaç sunucuyu anlık, grafiksel olarak izlemek için idealdir; kurulumu kolaydır ve saniye hassasiyetinde görselleştirme sunar. Ancak onlarca VPS’iniz varsa, uzun dönem metrik saklamak, gelişmiş alarm kuralları yazmak ve esnek dashboard’lar tasarlamak istiyorsanız Prometheus + Grafana mimarisi çok daha güçlüdür. Özetle: küçük-orta ölçekte hızlı başlangıç için Netdata, büyüyen altyapılar ve çoklu VPS için Prometheus tercih etmeniz gereken çözümdür; ikisini aynı anda da kullanabilirsiniz.

Genel olarak şu metriklere alarm koymanız tavsiye edilir: CPU için son 5–15 dakikanın ortalaması %80–90 üzerindeyse uyarı, %95+ ise kritik alarm. RAM tarafında kullanılan bellek toplam RAM’in %80’ini aşmaya başladığında ve swap devreye girdiğinde mutlaka alarm üretmelisiniz. Disk için doluluk oranı %80’e yaklaştığında uyarı, %90 üzerinde ise kritik alarm mantıklıdır. Ayrıca disk IO kuyruğu ve IOPS değerlerini, network tarafında ise arayüz bazlı trafik ve TCP bağlantı sayısını izlemek faydalıdır. Bu eşiği Prometheus alert kuralları veya benzer çözümlerle tanımlayıp e-posta ya da chat kanallarına bildirim gönderebilirsiniz.

CPU, RAM ve disk IO metrikleriniz normal görünüyorsa, sorun uygulama seviyesinde veya veritabanı tarafında olabilir. İlk adım olarak web sunucusu (Nginx/Apache) ve veritabanı (MySQL/MariaDB/PostgreSQL) log’larını inceleyin; yavaş sorgular, hatalar veya yeniden denemeler görebilirsiniz. Ardından uygulama tarafında önbellekleme (OPcache, Redis, tam sayfa cache) ve PHP-FPM ayarlarını gözden geçirin. Özellikle WordPress ve WooCommerce siteleri için doğru PHP-FPM ve cache ayarları büyük fark yaratır. Dilerseniz DCHost blogunda yer alan CPU/IO/MySQL darboğazı, PHP-FPM tuning ve veritabanı optimizasyonu makalelerinden yararlanarak sorunu daha detaylı teşhis edebilirsiniz.

Genellikle hayır; DCHost VPS’ler standart Linux dağıtımlarıyla gelir ve htop, iotop, Netdata, Prometheus exporter’ları gibi araçları paket yöneticisiyle doğrudan kurabilirsiniz. Dikkat etmeniz gereken noktalar; firewall (güvenlik duvarı) ayarlarının doğru yapılması, özellikle Netdata ve exporter portlarının doğrudan internete açılmaması ve mümkünse VPN veya IP kısıtlamasıyla korunmasıdır. Prometheus ve Grafana’yı ayrı bir izleme VPS’i üzerinde koşturmak da iyi bir pratiktir. Kurulum sırasında takıldığınız noktalarda DCHost destek ekibimiz, temel güvenlik ve erişim ayarları konusunda size rehberlik edebilir.