Netdata ile Nginx ve Apache Metriklerini İzleme

Sunucunuzda Nginx veya Apache çalıştırıyorsanız ve web trafiğinizin nasıl aktığını, hangi noktada darboğaz oluştuğunu anlamak istiyorsanız, Netdata bu konuda gerçekten işinizi görecek bir araç. Kurulumu basit, görselleştirmesi anlık ve web sunucusu entegrasyonları için hazır gelir. Bu yazıda Netdata’yı Nginx ve Apache ile nasıl entegre edeceğinizi, hangi metriklere bakmanız gerektiğini ve gerçek hayatta karşılaşılan senaryolarda bu verileri nasıl yorumlayacağınızı adım adım anlatacağım.

Netdata Neden Web Sunucusu İzleme için Uygun?

Pek çok izleme aracı web sunucusu metriklerini toplamak için ayrıca exporter kurmayı, Prometheus yapılandırması yapmayı ya da özel script yazmayı gerektiriyor. Netdata bu konuda farklı bir yaklaşım sunuyor: kurulumla birlikte gelen auto-detection mekanizması sayesinde Nginx veya Apache’nin çalıştığını algılayıp ilgili eklentiyi otomatik olarak devreye alıyor.

Netdata’nın web sunucusu izleme açısından öne çıkan özellikleri şunlar:

• Saniye bazlı metrik toplama: RPS (request per second), aktif bağlantı sayısı ve yanıt süreleri anlık olarak izleniyor
• Sıfır yapılandırmayla başlangıç: Çoğu standart kurulumda herhangi bir ek ayar yapmadan çalışıyor
• Alarm entegrasyonu: Eşik değerleri aşıldığında otomatik bildirim gönderebiliyor
• Düşük kaynak tüketimi: İzleme aracının kendisi sunucunuzu yavaşlatmamalı, Netdata bu konuda oldukça tutumlu

Ön Gereksinimler

Başlamadan önce şunların hazır olduğundan emin olun:

• Netdata kurulu ve çalışır durumda (eğer kurulu değilse aşağıdaki komutla hızlıca kurabilirsiniz)
• Nginx veya Apache web sunucusu aktif
• status modülü her iki sunucu için de etkinleştirilmiş olmalı (bunu aşağıda ayrıca ele alacağız)

Netdata kurulu değilse tek satırlık resmi script ile kurabilirsiniz:

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh
sh /tmp/netdata-kickstart.sh

Kurulum tamamlandıktan sonra Netdata http://sunucu-ip:19999 adresinde erişilebilir hale gelir.

Nginx için Durum Sayfası Yapılandırması

Netdata’nın Nginx metriklerini toplayabilmesi için ngx_http_stub_status_module modülünün aktif olması ve bir durum endpoint’inin tanımlanmış olması gerekiyor. Öncelikle modülün mevcut kurulumda derlenip derlenmediğini kontrol edelim:

nginx -V 2>&1 | grep -o with-http_stub_status_module

Eğer bu komut with-http_stub_status_module çıktısı veriyorsa hazırsınız. Çıktı boş geliyorsa Nginx’i bu modülle yeniden derlemeniz ya da paket yöneticinizden bu modülü içeren sürümü kurmanız gerekiyor.

Modül mevcutsa Nginx yapılandırmanıza aşağıdaki location bloğunu ekleyin. Genellikle bunu ayrı bir status.conf dosyası olarak /etc/nginx/conf.d/ altına koymak düzenli bir yol:

server {
    listen 127.0.0.1:80;
    server_name localhost;

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

Yapılandırmayı test edip yeniden yükleyin:

nginx -t && systemctl reload nginx

Endpoint’in çalıştığını doğrulamak için:

curl http://127.0.0.1/nginx_status

Aşağıdakine benzer bir çıktı görmelisiniz:

Active connections: 43
server accepts handled requests
 1523 1523 4891
Reading: 0 Writing: 5 Waiting: 38

Bu çıktı Netdata’nın okuyacağı ham veri. Şimdi bu verilerin ne anlama geldiğini kısaca açıklayalım:

• Active connections: Şu anda açık olan toplam bağlantı sayısı
• accepts: Kabul edilen toplam bağlantı sayısı (sunucu başlatıldığından beri)
• handled: Başarıyla işlenen bağlantı sayısı
• requests: İşlenen toplam HTTP istek sayısı
• Reading: Nginx’in istek header’ını okuduğu bağlantı sayısı
• Writing: Nginx’in istemciye yanıt yazdığı bağlantı sayısı
• Waiting: Keep-alive bağlantılarını bekleyen bağlantı sayısı (idle)

Apache için mod_status Aktivasyonu

Apache tarafında Netdata, mod_status modülünü ve ExtendedStatus direktifini kullanıyor. Öncelikle modülün etkin olup olmadığını kontrol edelim:

# Debian/Ubuntu
apache2ctl -M | grep status

# RHEL/CentOS
httpd -M | grep status

status_module (shared) veya status_module (static) çıktısı görüyorsanız modül aktif. Değilse etkinleştirin:

# Debian/Ubuntu
a2enmod status
systemctl restart apache2

Şimdi Apache yapılandırmasına status endpoint’ini ekleyin. /etc/apache2/mods-enabled/status.conf dosyasını düzenleyin ya da oluşturun:

<Location "/server-status">
    SetHandler server-status
    Require ip 127.0.0.1
    Require ip ::1
</Location>

ExtendedStatus On

Apache’yi yeniden yükleyin ve test edin:

systemctl reload apache2
curl http://127.0.0.1/server-status?auto

?auto parametresi machine-readable çıktı veriyor, Netdata bu formatı tercih ediyor. Çıktı şuna benzer görünmeli:

Total Accesses: 28492
Total kBytes: 89234
Uptime: 3621
ReqPerSec: 7.87
BytesPerSec: 25241.8
BytesPerReq: 3207.44
BusyWorkers: 12
IdleWorkers: 88

Netdata Kolektörlerini Yapılandırma

Netdata çoğu durumda Nginx ve Apache’yi otomatik algılar. Ancak standart dışı bir port veya yol kullanıyorsanız ya da otomatik algılama çalışmıyorsa manuel yapılandırma yapmanız gerekebilir.

Nginx Kolektörü

Netdata’nın Nginx kolektör yapılandırma dosyası şu konumda bulunur:

/etc/netdata/go.d/nginx.conf

Bu dosya yoksa varsayılan kopyayı oluşturun:

cd /etc/netdata
./edit-config go.d/nginx.conf

Temel yapılandırma şu şekilde:

jobs:
  - name: local
    url: http://127.0.0.1/nginx_status

  - name: production_nginx
    url: http://127.0.0.1:8080/nginx_status
    timeout: 5

Birden fazla Nginx instance izliyorsanız birden fazla job tanımı ekleyebilirsiniz. Örneğin hem 80 hem de 8080 portunda çalışan iki ayrı Nginx’i izlemek istiyorsanız iki ayrı job bloğu yazmanız yeterli.

Apache Kolektörü

Apache için benzer şekilde:

./edit-config go.d/apache.conf

jobs:
  - name: local
    url: http://127.0.0.1/server-status?auto

  - name: apache_ssl
    url: https://127.0.0.1:443/server-status?auto
    tls_skip_verify: yes

Yapılandırma değişikliklerini uygulamak için Netdata’yı yeniden başlatın:

systemctl restart netdata

Kolektörlerin düzgün çalışıp çalışmadığını kontrol etmek için Netdata loglarına bakın:

tail -f /var/log/netdata/error.log | grep -E "nginx|apache"

Netdata Dashboard’unda Nginx Metriklerini Okumak

Netdata arayüzünde sol menüde Nginx bölümünü açtığınızda birkaç farklı grafik görürsünüz. Bu grafikleri doğru okumak performans sorunlarını erken yakalamak için kritik.

Connections by Status

Bu grafik aktif bağlantıları durumlarına göre gösterir. Burada dikkat etmeniz gereken noktalar:

• Waiting (Keep-Alive) değerinin çok yüksek olması: Keep-alive timeout değerinizin çok uzun ayarlandığının işareti olabilir. Bağlantılar bekleme modunda dosya tanımlayıcısı tüketiyor
• Reading değerinin sürekli yüksek seyretmesi: İstemcilerin yavaş bağlantı üzerinden gelmesi ya da büyük header’lar göndermesi anlamına gelebilir
• Writing değerinin ani artışları: Genellikle büyük dosya transferleri veya yoğun istek trafiğinin işareti

Requests/s Grafiği

Saniyedeki istek sayısı en temel metriklerden biri. Bu değerin ani düşmesi (trafik normalken) backend sorunlarına, ani artışı ise DDoS veya viral içerik senaryolarına işaret edebilir.

Gerçek Dünya Senaryosu: Ani Trafik Artışı

Diyelim ki bir e-ticaret sitesi yönetiyorsunuz ve kampanya saatinde Nginx requests/s grafiğinde normal değerin 10 katı artış gördünüz. Aynı anda connections grafiğinde writing değeri de yükseldi ama waiting değeri düştü. Bu, sunucunun aktif olarak yanıt verdiğini, yani tıkanmadığını gösteriyor. Eğer waiting değeri de aşırı yükselseydi ve requests/s düşseydi bu bir upstream tıkanması yaşandığının işareti olurdu.

Apache Metriklerini Dashboard’da Yorumlamak

Apache’nin mod_status ile sağladığı veriler Nginx’e kıyasla çok daha zengin. Netdata bu verileri birkaç farklı panel altında sunar.

Workers

Apache’nin worker modeli (prefork, worker, event) kullandığınıza göre bu grafik kritik önem taşıyor. BusyWorkers değerinin sürekli MaxRequestWorkers değerine yakın seyretmesi şu anlama geliyor: Apache yeni bağlantıları kabul etmekte zorlanıyor, bağlantılar kuyrukta bekliyor.

Bu durumu test etmek için:

# Anlık worker durumunu göster
curl -s http://127.0.0.1/server-status | grep -E "BusyWorkers|IdleWorkers|requests currently"

Eğer IdleWorkers sürekli 0 veya 1’e düşüyorsa MaxRequestWorkers değerini artırmanın zamanı gelmiş demektir. Ancak bunu körü körüne yapmak yerine önce bellek durumuna bakın:

# Mevcut Apache process'lerinin bellek kullanımını kontrol et
ps aux | grep apache2 | awk '{sum += $6} END {print "Toplam RSS: " sum/1024 " MB"}'

Requests/s ve Bytes/s

Apache için requests/s ve bytes/s grafiklerini birlikte izlemek önemli. Eğer requests/s düşükken bytes/s yüksekse büyük dosya indirme trafiği söz konusudur, bu normal. Ama requests/s yüksekken bytes/s beklenenden düşükse çok sayıda küçük hatalı istek (404, 400 gibi) geliyor olabilir.

Gerçek Dünya Senaryosu: Yavaşlayan Apache

Bir müşterinizden “site yavaşladı” şikayeti geldiğinde Netdata’da şu sırayla bakın:

Önce Apache workers grafiğine bakın. BusyWorkers yüksekse sorun Apache kapasitesinde. Düşükse sorun backend’de (PHP-FPM, veritabanı gibi).

Sonra bytes/s grafiğine bakın. Yüksekse sunucu yanıt veriyor ama yavaş. Düşükse bağlantılar kurulmadan düşüyor olabilir.

Son olarak Apache access loglarına bakarak 5xx hata oranını kontrol edin:

tail -n 10000 /var/log/apache2/access.log | awk '{print $9}' | sort | uniq -c | sort -rn | head -20

Netdata Alarmları Oluşturma

Metrikleri izlemek yetmez; kritik eşikler aşıldığında bildirim almanız gerekiyor. Netdata’nın alarm sistemi bu konuda oldukça esnek.

Nginx için özel alarm eklemek istiyorsanız /etc/netdata/health.d/ dizinine yeni bir dosya oluşturun:

vim /etc/netdata/health.d/nginx_custom.conf

 alarm: nginx_active_connections_high
    on: nginx.connections_state
lookup: average -5m unaligned of active
 units: connections
 every: 1m
  warn: $this > 500
  crit: $this > 1000
  info: Nginx aktif baglanti sayisi yuksek
    to: sysadmin

 alarm: nginx_requests_spike
    on: nginx.requests_total
lookup: average -2m unaligned
 units: requests/s
 every: 30s
  warn: $this > 1000
  crit: $this > 5000
  info: Nginx saniyedeki istek sayisi anormalde yuksek
    to: sysadmin

Apache için de benzer şekilde:

vim /etc/netdata/health.d/apache_custom.conf

 alarm: apache_busy_workers_high
    on: apache.workers
lookup: average -5m unaligned of busy
 units: workers
 every: 1m
  warn: $this > 80
  crit: $this > 95
  info: Apache busy worker sayisi maksimuma yaklasıyor
    to: sysadmin

Alarmları oluşturduktan sonra Netdata’yı yeniden yükleyin:

systemctl reload netdata

Alarm durumunu kontrol etmek için:

netdatacli alarms 2>/dev/null | grep -E "nginx|apache"

Birden Fazla Sunucuyu Merkezi Olarak İzleme

Tek sunucu için yukarıdaki kurulum yeterli. Ama 10-20 web sunucusu çalıştırıyorsanız her birine ayrı ayrı giriş yapmak yerine Netdata’nın Parent-Child mimarisini kullanabilirsiniz.

Child sunucularda (web sunucularınız) netdata.conf dosyasına şunu ekleyin:

vim /etc/netdata/netdata.conf

[stream]
    enabled = yes
    destination = parent-sunucu-ip:19999
    api key = BURAYA-GUVENLI-BIR-UUID-GIRIN

UUID oluşturmak için:

cat /proc/sys/kernel/random/uuid

Parent sunucuda ise stream alımını etkinleştirin:

vim /etc/netdata/stream.conf

[BURAYA-CHILD-UUID]
    enabled = yes
    default history = 3600
    default memory mode = dbengine
    health enabled by default = auto
    allow from = *

Bu yapılandırmayla tüm web sunucularınızın Nginx ve Apache metriklerini tek bir Netdata arayüzünden izleyebilirsiniz. Dashboard’da her sunucu ayrı bağlam altında listelenir ve karşılaştırmalı grafik çizimi yapabilirsiniz.

Log Tabanlı Analiz ile Netdata’yı Tamamlamak

Netdata metrik bazlı izleme yapıyor ama bazen ham loglara da bakmanız gerekiyor. Özellikle hata oranı yükseldiğinde hangi URL’lerin, hangi IP’lerin sorun çıkardığını anlamak için şu araçları birlikte kullanın:

Nginx için hızlı hata analizi:

# Son 1 saatin 5xx hatalarını listele
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H')" '$4 > "["d && $9 ~ /^5/' /var/log/nginx/access.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn

# En çok istek atan IP'leri bul
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Apache için:

# Yavaş istekleri bul (eğer %D format string'i log formatınızdaysa)
awk '{print $NF, $7}' /var/log/apache2/access.log | sort -rn | head -20

Netdata’da “requests/s aniden yükseldi” alarmı gördükten hemen sonra bu komutları çalıştırarak hangi kaynaktan geldiğini anlayabilirsiniz.

Performans Ayarlama: Metriklerden Aksiyon Almak

İzleme tek başına bir amaç değil, aksiyona geçmek için araç. Netdata’da gördüğünüz metriklerden nasıl aksiyon alacağınıza dair birkaç pratik ipucu:

Yüksek Waiting (Keep-Alive) bağlantıları için Nginx’te:

keepalive_timeout 15;
keepalive_requests 100;

Bu değerleri düşürmek, boşta bekleyen bağlantı sayısını azaltır ve dosya tanımlayıcısı tüketimini kontrol altına alır.

Apache’de sürekli yüksek BusyWorkers için:

/etc/apache2/mods-enabled/mpm_event.conf dosyasını düzenleyin:

<IfModule mpm_event_module>
    StartServers             2
    MinSpareThreads         25
    MaxSpareThreads         75
    ThreadLimit             64
    ThreadsPerChild         25
    MaxRequestWorkers      200
    MaxConnectionsPerChild   0
</IfModule>

Bu değerleri değiştirdikten sonra Netdata’da workers grafiğini izleyerek BusyWorkers oranının düştüğünü ve IdleWorkers’ın makul bir değerde kaldığını doğrulayın. Bu, değişikliğin etkisini gerçek zamanlı görmek için mükemmel bir yöntem.

Rate limit senaryosu: Netdata’da requests/s grafiğinde tek bir IP’den gelen yük artışı yaşıyorsanız Nginx’e hızlıca rate limit ekleyebilirsiniz:

http {
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=30r/m;

    server {
        location / {
            limit_req zone=req_limit burst=10 nodelay;
        }
    }
}

Rate limit aktif olduktan sonra Netdata’da requests/s’nin düştüğünü ve bağlantı sayısının normalize olduğunu gözlemleyebilirsiniz.

Sonuç

Netdata, Nginx ve Apache için hazır gelen kolektörleri ve saniye bazlı veri toplama kapasitesiyle web sunucusu izleme konusunda ciddi bir kolaylık sunuyor. Kurulum basit, yapılandırma minimal ve görselleştirme anlık. Daha da önemlisi, “site yavaşladı” ya da “sunucu cevap vermiyor” gibi muğlak şikayetleri somut sayılara dönüştürüp köke inmek için gereken tüm veriyi önünüze seriyor.

Bu yazıda anlattıklarımı özetlemek gerekirse:

• Nginx için stub_status, Apache için mod_status modüllerini mutlaka aktif edin
• Netdata kolektörlerini yapılandırın ve otomatik algılamanın çalıştığını doğrulayın
• Workers, connections ve requests/s metriklerini birlikte okuyun; tek bir metriğe bakmak yanıltıcı olabilir
• Kritik eşikler için özel alarm kuralları yazın
• Birden fazla sunucu yönetiyorsanız Parent-Child mimarisine geçin
• Metrikten aldığınız sinyali log analizi ile destekleyin ve ardından yapılandırma değişikliğiyle kapayın

İzleme kültürünün en temel kuralı şu: bir şey ölçülmüyorsa iyileştirilemiyor. Netdata bu ölçümü mümkün olan en düşük maliyetle yapmanızı sağlıyor.