Apache Log Seviyesi Artırma: Debug Modu ile Hata Ayıklama

Bykomut

Bir Apache sunucusunda işler ters gitmeye başladığında, ilk içgüdün muhtemelen log dosyalarına bakmak olur. Ama bazen standart log seviyeleri sana yeterince bilgi vermez. “500 Internal Server Error” görürsün, error.log’a bakarsın, tek satır vardır, anlamsız gelir. İşte tam bu noktada Apache’nin log seviyesini artırmak, yani debug moduna geçmek hayat kurtarıcı olur. Bu yazıda Apache log seviyelerini detaylıca ele alacağız, debug modunu nasıl açacağını göstereceğiz ve gerçek dünya senaryolarında nasıl kullandığımızı paylaşacağız.

Apache Log Seviyeleri Nedir?

Apache, loglamayı RFC 5424 syslog standardına benzer bir hiyerarşiyle yönetir. Her seviye, bir öncekinden daha fazla detay içerir. Seviyeyi ne kadar aşağı çekersen, o kadar fazla log üretilir.

Seviyeler şu sıradadır (en kritikten en detaylıya doğru):

  • emerg: Sistem kullanılamaz durumda. Sunucu neredeyse hiç ayakta değil.
  • alert: Hemen müdahale gerektirir. Örneğin mutex dosyası oluşturulamıyor.
  • crit: Kritik hatalar. Örneğin child process başlatılamıyor.
  • error: Genel hatalar. İstekler işlenemiyor ama sunucu ayakta.
  • warn: Uyarılar. Bir şeyler yanlış gidiyor ama henüz kırılmadı.
  • notice: Normal ama kayda değer durumlar. Sunucu başlangıç/durdurma mesajları.
  • info: Genel bilgi mesajları. Hangi modülün yüklendiği gibi şeyler.
  • debug: Tüm detaylar. Geliştirici seviyesi bilgi.
  • trace1 – trace8: Aşırı detaylı izleme. Genellikle modül geliştiricileri için.

Varsayılan değer çoğu dağıtımda warn ya da error olarak gelir. Production ortamında bu mantıklıdır çünkü debug seviyesinde bir Apache, disk I/O’yu ciddi şekilde zorlayabilir.

Neden Debug Modu Açılır?

Şunu net söyleyeyim: debug modunu production’da sürekli açık bırakmak kötü bir fikirdir. Ama geçici olarak açmak için pek çok meşru sebep vardır:

  • Bir modülün neden yüklenemediğini anlamak istiyorsun
  • .htaccess kurallarının neden çalışmadığını araştırıyorsun
  • SSL/TLS handshake hatalarını debug ediyorsun
  • Rewrite kurallarının hangi adımda kırıldığını görmek istiyorsun
  • PHP veya Python WSGI gibi backend entegrasyonlarında 502/503 hatalarının kaynağını bulmak istiyorsun
  • Bir güvenlik modülünün (mod_security gibi) hangi kuralı tetiklediğini anlıyorsun

Log Seviyesini Değiştirme: Temel Yapılandırma

Apache’de log seviyesini değiştirmek için LogLevel direktifini kullanırsın. Bu direktif global konfigürasyona, VirtualHost bloğuna ya da Directory bloğuna eklenebilir.

Global Seviyede Değiştirme

Ubuntu/Debian tabanlı sistemlerde ana konfigürasyon dosyası genellikle /etc/apache2/apache2.conf yolundadır. CentOS/RHEL’de ise /etc/httpd/conf/httpd.conf.

# /etc/apache2/apache2.conf veya /etc/httpd/conf/httpd.conf içinde
LogLevel debug

Değişikliği yaptıktan sonra konfigürasyonu test et ve Apache’yi yeniden yükle:

# Konfigürasyon testi
sudo apachectl configtest

# Yeniden yükleme (sıfırlama değil, graceful reload)
sudo systemctl reload apache2
# veya CentOS/RHEL için
sudo systemctl reload httpd

VirtualHost Seviyesinde Değiştirme

Bu daha akıllıca bir yaklaşım. Tüm sunucuyu değil, sadece sorunlu VirtualHost’u debug moduna alırsın:

<VirtualHost *:443>
    ServerName uygulama.example.com
    DocumentRoot /var/www/uygulama

    # Sadece bu VirtualHost için debug modu
    LogLevel debug

    ErrorLog ${APACHE_LOG_DIR}/uygulama-error.log
    CustomLog ${APACHE_LOG_DIR}/uygulama-access.log combined
</VirtualHost>

Modül Bazında Log Seviyesi

Apache 2.3.6’dan itibaren harika bir özellik geldi: modül bazında log seviyesi ayarlayabiliyorsun. Yani rewrite modülünü debug’larken tüm sunucuyu debug seviyesine çekmek zorunda kalmıyorsun:

# Sadece mod_rewrite için debug, geri kalanı warn seviyesinde kalsın
LogLevel warn rewrite:debug

# Birden fazla modül için
LogLevel warn rewrite:debug ssl:info proxy:debug

# VirtualHost içinde de kullanılabilir
<VirtualHost *:80>
    ServerName test.example.com
    LogLevel warn rewrite:trace3
    ErrorLog ${APACHE_LOG_DIR}/test-error.log
</VirtualHost>

Bu özellik gerçekten çok değerli. Production’da tek bir modülü izole ederek debug yapabiliyorsun.

Gerçek Dünya Senaryosu 1: mod_rewrite Hata Ayıklama

Diyelim ki bir Laravel ya da WordPress sitesinde URL yeniden yazma kuralları çalışmıyor. Kullanıcılar 404 alıyor ama dosyalar yerli yerinde. Klasik bir senaryo.

Önce rewrite modülü için trace seviyesini aç:

# VirtualHost konfigürasyonuna ekle
LogLevel warn rewrite:trace2

Sonra birkaç istek yap ve log’a bak:

# Gerçek zamanlı log takibi
sudo tail -f /var/log/apache2/error.log | grep -i rewrite

# Sadece son 100 satır
sudo tail -100 /var/log/apache2/error.log

trace2 ile göreceğin çıktı şuna benzer:

[rewrite:trace2] [pid 12345] mod_rewrite.c(475): [client 192.168.1.10:54321]
init rewrite engine with requested uri /blog/2024/makale-basligi
[rewrite:trace3] [pid 12345] mod_rewrite.c(475): [client 192.168.1.10:54321]
applying pattern '^index.php$' to uri 'blog/2024/makale-basligi'

Bu çıktıdan hangi pattern’in uygulandığını, hangisinin eşleştiğini veya eşleşmediğini net görürsün. “Ah, RewriteBase /blog/ olması gerekiyormuş” gibi şeyleri bu sayede anlarsın.

Gerçek Dünya Senaryosu 2: SSL/TLS Sorunları

SSL sertifika sorunları debug etmek için ssl modülünü trace seviyesine çekmek gerekebilir:

# SSL modülü için detaylı loglama
LogLevel warn ssl:trace4

Ardından SSL hatalarını izle:

# SSL ile ilgili tüm hataları filtrele
sudo tail -f /var/log/apache2/error.log | grep -i ssl

# Belirli bir client IP'den gelen SSL hatalarını gör
sudo grep "192.168.1.50" /var/log/apache2/error.log | grep -i "ssl|tls|handshake"

Bir handshake hatası şöyle görünür debug modunda:

[ssl:debug] [pid 8901] ssl_engine_kernel.c(2235): [client 10.0.0.5:44312]
SSL library error 1 in handshake (server uygulama.example.com:443)
[ssl:info] [pid 8901] ssl_engine_kernel.c(2244): [client 10.0.0.5:44312]
SSL handshake failed: HTTP spoken on HTTPS port; trying to send HTML error page

Bu çıktı bize HTTP üzerinden HTTPS portuna bağlanılmaya çalışıldığını söylüyor. Load balancer’ın HTTP trafiğini yanlış porta yönlendirdiği durumlarda sıkça görülür.

Gerçek Dünya Senaryosu 3: Proxy ve Backend Hataları

Apache’yi reverse proxy olarak kullanıyorsan ve backend servislerle iletişim sorunları yaşıyorsan:

<VirtualHost *:80>
    ServerName api.example.com
    
    # Proxy debug modu
    LogLevel warn proxy:debug proxy_http:trace2
    
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/
    
    ErrorLog ${APACHE_LOG_DIR}/api-proxy-error.log
</VirtualHost>

Debug çıktısında şunu görürsün:

[proxy:debug] [pid 15234] proxy_util.c(2221): AH00942: CONNECT: will connect to localhost:8080
[proxy_http:trace2] [pid 15234] mod_proxy_http.c(2446): AH01411: Expect header
[proxy:error] [pid 15234] proxy_util.c(2222): AH00957: HTTP: attempt to connect to
127.0.0.1:8080 (localhost) failed

Backend’in gerçekten o portu dinleyip dinlemediğini hemen anlarsın.

Log Dosyalarını Efektif Analiz Etme

Debug modunda Apache log’ları çok hızlı büyür. Doğru araçları kullanmak kritik.

# Belirli bir zaman aralığındaki hataları filtrele
sudo awk '/[Thu Dec 28 14:00/,/[Thu Dec 28 14:30/' /var/log/apache2/error.log

# Hata türlerine göre gruplama ve sayma
sudo grep "[error]" /var/log/apache2/error.log | 
  awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# Belirli bir client IP'nin tüm aktivitesini çek
sudo grep "client 192.168.1.100" /var/log/apache2/error.log | 
  grep -v "notice|info" | tail -50

# Gerçek zamanlı hata takibi, gürültüyü filtrele
sudo tail -f /var/log/apache2/error.log | 
  grep -v "notice|AH00491|AH00094"

Log Rotation ile Çakışma Sorunu

Debug modunda logrotate ayarlarını da gözden geçirmelisin. Varsayılan günlük rotation, debug seviyesinde yetersiz kalabilir:

# /etc/logrotate.d/apache2 dosyasını kontrol et
sudo cat /etc/logrotate.d/apache2

# Manuel olarak log rotate tetikle (disk doluysa)
sudo logrotate -f /etc/logrotate.d/apache2

# Log boyutunu anlık izle
watch -n 5 'ls -lh /var/log/apache2/'

trace Seviyelerini Kullanma

trace1’den trace8’e kadar çok detaylı izleme seçenekleri var. Bunlar genellikle modül geliştiricilerine yönelik ama bazı durumlarda gerçekten işe yarıyor.

# mod_rewrite için maksimum detay (dikkatli kullan)
LogLevel warn rewrite:trace8

# Sadece belirli bir istek için trace yapmak istiyorsan
# mod_log_debug ile birlikte kullanılabilir
<If "%{REQUEST_URI} =~ /sorunlu-endpoint/">
    LogLevel debug
</If>

bloğu ile koşullu loglama harika bir teknik. Sadece belirli bir URL’ye gelen istekleri debug seviyesinde logla, diğerlerine dokunma.

Geçici Debug için Alternatif Yaklaşım

Konfigürasyon dosyasını değiştirmeden geçici olarak log seviyesini değiştirmenin bir yolu yok maalesef. Ama şu workflow ile işi hızlandırabilirsin:

#!/bin/bash
# apache-debug-toggle.sh - Apache debug modunu geçici aç/kapat

CONFIG="/etc/apache2/apache2.conf"
BACKUP="/tmp/apache2.conf.backup.$(date +%Y%m%d_%H%M%S)"

enable_debug() {
    echo "Debug modu aktiflesiriliyor..."
    cp "$CONFIG" "$BACKUP"
    sed -i 's/^LogLevel .*/LogLevel debug/' "$CONFIG"
    apachectl configtest && systemctl reload apache2
    echo "Debug aktif. Backup: $BACKUP"
    echo "Log takibi: tail -f /var/log/apache2/error.log"
}

disable_debug() {
    if [ -f "$1" ]; then
        echo "Orijinal konfigurasyon geri yukleniyor..."
        cp "$1" "$CONFIG"
        apachectl configtest && systemctl reload apache2
        echo "Debug kapatildi."
    else
        echo "Backup dosyasi belirt: $0 disable /tmp/apache2.conf.backup.XXXX"
    fi
}

case "$1" in
    enable) enable_debug ;;
    disable) disable_debug "$2" ;;
    *) echo "Kullanim: $0 enable | disable <backup_dosyasi>" ;;
esac

Disk Dolmasını Önleme

Debug modunda en büyük tehlike disk dolmasıdır. Bunu önlemek için birkaç önlem al:

# Debug açılmadan önce mevcut log boyutunu not et
du -sh /var/log/apache2/

# Disk kullanımını izle (debug açıkken)
watch -n 10 'df -h /var/log && ls -lh /var/log/apache2/'

# Log boyutu belirli bir eşiği geçince uyar
while true; do
    LOG_SIZE=$(du -sm /var/log/apache2/error.log | cut -f1)
    if [ "$LOG_SIZE" -gt 500 ]; then
        echo "UYARI: error.log 500MB'yi gecti! Debug modunu kapat." | 
          mail -s "Apache Log Uyarisi" [email protected]
        break
    fi
    sleep 60
done

Ayrıca debug session’ı için ayrı bir log dosyası kullanabilirsin:

# VirtualHost'a ekle
ErrorLog /tmp/apache-debug-session.log
LogLevel debug
# İşin bitince bu dosyayı sil, normal loga dön

Koşullu ve Seçici Loglama

Apache 2.4 ile gelen mod_log_debug modülü, log mesajlarını isteğin herhangi bir aşamasında ve koşullu olarak yazmana izin veriyor:

# mod_log_debug'ı etkinleştir
sudo a2enmod log_debug

# Konfigürasyona ekle
<VirtualHost *:80>
    ServerName debug.example.com
    
    # Sadece POST isteklerini debug et
    <If "%{REQUEST_METHOD} == 'POST'">
        LogLevel debug
        LogMessage "POST isteği alındı: %{REQUEST_URI}e"
    </If>
    
    # Belirli bir User-Agent için debug
    <If "%{HTTP_USER_AGENT} =~ /Sorunlu-Client/">
        LogLevel debug
        LogMessage "Sorunlu client baglandi: %{REMOTE_ADDR}e"
    </If>
</VirtualHost>

Bu yaklaşım production’da bile belirli koşullar altında debug yapmanı mümkün kılar, disk ve performans etkisi çok daha az olur.

Performans Etkisini Ölçme

Debug modunun performansa etkisini görmek için Apache’nin kendi benchmark aracını kullanabilirsin:

# Normal modda baseline al
ab -n 1000 -c 10 http://localhost/ > /tmp/benchmark-normal.txt

# Debug moduna geç (LogLevel debug)
sudo sed -i 's/^LogLevel.*/LogLevel debug/' /etc/apache2/apache2.conf
sudo systemctl reload apache2

# Debug modunda test
ab -n 1000 -c 10 http://localhost/ > /tmp/benchmark-debug.txt

# Karşılaştır
echo "=== Normal ===" && grep "Requests per second" /tmp/benchmark-normal.txt
echo "=== Debug ===" && grep "Requests per second" /tmp/benchmark-debug.txt

Tipik olarak debug modunda %20-40 performans düşüşü görürsün. Disk I/O’nun yavaş olduğu sistemlerde bu oran daha da yükselebilir.

Sık Karşılaşılan Tuzaklar

Debug modunu kullanırken birkaç şeye dikkat etmek gerekiyor:

  • Hassas veri loglanabilir: Debug seviyesinde HTTP header’ları, authentication token’ları ve hatta bazı durumlarda POST body verileri log’a yazılabilir. Log dosyalarının izinlerini kontrol et.
  • AH kodlarını tanı: Apache’nin AH ile başlayan hata kodları var. Bunları şu şekilde araştırabilirsin: grep "AH02003" /var/log/apache2/error.log sonra bu kodu Apache dokümantasyonunda ara.
  • Child process PID’leri: Debug loglarında her satırda farklı PID görürsün. Bu child process’ler, Apache’nin worker modeli gereği. PID’e takılma, asıl mesaja odaklan.
  • Zaman damgaları: Logları analiz ederken sunucu saatinin doğru olduğundan emin ol. NTP senkronizasyonu kritik, özellikle log korelasyonu yapıyorsan.
# Sunucu saatini kontrol et
timedatectl status

# Log'daki zaman damgasını system time ile karşılaştır
date && sudo tail -1 /var/log/apache2/error.log

Sonuç

Apache log seviyesini artırmak, “kara kutu” hissini tamamen ortadan kaldıran güçlü bir araç. Ama bir o kadar da dikkatli kullanılması gereken bir araç. Temel prensipleri özetlemek gerekirse:

Debug modunu geçici olarak aç, işin bitince mutlaka kapat. Mümkünse modül bazında log seviyesi ayarla, tüm sunucuyu etkileme. bloklarıyla koşullu loglama yap, özellikle production ortamında. Debug sırasında disk kullanımını izle ve bir alarm mekanizması kur. Log dosyalarına erişimi kısıtla, hassas veri içerebilir.

Bir sonraki sefer Apache’de gizemli bir hata aldığında, paniklemek yerine önce hangi modülün sorun çıkardığını tahmin et, sadece o modülü debug’a al ve logları metodikçe analiz et. Çoğu zaman cevap, o küçük debug satırının içinde gizlidir.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir