VPS Kaynak İzleme: 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.

Bu rehberde hızlı teşhis için htop ve iotop, görsel metrik takibi için Netdata, çoklu VPS ve ileri seviye senaryolar için de Prometheus ve exporter’ları ele alacağız. Yaklaşımımı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: Kullanıcı alanında uygulamaların yürüttüğü işler için CPU süresi.
• %system: Kernel ve sistem çağrıları için CPU süresi.
• %steal: Sanallaştırmada vCPU’nun host/hypervisor tarafından çalıştırılmadığı istem dışı bekleme süresi. Sürekliliğini gecikme ve işlemci yüküyle birlikte inceleyin; tek başına belirli bir komşu VPS’i veya nedeni göstermez.

Linux load average, 1, 5 ve 15 dakikada çalışabilir görevlerin ve kesilemeyen beklemedeki görevlerin ortalamasıdır; ikinci grup çoğunlukla I/O bekler. Load 4, dört vCPU’nun mutlaka dolu olduğunu göstermez. vCPU sayısını bağlam olarak kullanın, ardından CPU modlarını, I/O gecikmesini ve uygulama yanıt süresini karşılaştırın. Container veya CPU kotası varsa görünen vCPU sayısı tek başına kullanılabilir kapasiteyi anlatmayabilir.

RAM kullanımı ve swap

RAM yetersizliğinde, yapılandırılmışsa swap kullanılabilir; yoğun disk tabanlı swap trafiği gecikmeleri artırabilir. Dikkat etmeniz gerekenler:

• MemAvailable: Yeni uygulamalara swap yapmadan ayrılabilecek belleğin tahmini; düşük boş RAM’i cache’den ayırmaya yardımcı olur.
• Resident bellek (RES/RSS): Sürecin RAM’deki sayfalarıdır; paylaşılan sayfalar nedeniyle süreçlerin RES değerlerini toplamak gerçek toplamı aşabilir.
• Cache ve swap: Cache genellikle yararlıdır. Swap doluluğunu, swap-in/out hızlarını, OOM olaylarını ve uygulama gecikmesini birlikte izleyin. Varsa /proc/pressure/memory bellek yüzünden beklemeyi gösterir.

Sürekli artan swap kullanımı bellek baskısını araştırmak için bir işarettir; tek başına VPS planını büyütme kararı için yeterli değildir. Swap-in/out hızlarını, uygulamaların bellek tüketimini ve gecikmeleri birlikte değerlendirerek optimizasyon veya ek RAM ihtiyacını belirleyin. 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 izlenecek temel metrikler şunlardır:

• IOPS (Input/Output Operations Per Second): Saniyedeki IO işlemi sayısı.
• Throughput (MB/s): Saniyedeki veri aktarım miktarı.
• Gecikme ve kuyruk: Throughput veya IOPS tek başına doygunluk değildir. Okuma/yazma gecikmesini ve iş yükünü karşılaştırın. Linux iowait CPU’nun fiziksel olarak bloke olması değildir; muhasebe kısıtları nedeniyle tek başına tanı koydurmaz.

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+ doluluk, kalan alanı ve büyüme hızını kontrol etmek için bir uyarıdır; tek başına performans kaybı veya hata oluştuğunu göstermez. Log’lar gibi büyüyen dosyalar kalan alanı tüketirse “No space left on device” hatasıyla karşılaşabilirsiniz. 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).
• TCP bağlantılarının sayısı ve durum dağılımı (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

Paket kurulumları root veya sudo yetkisi gerektirir. Aşağıdaki örnekler Ubuntu 24.04 LTS ve AlmaLinux 9 içindir. Diğer Debian/Ubuntu veya Rocky Linux sürümlerinde destek durumunu ve paket depolarını kendi dağıtımınızın belgelerinden doğrulayın.

• Ubuntu 24.04 LTS:

  sudo apt update
  sudo apt install htop

• AlmaLinux 9: Önce dağıtımın EPEL ve CRB yönergelerini uygulayın; htop EPEL paketidir. Depolar etkinleştirildikten sonra:

  sudo dnf install htop

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ı: Yapılandırmaya göre vCPU başına kullanım gösterilebilir. Bir veya birkaç vCPU’nun sürekli %90+ kullanılması, CPU tarafını incelemek için bir işarettir; tek başına kod ya da sorgu hatasını kanıtlamaz.
• Load average: Sağ üstte genelde 1, 5 ve 15 dakikalık load değerleri bulunur.
• MEM ve SWAP: Yüksek RAM kullanımını cache, swap-in/out hızları ve uygulama gecikmeleriyle birlikte değerlendirin; swap alanının kullanılıyor olması tek başına performans düşüşünü kanıtlamaz.

F6 sıralama alanını seçer; CPU% veya MEM% ile öne çıkan süreçleri inceleyin. Görünen kolonları ve üstteki göstergeleri değiştirmek için F2 (Setup) ekranını kullanın. F3 komut satırında arama, F4 filtreleme, F5 süreç ağacını açma/kapatma içindir. Göstergeler sürüm ve yapılandırmaya bağlıdır; htop tek başına bir SQL sorgusunu veya yavaş isteği kanıtlamaz.

htop ile örnek bir senaryo: WooCommerce kampanyası

Varsayımsal bir örnekte, bir VPS’te çalışan WooCommerce mağazasının kampanya saatlerinde yavaşladığını düşünelim. htop’ta şu değerlerin görüldüğünü varsayalım:

• 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 varsayımsal durumda CPU darboğazı olasıdır. Gecikmelerin CPU yüküyle birlikte arttığı doğrulanırsa, kampanya süresince daha yüksek vCPU’lu bir plan veya PHP-FPM ve önbellekleme ayarlarının optimizasyonu değerlendirilebilir. 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, disk IO incelenmesi gereken olası nedenlerden biridir. Özellikle veritabanı ve log yazma trafiği yoğun sitelerde disk metriklerine bakmak yararlıdır; ağ ve uygulama bağımlılıklarını da dışlamamak gerekir.

iotop kurulumu

Bu rehberde C ile yazılmış iotop-c kullanılıyor. Eski Python iotop ile paket/özellik farkları olabilir; kurulu uygulamayı iotop --version ve iotop --help ile doğrulayın. Kurulum root/sudo gerektirir.

• Ubuntu 24.04 LTS: iotop-c paketinin bulunduğu Universe deposu etkin olmalıdır.

  sudo apt update
  sudo apt install iotop-c

• AlmaLinux 9: Önce EPEL ve CRB depolarını dağıtım yönergeleriyle hazırlayın.

  sudo dnf install iotop-c

İzleme için sudo iotop kullanın. Kernel’de CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING ve CONFIG_VM_EVENT_COUNTERS desteği gerekir. sysctl kernel.task_delayacct mevcut durumu okur. Delay accounting kapalıysa bekleme yüzdelerini yorumlamayın; açma kararını sistem yöneticisi vermeli, ek maliyeti ölçmeli ve önceki ayarı kaydetmelidir. Linux belgelerine göre sonradan etkinleştirildiğinde yalnız bundan sonra başlayan görevler için delay bilgisi oluşur. VPS/container yetki veya kernel kısıtları ölçümü engelleyebilir.

iotop çıktısını yorumlamak

sudo iotop etkileşimli görünümü açar. Sınırlı bir metin örneği almak için sudo iotop -b -o -P -n 10 -d 1 kullanılabilir: -b batch, -o I/O etkinliği olanlar, -P süreç toplamları, -n 10 on yineleme, -d 1 bir saniyelik aralıktır. Bu örnek hızları gösterir. -a birikimli miktarı seçer ve batch anlamına gelmez; birikimin başlangıcı sürüme göre kontrol edilmelidir. Ana kolonlar:

• DISK READ / DISK WRITE: Normal modda örnekleme aralığındaki süreç/thread okuma-yazma hızı. Cache ve yazma sıralaması nedeniyle süreç toplamı ile fiziksel diskin o anki aktarımı aynı olmayabilir.
• SWAPIN: Görevin swap-in bekleyerek geçirdiği zamanın yüzdesi; byte miktarı değildir.
• IO%: Görevin I/O bekleme zamanının yüzdesi; aygıtın kullanım yüzdesi veya kuyruk uzunluğu değildir. Yüksek değerleri aygıt gecikmesi, uygulama etkisi ve bellek baskısıyla ilişkilendirin.

Örneğin MySQL sürecinin DISK WRITE kolonunda sürekli yüksek değerler görüyorsanız, bunun normal yazma yükünden mi, yoğun sorgulardan mı yoksa ayrıntılı loglamadan mı kaynaklandığını araştırın. Yüksek yazma hızı tek başına sorguların yavaş çalıştığını göstermez.

Disk doluluğu ve log kaynaklı sorunlar

Disk kapasitesinin dolması da uygulama sorunlarına yol açabilir. SSH üzerinden şu komutlarla dosya sistemlerinin alan ve inode kullanımını hızlıca kontrol edebilirsiniz:

df -h
df -i

Özellikle / veya /var bölümlerinde %90 üzeri doluluk varsa kalan alanı ve büyüme hızını inceleyin. Alanı hangi dosyaların tükettiğini belirleyin; neden kontrolsüz büyüyen log dosyalarıysa logrotate ayarlarını gözden geçirin. Adım adım örneklerle anlattığımız logrotate ile disk doluluk sorunlarını önleme rehberini burada yeniden hatırlatmakta fayda var. Boş byte olsa da inode tükenebilir; yazılabilir bağlama durumunu, kotayı, kalan alanı ve dolma hızını da kontrol edin.

Netdata ile Görsel Kaynak İzleme

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)

Güncel resmî kurulum adresi https://get.netdata.cloud/kickstart.sh adresidir. Önce resmî Linux kurulum kılavuzunu ve mevcut kurulum türünü kontrol edin. Kurucu hizmeti başlatabileceğinden kurulumdan önce VPS ve sağlayıcı güvenlik duvarında 19999 portunu genel erişime kapatın. Kendinize ait boş bir çalışma dizininde dosyayı indirin ve okuyun; indirme başarılı olmadan sonraki adıma geçmeyin:

curl -fL --proto '=https' --tlsv1.2 https://get.netdata.cloud/kickstart.sh -o netdata-kickstart.sh
less netdata-kickstart.sh

İnceleme ve kurulum planı tamamlandıktan sonra kararlı kanal için:

sudo sh ./netdata-kickstart.sh --release-channel stable

Kurucu uygun paket yolunu seçebilir ve varsayılan olarak otomatik güncelleme kurar; telemetri ve güncelleme seçeneklerini gereksiniminize göre resmî kılavuzdan seçin. Bu rehber Cloud hesabı bağlamaz ve kurulumun her VPS imajında sorunsuz çalışacağını varsaymaz.

Tek VPS için yerel erişim örneği: mevcut netdata.conf dosyasındaki [web] bölümüne bind to = 127.0.0.1:19999 ayarını işleyin ve hizmeti kontrollü yeniden başlatın. Aynı bölümü ikinci kez eklemeyin. Ardından kendi bilgisayarınızda ssh -N -L 127.0.0.1:19999:127.0.0.1:19999 user@vps.example.com ile tünel açıp http://127.0.0.1:19999 adresini kullanın; kullanıcı/host yer tutucularını değiştirin. VPS’in gerçek dinleme adresini ve dışarıdan erişim kısıtını test edin. VPN veya kimlik doğrulamalı TLS proxy alternatiftir; proxy arkasında da doğrudan 19999 erişimini kapalı tutun. Parent/Child streaming kurulumu ek özel ağ izinleri gerektirir.

Netdata’da görebileceğiniz temel paneller

Etkin collector’lar, izinler ve toplama aralığına bağlı olarak aşağıdaki grafikler görülebilir. Uygulama metrikleri gerekli plugin/collector ayarını ve sınırlı yetkili erişim bilgilerini isteyebilir; her kurulumda bütün paneller otomatik dolmaz.

• 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).

Varsayımsal bir WooCommerce kampanyasında CPU, sorgu sayısı ve disk I/O grafiklerinin aynı zaman dilimindeki değişimini karşılaştırabilirsiniz. Aynı anda yükselmeleri neden-sonuç ilişkisini kanıtlamaz; yavaş sorgu kaydı, istek gecikmesi ve zamanlanmış işleri eşleştirin. Böylece ekip, hangi değişikliğin deneneceğini ve başarının nasıl ölçüleceğini belirleyebilir.

Netdata ve Prometheus arasında nasıl seçim yapılır?

Netdata tek VPS’te başlayabilir; Parent/Child streaming ve replication ile birçok sunucunun metriklerini merkezileştirebilir. Yerel veritabanı retention ayarları geçmişi zaman ve boyut sınırlarıyla yönetir. Seçim yaparken şunları belirleyin:

• Kaç düğüm, hangi uygulamalar ve hangi collector’lar izlenecek?
• Hangi çözünürlükte ne kadar geçmiş saklanacak; disk/RAM maliyeti nedir?
• Hangi sorgular, alarmlar, bildirim kanalları ve ekip erişim kuralları gerekli?

Prometheus etiketli metrikler, PromQL ve exporter ekosistemiyle farklı bir kurulum seçeneğidir. Sadece düğüm sayısı veya uzun geçmiş ihtiyacı nedeniyle Netdata’dan zorunlu geçiş gerekmez. Birlikte kullanılabilirler; aynı metrikleri tekrar toplamanın maliyetini ölçün. Netdata Cloud özelliklerini seçilen güncel planla ayrıca doğrulayın.

Çoklu VPS ve Ölçekli Senaryolar: Prometheus ile Metrik Toplama

Birden fazla VPS, veritabanı, cache ve queue worker için ortak etiketlerle sorgulama istiyorsanız Prometheus + exporter mimarisini değerlendirebilirsiniz. Kurulumu; toplama, saklama, sorgulama ve bildirim sorumluluklarını ayırarak tasarlayın.

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.
• Alertmanager, yapılandırıldığında Prometheus alarmlarını gruplar ve bildirimlere yönlendirir.

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 işletim sistemi/donanım metriklerini sunar; uygulama loglarını toplamaz. Varsayılan portu 9100’dür. Hizmeti başlatmadan önce erişimi Prometheus sunucusuyla sınırlayın; uzak scrape için özel ağ veya uygun TLS/kimlik doğrulama kullanın. Etkin collector ve kernel desteğine göre 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:

• CPU ve load geçmişi: 30 gün isteniyorsa retention ve depolama bunu karşılamalıdır. Prometheus’ta zaman/boyut sınırı belirtilmezse varsayılan retention 15 gündür.
• Dosya sisteminde kullanılabilir alan, inode ve büyüme hızı; eşikleri iş yüküne göre seçin.
• Arayüz bazında trafik hızları ve hata artışları; sayaçları doğrudan hız gibi çizmeyin.

Alarm kuralları: Sorun çıkmadan uyarı almak

Alarm, ölçülebilir bir koşulu ve araştırma adımını anlatmalıdır. Aşağıdaki örnek, job="node" etiketli ve seçilmiş dosya sistemi türlerindeki yazılabilir mount’larda kullanılabilir alan oranı 15 dakika boyunca %15’in altında kalırsa uyarır. Tür listesini gerçek mount’larınıza göre uyarlayın; inode, read-only ve scrape başarısızlığı ayrı kontrollerdir.

groups:
  - name: vps-resources
    rules:
      - alert: NodeFilesystemLowAvailable
        expr: |
          (
            node_filesystem_avail_bytes{job="node",fstype=~"ext4|xfs|btrfs",mountpoint!=""}
            / node_filesystem_size_bytes{job="node",fstype=~"ext4|xfs|btrfs",mountpoint!=""}
          ) < 0.15
          and on (job, instance, device, mountpoint, fstype)
            node_filesystem_readonly{job="node"} == 0
          and on (job, instance, device, mountpoint, fstype)
            node_filesystem_size_bytes{job="node"} > 0
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: 'Available filesystem space below 15% on {{ $labels.instance }} {{ $labels.mountpoint }}'
      - alert: NodeScrapeFailed
        expr: up{job="node"} == 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'Node scrape failed for {{ $labels.instance }}'

Dosyayı vps-alerts.yml olarak kaydedip promtool check rules vps-alerts.yml ile denetleyin; ana Prometheus yapılandırmasındaki rule_files listesine ekleyip bütün yapılandırmayı ayrıca doğrulayın. Kontrollü testte pending, firing ve normale dönüşü, ardından bildirim teslimini kontrol edin. up == 0 başarısız scrape’i gösterir; hedef keşiften kaybolursa eksik hedef/seri denetimi de gerekir. CPU veya swap alarmı tek başına darboğaz/RAM yetersizliği ilan etmemelidir.

Prometheus’un Alertmanager bağlantısı ve uygun bildirim rotaları yapılandırıldığında alarmlar e-posta veya desteklenen mesaj kanallarına yönlendirilebilir. Teslimatı ve çözülme bildirimini ayrıca test edin. Daha gelişmiş senaryolar için Prometheus, Grafana ve Node Exporter ile uyarı kurma rehberimizi inceleyebilirsiniz.

Network ve TCP Seviyesinde Ekstra İpuçları

Ağ ve TCP metriklerini uygulama gecikmeleriyle birlikte izleyin. Ayar değiştirmeden önce hangi bağlantı aşamasında bekleme veya hata oluştuğunu belirlemek, geniş kapsamlı tuning yapmaktan daha anlamlıdır.

Bağlantı durumları ve TIME_WAIT

ss -s özet verir; ikinci komut TCP tablosunun yalnız ilk 20 satırını gösterir, toplam bağlantı sayısını hesaplamaz:

ss -s
ss -ant | head -n 20

TIME_WAIT TCP kapanışının normal bir durumudur; yüksek sayı tek başına arıza değildir. Kısa bağlantıların hızını, başarısız connect/accept çağrılarını ve gecikmeleri inceleyin. net.core.somaxconn listen backlog sınırıdır; net.ipv4.ip_local_port_range yerel port seçim aralığıdır. Bunlar TIME_WAIT için genel bir düzeltme değildir. Keep-alive veya port ayarını ancak ilgili darboğaz kanıtlandığında, staging testi ve geri dönüş planıyla değiştirin. 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 ve node_network_transmit_bytes_total biriken byte sayaçlarıdır. Örneğin rate(node_network_receive_bytes_total{job="node",device!="lo"}[5m]) arayüz başına byte/s verir. Gerçek fiziksel/sanal yolunuzu seçin; bütün arayüzleri toplamak aynı trafiği iki kez sayabilir.
• node_netstat_Tcp_CurrEstab, TCP MIB tanımına göre ESTABLISHED ve CLOSE_WAIT durumlarındaki bağlantıların anlık sayısıdır; TIME_WAIT’i veya tüm socket’leri kapsamaz.
• node_network_receive_errs_total hata sayacındaki artışı rate() veya increase() ile değerlendirin; geçmişten kalan pozitif toplam devam eden hata demek değildir.

Bu metrikler kampanya veya saldırı sırasında değişen yükü gösterir; tek başına DDoS ile organik trafiği ayıramaz. İstek türleri, kaynak dağılımı, uygulama logları ve ağ/güvenlik olaylarını birlikte inceleyin.

Metrikleri Operasyon Süreçlerine Bağlamak

Grafikleri karar süreçlerine bağlamak için normal ve yoğun dönemleri karşılaştırın. Kapasite veya mimari değerlendirmesinde şu sorular işe yarar:

• CPU baskısı veya uzun kuyruk, benzer trafik altında yanıt süresini etkiliyor mu?
• MemAvailable düşüşü, aktif swap, OOM veya bellek PSI artışı var mı?
• Disk/inode büyüme hızına göre müdahale için ne kadar süre kaldı?
• Ağ yoğunluğunda hata, yeniden deneme ve uygulama gecikmesi artıyor 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. Merkezi loglama yazma miktarını kendiliğinden azaltmaz; gereksiz log seviyesini, saklama süresini, aktarım kuyruklarını ve toplayıcı maliyetini ayrıca yönetin.

Sonuç ve Sonraki Adımlar

htop ve iotop süreçlerin o andaki davranışını, Netdata veya Prometheus ise yapılandırılmış geçmişi ve alarmları sağlar. İhtiyacınız olan bileşenleri seçin; hepsini birlikte kurmak zorunlu değildir. Metrikleri uygulama logları, istek gecikmesi ve kontrollü değişikliklerle ilişkilendirerek ölçümden karara ilerleyin.

Bir başlangıç planı; temel metrikler, test edilmiş alarmlar ve gerektiğinde merkezi loglama katmanlarından oluşabilir. Siz de VPS’inizde bu adımları uygulamaya başlarken, Prometheus ve Grafana başlangıç rehberimizden veya ileri uyarı senaryolarından yararlanabilirsiniz.

DCHost VPS seçeneklerini değerlendirirken işletim sistemi desteğini, erişim yetkilerini, kaynak limitlerini ve yönetilen hizmet kapsamını teklifinizde netleştirin. Destek talebi için zaman aralığı, etkilenen servis, grafikler ve hassas bilgilerden arındırılmış hata örnekleri hazırlayın. Ölçümlere dayalı plan büyütme veya mimari değişiklik kararında destek kapsamını ayrıca doğrulayın.

Resmî Kaynaklar

• Linux /proc: CPU and memory accounting
• Linux delay accounting
• Linux PSI
• htop: upstream manual
• iotop-c: upstream manual
• AlmaLinux: EPEL and CRB
• Ubuntu 24.04: iotop-c / Universe
• Netdata: Linux installation
• Netdata: web server configuration
• Netdata: streaming and replication
• Prometheus: alerting rules
• Prometheus: storage and retention
• Prometheus: rate and query functions