Performans İzleme Araçları Karşılaştırması

Performans izleme araçları listesi arayan çoğu kişi aslında yanlış soruyu soruyor. Doğru soru "hangi araç en iyi" değil, "benim şu anki sorunum hangi katmanda ve o katmanı hangi tür araç ölçer" sorusudur. Çünkü bir hız testi sitesi sana veritabanı kilitlenmesini asla göstermez, bir sunucu izleme paneli de kullanıcının telefonunda düzen kaymasından haberdar olmaz. İki farklı araç, iki farklı gerçeği ölçer ve birbirinin yerine geçmez.

Bu yazıda araçları tek tek övmek yerine önce dört izleme katmanını ayıracağım: sentetik test, gerçek kullanıcı ölçümü, altyapı izleme ve uygulama içi izleme. Her katmanda öne çıkan araçları gerçek güçlü ve zayıf yanlarıyla karşılaştıracağım, sonra da ölçeğe göre üç hazır kurulum seti önereceğim. Amacım sana bir favori satmak değil; hangi boşluğu neyle kapatacağını netleştirmek.

Dört İzleme Katmanı#

Bir web sisteminde ölçebileceğin her şey kabaca dört kutuya girer. Bu ayrımı içselleştirirsen araç seçimi kendiliğinden çözülür.

Bu dördüne bir de "uptime izleme" eklenir ama o aslında sentetik testin en sade hâlidir: düzenli aralıklarla dışarıdan bir istek atıp cevabı ve süresini kaydeder. Küçük bir sitede çoğu zaman ilk kuracağın ve uzun süre tek başına yeteceği araç budur.

Katmanların birbirini nasıl tamamladığını görmek için tipik bir senaryoyu düşün: RUM verisinde mobil kullanıcıların LCP'si bozuluyor, sentetik test bunu ana sayfada doğruluyor, altyapı izleme o saatlerde disk beklemesinin tırmandığını gösteriyor, APM ise yavaşlığın belirli bir sorguda toplandığını söylüyor. Dördü olmadan bu zinciri kuramazsın. Katmanları teşhis sırasına oturtmak için yavaş site teşhis akışı yazısındaki eleme mantığını kullan.

Sentetik Test Araçları#

Sentetik araçlar bir adresi verirsin, belirli bir konumdan açıp rapor üretirler. En büyük değerleri tekrarlanabilir olmalarıdır: aynı testi deploy öncesi ve sonrası çalıştırıp farkı görebilirsin.

PageSpeed Insights hem laboratuvar (Lighthouse) hem saha (CrUX) verisini bir arada gösterdiği için ilk bakılacak yerdir. Saha bölümü gerçek kullanıcı verisidir ama yalnızca yeterli trafiği olan siteler için doldurulur; küçük sitelerde o bölüm boş kalır ve elinde sadece laboratuvar puanı olur. Puanın kendisine takılma, altındaki metrik değerlerine bak.

Lighthouse aynı motoru yerel olarak çalıştırmanı sağlar. Komut satırından kullanabilmesi onu otomasyona sokmanın en pratik yoludur:

# Lighthouse'u komut satırından çalıştır ve JSON rapor üret
npx lighthouse https://firmaniz.com/ \
  --only-categories=performance \
  --output=json --output-path=./rapor.json \
  --chrome-flags="--headless --no-sandbox"

# Sadece LCP değerini çek
cat rapor.json | grep -o '"largest-contentful-paint".\{0,200\}' | head -1

WebPageTest en ayrıntılı sonucu verir: gerçek cihazlarda, seçtiğin konumdan, birden fazla tekrarla ve tam şelale (waterfall) grafiğiyle. İlk yüklemeyi ve tekrar yüklemeyi ayrı raporlaması, önbelleğinin gerçekten çalışıp çalışmadığını gösteren en dürüst testtir.

GTmetrix okunması kolay raporları ve tarihsel grafikleriyle özellikle WordPress tarafında yaygındır. Ücretsiz katmanında test konumu ve tekrar sayısı sınırlıdır; ölçümü hep aynı konumdan yapmaya dikkat et, yoksa grafiğindeki dalgalanma siteden değil test konumundan gelir. Bu aracı WordPress bağlamında adım adım kullanmak için GTmetrix WordPress hız testi yazısına bakabilirsin.

Uptime ve Yanıt Süresi İzleyicileri#

Bu araçlar belirli aralıklarla sitene istek atar, HTTP kodunu ve yanıt süresini kaydeder, bozulunca haber verir. Kurulumu en kolay, karşılığı en yüksek izleme türüdür; hiçbir şey yapmayacaksan bile bunu yap.

Dikkat edilmesi gereken üç ayar vardır. Kontrol sıklığı: 5 dakika çoğu site için yeterlidir, 1 dakika kritik sistemler içindir. Kontrol konumu: tek konumdan gelen bir hata, senin sitenin değil o konumun sorunu olabilir; çok konumlu doğrulama yapan servisleri tercih et. Kontrol edilen adres: ana sayfa yerine gerçekten veritabanına dokunan bir sağlık ucu kontrol et, yoksa önbellekten dönen statik bir sayfa her şey çökmüşken bile 200 döner.

Basit bir sağlık ucu şöyle görünebilir ve ana sayfadan çok daha bilgilendiricidir:

<?php
// /saglik.php - veritabanına ve önbelleğe gerçekten dokunur
header("Content-Type: text/plain");
$baslangic = microtime(true);
try {
    $pdo = new PDO("mysql:host=127.0.0.1;dbname=uygulama", $kullanici, $sifre);
    $pdo->query("SELECT 1")->fetch();
    $sure = round((microtime(true) - $baslangic) * 1000);
    http_response_code(200);
    echo "ok db_ms=" . $sure;
} catch (Throwable $e) {
    http_response_code(503);
    echo "hata";
}

Kendi izlemeni kurmak istersen dış servise bağımlı kalmadan da bunu yapabilirsin; yöntemi sunucu yanıt süresi izleme yazısında curl ve zamanlanmış görevlerle adım adım anlattım.

Altyapı ve Sunucu İzleme Araçları#

Bu katman CPU, RAM, disk, ağ, süreç ve servis metriklerini toplar. Yavaşlığın nedenini bulmanın anahtarı genelde buradadır, çünkü sentetik test sana yalnızca sonucu gösterir.

Netdata kurulumu en hızlı olanıdır; tek komutla kurulur, saniyelik çözünürlükte yüzlerce metriği otomatik keşfeder ve hemen kullanılabilir bir arayüz sunar. Zayıf yanı uzun süreli saklama ve çok sunuculu merkezî yönetimdir; tek sunucuda mükemmel, otuz sunucuda zorlanır.

Zabbix klasik ve olgun bir çözümdür. Ajan tabanlı çalışır, güçlü bir alarm motoru ve envanter yönetimi vardır. Karşılığında kurulum ve şablon yapılandırması ciddi zaman ister; küçük bir site için fazla ağırdır.

Prometheus + Grafana bugünün fiili standardıdır. Prometheus metrikleri toplar ve sorgulanabilir bir zaman serisi veritabanında tutar, Grafana çizer. Sunucu metrikleri için node_exporter, dış prob için blackbox_exporter kullanılır. Esnekliği yüksek, öğrenme eğrisi ortadır.

# prometheus.yml - sunucu metrikleri ve dış HTTP probu
scrape_configs:
  - job_name: 'sunucular'
    static_configs:
      - targets: ['185.12.34.56:9100']   # node_exporter

  - job_name: 'site-probu'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://firmaniz.com/
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: 127.0.0.1:9115      # blackbox_exporter

Munin eski ama hâlâ işlevseldir; kaynak tüketimi düşüktür ve beş dakikalık çözünürlükle uzun vadeli trend için yeterlidir. Ani dalgalanmaları kaçırır.

Bu araçlardan hangisini kurarsan kur, ilk bakacağın grafik yük ortalaması olacaktır; onu doğru yorumlamak için load average nasıl okunur yazısındaki çekirdek sayısına bölme ve iowait ayrımı kuralını uygula.

APM ve Log Tabanlı Analiz#

APM (Application Performance Monitoring) araçları uygulamanın içine girer: hangi istek hangi fonksiyonda ne kadar zaman harcadı, hangi sorgu kaç kez çalıştı, hangi harici API çağrısı bekletti. Ticari APM ürünleri güçlüdür ama maliyetlidir ve genelde her isteğe bir miktar ek yük bindirirler.

Bütçe kısıtlıysa APM'in yüzde seksenini ücretsiz araçlarla kurabilirsin. PHP tarafında yavaş istek günlüğü, hangi dosyanın hangi satırında takıldığını doğrudan yazar. Veritabanı tarafında yavaş sorgu günlüğü ve pt-query-digest benzeri özetleyiciler, en pahalı sorguları sıralar. Web sunucusu günlüklerinden ise istek süresi dağılımını çıkarabilirsin:

# nginx access.log'da yanıt süresi son alan ise: en yavaş 20 istek
awk '{print $NF, $7}' /var/log/nginx/access.log \
  | sort -rn | head -20

# Yol bazında ortalama süre - en pahalı uç noktaları bulur
awk '{topla[$7]+=$NF; adet[$7]++} END {for (y in topla) printf "%.3f  %6d  %s\n", topla[y]/adet[y], adet[y], y}' \
  /var/log/nginx/access.log | sort -rn | head -20

GoAccess aynı günlükleri gerçek zamanlı bir panoya çevirir ve tek komutla çalışır; trafik kaynaklarını, durum kodu dağılımını ve en çok istenen yolları görmek için hızlı bir seçenektir. Bot trafiğinin yükünü ayırmak istiyorsan bu analiz seni doğrudan sonuca götürür; ayrıntısı için bot trafiği sunucu yükünü nasıl artırır yazısına bak.

Ölçeğe Göre Üç Hazır Set#

Araçları tek tek değerlendirmek yerine kendini şu üç profilden birine yerleştir ve o setle başla.

1. Tek siteli, paylaşımlı hosting. Bir uptime izleyici (5 dakikalık kontrol), ayda bir PageSpeed Insights kontrolü ve hosting panelindeki kaynak kullanım grafikleri. Ek yazılım kurmana gerek yok; sunucuya erişimin zaten sınırlıdır.
2. Tek VDS, birkaç site. Uptime izleyici, Netdata, nginx günlüklerinden haftalık awk özeti, PHP yavaş istek günlüğü ve MySQL yavaş sorgu günlüğü. Bu set toplam bir saatte kurulur ve sorunların büyük çoğunluğunu yakalar.
3. Birden fazla sunucu, ekip çalışması. Prometheus + Grafana + Alertmanager, node_exporter ve blackbox_exporter, merkezî günlük toplama ve kendi kurduğun RUM toplayıcı. Burada kritik olan alarm kurallarının sahibinin belli olmasıdır; sahipsiz alarm kısa sürede görmezden gelinir.

Hangi sette olursan ol, RUM tarafını atlama. Sentetik ve altyapı araçları sana sistemin durumunu söyler ama kullanıcının ne yaşadığını söylemez; o boşluğu RUM gerçek kullanıcı ölçümü yazısındaki basit toplayıcıyla kapatabilirsin.

Sık Yapılan Hatalar#

Her şeyi ölçüp hiçbirine alarm bağlamamak. Üç yüz grafik içeren bir pano, kimse bakmadığı sürece dekoratiftir. Önce beş kritik metriğe alarm kur, panoyu sonra genişlet.

Alarm eşiklerini çok hassas ayarlamak. Günde otuz kez tetiklenen bir alarm iki hafta içinde sessize alınır ve gerçek olay kaçırılır. Eşiği, gerçekten müdahale gerektiren seviyeye koy ve süre koşulu ekle: "5 dakika boyunca" gibi.

İzleme aracını izlenen sunucuya kurmak. Sunucu tamamen çökerse üzerindeki izleme de çöker ve hiç haber alamazsın. Dış prob mutlaka başka bir yerden gelmelidir.

Tek bir konumdan test edip genelleme yapmak. Sunucuna 20 ms uzaklıktaki bir test noktası, kullanıcılarının çoğu başka bir kıtadaysa yanlış bir güven verir.

Ölçüm maliyetini göz ardı etmek. Saniyelik çözünürlükte yüzlerce metrik toplayan bir ajan, küçük bir sunucuda kayda değer CPU ve disk tüketir. İzlemenin kendisi de bir yüktür; ölçtüğün sistemin kapasitesine göre çözünürlük seç.

Sıkça Sorulan Sorular#

Hangi performans izleme aracı en iyisi#

Tek bir "en iyi" yoktur çünkü araçlar farklı katmanları ölçer. Sunucunun kaynak durumunu Netdata ya da Prometheus, kullanıcı deneyimini RUM, sayfa yapısını Lighthouse veya WebPageTest, erişilebilirliği ise bir uptime izleyici ölçer. Doğru soru "hangisi en iyi" değil, "şu an hangi katmanda körüm" sorusudur; o boşluğu kapatan araç senin için en iyisidir.

Ücretsiz araçlar yeterli olur mu#

Küçük ve orta ölçekli sitelerin neredeyse tamamı için evet. Netdata, Prometheus, Grafana, GoAccess, Lighthouse ve WebPageTest'in ücretsiz katmanı ciddi bir izleme altyapısı kurar. Ücretli ürünlerin asıl kattığı şey özellik değil, zamandır: hazır panolar, otomatik enstrümantasyon, uzun süreli saklama ve destek. Ekip büyüdükçe bu zaman tasarrufu lisans bedelinden daha değerli hâle gelir.

Ne sıklıkta performans testi yapmalıyım#

Sentetik testi düzenli değil, olaya bağlı çalıştır: her önemli deploy sonrası, tema veya eklenti değişikliğinde ve ayda bir genel kontrol için. Sürekli çalışması gereken şey sentetik test değil, uptime ve yanıt süresi izlemesidir; onu 1–5 dakikalık aralıkla kesintisiz çalıştır. RUM ise doğası gereği zaten sürekli veri toplar.

İzleme aracı sunucumu yavaşlatır mı#

Doğru yapılandırıldığında etkisi ihmal edilebilir düzeydedir; tipik bir metrik ajanı işlemcinin yüzde birinden azını kullanır. Sorun çözünürlüğü aşırıya kaçırdığında başlar: saniyelik örnekleme, yüzlerce özel kontrol ve sık disk yazımı küçük bir sunucuda hissedilir. Küçük makinelerde 10–15 saniyelik örnekleme aralığı hem yeterli ayrıntıyı verir hem de yükü düşük tutar.

Uptime izleme için ana sayfayı mı kontrol etmeliyim#

Hayır, tercihen veritabanına ve kritik bağımlılıklara dokunan ayrı bir sağlık ucu oluştur. Ana sayfa çoğu kurulumda tam önbelleklidir ve veritabanı tamamen çökmüşken bile 200 döner; bu durumda izlemen sana "her şey yolunda" der. Sağlık ucunu ayrıca arama motorlarından gizle ve içinde hassas bilgi döndürme.

Grafana ile Netdata birlikte kullanılabilir mi#

Evet ve yaygın bir kombinasyondur. Netdata'yı yerel, yüksek çözünürlüklü teşhis aracı olarak tutup metriklerini Prometheus'a aktarabilir, uzun vadeli saklama ve merkezî panoları Grafana üzerinden yönetebilirsin. Böylece bir olay anında Netdata'nın saniyelik ayrıntısına, trend analizinde ise Grafana'nın aylık grafiklerine bakarsın.

Kapanış#

Araç seçimini basitleştiren şey, araçları değil katmanları öğrenmektir. Aklında kalması gereken dört alışkanlık şu: önce hangi katmanda kör olduğunu belirle, uptime izlemeyi her koşulda kur çünkü karşılığı en yüksek olan odur, topladığın her kritik metriğe gerçekten müdahale gerektiren bir eşik bağla ve dış probu izlenen sunucunun dışında çalıştır. Bunları yaptıktan sonra hangi markayı seçtiğin ikinci derece bir ayrıntı hâline gelir.

İzleme kurulumu için tam kontrol gerekiyorsa, kendi ajanlarını ve prob sunucunu kurabileceğin VDS veya bulut sunucu paketlerimiz uygun bir zemin sunar. Kurulumu ve alarm kurallarını bizim üstlenmemizi istersen sunucu yönetimi hizmetimiz izleme yığınını baştan sona yapılandırır. Sunucu tarafıyla hiç uğraşmadan hızlı bir başlangıç istiyorsan web hosting paketlerimizde temel kaynak grafikleri panelde hazır gelir.